グローバルテーブルの準備チェックリストとよくある質問
グローバルテーブルをデプロイするときの決定事項とタスクには、次のチェックリストを使用してください。
グローバルテーブルに参加するリージョンの数と各リージョンを決定します。
アプリケーションの書き込みモードを決定します。詳細については、「グローバルテーブルによる書き込みモード」を参照してください。
書き込みモードに基づいて「グローバルテーブルを使用したリクエストルーティング」戦略を計画します。
リージョンごとのヘルス、レイテンシー、エラーに関するメトリクスをキャプチャします。DynamoDB メトリクスのリストについては、AWS ブログ記事「運用状況を把握するための Amazon DynamoDB のモニタリング
」で確認すべきメトリクスのリストを参照してください。また、合成 canary (炭鉱のカナリアにちなんで名付けられた、障害を検出するための人工的なリクエスト) の使用や、顧客トラフィックのライブ観察も必要です。すべての問題が DynamoDB メトリクスに反映されるわけではありません。 ReplicationLatencyの継続的な増加に対するアラームを設定します。この増加は、グローバルテーブルの書き込み設定がリージョンごとに異なるという偶発的な設定ミスを示している可能性があり、その結果、レプリケートされたリクエストが失敗し、レイテンシーが高くなります。また、リージョンに混乱が生じていることを示している可能性もあります。良い例としては、最近の平均が 180,000 ミリ秒を超えた場合にアラートを生成することが挙げられます。また、 ReplicationLatencyが 0 に下がり、レプリケーションの停止状態を示していることを監視することもできます。各グローバルテーブルに十分な最大読み取り/書き込み設定を割り当てます。
リージョンから退避する理由を事前に特定します。決定に人間の判断が関与する場合は、すべての考慮事項を文書化します。この作業は、必要に迫られて行うのではなく、事前に慎重に行う必要があります。
リージョンから退避する際に実行する必要があるすべてのアクションのランブックを用意しておきます。通常、グローバルテーブルに関係する作業はほとんどありませんが、スタックの残りの部分を移動するのは複雑な作業になる場合があります。
注記
リージョンに障害が発生すると、一部のコントロールプレーンオペレーションのパフォーマンスが低下する可能性があるため、コントロールプレーンオペレーションには依存せず、データプレーンオペレーションにのみ依存するのがベストプラクティスです。
詳細については、AWS ブログ記事「Amazon DynamoDB グローバルテーブルを使用した回復性の高いアプリケーションの構築: パート 4
」を参照してください。 リージョンの退避を含め、ランブックのあらゆる側面を定期的にテストします。テストしないと、ランブックの信頼性が低下します。
Resilience Hub を使用して、アプリケーション全体 (グローバルテーブルを含む) のレジリエンスを評価することを検討します。ダッシュボードを通じて、アプリケーションポートフォリオ全体のレジリエンスステータスを包括的に確認できます。
ARC の準備状況チェックを使用して、アプリケーションの現在の設定を評価し、ベストプラクティスから逸脱していないか追跡することを検討します。
Route 53 または Global Accelerator で使用するヘルスチェックを作成する場合、DynamoDB エンドポイントが稼働していることを ping するだけでは不十分です。IAM 設定エラー、コードデプロイの問題、DynamoDB 外部のスタック障害、平均を超える読み取り/書き込みレイテンシーなど、多くの障害モードは含まれていません。データベースフロー全体を実行する一連の呼び出しを実行するのが最善です。
グローバルテーブルのデプロイに関するよくある質問 (FAQ)
DynamoDB グローバルテーブルの使用全般に役立つ原則にはどのようなものがありますか?
DynamoDB グローバルテーブルにはコントロールノブがほとんどありませんが、それでもいくつかの考慮事項が必要です。書き込みモード、ルーティングモデル、および退避プロセスを決定する必要があります。すべてのリージョンにわたってアプリケーションをインストルメントし、グローバルヘルスを維持するためのルーティングの調整や退避に備える必要があります。これにより、読み取りと書き込みが低レイテンシーで、サービスレベルアグリーメントが 99.999% のグローバルに分散されたデータセットが実現します。
グローバルテーブルの料金はいくらですか?
従来の DynamoDB テーブルへの書き込みは、書き込みキャパシティユニット (WCU、プロビジョニングされたテーブルの場合) または書き込みリクエストユニット (WRU、オンデマンドテーブルの場合) で料金が設定されます。5 KB の項目を書き込むと、5 ユニットの料金が発生します。グローバルテーブルへの書き込みは、レプリケートされた書き込みキャパシティユニット (rWCU、プロビジョニングされたテーブルの場合) またはレプリケートされた書き込みリクエストユニット (rWRU、オンデマンドテーブルの場合) で料金が設定されます。
rWCU と rWRU には、レプリケーションの管理に必要なストリーミングインフラストラクチャのコストが含まれます。そのため、WCU や WRU よりも料金が 50% 高くなります。リージョン間のデータ転送料金がかかります。
レプリケートされた書き込みユニットの料金は、項目が直接書き込まれたか、レプリケートされて書き込まれた、すべてのリージョンで発生します。
グローバルセカンダリインデックス (GSI) への書き込みはローカル書き込みと見なされ、通常の書き込みユニットを使用します。
現在、rWCU に利用できるリザーブドキャパシティはありません。リザーブドキャパシティの購入は、GSI が書き込みユニットを消費するテーブルでは依然として有益な場合があります。
グローバルテーブルに新しいリージョンを追加するときの初期ブートストラップには、復元されたデータの GB あたりのリストアと同様の料金に加えて、リージョン間のデータ転送料金がかかります。
グローバルテーブルはどのリージョンをサポートしていますか?
グローバルテーブルバージョン 2019.11.21 (現行) は、ほとんどのリージョンで使用できます。レプリカを追加すると、DynamoDB コンソールの [リージョン] ドロップダウンリストに最新のリストが表示されます。
GSI はグローバルテーブルでどのように処理されますか?
グローバルテーブルバージョン 2019.11.21 (現行) では、あるリージョンで GSI を作成すると、他の参加リージョンでも自動的に作成され、自動的にバックフィルされます。
グローバルテーブルのレプリケーションを停止するにはどうしたらいいですか?
レプリカテーブルは、他のテーブルを削除するのと同じ方法で削除できます。グローバルテーブルを削除すると、そのリージョンへのレプリケーションが停止し、そのリージョンに保持されているテーブルのコピーが削除されます。ただし、テーブルのコピーを独立したエンティティとして保持している間は、レプリケーションを停止または一時停止することはできません。
DynamoDB Streams はグローバルテーブルとどのようにやり取りするのですか?
各グローバルテーブルは、書き込み元に関係なく、すべての書き込みに基づいて独立したストリームを生成します。DynamoDB ストリームを 1 つのリージョンで使用するか、すべてのリージョンで (個別に) 使用するかを選択できます。レプリケートされた書き込みオペレーションではなく、ローカル書き込みオペレーションを処理する場合は、各項目に独自のリージョン属性を追加して、書き込みリージョンを識別できます。次に、Lambda イベントフィルターを使用して、ローカルリージョンでの書き込みオペレーションに対してのみ Lambda 関数を呼び出すことができます。これは挿入および更新オペレーションには役立ちますが、残念ながら削除オペレーションには役立ちません。
グローバルテーブルはトランザクションをどのように処理するのですか?
トランザクションオペレーションは、書き込みオペレーションが最初に発生したリージョン内でのみ、不可分性、一貫性、分離性、および耐久性 (ACID) を保証します。グローバルテーブルのリージョン間では、トランザクションはサポートされていません。例えば、米国東部 (オハイオ) および米国西部 (オレゴン) リージョンにレプリカを持つグローバルテーブルがあり、米国東部 (オハイオ) リージョンで TransactWriteItems オペレーションを実行すると、変更がレプリケートされたときに米国西部 (オレゴン) では部分的に完了したトランザクションが観察されることがあります。変更は、ソースリージョンでコミットされた後でのみ、他のリージョンにレプリケートされます。
グローバルテーブルは DynamoDB Accelerator キャッシュ (DAX) とどのようにやり取りするのですか?
グローバルテーブルは DynamoDB を直接更新することで DAX をバイパスするため、DAX はそれが古いデータを保持していることを認識しません。DAX キャッシュは、キャッシュの TTL が期限切れになったときにのみ更新されます。
テーブルのタグは伝播されますか?
いいえ、タグは自動的には伝播されません。
すべてのリージョンのテーブルをバックアップすべきですか? 1 つのリージョンのテーブルのみをバックアップすべきですか?
答えはバックアップの目的によって異なります。データの耐久性を確保したい場合、DynamoDB には既に保護手段が用意されています。このサービスにより、耐久性が保証されます。履歴記録のスナップショットを保持する場合 (規制要件を満たすためなど)、1 つのリージョンでバックアップすれば十分です。AWS Backup を使用してバックアップを別のリージョンにコピーできます。誤って削除または変更したデータを復元する場合は、1 つのリージョンで DynamoDB ポイントインタイムリカバリ (PITR) を使用します。
AWS CloudFormation を使用してグローバルテーブルをデプロイするにはどうすればいいですか?
CloudFormation は、DynamoDB テーブルとグローバルテーブルを 2 つの独立したリソース (AWS::DynamoDB::Table と AWS::DynamoDB::GlobalTable) として表します。1 つの方法としては、GlobalTable コンストラクトを使用して、グローバルになる可能性のあるすべてのテーブルを作成します。その後、最初はスタンドアロンテーブルとして保持し、必要に応じて後でリージョンを追加できます。
CloudFormation では、レプリカの数に関係なく、各グローバルテーブルは単一リージョン内の単一スタックによって制御されます。テンプレートをデプロイすると、CloudFormation はすべてのレプリカを単一スタックのオペレーションの一部として作成および更新します。同じ AWS::DynamoDB::GlobalTable リソースを複数のリージョンにデプロイしないでください。これは、エラーとなるため、サポートされていません アプリケーションテンプレートを複数のリージョンにデプロイする場合は、条件を使用して単一リージョンに AWS::DynamoDB::GlobalTable リソースを作成できます。または、アプリケーションスタックとは別のスタック内に AWS::DynamoDB::GlobalTable リソースを定義し、それが単一リージョンにのみデプロイされるようにします。
通常のテーブルがあり、それを CloudFormationtion で管理したままグローバルテーブルに変換する場合は、削除ポリシーを [保持] に設定して、テーブルをスタックから削除し、コンソールでテーブルをグローバルテーブルに変換します。次に、グローバルテーブルを新しいリソースとしてスタックにインポートします。
クロスアカウントレプリケーションは現在サポートされていません。
