クラウドデータベース 比較解説まとめ

  • このエントリーをはてなブックマークに追加

最終更新



クラウドのリレーショナル・データベースサービス Amazon RDS、Azure SQL Database、Google Cloud SQL について、機能・料金・管理面などの比較をしてみます。

  • 2019/06/21、Amazon RDS にて Aurora 以外にも容量自動拡張機能が追加されました。詳細
  • 019/04/26、Amazon RDS の 1時間単位の課金が秒単位 (ただし最低利用10分) になったことを追記
  • 2019/04/10、DBバージョン・CPU・メモリ等を最新化。Azure SQL Database の「読み取りスケールアウト」の説明を追記 (追加コストなし!)

目次

リレーショナル・データベースとは

リレーショナル・データベース (RDBMS) とは、表形式でデータを保存でき、 SQL などの言語によってデータの取得・集計・加工が行えるものです。

クラウド以前より、下記のような RDBMS が存在していました。

  • Oracle Database
  • MySQL
  • PostgreSQL
  • Microsoft SQL Server
  • IBM DB2
  • SAP Sybase

クラウドでのリレーショナル・データベースエンジン

2000年台後半より、リレーショナル・データベースエンジンをクラウドサービスに乗せる動きが進んでいます。クラウドサービス上でリレーショナル・データベースエンジンを動かすメリットは下記です。

  • インストール不要で簡単構築
  • 管理画面操作ですぐに使える
  • 使った分だけ課金
  • スケールアップ・スケールダウンを行える
  • バックアップの自動化
  • 冗長構成を簡単に組める
  • パッチ当て不要
  • ライセンス購入不要
  • ストレージ拡張が容易
  • ハードウェア障害対応不要

構築やメンテナンスの手間を省けるというメリットが非常に大きいと考えます。法人・商用サービスだけではなく、小規模な個人利用であってもぜひ利用を検討してみてください。

クラウドサービスとしてリレーショナル・データベースを動かすことを DBaaS (データベース・アズ・ア・サービス) と呼びます。Amazon・Microsoft・Google 各社が提供する DBaaS のサービス名称は下記のとおりです。

  • Amazon Relational Database Service (RDS)
  • Azure SQL Database (このページでは Azure Database for MySQL、Azure Database for PostgreSQL、Azure Database for MariaDB も含めて説明します)
  • Google Cloud SQL


各サービス比較表

Amazon RDS・Azure SQL Database・Google Cloud SQL についての DBaaS の機能比較表は以下のとおりです。細かな解説はのちほど。

この場所には ↓ にある表が自動的にしゅっとまとめられるはずですが、この文章が見えているということは Javascript がうまく動いていないということなので、その場合は教えてもらえるとありがたいです。

比較表はここまでです。以下、詳細説明です。

管理画面からの操作

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
管理画面から簡単操作で DB 構築

まずは当然の話ではあるのですが、 管理画面でポチポチと操作するだけでデータベースが構築できますよという点。ソースからビルドしたり、パッケージインストールしたり、 my.cnf いじったり、ということはやらなくてもいいんですよ、ということです。

レプリケーション (耐障害性) について

自前で DB レプリケーションを行うのはめんどくさい! まさにこういうところで DBaaS を使って楽することにしましょう。レプリケーションの目的は耐障害性向上・負荷分散がありますが、 まずは耐障害性向上から。

レプリケーション について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
レプリケーション◯ (Multi-AZ 設定可)◯ (常に3重化)◯ (フェイルオーバーレプリカ作成可能)

Amazon RDS では、シングル構成にするか、Multi-AZ 構成にするかを選択できます。Multi-AZ にすると、「同じリージョンかつ異なるアベイラビリティゾーン」に、 スレーブのインスタンスが用意され、データが同期され続けます。もしマスタに異常が発生した場合、スレーブに切り替わります。Multi-AZ を有効にした場合、インスタンスの料金は 2倍となります。

Azure SQL Database の場合、SQL Database を作成すると、 自動的にそのリージョンにてデータの 3重化が行われます。これは自動的に行われ、機能を OFF にすることはできません。また、フェイルオーバーも内部で自動的に行われます。内部的にはマスター・スレーブがあるのでしょうが、 外部からそれぞれの状況を知ることはできません。スレーブに接続することもできません。3重化は Azure 内部で行われていることなので、 3重化だから料金は 3倍です、ということはありません。

