クラウド リレーショナル・データベース比較 (Amazon RDS・Azure SQL Database・Google Cloud SQL)

前へ << クラウドストレージ比較まとめ (Amazon S3・Azure Storage・Google Cloud Storage) クラウド CDN 比較まとめ (Amazon CloudFront・Azure CDN・GCP Cloud CDN) >> 次へ

目次

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

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

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

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

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

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

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

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

  • Amazon Relational Database Service (RDS)
  • Azure SQL Database
  • Google Cloud SQL

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

- Amazon RDS Azure Database Google Cloud SQL
MySQL ◯ (2018/04 GA)
MariaDB △ (2017/11 に対応を表明したが、まだ使えない?) -
Amazon Aurora - -
PostgreSQL ◯ (2018/04 GA) ○ (2018/04 GA)
SQL Server ×
Oracle × (VM を使う方法はある) × (VM を使う方法はある)

MySQL と PostgreSQL は、いずれも有名なオープンソースの RDBMS です。

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

SQL Server は、マイクロソフト製の DB。 Azure 上での DBaaS サービスとしての SQL Server を、 "SQL Database" と呼ぶ。

Amazon Aurora は、Amazon が開発した高性能 DB で、「オーロラ」と読みます。 Amazon 曰く、MySQL の 5倍、PostgreSQL の 3倍速いとのこと。 2017年11月、Aurora Serverless と Aurora Multi Master のプレビューが開始され、 まだまだ進化しそうです。

Oracle は、いわずと知れた Oracle Database です。

各サービス比較表

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

