Amazon DynamoDBグローバルテーブル

Amazon DynamoDBグローバルテーブルは、同じ論理テーブルのレプリカを複数のAWSリージョンに配置し、リージョン間でデータ変更を複製する機能です。利用者に近いリージョンで読み書きするアプリケーションや、リージョン障害時にも別リージョンでデータベースを利用したいアプリケーションで使います。

グローバルテーブルはマルチリージョン・マルチアクティブです。単一の書き込みプライマリと読み取り専用のセカンダリを決める方式ではなく、どのレプリカも読み書きを受け付けます。各リージョンのアプリケーションは近くのレプリカへアクセスでき、変更はほかのレプリカにも伝播します。ただし、レプリカ間の整合性は選択するモードで異なります。構成図では変更の複製経路を示しています。結果整合性モードの複製は非同期であり、変更が常に同時に見えることを表すものではありません。

レプリカと変更複製の仕組み

グローバルテーブルは、リージョンごとのDynamoDBテーブルをレプリカとして束ねます。各レプリカは同じグローバルテーブルの一部であり、あるレプリカに加えたアイテム変更をほかのレプリカへ複製します。アプリケーションは各リージョンのエンドポイントを使い、配置したレプリカへ読み書きします。

レプリカ間の変更伝播にはDynamoDB Streamsが利用されます。Streamsはアイテムの作成・更新・削除を変更レコードとして扱う仕組みで、グローバルテーブルはこの変更情報を使って別リージョンへデータを届けます。Streamsはしたがって、Lambdaなどへ変更を通知する機能であると同時に、グローバルテーブルのレプリケーションを支える仕組みでもあります。

グローバルテーブルのレプリケーションでは、変更前後のアイテムを含む NEW_AND_OLD_IMAGES のストリームビューが使われます。グローバルテーブルの作成・レプリカ管理に伴ってサービスが必要なStreams設定を有効化するため、アプリケーションが複製目的で手動設定を作る必要はありません。レプリケーションを保つにはStreamsを無効化せず、レプリカの追加・削除やストリーム設定はグローバルテーブルの管理手順に沿って行います。StreamsのイベントをLambdaなどでも処理する場合は、レプリカごとにストリームが存在すること、イベントソースマッピングの参照先がリージョン固有のストリームARNであることを把握します。グローバルテーブルの複製を、独自のStreamsコンシューマーで自作する必要はありません。

レプリカは同じアカウントに作成し、同一の論理テーブルとして扱えるようにします。特にテーブル名とプライマリキーの定義は全レプリカで共通でなければなりません。既存テーブルをレプリカとして取り込むときは、名前やキーだけでなく、キャパシティモード、インデックスやストリームなどの条件がグローバルテーブルの要件と合っているか確認します。新規レプリカを追加する場合は、対応するレプリカ作成手順を使うとテーブルの複製設定もサービス側で管理できます。

整合性モード

グローバルテーブルでは、アプリケーションが必要とする読み取り整合性とリージョン構成に応じて、**マルチリージョン結果整合性（MREC）またはマルチリージョン強整合性（MRSC）**を選択します。どちらも複数リージョンにデータを配置しますが、変更の反映方法と利用条件は異なります。

観点	MREC	MRSC
整合性	リージョン間の変更複製は非同期で、結果整合性	対応する構成で、リージョンをまたいだ強い整合性を提供
読み取り	複製が到着する前は、レプリカによって見える値が異なる場合がある	強整合性が必要な読み取りを複数リージョンにまたがって行える
リージョン条件	複数の対応リージョンへレプリカを配置する	利用可能なリージョンの組み合わせ、レプリカ数、機能制約に条件がある
主な設計上の注意	複製遅延と同一アイテムへの同時更新を考慮する	強整合性の要件と、対応リージョンおよびサービス上の制約を事前に確認する