Google Cloud SQL の場合、 フェイルオーバーレプリカというものを作成できます。Amazon RDS でいう Multi-AZ と同じようなものと考えてよいです。

Amazon・Azure・GCP いずれも、目指しているのは下記です。「マスタで障害が発生した場合、アプリケーション側で何もしなくても、 少し (1〜2分) 待てばデータベースが復旧する」

Amazon RDS では Multi-AZ を有効にしないと SLA 対象となりません。Google Cloud SQL もフェイルオーバーレプリカを有効にしないと SLA 対象になりません。金額が倍になるのは痛いですが、あきらめましょう。

レプリカの個数 について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
レプリカの個数0個または1個常に3重化0個または1個

Amazon RDS では Multi-AZ を有効にするかしないか、のみ選択可能ですので、 個数は 0個または1個です。「Multi-AZ をさらに追加」ということはできません。

Azure SQL Database は、内部的に3重化です。外部から確認や設定変更は一切できません。

Google Cloud SQL は Amazon RDS と同様に、フェイルオーバーレプリカを作るか作らないかですので、 0個または1個です。

レプリカのリージョン について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
レプリカのリージョンマスタと同じリージョンマスタと同じリージョンマスタと同じリージョン

Amazon RDS・Google Cloud SQL いずれも、レプリカはマスタと同じリージョンかつ、 異なるゾーンに配置します。Azure SQL Database は、内部的に3重化しており、外部から設定や確認は一切できませんが、 よい感じに配置してあるはずです。

レプリカのインスタンスサイズ指定 について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
レプリカのインスタンスサイズ指定不可不可不可 (正確にはマスタ以上)

これは「マスタは Standard だけど、レプリカは Small にして費用を節約することができるか」 という意味で書きましたが、残念ながらできないようです。

上記レプリケーションへの通常時アクセス について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
上記レプリケーションへの通常時アクセス不可不可不可?

「レプリケーションは障害発生に備えたものであることはわかるけど、 障害が発生していないときはもったいないから、負荷分散にも使えないの?」 という意味で書きました。

Amazon RDS・Azure SQL Database ではそのような使い方はできません (レプリカに別 IP アドレスが振られていないので、通常時は接続できない)。(★Azure 読み取りスケールアウトでできる旨要追記)

Google Cloud SQL は、少なくとも別 IP アドレスが振られているのでもしかしたらできるかも… (★できるっぽい。要追記)

手動フェイルオーバー について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
手動フェイルオーバー不可

Amazon RDS と Google Cloud SQL のみ、手動フェイルオーバーが可能です。そもそもレプリケーションもフェイルオーバーも DBaaS の責任範囲ですので、 動作確認という意味はあまりありません。しかしながら何分くらいでサービス正常性が戻るのか確認しておくのはよいことだと思います。

メモ: CloudSQLの自動フェイルオーバーはマスターインスタンス障害時には発火しない 要調査 → 最新版では問題ないように見える

マルチマスタ について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
マルチマスタAurora で可不可不可

要追記。



レプリケーション (負荷分散) について

続いては、負荷分散のためのレプリケーションです。

リードレプリカ について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
リードレプリカ◯ (任意リージョン、5個まで) ◯ SQL Database (2019/3 読み取りスケールアウト GA。また、アクティブgeo レプリケーションでも実現可能かも)

○ MySQL・PostgreSQL・MariaDB

リードレプリカとは、「マスタ→レプリカのレプリケーション設定をした上で、レプリカを読み取り専用とする」 というやり方です。

Amazon RDS・Azure SQL Database・Google Cloud SQL いずれもリードレプリカに対応しています。

Amazon RDS では、1つのマスタについて最大 5個のリードレプリカを作成できます。

Azure SQL Database では、 Premium と Business Critical サービスレベルのみですが、「読み取りスケールアウト」という機能が 2019/3 より使用可能となりました。SQL Database では自動的にレプリケーションが行われ3重化されますが、通常は 1つのインスタンスのみに接続します。残り 2つのインスタンスにリードオンリーで接続することで負荷分散を実現するというのが「読み取りスケールアウト」です。メリットは無料であること。もともと3重化されているものに接続しにいくので、お金がかからないわけですね。

Google Cloud SQL ではリードレプリカの制限はなく、「インスタンス上限40個」内であればいくつでも作れるようです (とりあえず 12個までは確認済)。

なお、読み取りのみの場合はレプリカを参照、更新が必要な場合はマスタに更新します。