機能 Amazon RDS Azure SQL Database Google Cloud SQL
管理画面から簡単操作で DB 立上げ
レプリケーション (耐障害性)
機能 Amazon RDS Azure SQL Database Google Cloud SQL
レプリケーション ◯ (Multi-AZ 設定可) ◯ (常に3重化) ◯ (フェイルオーバーレプリカ作成可能)
レプリカの個数 0個または1個 常に3重化 0個または1個
レプリカのリージョン マスタと同じリージョン マスタと同じリージョン マスタと同じリージョン
レプリカのインスタンスサイズ指定 不可 不可 不可 (正確にはマスタ以上)
上記レプリケーションへの通常時アクセス 不可 不可 不可?
手動フェイルオーバー 不可
マルチマスタ Aurora で可 不可
レプリケーション (負荷分散)
リードレプリカ ◯ (任意リージョン、5個まで) ◯ (アクティブgeo レプリケーションで実現可能だと思う) ◯ (MySQL のみ。ベータの PostgreSQL はまだ)
任意リージョンへのリードレプリカ作成 ×
リードレプリカでの低インスタンスサイズ
リードレプリカからのバックアップ MySQL/MariaDBなら可。PostgreSQL は不可 不可
リードレプリカへの更新 MySQL/MariaDBなら可。PostgreSQL は不可 不可
レプリケーション無効化/再開
外部へのリードレプリカ作成 × × ◯?
外部をマスタとしたリードレプリカ × × ◯?
リードレプリカからの昇格 ○ (レプリカのプロモート)
複数 DB 統合管理
機能 Amazon RDS Azure SQL Database Google Cloud SQL
複数DB管理 × ◯ (Elastic Pool) ×
DB バージョン
機能 Amazon RDS Azure SQL Database Google Cloud SQL
MySQL バージョン 5.5、5.6、5.7 (マイナーバージョンまで指定可) 5.6.38、5.7.20 5.5、5.6、5.7
MariaDB バージョン 10.0、10.1 (対応予定) -
PostgreSQL バージョン 9.3、9.4、9.5、9.6 (マイナーバージョンまで指定可) 9.5.7、9.6.2 9.6
SQL Server/SQL Database バージョン SQL Server 2008 R2, 2012, 2014, 2016 v12 -
Oracle バージョン 11g リリース2、12c - -
メジャーバージョンアップグレード MySQL: 管理画面操作で可能、その他は調査中 SQL Database: 調査中、MySQL/PostgreSQL: 不可 MySQL/PostgreSQL: 手動。移行ツール提供予定あり。12ヵ月経過すると強制自動更新。
マイナーバージョンアップグレード 自動 または しない を選択可 (おそらく) 強制 強制
インスタンスサイズ
機能 Amazon RDS Azure SQL Database Google Cloud SQL
インスタンスサイズを変更できる
CPU vCPU: 1〜64 記載なし 共用〜32
メモリ 1GB〜256GB 記載なし 0.6GB〜208GB
CPU/メモリ カスタマイズ × × △ PostgreSQL は可能 (MySQL は不可)
料金
機能 Amazon RDS Azure SQL Database Google Cloud SQL
料金 (東京・1時間あたり・2017/12調査) 0.026USD (MySQL), 0.026USD (MariaDB), 0.028USD (PostgreSQL), 0.031USD (SQL Server), 0.041USD (Oracle), 0.063USD (Aurora) 0.78円 (SQL Database) 0.0195USD (MySQL, PostgreSQL) ※さらに継続利用割引あり
課金単位時間 1時間 1時間 1分
インスタンス停止時の課金 △ (条件による) × (停止できない) ○ (停止可能・停止時課金なし)
課金単位 インスタンス データベース インスタンス
バックアップ・リストア
機能 Amazon RDS Azure SQL Database Google Cloud SQL
自動バックアップ ◯ (日次) ◯ (数時間に一度) ◯ (日次)
自動バックアップ保存期間 1〜35日で選択可能 Basic: 7日、Standard と Premium: 35日 7日
任意時点のデータ復元
バックアップウィンドウ 30分単位で指定可能 (04:00〜04:30 など) 指定不可 4時間幅で指定可能 (02:00〜06:00 など)
任意タイミングでスナップショット生成
その他管理
機能 Amazon RDS Azure SQL Database Google Cloud SQL
メンテナンスウィンドウ 月曜 1:00〜1:30 などと指定可能 指定不可 月曜 1:00〜2:00 などと指定可能。おまかせ/遅め/早め を指定可能
ストレージ
機能 Amazon RDS Azure SQL Database Google Cloud SQL
最小DB容量 5GB SQL Database: 2GB、MySQL/PostgreSQL: 5GB 10GB
最大DB容量 6TB (SQL Server は 4TB、マグネティックは 3TB) SQL Database: 4TB、MySQL/PostgreSQL: 2TB、 3〜10TB (インスタンスタイプによる。なお、第一世代は250 GB)
容量自動拡張 △ (Aurora のみ可) ○ (サービスレベルごとの上限はある) ○ (自動拡張 ON/OFF を設定可能)
HDD/SSD 選択 ◯ (※後から変更可) ○ (※Managed Disk なので多分 SSD 指定可能) ◯ (※後から変更不可)
セキュリティ
機能 Amazon RDS Azure SQL Database Google Cloud SQL
接続元 IP アドレス制限
ログ
その他 インメモリなんとか。

管理画面からの操作

機能 Amazon RDS Azure SQL Database Google Cloud SQL
管理画面から簡単操作で DB 立上げ
まずは当然の話ではあるのですが、 管理画面でポチポチと操作するだけでデータベースが立ち上がりますよという点。 ソースからビルドしたり、パッケージインストールしたり、 my.cnf いじったり、ということはやらなくてもいいんですよ、ということです。

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

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

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

機能 Amazon RDS Azure SQL Database Google 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 RDS Azure SQL Database Google 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 RDS Azure SQL Database Google Cloud SQL
レプリカのリージョン マスタと同じリージョン マスタと同じリージョン マスタと同じリージョン

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

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

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

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

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

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

