小西秀和です。
2020年度に続き2021年、2022年、2023年もJapan AWS All Certifications Engineer(旧称：APN ALL AWS Certifications Engineer)、Japan AWS Top Engineer(Services) (旧称：APN AWS Top Engineer)に選出していただきました。これも多くの方に読んでいただいたAWS認定記事に依るところが大きいと思いますが、今後はAWS認定以外の記事も書いていこうと思います。まずはデータベースに関するテーマからです。
AWSのデータベースサービスには現在、Amazon Aurora、Amazon DocumentDB、Amazon DynamoDB、Amazon ElastiCache、Amazon Keyspaces (for Apache Cassandra)、Amazon MemoryDB for Redis、Amazon Neptune、Amazon QLDB、Amazon RDS、Amazon Timestreamなど様々なサービスがあります。
その中でもAmazon Auroraおよびそれ以降に登場したAmazon DocumentDBやAmazon Neptuneといったデータベースサービスではクォーラムモデルというデータレプリケーションが採用されています。
クォーラムモデルとは簡潔に言うと、複数のデータコピーのうち一定数に書き込みまたは読み込みできた場合にその処理を完了とし、それ以外のデータコピーは非同期で整合性をとるというものです。
このクォーラムモデルの特徴は従来の同期レプリケーションの遅延や非同期レプリケーションの障害耐性の問題などを解決するアプローチとなっています。
Amazon Auroraの場合は、3つのAZに6個のコピーを自動作成して非同期レプリケーションし、6個中4個の書込クォーラム、6個中3個の読込クォーラムでオペレーションを成功とみなします。これにより、最大2個のコピー損失でも書込影響無し、最大3個のコピー損失でも読込影響無しという可用性を実現しています。
なお、Amazon Auroraではコストと効率の観点から、読み込みクォーラムを実際に使用するのは、プライマリDBインスタンスのキャッシュの喪失、プライマリDBインスタンスの再起動やレプリカのプライマリへの昇格などローカルの状態再構築、破損したセグメントの再構築、クォーラムの修復といった場合で、それ以外は予め管理している必要なデータバージョンをもつノードから読み取りをします。このようなAuroraで採用されているクォーラムモデルの詳細を知りたい場合には次の記事が役に立ちます。
Amazon Aurora under the hood: クオーラムと障害 | Amazon Web Services ブログ
Amazon Aurora Under the Hood: クオーラムの読み取りと状態の遷移 | Amazon Web Services ブログ
Amazon Aurora Under the Hood: クオーラムセットを使ったコスト削減 | Amazon Web Services ブログ
Amazon Aurora Under the Hood: クオーラムメンバーシップ | Amazon Web Services ブログ
さて、このクォーラムモデルを採用したAmazon Aurora、Amazon DocumentDB、Amazon NeptuneはAWSドキュメントやAWSクラウドサービス活用資料集の内容を確認すると特にクラスターの構成やストレージの仕組みが非常に似ています。
ただ、本記事執筆時点でAWSからこれらのデータベース基盤の仕組みが同一のものであるという公式のアナウンスは出ていないようです。
そのため、今回はこれらのデータベースサービスの理解を効率よく深めるために共通点、相違点を比較表にまとめてみました。
次の比較表はAWSドキュメント、AWSサービス別資料(AWS Black Belt Online Seminar資料)を情報源にして、ドキュメントと実際の動きの差異などを個人的にAWSサポートに確認しながらまとめたものです。
あくまで個人としてまとめたものなので不備等がある可能性を認識の上で参考にしていただければと思います。
Amazon Aurora、Amazon DocumentDB、Amazon Neptuneの主な機能の共通点、相違点の比較表
| 比較項目 | Amazon Aurora | Amazon DocumentDB | Amazon Neptune |
|---|---|---|---|
| 概要 | リレーショナルデータベース | MongoDB互換データベース | グラフデータベース |
| サポートデータベース | MySQL, PostgreSQL | MongoDB | Gremlin, SPARQL |
| ストレージ拡張 | 10GB毎に最大128TiBまで自動拡張 | 10GB毎に最大128TiBまで自動拡張 | 10GB毎に最大128TiBまで自動拡張 |
| ストレージ可用性 | 3AZに6個コピー自動作成。6個中4個の書込クォーラム、6個中3個の読込クォーラムで、最大2個のコピー損失でも書込影響無し、最大3個のコピー損失でも読込影響無しの可用性。 | 3AZに6個コピー自動作成。6個中4個の書込クォーラム、6個中3個の読込クォーラムで、最大2個のコピー損失でも書込影響無し、最大3個のコピー損失でも読込影響無しの可用性。 | 3AZに6個コピー自動作成。6個中4個の書込クォーラム、6個中3個の読込クォーラムで、最大2個のコピー損失でも書込影響無し、最大3個のコピー損失でも読込影響無しの可用性。 |
| クラスター構成 | 1つのプライマリDBインスタンス、 0個～15個のリードレプリカDBインスタンス |
1つのプライマリDBインスタンス、 0個～15個のリードレプリカDBインスタンス |
1つのプライマリDBインスタンス、 0個～15個のリードレプリカDBインスタンス |
| フェイルオーバー優先順位 | レプリカの昇格階層は0(最も高い)から15(最も低い)で指定。次の順番で昇格。 1. 指定した優先度が高い(より0に近い)リードレプリカ 2. 優先度が同じ場合はサイズの大きいリードレプリカ 3. 優先度とサイズが同じ場合は任意のリードレプリカ |
レプリカの昇格階層は0(最も高い)から15(最も低い)で指定。次の順番で昇格。 1. 指定した優先度が高い(より0に近い)リードレプリカ 2. 優先度が同じ場合はサイズの大きいリードレプリカ 3. 優先度とサイズが同じ場合は任意のリードレプリカ |
レプリカの昇格階層は0(最も高い)から15(最も低い)で指定。次の順番で昇格。 1. 指定した優先度が高い(より0に近い)リードレプリカ 2. 優先度が同じ場合はサイズの大きいリードレプリカ 3. 優先度とサイズが同じ場合は任意のリードレプリカ |
| エンドポイント | クラスターエンドポイント、 リーダーエンドポイント、 インスタンスエンドポイント、 カスタムエンドポイント |
クラスターエンドポイント、 リーダーエンドポイント、 インスタンスエンドポイント |
クラスターエンドポイント、 リーダーエンドポイント、 インスタンスエンドポイント、 カスタムエンドポイント |
| デフォルトDBポート | 3306(MySQL)、5432(PostgreSQL) | 27107 | 8182 |
| VPC設定 | enableDnsHostnamesとenableDnsSupportをtrueにする。 | enableDnsHostnamesとenableDnsSupportをtrueにする。 | enableDnsHostnamesとenableDnsSupportをtrueにする。 |
| データ保管の暗号化 | AWS KMSを使用 | AWS KMSを使用 | AWS KMSを使用 |
| データ転送の暗号化 | パラメータグループでTLS暗号化設定(デフォルト有効) | パラメータグループでTLS暗号化設定(デフォルト有効化) | Neptuneエンジンバージョン1.0.4.0以降はTLS暗号化が強制 |
| リソース管理権限制御 | IAMロール・IAMユーザー | IAMロール・IAMユーザー | IAMロール・IAMユーザー |
| DBポートアクセス制御 | セキュリティグループ、NACL | セキュリティグループ、NACL | セキュリティグループ、NACL |
| DB接続権限制御 | ユーザー名とパスワード、IAMデータベース認証 | ユーザー名とパスワード | IAMデータベース認証 |
| 監査ログ | Amazon CloudWatch Logsエクスポートとパラメータグループの「server_audit_logging」の有効化で可能 | Amazon CloudWatch Logsエクスポートとパラメータグループの「audit_logs」の有効化で可能 | Amazon CloudWatch Logsエクスポートとパラメータグループの「neptune_enable_audit_log」の有効化で可能 |
| 課金体系 | DBインスタンス、ストレージ、バックアップストレージ、データ転送の従量課金 | DBインスタンス、ストレージ、バックアップストレージ、データ転送の従量課金 | DBインスタンス、ストレージ、バックアップストレージ、データ転送の従量課金 |
| メンテナンスウィンドウ | リージョン毎の8時間ブロック内でランダムな30分間が割当。曜日も指定をしなければランダムに割当。 | リージョン毎の8時間ブロック内でランダムな30分間が割当。曜日も指定をしなければランダムに割当。 | リージョン毎の8時間ブロック内でランダムな30分間が割当。曜日も指定をしなければランダムに割当。 |
| バックアップウィンドウ | リージョン毎の8時間ブロック内でランダムな30分間が割当。開始時にシングルAZ配置は数秒間ストレージI/O中断、マルチAZ配置は数分間レイテンシー上昇。 | リージョン毎の8時間ブロック内でランダムな30分間が割当。開始時にシングルAZ配置は数秒間ストレージI/O中断、マルチAZ配置は数分間レイテンシー上昇。 | リージョン毎の8時間ブロック内でランダムな30分間が割当。開始時にシングルAZ配置は数秒間ストレージI/O中断、マルチAZ配置は数分間レイテンシー上昇。 |
| 自動バックアップ保持期間 | 1日～35日 | 1日～35日 | 1日～35日 |
| ポイントタイムリカバリ | 自動バックアップを使用して可能 | 自動バックアップを使用して可能 | 自動バックアップを使用して可能 |
| バックアップ手段 | 自動バックアップ(自動スナップショット、トランザクションログ)、手動スナップショット | 自動バックアップ(自動スナップショット、トランザクションログ)、手動スナップショット | 自動バックアップ(自動スナップショット、トランザクションログ)、手動スナップショット |
| バックアップの共有・コピー | 手動スナップショットはリージョン間コピー、アカウント間共有可能。 自動スナップショットは手動スナップショットにコピーすれば可能。 暗号化されている場合はカスタムKMSキーに共有先の権限を付与すれば可能。 デフォルトKMSキー暗号化の場合はカスタムKMSキー暗号化スナップショットにコピーすれば可能。 |
手動スナップショットはリージョン間コピー、アカウント間共有可能。 自動スナップショットは手動スナップショットにコピーすれば可能。 暗号化されている場合はカスタムKMSキーに共有先の権限を付与すれば可能。 デフォルトKMSキー暗号化の場合はカスタムKMSキー暗号化スナップショットにコピーすれば可能。 |
手動スナップショットはリージョン間コピー、アカウント間共有可能。 自動スナップショットは手動スナップショットにコピーすれば可能。 暗号化されている場合はカスタムKMSキーに共有先の権限を付与すれば可能。 デフォルトKMSキー暗号化の場合はカスタムKMSキー暗号化スナップショットにコピーすれば可能。 |
| ストリーム機能 | データベースアクティビティストリーム。 他のサービスと連携可能なデータベース変更のログを重複無く発生順序を維持してAmazon Kinesis Data Streamsにプッシュする。 |
変更ストリーム。 他のサービスと連携可能なデータベース変更のログを重複無く発生順序を維持してクラスター内に7日間保持。プライマリインスタンスからのみ取得可能。 |
Neptuneストリーム。 他のサービスと連携可能なデータベース変更のログを重複無く発生順序を維持してクラスター内に7日間保持。プライマリインスタンスとリードレプリカインスタンスから取得可能。 |
| イベント通知機能 | クラスター・インスタンスのイベント発生時にAmazon SNSに連携。 | クラスター・インスタンスのイベント発生時にAmazon SNSに連携。 | クラスター・インスタンスのイベント発生時にAmazon SNSに連携。 |
| バックトラック | 同じDBクラスター内のデータを指定時間まで数分で巻き戻す機能。 | － | － |
| クローン機能 | DBクラスターのクローンをダウンタイム無しで作成。 | DBクラスターのクローンをダウンタイム無しで作成。 | DBクラスターのクローンをダウンタイム無しで作成。 |
| Serverlessクラスターの作成 | オンデマンド自動スケーリング構成のクラスターを作成。 | － | － |
| Elasticクラスターの作成 | － | ダウンタイムとパフォーマンスへの影響を最小限に抑えながら、1秒間に数百万件の書き込みと読み取りを処理し、ペタバイトのストレージに拡張することができるAmazon DocumentDB Elastic Clustersを作成。 | － |
| Performance Insights | データベース負荷原因を待機状態、SQLクエリ、ホスト、ユーザーなどで分析。 | データベース負荷原因を待機状態、SQLクエリ、ホスト、ユーザーなどで分析。 | － |
| クロスリージョン配置 | Amazon Aurora Global Databaseで各リージョンにリードレプリカを作成するシングルマスター構成。 トランザクションは1つのリージョンに存在するプライマリDBインスタンスでサポート。 |
Amazon DocumentDB Global Clustersで各リージョンにリードレプリカを作成するシングルマスター構成。 | Amazon Neptune Global Databaseで各リージョンにリードレプリカを作成するシングルマスター構成。 |
| マルチマスター配置 | Amazon Aurora Multi-Masterで1つのリージョン内でマルチマスターデータベースを作成。 | － | － |
| プロファイラー | － | 操作実行時間と詳細ログをAmazon CloudWatch Logsに記録。 | － |
Amazon Aurora、Amazon DocumentDB、Amazon Neptuneの類似したモニタリング項目
Amazon Aurora、Amazon DocumentDB、Amazon Neptuneにモニタリング項目のうち同様の内容のものをまとめました。
実際には次の表以外にも各データベース固有のメトリクスが存在します。
これらのうち、BufferCacheHitRatio、CPUUtilization、FreeableMemoryはインスタンスクラスの増減を決める基準として使われます。
| メトリクス名 | メトリクス内容 |
|---|---|
| BufferCacheHitRatio(Aurora) BufferCacheHitRatio(DocumentDB) BufferCacheHitRatio(Neptune) |
バッファキャッシュで処理されるリクエスト割合(％)。キャッシュヒット率99.9％未満かつ高レイテンシの場合などにインスタンスクラスを大きく(メモリデータキャッシュ増加)する検討指標となる。 |
| CPUUtilization(Aurora) CPUUtilization(DocumentDB) CPUUtilization(Neptune) |
CPU使用率。CPU使用率が100％に近く | 十分なパフォーマンスが得られない場合などにインスタンスクラスを大きくする検討指標となる。 |
| FreeableMemory(Aurora) FreeableMemory(DocumentDB) FreeableMemory(Neptune) |
メモリ(RAM)容量(Bytes)。メモリ不足の場合などにインスタンスクラスを大きくする検討指標となる。 |
| EngineUptime(Aurora) EngineUptime(DocumentDB) EngineUptime(Neptune) |
インスタンス実行時間(秒)。 |
| VolumeBytesUsed(Aurora) VolumeBytesUsed(DocumentDB) VolumeBytesUsed(Neptune) |
DBクラスターに割り当てられたストレージ容量(Bytes)。 |
| AuroraReplicaLag(Aurora) DBInstanceReplicaLag(DocumentDB) ClusterReplicaLag(Neptune) |
プライマリインスタンスとレプリカ間のレプリケート遅延時間(ミリ秒)。 |
| AuroraReplicaLagMaximum(Aurora) DBClusterReplicaLagMaximum(DocumentDB) ClusterReplicaLagMaximum(Neptune) |
プライマリインスタンスと各レプリカ間の最大レプリケート遅延時間(ミリ秒)。 |
| AuroraReplicaLagMinimum(Aurora) DBClusterReplicaLagMinimum(DocumentDB) ClusterReplicaLagMinimum(Neptune) |
プライマリインスタンスと各レプリカ間の最小レプリケート遅延時間(ミリ秒)。 |
Amazon Aurora、Amazon DocumentDB、Amazon Neptune共通の変更反映タイミング
Amazon Aurora、Amazon DocumentDB、Amazon Neptuneでデータベースに変更を加えた場合の共通の変更反映タイミングについてまとめました。
「Apply Immediately(すぐに適用)」を変更を実行時に選択しない場合、
クラスター識別子、マスターパスワード、IAM DB認証、インスタンス識別子、インスタンスクラス
についてはメンテナンスウィンドウで変更が適用されます。上記以外の設定は「Apply Immediately(すぐに適用)」の指定に関係なく即時適用されます。
| スコープ | 変更対象 | 影響 |
|---|---|---|
| クラスター | クラスター識別子 | ダウンタイム無し。 |
| クラスター | マスターパスワード | ダウンタイム無し。 |
| クラスター | IAM DB認証 (DocumentDBは機能無し) |
ダウンタイム無し。 |
| クラスター | セキュリティグループ | ダウンタイム無し。 |
| クラスター | パラメータグループ | パラメータ変更はフェイルオーバー無しの 手動再起動時のみ反映。 |
| クラスター | メンテナンスウィンドウ | 現在時刻を含むメンテナンス時間変更をし、 かつ保留中アクションが機能停止する場合、 保留中アクションが即時適用され機能停止が発生。 |
| クラスター | バックアップ保持期間 | ダウンタイム無し。 |
| クラスター | バックアップウィンドウ | ダウンタイム無し。 |
| インスタンス | インスタンス識別子 | DBインスタンス再起動が発生し、 変更中に機能停止する。 |
| インスタンス | インスタンスクラス | 変更中に機能停止する。 |
| インスタンス | 昇格階層 | ダウンタイム無し。 |
| クラスター | 削除保護 | ダウンタイム無し。 |
参考：
AWS Blog
Welcome to AWS Documentation
Tech Blog with related articles referenced
まとめ
このように比較表で見てみるとAmazon Aurora、Amazon DocumentDB、Amazon Neptuneはクォータの違いはあるもののクォーラムモデルをベースにした可用性、バックアップの機能についてはほぼ同じと言えます。
一方でセキュリティ機能はデータベースの特性に応じた認証方法の差異があり、モニタリング機能は類似する内容のメトリクスでも細かい名称の違いが見受けられます。
また、Amazon Auroraのバックトラック、Multi-Masterといった機能はこの記事の執筆時点でAmazon DocumentDB、Amazon Neptuneにはありません。
一方でAmazon DocumentDBのプロファイラー、Elastic Clustersといった機能はこの記事の執筆時点でAmazon Aurora、Amazon Neptuneにはありません。
こうしてみると現時点で部分的には同じ機能はありますが、各AWSサービスは頻繁にアップデートするため、ある時点で同じでもまたある時点では異なる場合があるなど、AWSサービスのアップデートの継続的な情報収集は欠かせません(これが各サービスの共通点を一概に同じと言うことが難しい理由の一つだと私は考えています)。
これらのクォーラムモデルをベースにしたAWSデータベースサービスについても今後の新しい機能追加やアップデートに期待しながらチェックを継続することが大切と言えるでしょう。