任意リージョンへのリードレプリカ作成 について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
任意リージョンへのリードレプリカ作成?×

「任意リージョンへのリードレプリカ作成」は、例えば「マスタ DB が日本にあるときに、 リードレプリカを米国などに作成できるか」です。Amazon RDS ではどのリージョンでも選択可能でした。Google Cloud SQL では、リードレプリカのリージョンは、マスタと同じリージョン固定でした。どうしてなんでしょうね。

リードレプリカでの低インスタンスサイズ について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
リードレプリカでの低インスタンスサイズ.△ (MySQLでは可、PodtgreSQLでは不可)

「リードレプリカでの低インスタンスサイズ」は、「マスタは Standard だけど、レプリカは Small にして費用を節約することができるか」という意味ですが、Amazon RDS は可能です。

Google Cloud SQL では、MySQL は可能ですが、PostgreSQL では元のDB以上の CPU・メモリが必要です。

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
リードレプリカからのバックアップMySQL/MariaDBなら可。PostgreSQL は不可.不可
機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
リードレプリカへの更新MySQL/MariaDBなら可。PostgreSQL は不可.不可
機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
レプリケーション無効化/再開..
機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
外部へのリードレプリカ作成××◯?

外部をマスタとしたリードレプリカ について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
外部をマスタとしたリードレプリカ○ (少なくとも MySQL, MariaDB は可) ○ SQL Database (SQL Data Sync でできそう)
MySQL・PostgreSQL・MariaDB は調査中
◯ (2018/7 対応 MySQL のみ)

オンプレミスや、他クラウドサービスにマスタ DB を置いて、 クラウドサービス上の DBaaS をレプリケーションできるか、について。これが実現できると、オンプレミスの準リアルタイムバックアップや、 オンプレミス → クラウド DBaaS の移行が簡単になります。

Google Cloud SQL では、2018/7 より外部 MySQL をマスタとし、 Google Cloud SQL の MySQL をスレーブとする設定が可能となりました。

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
リードレプリカからの昇格.○ (レプリカのプロモート)


対応DB・対応バージョン

対応DB

下記はそれぞれのクラウドサービスが対応している RDBMS の比較表です。Amazon RDS の歴史が長いだけあって、対応している種類が多いですね。

Amazon RDSAzure DatabaseGoogle Cloud SQL
MySQL◯ (2018/04 GA)
MariaDB○ (2018/12 GA)
Amazon Aurora
PostgreSQL◯ (2018/04 GA)○ (2018/04 GA)
SQL Server△ (2019年内予定)
Oracle× (VM を使う方法はある)× (VM を使う方法はある)

MySQL は有名なオープンソースの RDBMS です。AWS・Azure・GCP いずれも利用可能です。

MariaDB は MySQL から分岐したオープンソース RDBMS です。MySQL AB 社がサン・マイクロシステムズに買収され、 その後サン・マイクロシステムズがオラクル社に買収された際、「Oracle Database で稼いでいるオラクル社が MySQL をつぶすのではないか」 と懸念する声があがり、MySQL 創始者が自ら MariaDB を立ち上げたもの。AWS・Azure で利用可能です。

Amazon Aurora は、Amazon が開発した高性能 DB で、「オーロラ」と読みます。Amazon 曰く、MySQL の 5倍、PostgreSQL の 3倍速いとのこと (本当かどうかは知らない)。2018/8 にサーバレス版の Aurora Serverless がリリースされました。さらに Aurora Multi Master (2019/5 現在、プレビュー) が控えており、まだまだ進化しそうです。Aurora が使えるのは AWS のみです。

PostgreSQL も MySQL に並び立つオープンソース RDBMS です。AWS・Azure・GCP いずれも利用可能です。

SQL Server は、マイクロソフト製の DB で、クラウド以前の 1990年代から存在します。Azure では DBaaS サービスとして「SQL Database」が利用可能です。これは SQL Server をベースとして開発された、Azure 上で動作する SQL Server 互換のサービスです (SQL Database と SQL Server は完全に機能が同じなわけではない)。また、Amazon RDS でも SQL Server が選択可能です。GCP においては 2019/4 に「Cloud SQL for Microsoft SQL Server」が発表されましたが、2019年中にサービス開始予定とのことです。

SQL Server on Virtual Machines とは