MRECでは、あるリージョンの書き込みが別のリージョンからすぐに読めるとは限りません。レプリカ間の伝播には時間がかかるため、直後の読み取りで古い値が返る場合があります。グローバルテーブルを使っていることだけを根拠に、書き込み後にどのリージョンからでも必ず最新値を読み取れると考えないようにします。

MRSCは、リージョンをまたぐ強整合性を必要とするワークロード向けのモードです。ただし、利用できるリージョン、レプリカまたは witness を含む配置方法、作成後に変更できる設定、サポートされる機能に条件があります。MRSCがすべてのリージョンやすべての既存グローバルテーブルで利用できると仮定せず、設計時にAWSの現行要件を確認します。MRECからMRSCへ切り替えるだけであらゆる構成を移行できるとも限らないため、モード選択はリージョン配置と一緒に決めます。

書き込み競合とアプリケーション設計

マルチアクティブ構成では、複数リージョンが同時に更新を受け付けます。同じアイテムに対する書き込みが競合した場合、MRECでは**Last Writer Wins（最後の書き込み優先）**の競合解決規則に従って最終状態が決まります。これはアプリケーションが任意の優先度を指定できる規則ではありません。アプリケーションが競合解決の順番を制御したり、複数リージョンにまたがる独自のロックとして使ったりすることはできません。特定の更新を必ず保持する要件がある場合は、書き込み先を業務上の所有リージョンに寄せる、条件付き更新を利用する、または競合を検出・解決するアプリケーション設計を検討します。

グローバルテーブルは、複数リージョンのレプリカを提供しますが、単一のACIDトランザクションを複数リージョンにまたがって実行する機能ではありません。トランザクションが実行されたリージョン内での原子性と、その結果が他リージョンへ複製される動作を区別します。リージョン間で同時に発生する業務イベントの順序や一連の更新全体の原子性が必要なら、グローバルテーブルの複製だけで保証できるかを確認します。

アプリケーション側では、読み書き先のリージョン選択も必要です。グローバルテーブルを構成しただけで、クライアントが障害リージョンから自動的に退避するわけではありません。DNS、ロードバランサー、アプリケーション設定などを使った接続先切り替え、フェイルオーバー時の書き込み先、復旧後にどのレプリカへ戻すかを設計します。リージョンごとのデータ鮮度や障害時の動作を監視し、復旧手順を確認しておきます。

レプリカ間でそろえる設定

複数のレプリカは同一データセットを表すため、テーブル定義や容量設定を独立した無関係なテーブルとして扱うことはできません。一方で、すべての設定値を必ず手作業で同じにしなければならないという説明も正確ではありません。レプリカ作成時の要件、グローバルテーブルが自動伝播する設定、リージョン固有で選ぶ設定を区別します。

設定項目	確認すること
テーブル名・プライマリキー	同一のグローバルテーブルを構成する全レプリカで一致させる
キャパシティモード	グローバルテーブルの各レプリカで利用するモードと料金への影響を確認する。プロビジョンドではレプリケーションによる書き込みも含めて容量を計画する
オートスケーリング	プロビジョンドを選ぶ場合、各レプリカのローカル書き込みと複製書き込みの負荷を見積もり、スケーリング範囲を構成する
グローバルセカンダリインデックス	必要なインデックスを設計し、作成・変更がレプリカへ伝播する条件、追加のキャパシティと料金を確認する
TTL	有効化する属性や期限切れアイテムの複製動作を把握し、各リージョンでの削除反映とアプリケーションの期待を合わせる
暗号化	各レプリカのリージョンで利用する暗号化キーとアクセス許可を確認する。KMSキーはリージョン固有のリソースなので、同じキーARNを複数リージョンで共用するとは考えない
Streams	レプリケーションに必要なストリーム設定を維持する。独自コンシューマーがある場合は、各レプリカのストリーム参照と処理権限を管理する

