DynamoDB グローバルテーブルの準備チェックリスト

対象のユースケースの場合、MRSC と、MREC の整合性モードでは、どちらの利点が大きいかを判断します。レイテンシーなどのトレードオフが大きい場合でも、強力な整合性が必要ですか?

グローバルテーブルに参加するリージョンの数と各リージョンを決定します。MRSC の使用を計画している場合は、3 番目のリージョンをレプリカにするか、監視にするかを決定します。

アプリケーションの書き込みモードを決定します。これは整合性モードとは異なります。詳細については、「DynamoDB グローバルテーブルによる書き込みモード」を参照してください。

書き込みモードに基づいて「DynamoDB のルーティング戦略」戦略を計画します。

整合性モード、書き込みモード、ルーティング戦略に基づいて、 退避プロセス を定義します。

リージョンごとのヘルス、レイテンシー、エラーに関するメトリクスをキャプチャします。DynamoDB メトリクスのリストについては、AWS ブログ記事「運用状況を把握するための Amazon DynamoDB のモニタリング」で確認すべきメトリクスのリストを参照してください。また、合成 canary (炭鉱のカナリアにちなんで名付けられた、障害を検出するための人工的なリクエスト) の使用や、顧客トラフィックのライブ観察も必要です。すべての問題が DynamoDB メトリクスに反映されるわけではありません。

MREC を使用している場合は、ReplicationLatency に継続的な増加が見られた際のアラームを設定します。この増加は、グローバルテーブルの書き込み設定がリージョンごとに異なるという偶発的な設定ミスを示している可能性があり、その結果、レプリケートされたリクエストが失敗し、レイテンシーが高くなります。また、リージョンに混乱が生じていることを示している可能性もあります。良い例としては、最近の平均が 180,000 ミリ秒を超えた場合にアラートを生成することが挙げられます。また、ReplicationLatency が 0 に下がり、レプリケーションの停止状態を示していることを監視することもできます。

各グローバルテーブルに十分な最大読み取り/書き込み設定を割り当てます。

リージョンから退避する理由を事前に特定します。決定に人間の判断が関与する場合は、すべての考慮事項を文書化します。この作業は、必要に迫られて行うのではなく、事前に慎重に行う必要があります。

リージョンから退避する際に実行する必要があるすべてのアクションのランブックを用意しておきます。通常、グローバルテーブルに関係する作業はほとんどありませんが、スタックの残りの部分を移動するのは複雑な作業になる場合があります。

詳細については、AWS ブログ記事「Amazon DynamoDB グローバルテーブルを使用した回復性の高いアプリケーションの構築: パート 4」を参照してください。

リージョンの退避を含め、ランブックのあらゆる側面を定期的にテストします。テストしないと、ランブックの信頼性が低下します。

AWS Resilience Hub を使用して、アプリケーション全体 (グローバルテーブルを含む) のレジリエンスを評価することを検討します。ダッシュボードを通じて、アプリケーションポートフォリオ全体のレジリエンスステータスを包括的に確認できます。

ARC の準備状況チェックを使用して、アプリケーションの現在の設定を評価し、ベストプラクティスから逸脱していないか追跡することを検討します。

Route 53 または Global Accelerator で使用するヘルスチェックを記述する際には、データベースフロー全体をカバーする一連の呼び出しを行います。チェックを制限し、DynamoDB エンドポイントが起動していることを確認するだけでは、AWS Identity and Access Management (IAM) 設定エラー、コードデプロイの問題、DynamoDB 外のスタックでの障害、平均読み取りまたは書き込みレイテンシーを超える状況といった、障害のさまざまな状態をカバーできません。

従来の DynamoDB テーブルへの書き込みオペレーションは、プロビジョニングされたテーブルの場合、書き込みキャパシティユニット (WCU)、オンデマンドテーブルの場合、書き込みリクエストユニット (WRU) で料金が設定されます。5 KB のアイテムを書き込むと、5 ユニットの料金が発生します。グローバルテーブルへの書き込みは、プロビジョニングされたテーブルの場合、レプリケートされた書き込みキャパシティユニット (rWCU)、オンデマンドテーブルの場合、レプリケートされた書き込みリクエストユニット (rWRU) で料金が設定されます。rWCU と rWRU の料金は、それぞれ WCU と WRU の料金と同額です。

rWCU 料金と rWRU 料金は、アイテムが直接書き込まれたか、レプリケーションを介して書き込まれた、すべてのリージョンで発生します。リージョン間のデータ転送料金が適用されます。

グローバルセカンダリインデックス (GSI) への書き込みはローカル書き込みオペレーションと見なされ、通常の書き込みユニットを使用します。

現在、rWCU または rWRU に利用できるリザーブドキャパシティはありません。WCU 用のリザーブドキャパシティの購入は、GSI が書き込みユニットを消費するテーブルでは有益な場合があります。

グローバルテーブルに新しいリージョンを追加すると、DynamoDB は新しいリージョンを自動的にブートストラップし、テーブルの GB サイズに基づいてテーブルを復元したかのように料金が発生します。リージョン間のデータ転送料金もかかります。

US リージョンセット: 米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)

EU リージョンセット: 欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)

AP リージョンセット: アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)。