さらに Azure には Azure の Virtual Machine 上で動作する SQL Server として “SQL Server on Virtual Machines” というものもあります (実体としては SQL Server 入りの VM イメージ)。オンプレミスでの SQL Server の挙動に限りなく近づけたい場合は、SQL Database ではなく SQL Server on Virtual Machines を使うとよいでしょう。

Oracle は、いわずと知れた Oracle Database です。一時期は AWS や Azure で比較的安価に利用できたのですが、近年は Oracle 社が自ら立ち上げた Oracle Cloud にシフトを進めています。

対応バージョン

Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
MySQL バージョン5.5、5.6、5.7、8.0 (マイナーバージョンまで指定可)
5.6.39、5.7.21
5.5、5.6、5.7
MariaDB バージョン10.0、10.1、10.2、10.310.2.17
PostgreSQL バージョン9.3、9.4、9.5、9.6、10.1、10.3、10.4、10.5、10.6、11 (プレビュー)
※マイナーバージョンまで指定可

9.5.14、9.6.10、10.5
9.6、11.1 (beta 2019/4追加)
SQL Server/SQL Database バージョンSQL Server 2008 R2, 2012, 2014, 2016, 2017v12
Oracle バージョン11g リリース2、12c

Amazon RDS のみ、マイナーバージョンまで指定できます。2019/4 現在、MySQL の場合は下記を選択可能です。

  • MySQL 8.0.11
  • MySQL 5.7.23~5.7.16
  • MySQL 5.6.41~5.6.34
  • MySQL 5.5.61~5.5.46

Azure や GCP では、5.5、5.6、5.7 といったメジャーバージョンまでの指定となります。

特徴ふたつめ。Amazon RDS では、マイナーバージョンの自動バージョンアップを有効にするか否かを設定することができます。Azure や GCP では、強制的に自動バージョンアップがなされます。

メジャーバージョンアップ

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
メジャーバージョンアップグレードMySQL: 管理画面操作で可能、その他は調査中SQL Database: 調査中、MySQL/PostgreSQL: 不可MySQL/PostgreSQL: 手動。移行ツール提供予定あり。12ヵ月経過すると強制自動更新。

マイナーバージョンアップ

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
マイナーバージョンアップグレード自動 または しない を選択可(おそらく) 強制強制

複数 DB 統合管理

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
複数DB統合管理× ◯ SQL Database (Elastic Pool)
MySQL・PostgreSQL・MariaDB は調査中 
×

Azure SQL Database には Elastic Pool (エラスティックプール) という機能があります。これは、データベースそれぞれでインスタンスを立てるのではなく、 全体としてある程度のリソースを購入し、その中で複数のデータベースを動かすイメージです。

例えば、

  • フロント用 DB … 日中帯に負荷が高まるが、夜間・早朝は負荷が低い
  • バックエンド用 DB … 夜間・早朝のバッチ動作時に負荷が高まるが、日中帯は負荷が低い

などのように、異なる負荷特性を持つデータベースが複数ある場合や、

  • 10個のデータベースがあり、それぞれ突発的に負荷が高まることがあるが、それ以外のほとんどは負荷が低い場合

というケースにて役立つでしょう。



料金・課金・コスト

料金 について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
料金 (東京・1時間あたり・2019/4調査)0.026USD (MySQL)
0.026USD (MariaDB)
0.028USD (PostgreSQL)
0.031USD (SQL Server)
0.041USD (Oracle)
0.063USD (Aurora)
0.85円 (SQL Database)
5.8円 (MySQL, MariaDB, PostgreSQL)

0.0195USD (MySQL, PostgreSQL)
※さらに継続利用割引あり

すごく比較が難しいのですが、

  • Amazon RDS は、Multi-AZ だと 2倍
  • Google Cloud SQL は、フェイルオーバーレプリカだと 2倍
  • Azure SQL Database はデフォルト 3重化なので Multi-AZ・フェイルオーバーレプリカ相当の料金は「込み」といえる。
  • Amazon RDS は、リザーブドインスタンスにすれば安くなる
  • Google Cloud SQL は、継続利用割引があるので 1ヶ月使い続ければ 30% OFF

という前提で、 「MySQL や PostgreSQL で、1ヶ月間使い続ける、リザーブドインスタンスはやらない」 という条件とすると、GCP は Amazon RDS の約半額になるのではと思います。

なお、ストレージ料金について比較をしようとしてまとめたメモを下記に貼っておく (東京リージョン前提)。