オンデマンドキャパシティモードでは、読み書きキャパシティユニットを固定値として事前指定しません。プロビジョンドモードでは、ローカルアプリケーションからの書き込みに加え、ほかのリージョンから複製される書き込みも処理できるように容量を考慮します。プロビジョンドでは固定容量を設定する方法とオートスケーリングを組み合わせる方法があり、オートスケーリングはすべてのグローバルテーブルに共通する必須条件ではありません。いずれの方法でも、突発的な負荷増加やスケーリング反映までの時間に備える必要があります。

容量モード、暗号化、インデックスなどの変更可否や伝播方法は、グローバルテーブルのバージョンと操作方法によって条件が異なる場合があります。複数の既存テーブルを先に別々に作って後から束ねる設計では、設定差が原因でレプリカ追加に失敗することがあります。必要なレプリカ設定とリージョンごとのKMSキーを整理し、AWSのレプリカ追加・更新手順で管理します。

可用性・料金・バックアップの境界

グローバルテーブルはリージョン障害への耐性や各地からの低遅延アクセスに役立ちますが、アプリケーション全体の可用性を自動で完成させるものではありません。別リージョンにレプリカが存在しても、アプリケーションが正常なリージョンのエンドポイントへ接続できること、必要な認証情報やネットワーク設定を使えること、障害時に処理を切り替えられることが必要です。

各レプリカの書き込みは、ローカルの書き込みだけでなく他リージョンから届く変更によってもキャパシティや料金に影響します。オンデマンドとプロビジョンド、レプリカ数、リージョン間の書き込み量、インデックス、バックアップなどがコストに関わります。料金単価はリージョンや利用条件により異なるため、Amazon DynamoDBの料金ページで構成ごとの課金要素を確認します。

グローバルテーブルはレプリカ間で現在のデータを複製する仕組みで、誤操作や不正な更新を過去の状態へ戻すバックアップではありません。誤削除やアプリケーション不具合による更新も、ほかのレプリカへ伝播し得ます。復元時点の要件にはオンデマンドバックアップやポイントインタイムリカバリを別途検討し、リージョン障害への複製とデータ保護を混同しないようにします。

試験で押さえるポイント

• 複数リージョンにDynamoDBテーブルのレプリカを持ち、各地から読み書きする要件にはグローバルテーブルを検討する。
• グローバルテーブルは単一プライマリの読み取り専用レプリカ構成ではなく、各レプリカで書き込みを受け付けるマルチアクティブ構成である。
• レプリカ間の変更複製にはDynamoDB Streamsが使われる。Streamsの一般的なイベント処理機能と、グローバルテーブル内部の複製機構を区別する。
• MRECは結果整合性で、リージョン間の反映遅延がある。同じアイテムへの同時書き込みにはLast Writer Winsによる競合解決が適用される。
• MRSCは複数リージョンで強い整合性を必要とする選択肢だが、利用可能リージョンや構成、機能に制約がある。
• オンデマンドまたはプロビジョンドを選び、プロビジョンドではレプリケーション分も含めて各レプリカの書き込み容量を計画する。
• テーブル名と主キーなどのレプリカ要件を確認する。TTL、インデックス、暗号化、Streams、キャパシティは複製方法やリージョン固有条件を含めて管理する。
• レプリカの存在だけでクライアントのリージョン切り替え、トランザクションのリージョン間原子性、バックアップからの復元が自動で得られるわけではない。

AWS公式ドキュメント

• Amazon DynamoDBグローバルテーブル
• グローバルテーブルの要件
• グローバルテーブルのベストプラクティス
• マルチリージョン結果整合性（MREC）グローバルテーブル
• マルチリージョン強整合性（MRSC）グローバルテーブル
• DynamoDB Streams
• DynamoDBの料金

関連トピック

• Amazon DynamoDBの基本とデータモデル
• Amazon DynamoDBのキャパシティモードと読み書き性能
• Amazon DynamoDB Streamsと変更イベント