「レプリケーションは障害発生に備えたものであることはわかるけど、 障害が発生していないときはもったいないから、負荷分散にも使えないの?」 という意味で書きましたが、Amazon RDS・Azure SQL Database ではそのような使い方はできません (レプリカに別 IP アドレスが振られていないので、通常時は接続できない)。 Google Cloud SQL は、少なくとも別 IP アドレスが振られているのでもしかしたらできるかも…。

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

機能 Amazon RDS Azure SQL Database Google Cloud SQL
手動フェイルオーバー 不可

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

メモ: CloudSQLの自動フェイルオーバーはマスターインスタンス障害時には発火しない 要調査。

マルチマスタ について

機能 Amazon RDS Azure SQL Database Google Cloud SQL
マルチマスタ Aurora で可 不可

要追記。

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

機能 Amazon RDS Azure SQL Database Google Cloud SQL
リードレプリカ ◯ (任意リージョン、5個まで) ◯ (アクティブgeo レプリケーションで実現可能だと思う) ◯ (MySQL のみ。ベータの PostgreSQL はまだ)
任意リージョンへのリードレプリカ作成 ×
リードレプリカでの低インスタンスサイズ
リードレプリカからのバックアップ MySQL/MariaDBなら可。PostgreSQL は不可 不可
リードレプリカへの更新 MySQL/MariaDBなら可。PostgreSQL は不可 不可
レプリケーション無効化/再開
外部へのリードレプリカ作成 × × ◯?
外部をマスタとしたリードレプリカ × × ◯?
リードレプリカからの昇格 ○ (レプリカのプロモート)

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

Amazon RDS・Google Cloud SQL いずれもリードレプリカに対応しています。 Amazon RDS では、1つのマスタについて最大 5個のリードレプリカを作成できます。 Google Cloud SQL ではリードレプリカの制限はなく、「インスタンス上限40個」内であればいくつでも作れるようです (とりあえず 12個までは確認済)。 なお、Google Cloud SQL で PostgreSQL を使用した場合、リードレプリカは未対応です。 現在ベータなので、そのうち対応されるでしょう。

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

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

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

バージョン

機能 Amazon RDS Azure SQL Database Google Cloud SQL
MySQL バージョン 5.5、5.6、5.7 (マイナーバージョンまで指定可) 5.6.38、5.7.20 5.5、5.6、5.7
MariaDB バージョン 10.0、10.1 (対応予定) -
PostgreSQL バージョン 9.3、9.4、9.5、9.6 (マイナーバージョンまで指定可) 9.5.7、9.6.2 9.6
SQL Server/SQL Database バージョン SQL Server 2008 R2, 2012, 2014, 2016 v12 -
Oracle バージョン 11g リリース2、12c - -
特徴は2つです。 まずひとつめ。 Amazon RDS のみ、マイナーバージョンまで指定できます。2017/12 現在、MySQL の場合は下記を選択可能です。
  • MySQL 5.7.19, 5.7.17, 5.7.16
  • MySQL 5.6.37, 5.6.35, 5.6.34, 5.6.29, 5.6.27
  • MySQL 5.5.57, 5.5.54, 5.5.53, 5.5.46
Azure や GCP では、5.5、5.6、5.7 といったメジャーバージョンまでの指定となります。

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

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

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

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

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

複数 DB 管理

機能 Amazon RDS Azure SQL Database Google Cloud SQL
複数DB管理 × ◯ (Elastic Pool) ×

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

例えば、

  • フロント用 DB … 日中帯に負荷が高まるが、夜間・早朝は負荷が低い
  • バックエンド用 DB … 夜間・早朝のバッチ動作時に負荷が高まるが、日中帯は負荷が低い
などのように、異なる負荷特性を持つデータベースが複数ある場合や、
  • 10個のデータベースがあり、それぞれ突発的に負荷が高まることがあるが、それ以外のほとんどは負荷が低い場合
というケースにて役立つでしょう。

課金

料金 について