[AWS]
 Aurora
  ストレージ料金 0.12USD GB あたり/月
  I/O 料金 0.24USD/100 万件のリクエスト
 MySQL・MariaDB・PostgeSQL・SQL Server・Oracle
  汎用(SSD)
   シングルAZ: 0.138USD GB あたり/月
   Multi-AZ: 0.276USD GB あたり/月
  プロビジョンド IOPS(SSD)ストレージ
   シングルAZ
    ・ストレージ料金 0.15USD GB あたり/月
    ・プロビジョンド IOPS レート 0.12USD IOPS あたり/月
   Multi-AZ
    ・マルチ AZ ストレージ料金 0.30USD GB あたり/月
    ・マルチ AZ プロビジョンド IOPS レート 0.24USD IOPS あたり/月
  Magnetic ストレージ
   シングルAZ
    ・ストレージ料金 0.24USD GB あたり/月
    ・I/O 料金 0.12USD/100 万件のリクエスト
   マルチAZ
    ・ストレージ料金 0.12USD GB あたり/月
    ・I/O 料金 0.12USD/100 万件のリクエスト
[Azure]
 付属ストレージ分はいくらなのか計算できない
 超過ストレージ (プレビュー。プレビュー期間なので半額かもしれない)
  Standard: \0.0119/時間 (≒8.568円 GB あたり/月)
  Premium および Premium RS: \0.0237/時間 (≒17.064円 GB あたり/月)
[GCP]
 $0.22 per GB/month for SSD storage capacity
 $0.12 per GB/month for HDD storage capacity
 $0.10 per GB/month for backups (used)

なお、この他にネットワーク料金やバックアップストレージ料金の考慮も必要。

課金単位時間 について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
課金単位時間1秒 (最低利用10分)1時間1分

Amazon RDS は 1秒単位の課金ですが、最低利用として 10分の課金がありますので、5分使ったら 10分、15分使ったら 15分の課金です。

以前は 1時間単位の課金でした

2019/04/25 より前は Amazon RDS は 1時間単位の課金でしたが、 2019/04/25 に1秒単位に変更となりました。アナウンスはこちら

Azure SQL Database は 1時間です。5分間だけ触ったとしても請求は 1時間分です。

GCP の Cloud SQL は 1分単位です。

インスタンス停止時の課金 について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
インスタンス停止○ (一部制限あり)× (停止できない)○ (一部制限あり)

開発環境や検証環境など、「たまにしかデータベースを使わない」「夜間土日は一切使わない」 というケースもあると思います。そのような場合、コスト削減のためにデータベースを停止したくなるでしょう。停止が可能な場合と、停止できない場合がありますので以下説明します。

Amazon RDS は停止が可能ではあるものの、 「SQL Server かつ Multi-AZ の場合は停止できない」 「リードレプリカが存在すると停止できない」 「SQL Server ミラーリングを使用している場合は停止できない」 という制限事項があります。また、停止できるのは最大7日で、7日を経過すると自動的に起動してしまいます。

ちなみに Amazon RDS の停止機能の変遷は以下のとおりです。

  • 2009年のリリース時点では停止機能なし
  • 2017/6 に停止機能が実装されたが、Multi-AZ は停止不可
  • 2018/10 に Multi-AZ の停止機能を実装 (SQL Server 以外)

Azure SQL Database には、2017/12 現在も「停止」機能が実装されていません。大変よろしくないことと感じます。

GCP Cloud SQL は停止機能があります。ただし、「レプリカが存在する状況でマスタの停止はできない」 「リードレプリカやフェイルオーバーレプリカの停止はできない」ようです。中途半端な状態で停止するくらいなら削除しなさい、ということでしょうか。なお、停止したまま90日が経過すると自動削除されることに注意です。

なお、Amazon RDS・Cloud SQL とも「停止」するとインスタンス分の課金はされませんが、 「データ保持」のためのストレージ料金は必要ですのでご注意を。

課金単位 について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
課金単位インスタンスデータベースインスタンス

Amazon RDS・GCP Cloud SQL の課金単位は「インスタンス」です。例えば Amazon RDS では「db.m4.large」インスタンスを 1つだけ作り、 その中で “CREATE DATABASE” 的なことを行うことで、 1インスタンス内にデータベースを複数持つことができます。

