# DynamoDB グローバルテーブルの準備チェックリスト
グローバルテーブルをデプロイするときの決定事項とタスクには、次のチェックリストを使用してください。
+ 対象のユースケースの場合、MRSC と、MREC の整合性モードでは、どちらの利点が大きいかを判断します。レイテンシーなどのトレードオフが大きい場合でも、強力な整合性が必要ですか?
+ グローバルテーブルに参加するリージョンの数と各リージョンを決定します。MRSC の使用を計画している場合は、3 番目のリージョンをレプリカにするか、監視にするかを決定します。
+ アプリケーションの書き込みモードを決定します。これは整合性モードとは異なります。詳細については、「[DynamoDB グローバルテーブルによる書き込みモード](bp-global-table-design.prescriptive-guidance.writemodes.md)」を参照してください。
+ 書き込みモードに基づいて「[DynamoDB のルーティング戦略](bp-global-table-design.prescriptive-guidance.request-routing.md)」戦略を計画します。
+ 整合性モード、書き込みモード、ルーティング戦略に基づいて、[ 退避プロセス グローバルテーブルを使用したリージョンからの退避 リージョンの退避とは、アクティビティ (通常は読み取りおよび書き込みアクティビティだが、読み取りアクティビティの場合もある) をそのリージョンから移行するプロセスを意味します。 ライブリージョンからの退避ライブリージョン ライブリージョンからの退避 ライブリージョンからの退避の決定には、さまざまな理由が考えられます。例えば、通常のビジネスアクティビティの一部である (例: 1 つのリージョンへの書き込みモードを使い、フォローザサン方式を取っている)、現在アクティブなリージョンをビジネス上変更する、DynamoDB 外で生じたソフトウェアスタック障害に対応する、リージョン内のレイテンシーが通常よりも増加したといった一般的な問題が発生している、などです。 *任意のリージョンへの書き込み*モードを使用すると、ライブリージョンから簡単に退避できます。任意のルーティングシステムを使用して、トラフィックを代替リージョンにルーティングでき、退避したリージョンでの書き込みオペレーションを通常どおりレプリケートすることが可能です。 1 つのリージョンへの書き込みモードと、自分のリージョンへの書き込みモードは、一般的に、MREC テーブルで使用されます。したがって、新しいアクティブリージョンで書き込みオペレーションを開始する前に、アクティブリージョンへのすべての書き込みオペレーションが完全に記録、ストリーム処理、グローバルに伝播されたことを確認し、その後は、最新バージョンのデータに書き込みオペレーションが行われるようにする必要があります。 例えば、リージョン A がアクティブ、リージョン B がパッシブだとします (リージョン A をホームとするテーブル全体または項目のいずれかが対象)。退避を実行する一般的なメカニズムは、A への書き込みオペレーションを一時停止し、そのオペレーションが B に完全に伝播されるまで待ち、アーキテクチャスタックを更新して B がアクティブであることを認識してから、B への書き込みオペレーションを再開することです。リージョン A がリージョン B にデータを完全にレプリケートしたことを確実に示すメトリクスはありません。リージョン A が正常であれば、リージョン A への書き込みオペレーションを一時停止し、`ReplicationLatency` メトリクスの最新の最大値の 10 倍を待てば、通常はレプリケーションが完了したことを十分に確認できます。リージョン A に異常があり、他の領域でのレイテンシーの増加も示している場合は、待機時間の倍数を大きくします。 オフラインリージョンからの退避オフラインリージョン オフラインリージョンからの退避 考慮すべき特別なケースがあります。リージョン A が予告なしに完全にオフラインになった場合、どのような影響が生じるでしょうか? 非常にまれなケースですが、考慮する必要があります。
オフライン MRSC テーブルの退避
そのような状況が MRSC テーブルで発生した場合、特別な操作は必要ありません。MRSC グローバルテーブルでは、目標復旧時点 (RPO) ゼロがサポートされています。オフラインリージョンの MRSC テーブルに実行され成功したすべての書き込みオペレーションは、他のすべてのリージョンテーブルに適用されるため、リージョンが予告なしに完全にオフラインになっても、データに差が生じる可能性はありません。他のリージョンにあるレプリカを業務に引き続き使用できます。
オフライン MREC テーブルの退避
そのような状況が MREC テーブルで発生した場合、リージョン A でまだ伝播されていない書き込みオペレーションはすべて保持され、リージョン A がオンラインに戻った後に伝播されます。書き込みオペレーションは失われませんが、その伝播は無期限に遅延します。
このイベントの処理方法は、アプリケーションの決定によります。ビジネスの継続性を確保するために、書き込みオペレーションを新しいプライマリリージョン B に移行することが必要になる場合があります。ただし、リージョン A の項目に対する書き込みオペレーションの伝播が保留されているときに、リージョン B でその項目が更新を受け取ると、*最終書き込み者優先*モデルに従ってその伝播は抑制されます。リージョン B での更新は、着信する書き込みリクエストを抑制する可能性があります。
*任意のリージョンへの書き込み*モードでは、リージョン A の項目が最終的にリージョン B に伝播されることを信頼し、リージョン A がオンラインに戻るまで項目が欠落する可能性を認識しながら、リージョン B で読み取りおよび書き込みオペレーションを続行できます。可能であれば、べき等書き込みオペレーションなどでは、最近の書き込みトラフィックを (アップストリームのイベントソースを使用するなどして) 再生することを検討してください。これにより、欠落している可能性のある書き込みオペレーションのギャップを埋め、最終書き込み者優先の競合解決により、着信する書き込みオペレーションの最終的な伝播を抑制します。
他の書き込みモードでは、どの程度の作業を継続できるかを、少し時代遅れの方法で考慮する必要があります。リージョン A がオンラインに戻るまで、`ReplicationLatency` で追跡する書き込みオペレーションの一部の短い期間は失われます。ビジネスを継続できるでしょうか。一部のユースケースでは可能ですが、他のユースケースでは追加の緩和メカニズムがないと難しい場合があります。
例えば、あるリージョン全体で障害が発生した後でも、利用可能なクレジット残高を中断することなく維持する必要があるとします。残高を 2 つの異なる項目に分割し、1 つはリージョン A に、もう 1 つはリージョン B に置き、それぞれ利用可能な残高を半分にして開始できます。この場合は、*自分のリージョンへの書き込み*モードを使用します。各リージョンで処理されたトランザクションの更新は、残高のローカルコピーに対して書き込まれます。リージョン A が完全にオフラインになっても、リージョン B でトランザクション処理を続行でき、書き込みオペレーションはリージョン B に保持されている残高部分に制限されます。このように残高を分割すると、残高が少なくなった場合やクレジットの再調整が必要になった場合に複雑になりますが、保留中の書き込みオペレーションが不安定でも安全にビジネスを回復できる一例となります。
別の例として、ウェブフォームのデータをキャプチャするとします。[オプティミスティック同時実行制御 (OCC)](DynamoDBMapper.OptimisticLocking.md) (OCC) を使用してデータ項目にバージョンを割り当て、最新バージョンを非表示フィールドとしてウェブフォームに埋め込むことができます。送信するたびに、データベース内のバージョンがフォーム作成時のバージョンとまだ一致する場合にのみ、書き込みオペレーションが成功します。バージョンが一致しない場合、データベース内の現在のバージョンに基づいてウェブフォームを更新 (または慎重にマージ) することで、ユーザーは再度続行できます。OCC モデルは通常、別のクライアントがデータを上書きして新しいバージョンを生成するのを防ぎますが、フェイルオーバー中にクライアントが古いバージョンのデータに遭遇する可能性がある場合にも役立ちます。タイムスタンプをバージョンとして使用しているとします。フォームを当初 12:00 にリージョン A に対して作成しましたが、(フェイルオーバー後に) リージョン B に書き込もうとして、データベースの最新バージョンが 11:59 であることに気付いたとします。このシナリオの場合、クライアントは 12:00 バージョンがリージョン B に伝播されるのを待ってからそのバージョンに書き込むか、11:59 バージョンに基づいて構築し、新しい 12:01 バージョンを作成することができます (書き込み後、リージョン A の回復後に着信したバージョンは抑制されます)。
3 つ目の例として、金融サービス会社が顧客アカウントおよび金融取引に関するデータを DynamoDB データベースに保持しているとします。同社は、リージョン A が完全に停止した場合、アカウントに関連する書き込みアクティビティのすべてがリージョン B で完全に利用可能であることを確認するか、リージョン A がオンラインに戻るまでアカウントを部分的なものとして隔離したいと考えていました。すべての業務を一時停止するのではなく、伝播されていないトランザクションがあると判断したごく一部のアカウントに対してのみ業務を一時停止することにしました。これを実現するために、同社は 3 番目のリージョン (リージョン C と呼びます) を使用しました。リージョン A で書き込みオペレーションを処理する前に、保留中のオペレーション (アカウントの新規トランザクション数など) の簡潔な要約をリージョン C に配置しました。この要約は、リージョン B のビューが完全に最新であるかどうかを判断するのに十分でした。このアクションにより、リージョン C での書き込み時点から、リージョン A が書き込みオペレーションを受け入れてリージョン B がそれを受け取るまでの間、アカウントは事実上ロックされました。リージョン C のデータは、フェイルオーバープロセスの一部として以外は使用されませんでした。その後、リージョン B はリージョン C とデータを相互チェックして、古いアカウントがないかどうかを確認できました。これらのアカウントは、リージョン A リカバリによって部分的なデータがリージョン B に伝播されるまで隔離済みとしてマークされます。リージョン C に障害が発生した場合は、代わりに新しいリージョン D をスピンアップして使用できます。リージョン C のデータはごく一時的なもので、数分後には処理中の書き込みオペレーションの最新の記録がリージョン D に反映されて十分に役立つようになります。リージョン B に障害が発生しても、リージョン A はリージョン C と協力して書き込みリクエストを引き続き受け入れることができます。同社は、より高いレイテンシーの書き込み (C に続けて A という 2 つのリージョンへの書き込み) をあえて受け入れ、アカウントの状態を簡潔に要約できるデータモデルを持つことができたことを喜んでいます。 ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title) [退避プロセス](bp-global-table-design.prescriptive-guidance.evacuation.md) を定義します。
+ リージョンごとのヘルス、レイテンシー、エラーに関するメトリクスをキャプチャします。DynamoDB メトリクスのリストについては、AWS ブログ記事「[運用状況を把握するための Amazon DynamoDB のモニタリング](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)」で確認すべきメトリクスのリストを参照してください。また、[合成 canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (炭鉱のカナリアにちなんで名付けられた、障害を検出するための人工的なリクエスト) の使用や、顧客トラフィックのライブ観察も必要です。すべての問題が DynamoDB メトリクスに反映されるわけではありません。
+ MREC を使用している場合は、`ReplicationLatency` に継続的な増加が見られた際のアラームを設定します。この増加は、グローバルテーブルの書き込み設定がリージョンごとに異なるという偶発的な設定ミスを示している可能性があり、その結果、レプリケートされたリクエストが失敗し、レイテンシーが高くなります。また、リージョンに混乱が生じていることを示している可能性もあります。[良い例](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)としては、最近の平均が 180,000 ミリ秒を超えた場合にアラートを生成することが挙げられます。また、`ReplicationLatency` が 0 に下がり、レプリケーションの停止状態を示していることを監視することもできます。
+ 各グローバルテーブルに十分な最大読み取り/書き込み設定を割り当てます。
+ リージョンから退避する理由を事前に特定します。決定に人間の判断が関与する場合は、すべての考慮事項を文書化します。この作業は、必要に迫られて行うのではなく、事前に慎重に行う必要があります。
+ リージョンから退避する際に実行する必要があるすべてのアクションのランブックを用意しておきます。通常、グローバルテーブルに関係する作業はほとんどありませんが、スタックの残りの部分を移動するのは複雑な作業になる場合があります。
**注記**
フェイルオーバー手順のベストプラクティスを実装するには、コントロールプレーンでのオペレーションではなくデータプレーンでのオペレーションにのみ依存すると良いでしょう。リージョンでの障害発生中には、一部のコントロールプレーンオペレーションのパフォーマンスが低下する可能性があるからです。
詳細については、AWS ブログ記事「[Amazon DynamoDB グローバルテーブルを使用した回復性の高いアプリケーションの構築: パート 4](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/)」を参照してください。
+ リージョンの退避を含め、ランブックのあらゆる側面を定期的にテストします。テストしないと、ランブックの信頼性が低下します。
+ [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) を使用して、アプリケーション全体 (グローバルテーブルを含む) のレジリエンスを評価することを検討します。ダッシュボードを通じて、アプリケーションポートフォリオ全体のレジリエンスステータスを包括的に確認できます。
+ ARC の準備状況チェックを使用して、アプリケーションの現在の設定を評価し、ベストプラクティスから逸脱していないか追跡することを検討します。
+ Route 53 または Global Accelerator で使用するヘルスチェックを記述する際には、データベースフロー全体をカバーする一連の呼び出しを行います。チェックを制限し、DynamoDB エンドポイントが起動していることを確認するだけでは、AWS Identity and Access Management (IAM) 設定エラー、コードデプロイの問題、DynamoDB 外のスタックでの障害、平均読み取りまたは書き込みレイテンシーを超える状況といった、障害のさまざまな状態をカバーできません。
## グローバルテーブルのデプロイに関するよくある質問 (FAQ)
**グローバルテーブルの料金はいくらですか?**
+ 従来の DynamoDB テーブルへの書き込みオペレーションは、プロビジョニングされたテーブルの場合、書き込みキャパシティユニット (WCU)、オンデマンドテーブルの場合、書き込みリクエストユニット (WRU) で料金が設定されます。5 KB のアイテムを書き込むと、5 ユニットの料金が発生します。グローバルテーブルへの書き込みは、プロビジョニングされたテーブルの場合、レプリケートされた書き込みキャパシティユニット (rWCU)、オンデマンドテーブルの場合、レプリケートされた書き込みリクエストユニット (rWRU) で料金が設定されます。rWCU と rWRU の料金は、それぞれ WCU と WRU の料金と同額です。
+ rWCU 料金と rWRU 料金は、アイテムが直接書き込まれたか、レプリケーションを介して書き込まれた、すべてのリージョンで発生します。リージョン間のデータ転送料金が適用されます。
+ グローバルセカンダリインデックス (GSI) への書き込みはローカル書き込みオペレーションと見なされ、通常の書き込みユニットを使用します。
+ 現在、rWCU または rWRU に利用できるリザーブドキャパシティはありません。WCU 用のリザーブドキャパシティの購入は、GSI が書き込みユニットを消費するテーブルでは有益な場合があります。
+ グローバルテーブルに新しいリージョンを追加すると、DynamoDB は新しいリージョンを自動的にブートストラップし、テーブルの GB サイズに基づいてテーブルを復元したかのように料金が発生します。リージョン間のデータ転送料金もかかります。
**グローバルテーブルはどのリージョンをサポートしていますか?**
[グローバルテーブル (現行バージョンは 2019.11.21)](GlobalTables.md) については、MREC テーブルの場合、すべての AWS リージョン が、MRSC テーブルの場合、次のリージョンセットがサポートされています。
+ US リージョンセット: 米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)
+ EU リージョンセット: 欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)
+ AP リージョンセット: アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)。
**GSI はグローバルテーブルでどのように処理されますか?**
[グローバルテーブルバージョン 2019.11.21 (現行)](GlobalTables.md) では、あるリージョンで GSI を作成すると、他の参加リージョンでも自動的に作成され、自動的にバックフィルされます。
**グローバルテーブルのレプリケーションを停止するにはどうしたらいいですか?**
+ レプリカテーブルは、他のテーブルを削除するのと同じ方法で削除できます。グローバルテーブルを削除すると、そのリージョンへのレプリケーションが停止し、そのリージョンに保持されているテーブルのコピーが削除されます。ただし、テーブルのコピーを独立したエンティティとして保持している間は、レプリケーションを停止または一時停止することはできません。
+ MRSC テーブルは、厳密に 3 つのリージョンにデプロイする必要があります。レプリカを削除するには、MRSC テーブルがローカルテーブルとなるように、すべてのレプリカと監視を削除する必要があります。
**DynamoDB Streams はグローバルテーブルとどのようにやり取りするのですか?**
+ 各グローバルテーブルは、書き込み元に関係なく、すべての書き込みオペレーションに基づいて独立したストリームを生成します。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 Accelerator キャッシュ (DAX) とどのようにやり取りするのですか?**
グローバルテーブルは DynamoDB を直接更新することで DAX をバイパスするため、DAX はそれが古いデータを保持していることを認識しません。DAX キャッシュは、キャッシュの TTL が期限切れになったときにのみ更新されます。
**テーブルのタグは伝播されますか?**
いいえ、タグは自動的には伝播されません。
**すべてのリージョンのテーブルをバックアップすべきですか? 1 つのリージョンのテーブルのみをバックアップすべきですか?**
答えはバックアップの目的によって異なります。
+ データの耐久性を確保したい場合、DynamoDB には既に保護手段が用意されています。このサービスにより、耐久性が保証されます。
+ 履歴記録のスナップショットを保持する場合 (規制要件を満たすためなど)、1 つのリージョンでバックアップすれば十分です。AWS Backup を使用してバックアップを別のリージョンにコピーできます。
+ 誤って削除または変更したデータを復元する場合は、1 つのリージョンで [DynamoDB ポイントインタイムリカバリ (PITR)](PointInTimeRecovery_Howitworks.md) を使用します。
** を使用してグローバルテーブルをデプロイするにはどうすればいいですか?CloudFormation**
+ CloudFormation は、DynamoDB テーブルとグローバルテーブルを 2 つの独立したリソース (`AWS::DynamoDB::Table` と `AWS::DynamoDB::GlobalTable`) として表します。1 つの方法としては、`GlobalTable` コンストラクトを使用してグローバルになる可能性のあるすべてのテーブルを作成します。これらのテーブルは、最初はスタンドアロンテーブルのままにし、必要に応じて後でリージョンを追加します。
+ CloudFormation では、レプリカの数に関係なく、各グローバルテーブルは単一リージョン内の単一スタックによって制御されます。テンプレートをデプロイすると、CloudFormation はすべてのレプリカを単一スタックのオペレーションの一部として作成および更新します。同じ [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) リソースを複数のリージョンにデプロイしないでください。これは、エラーとなるため、サポートされていません アプリケーションテンプレートを複数のリージョンにデプロイする場合は、条件を使用して単一リージョンに `AWS::DynamoDB::GlobalTable` リソースを作成できます。または、アプリケーションスタックとは別のスタック内に `AWS::DynamoDB::GlobalTable` リソースを定義し、それが単一リージョンにのみデプロイされるようにします。
+ 通常のテーブルがあり、それを CloudFormation で管理したままグローバルテーブルに変換する場合は、次のようにします。削除ポリシーを `Retain` に設定して、テーブルをスタックから削除し、コンソールでテーブルをグローバルテーブルに変換します。次に、グローバルテーブルを新しいリソースとしてスタックにインポートします。詳細については、「[AWS GitHub リポジトリ](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk)」を参照してください。
+ クロスアカウントレプリケーションは現在サポートされていません。