レプリカテーブルは、他のテーブルを削除するのと同じ方法で削除できます。グローバルテーブルを削除すると、そのリージョンへのレプリケーションが停止し、そのリージョンに保持されているテーブルのコピーが削除されます。ただし、テーブルのコピーを独立したエンティティとして保持している間は、レプリケーションを停止または一時停止することはできません。

MRSC テーブルは、厳密に 3 つのリージョンにデプロイする必要があります。レプリカを削除するには、MRSC テーブルがローカルテーブルとなるように、すべてのレプリカと監視を削除する必要があります。

各グローバルテーブルは、書き込み元に関係なく、すべての書き込みオペレーションに基づいて独立したストリームを生成します。DynamoDB ストリームを 1 つのリージョンで使用するか、すべてのリージョンで (個別に) 使用するかを選択できます。レプリケートされた書き込みオペレーションではなく、ローカル書き込みオペレーションを処理する場合は、各項目に独自のリージョン属性を追加して、書き込みリージョンを識別できます。次に、Lambda イベントフィルターを使用して、ローカルリージョンでの書き込みオペレーションに対してのみ Lambda 関数を呼び出すことができます。これは挿入および更新オペレーションには役立ちますが、削除オペレーションには役立ちません。

マルチリージョンの結果整合性 (MREC テーブル) を設定したグローバルテーブルでは、レプリカテーブルの DynamoDB ストリームから変更を読み取り、それを他のすべてのレプリカテーブルに適用して、変更をレプリケートします。したがって、デフォルトの場合 DynamoDB は、MREC グローバルテーブル内のすべてのレプリカで有効になっており、こうしたレプリカで無効にすることはできません。MREC のレプリケーションプロセスでは、短時間に発生した複数の変更を 1 度の書き込みオペレーションとして結合し、レプリケートを行えます。その結果、各レプリカのストリームには、わずかに異なるレコードが含まれている可能性があります。MREC レプリカの DynamoDB Streams レコードは、常に項目ごとに順序付けられますが、項目間の順序はレプリカによって異なる場合があります。

マルチリージョンの強力な整合性を設定したグローバルテーブル (MRSC テーブル) では、レプリケーションに DynamoDB Streams が使用されないため、デフォルトの場合、MRSC レプリカではこの機能は有効になっていません。しかし、設定により、MRSC レプリカで DynamoDB Streams を有効にすることができます。MRSC レプリカの DynamoDB Streams レコードはすべてのレプリカで同一であり、常に項目ごとに順序付けされますが、項目間の順序付けはレプリカ間で異なる場合があります。

MRSC テーブルにトランザクションオペレーションを行うと、エラーが返ります。

MREC テーブルでのトランザクションオペレーションでは、書き込みオペレーションが最初に発生したリージョン内でのみ、アトミック性、整合性、分離性、耐久性 (ACID) が保証されます。グローバルテーブルのリージョン間では、トランザクションはサポートされていません。例えば、米国東部 (オハイオ) および米国西部 (オレゴン) リージョンにレプリカを持つ MREC グローバルテーブルがあり、米国東部 (オハイオ) リージョンで TransactWriteItems オペレーションを実行すると、変更がレプリケートされたときに米国西部 (オレゴン) では部分的に完了したトランザクションが観察されることがあります。変更は、ソースリージョンでコミットされた後でのみ、他のリージョンにレプリケートされます。

データの耐久性を確保したい場合、DynamoDB には既に保護手段が用意されています。このサービスにより、耐久性が保証されます。

履歴記録のスナップショットを保持する場合 (規制要件を満たすためなど)、1 つのリージョンでバックアップすれば十分です。AWS Backup を使用してバックアップを別のリージョンにコピーできます。

誤って削除または変更したデータを復元する場合は、1 つのリージョンで DynamoDB ポイントインタイムリカバリ (PITR) を使用します。

CloudFormation は、DynamoDB テーブルとグローバルテーブルを 2 つの独立したリソース (AWS::DynamoDB::Table と AWS::DynamoDB::GlobalTable) として表します。1 つの方法としては、GlobalTable コンストラクトを使用してグローバルになる可能性のあるすべてのテーブルを作成します。これらのテーブルは、最初はスタンドアロンテーブルのままにし、必要に応じて後でリージョンを追加します。

CloudFormation では、レプリカの数に関係なく、各グローバルテーブルは単一リージョン内の単一スタックによって制御されます。テンプレートをデプロイすると、CloudFormation はすべてのレプリカを単一スタックのオペレーションの一部として作成および更新します。同じ AWS::DynamoDB::GlobalTable リソースを複数のリージョンにデプロイしないでください。これは、エラーとなるため、サポートされていません アプリケーションテンプレートを複数のリージョンにデプロイする場合は、条件を使用して単一リージョンに AWS::DynamoDB::GlobalTable リソースを作成できます。または、アプリケーションスタックとは別のスタック内に AWS::DynamoDB::GlobalTable リソースを定義し、それが単一リージョンにのみデプロイされるようにします。

通常のテーブルがあり、それを CloudFormation で管理したままグローバルテーブルに変換する場合は、次のようにします。削除ポリシーを Retain に設定して、テーブルをスタックから削除し、コンソールでテーブルをグローバルテーブルに変換します。次に、グローバルテーブルを新しいリソースとしてスタックにインポートします。詳細については、「AWS GitHub リポジトリ」を参照してください。

クロスアカウントレプリケーションは現在サポートされていません。