一方、Azure SQL Database の課金単位は「データベース」です。”CREATE DATABSAE” 的なもので DB を 2個作ると、2個分の費用がかかります。(注: 2018/3 頃、SQL Database Managed Instance というサービスが始まり、 インスタンス単位での管理も選択可能となりました。要詳細追記)

無料枠について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
無料枠12ヶ月間、db.t2.micro インスタンスでの MySQL, PostgreSQL, MariaDB, Oracle BYOL, SQL Server の Single-AZ 750時間/月、SSD ストレージ 20GB12ヶ月間、SQL Database S0 (10DTU, ストレージ250GB)12ヶ月間、$300 のクレジット

Amazon RDS では、サービス利用開始から 12ヶ月間、

  • db.t2.micro インスタンスでの MySQL, PostgreSQL, MariaDB, Oracle BYOL, SQL Server の Single-AZ 750時間/月
  • SSD ストレージ 20GB

が無料となっています。31日×24時間=744時間ですので、毎月 RDS を起動し続けておくことができます。なお、Aurora は無料枠対象ではありません。Oracle は BYOL (ライセンス持ち込み) のみです。

Azure Database では、サービス利用開始から 12ヶ月間、 S0 というインスタンスが無料で使えます。これは SSD 250GB を含みます。なお、S0 を複数個使ったらすべて無料になるかは明記されていませんが、誰か試してみてください。なお、対象は Azure Database のみであり、Azure Database for MySQL・Azure Database for PostgreSQL・Azure Database for MariaDB は対象外のようです。

GCP では Cloud SQL の無料枠というものはありませんが、12ヶ月有効な $300 のクレジットで実質無料使用ができます。

Amazon・Azure・GCP いずれのデータベースサービスも、12ヶ月を超えた場合の無料枠はないようです。

無料枠についてのさらなる情報は こちら

インスタンスサイズについて

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
インスタンスサイズを変更できる
CPUvCPU: 1〜128
※対応DBに注意
記載なし共用〜64
メモリ1GB〜3,904GB
※対応DBに注意
記載なし0.6GB〜416GB
CPU/メモリ カスタマイズ××△ PostgreSQL は可能 (MySQL は不可)

Amazon・Azure・GCP とも、 自由にインスタンスサイズを選択することができ、後から変更することが可能です Amazon RDS・GCP はあらかじめ用意されているインスタンスサイズから選択する方式ですが、 なぜか Google Cloud SQL for PostgreSQL のみ、CPU とメモリの量を指定可能でした。Cloud SQL + MySQL でもそのうち指定可能になるんでしょうか。

Amazon RDS の vCPU 最大 128、メモリ最大 3,904GB は立派なものですが、対応 DB に注意が必要です。この vCPU・メモリに対応しているのは Oracle のみで、例えば MySQL・MariaDB・PostgreSQL は最大 96 vCPU、SQL Server は最大 64 vCPU のようです。

Azure SQL Database の場合、 価格表示 では、 CPU もメモリも記載がありません。代わりに下記のように「DTU」という表示があります。

Basic: DTU: 5 0.78円/時間
Standard S0: DTU: 10     2.33円/時間
Standard S1: DTU: 20     4.65円/時間
Standard S2: DTU: 50     11.65円/時間
 (略)
Premium P15: DTU: 4000  2,482.89円/時間

DTU とは “Database Transaction Unit” のことで、 CPU・メモリ・I/O を組み合わせた指標値と考えるとよいでしょう。Basic であれば DTU 5 ですが、Standard S2 であれば DTU 50 です。「Standard S2 は Basic の 10倍の処理能力を提供可能」と言ってよいです。

一方で、SQL を実行するたびに DTU を消費していきます。CPU もメモリもあまり使わない、I/O もほぼないような軽い SQL であればあまり DTU を消費しませんが、CPU もメモリも I/O もたくさんで 数分間かかるような SQL であればがっつり DTU を消費します。単位時間あたりの DTU を使い尽くしてしまった場合、待たされます。

Azure ポータル (管理画面) にて、DTU 使用率のグラフを簡単に見ることができるので、 DTU 不足と思った場合はインスタンスサイズをあげるなり、 SQL チューニングや Redis 等に逃がすなどの改善をしましょう。

バックアップ・リストアについて

バックアップ・リストアの基礎知識

まずはバックアップとリストアの基礎知識から。