機能 Amazon RDS Azure SQL Database Google Cloud SQL
料金 (東京・1時間あたり・2017/12調査) 0.026USD (MySQL), 0.026USD (MariaDB), 0.028USD (PostgreSQL), 0.031USD (SQL Server), 0.041USD (Oracle), 0.063USD (Aurora) 0.78円 (SQL Database) 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 の約半額になるのではと思います。

課金単位時間 について

機能 Amazon RDS Azure SQL Database Google Cloud SQL
課金単位時間 1時間 1時間 1分

Amazon RDS・Azure SQL Database はいずれも課金単位は 1時間です。 5分間だけ触ったとしても請求は 1時間分です。 一方、GCP の Cloud SQL は 1分単位です。素晴らしいことです。

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

機能 Amazon RDS Azure SQL Database Google Cloud SQL
インスタンス停止時の課金 △ (条件による) × (停止できない) ○ (停止可能・停止時課金なし)

Amazon RDS は 2009年のリリース依頼、ずっと「停止」という機能が存在しませんでしたが、 2017/6 よりようやく停止機能が実装されました。 しかしながら中途半端で、「Multi-AZ の場合は停止できない」 「リードレプリカが存在すると停止できない」 「停止してから 7日が経過すると自動的に再開される」 という制限があります。 しかしながら、停止中はインスタンスの費用がかからない (ストレージ分は費用発生) ので、特に開発環境などの費用を節約することができます。

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

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

なお、「停止」するとインスタンス分の課金はされませんが、 「データ保持」の料金は必要ですので念のため。

課金単位 について

機能 Amazon RDS Azure SQL Database Google Cloud SQL
課金単位 インスタンス データベース インスタンス

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

一方、Azure SQL Database の課金単位は「データベース」です。 "CREATE DATABSAE" 的なもので DB を 2個作ると、2個分の費用がかかります。

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

[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 RDS Azure SQL Database Google Cloud SQL
インスタンスサイズを変更できる
CPU vCPU: 1〜64 記載なし 共用〜32
メモリ 1GB〜256GB 記載なし 0.6GB〜208GB
CPU/メモリ カスタマイズ × × △ PostgreSQL は可能 (MySQL は不可)

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

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 RDS Azure SQL Database Google Cloud SQL
自動バックアップ ◯ (日次) ◯ (数時間に一度) ◯ (日次)

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

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

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

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

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

任意時点のデータ復元

機能 Amazon RDS Azure SQL Database Google Cloud SQL
任意時点のデータ復元

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

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

機能 Amazon RDS Azure SQL Database Google 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 RDS Azure SQL Database Google Cloud SQL
最小DB容量 5GB SQL Database: 2GB、MySQL/PostgreSQL: 5GB 10GB
最大DB容量 6TB (SQL Server は 4TB、マグネティックは 3TB) SQL Database: 4TB、MySQL/PostgreSQL: 2TB、 3〜10TB (インスタンスタイプによる。なお、第一世代は250 GB)
容量自動拡張 △ (Aurora のみ可) ○ (サービスレベルごとの上限はある) ○ (自動拡張 ON/OFF を設定可能)
HDD/SSD 選択 ◯ (※後から変更可) ○ (※Managed Disk なので多分 SSD 指定可能) ◯ (※後から変更不可)

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

ちょっと意外だったのは「容量自動拡張」について。 DBaaS と言うからにはよい感じに自動管理してくれるのかと思ったら、 Amazon RDS で自動拡張してくれるのは Aurora のみでした。 GCP の場合、MySQL でも PostgreSQL でも自動拡張設定が可能なので、 Amazon RDS も頑張ればできるはず!

その他管理

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

機能 Amazon RDS Azure SQL Database Google 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 をインストールするという前提であれば、いずれも動作するはずです。

前へ << クラウドストレージ比較まとめ (Amazon S3・Azure Storage・Google Cloud Storage) クラウド CDN 比較まとめ (Amazon CloudFront・Azure CDN・GCP Cloud CDN) >> 次へ

ご意見・ご指摘は Twitter: @68user までお願いします。