すべての RDBMS では、データベースをフルバックアップすることができます。例えば MySQL なら mysqldump コマンドを使います。「1日1回や、週1回のフルバックアップがあればよい」 「フルバックアップ以降の更新分は失われてもよい」 ということであれば話は終了です。直近のフルバックアップを使ってリストアしてください、です。

とはいえ普通は「できるだけ最近のデータも救って」という話になるわけです。しかし、フルバックアップの頻度を1時間に1回、30分間に1回、10分に1回と頻度をあげていっても DB が重くなるだけです。そこで一般的には、フルバックアップ + ジャーナルファイル という組み合わせを使います。ジャーナルファイルは MySQL だとバイナリログ、Oracle だと REDO ログやアーカイブログと言いますが、 内容は「実行した SQL 文や、追加・更新したデータが実行時刻付きで時系列に並んでいるもの」と思ってください。

直近で取得したフルバックアップに対して、ジャーナルファイルをどんどん当て込んでいくことで、 最新のデータベースに近づいていくわけです。また、ある時刻でジャーナルファイルの適用を止めれば、「任意時刻時点のリカバリ」となります。以上、基礎知識おわり。

自動バックアップ

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
自動バックアップ◯ (日次)◯ (数時間に一度)◯ (日次)

AWS・Azure・GCP いずれも、自動的にバックアップを取得して保存しておくことができます。取得タイミングは 1日1回や数時間に 1回などと決まっており、変更はできません。ただし、ジャーナルファイルがありますので、1日1回のバックアップだからといって、 最長24時間データが巻き戻ってしまうわけではありません (ただしバックアップ頻度が長すぎると、 リストア時に時間がかかってしまう)。

このときのバックアップがフルバックアップであるか、 フルバックアップ + ジャーナルファイルであるかは、気にする必要がありません。例えば管理画面上からは「2018/06/14 18:30:11 時点のバックアップ」として見えているものが、 フルバックアップかもしれないし、フルバックアップにジャーナルファイルを当て込んで生成されるものかもしれないが、気にしなくてよいということです。

自動バックアップ保存期間

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
自動バックアップ保存期間1〜35日で選択可能Basic: 7日、Standard と Premium: 35日7日

自動バックアップしたデータは、上記の日数の間、保存されます。例えば保存期間が 7日である場合、7日前のデータに戻すことはできるが、8日前に戻すことはできません。ただし、手動でバックアップを取得する方法がありますので、 手動バックアップであれば 1ヵ月間でも 1年間でも保存しておくことができます (その分、コストはかかります)。

任意時点のデータ復元

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
任意時点のデータ復元

いずれのサービスも、自動バックアップ保存期間内であれば、任意時点のデータを復元することが可能です。

「バックアップウィンドウ」について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
バックアップウィンドウ30分単位で指定可能 (04:00〜04:30 など)指定不可4時間幅で指定可能 (02:00〜06:00 など)

Amazon RDS・Google Cloud SQL では、日次バックアップを行う時間帯 (ウィンドウ) を指定することができます。Amazon は 30分幅、GCP は 4時間幅です。一般的には朝方など、利用者の少ない時間帯を指定しておくとよいでしょう。ただし Amazon RDS で Multi-AZ を有効にしている場合、待機系であるスレーブからバックアップを取得するため、 マスタへの負荷の影響はほぼないと見てよいでしょう。

Azure SQL Database では、バックアップの時間帯は指定できないようです。

「任意タイミングでスナップショット生成」について

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL

任意タイミングでスナップショット生成

ストレージについて

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
最小DB容量5GB
※プロビジョンドIOPS (SSD)の場合は20GBか100GB
SQL Database: 2GB、MySQL/PostgreSQL: 5GB10GB
最大DB容量6TB (SQL Server は 4TB、マグネティックは 3TB)
※プロビジョンドIOPS (SSD)の場合は16TBか32TB
SQL Database: 4TB、MySQL/PostgreSQL: 2TB3〜30TB (インスタンスタイプによる。なお、第一世代は250 GBまで)
容量自動拡張◯ (自動拡張ON/OFFを設定可能。拡張上限設定可能)△ (サービスレベルごとの上限内なら自動管理)○ (自動拡張 ON/OFF を設定可能。拡張上限設定可能。インスタンスタイプごとの上限あり)
HDD/SSD 選択◯ (後から変更可)○ (Managed Disk なので多分 SSD 指定可能)◯ (後から変更不可)

どのサービスも最大数TB程度はいけるようです。

AWS の場合、通常の RDS のストレージに SSD や HDD を選択した場合、容量は最低 5GB、最大 数TB 程度ですが、「プロビジョンドIOPS (SSD)」を選択すると容量が最低 100GB、最大 32TB と一気に広がります (SQL Server は最低 20GB、最大 16TB)。

ストレージ容量の自動拡張について

Amazon RDS・Google Cloud SQL は「容量自動拡張」を持っています。データを保存するストレージが不足した場合、勝手に拡張してくれます。

ただし気づかない間にどんどん容量が増えてコストが増えてしまうのは困るというケースもあるでしょうから、 Amazon RDS・Google Cloud SQL いずれも自動拡張の ON/OFF や、自動拡張時の上限容量設定が可能です。

Amazon RDS の容量自動拡張について

これまで Amazon Aurora にしか容量自動拡張機能がなかったのですが、2019/06/21 に MySQL・MariaDB・PostgreSQL・SQL Server・Oracle などの他の RDS にも自動拡張機能が追加されました。

Google CLoud SQL 自動拡張容量上限について

2019/06/21 時点では、GCP コンソール (管理画面) からは設定できないようですが、gloud beta sql instances create (または patch) コマンドでは設定可能です。

Azure SQL Database は、選択したサービスレベル (Basic・Standard S0, S1, S2 など) ごとに上限が決まっていて、その枠内ならば自由に使えます。それを超える場合は、上位サービスレベルの変更が必要になります。

その他管理

メンテナンスウィンドウ

機能Amazon RDSAzure SQL DatabaseGoogle Cloud SQL
メンテナンスウィンドウ月曜 1:00〜1:30 などと指定可能指定不可月曜 1:00〜2:00 などと指定可能。おまかせ/遅め/早め を指定可能

Oracle Database

Oracle Database は、「Amazon RDS for Oracle」というサービス名称で、 Amazon RDS のみでサポートされています。対象バージョンは下記のとおりです。

  • 11.2 (11g リリース 2)
  • 12c

対応エディションは以下のとおりです。

  • BYOL (持ち込み) の場合:
    • Standard Edition Two (SE2)
    • Standard Edition One (SE1)
    • Standard Edition (SE)
    • Enterprise Edition (EE)
  • ライセンス込みの場合:
    • Standard Edition Two (SE2)
    • Standard Edition One (SE1)

Amazon RDS for Oracle では、RAC はサポートされていません。また、その他の Enterprise のオプション、

  • Oracle Active Data Guard
  • Oracle Advanced Analytics
  • Oracle Advanced Compression
  • Oracle Advanced Security
  • Oracle Database Vault
  • Oracle Label Security
  • Oracle On-Line Analytical Processing (OLAP)
  • Oracle Partitioning
  • Oracle RAC One Node
  • Oracle Real Application Clusters (Oracle RAC)
  • Oracle Real Application Testing
  • Oracle Spatial and Graph
  • Oracle TimesTen Application-Tier Database Cache

について、Advanced Compression や Advanced Security などの一部オプションは BYOL (持ち込み) モデルではサポートされていると FAQ に書いてありますが、逆に言うと、ライセンス込みモデルでは サポートされていない? いずれにせよ全オプションが利用可ではないようなので、注意が必要です。

以前 Azure には Oracle Database ライセンス込みの VM があったのですが、 2016/05 に終了となったようです。Marketplace での提供はなされているので、使えなくなったわけではありません。

なお、RDS 等の DBaaS を使わず、仮想マシン (Amazon EC2、Azure VM、GCP Compute Engine) に、 自分で Oracle Database をインストールするという前提であれば、いずれも動作するはずです。



TODOメモ

  • Azure: DTU だけではなく、vCore 単位での課金タイプもある。
  • Azure: Premium で 4重化
  • Azure: アクティブ geo レプリケーション は手動フェイルオーバー可能
  • Azure: https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-planned-maintenance の「 再構成/フェールオーバーは、通常、30 秒以内に完了します (平均は 8 秒)」「平均すると、1 か月に 1.7 回の計画メンテナンス イベントが発生します。」 を追加
  • Azure: バックアップ10年保存
  • Azure: マネージドインスタンス
  • GCP: MySQL はフェイルオーバーレプリカをリードレプリカとして使用可能ではないか。PostgreSQL ではできないように見える。
  • このエントリーをはてなブックマークに追加

SNSでもご購読できます。

Leave a Reply

*

CAPTCHA