グローバルテーブルを管理するためのベストプラクティスと要件

Amazon DynamoDB グローバルテーブルを使用すると、テーブルデータを AWS リージョン間でレプリケートできます。データが適切にレプリケートされるように、グローバルテーブル内のレプリカテーブルとセカンダリインデックスにも、書き込みキャパシティーが同じように設定されていることが重要です。

後でわかりやすくするために、いつかグローバルテーブルになる可能性のあるテーブルの名前にリージョンを入れない方が便利な場合があります。

警告

各グローバルテーブルのテーブル名は、AWS アカウント内で一意である必要があります。

グローバルテーブルのバージョン

使用しているグローバルテーブルのバージョンを確認するには、「」を参照してください使用しているグローバルテーブルのバージョンを確認する。

キャパシティを管理するための要件

グローバルテーブルには、次の 2 つの方法のいずれかでスループットキャパシティが設定されている必要があります。

1. オンデマンドキャパシティモードは、レプリケートされた書き込み要求ユニット (rWRU) で測定されます

2. オートスケーリングでプロビジョニングされたキャパシティモードは、レプリケートされた書き込みキャパシティユニット (rWCU) で測定されます

オートスケーリングまたはオンデマンドキャパシティモードでプロビジョニングされたャパシティモードを使用すると、グローバルテーブルのすべてのリージョンにレプリケートされた書き込みを実行するのに十分なキャパシティが確保されます。

注記

いずれかのリージョンで 1 つのテーブルキャパシティモードから別のキャパシティモードに切り替えると、すべてのレプリカのモードが切り替わります。

グローバルテーブルのデプロイ

AWS CloudFormation では、各グローバルテーブルは、単一のリージョン内の単一のスタックによって制御されます。これは、レプリカの数に関係なく行われます。テンプレートをデプロイすると、1 回のスタックオペレーションの一部としてすべてのレプリカ CloudFormation を作成/更新します。このため、同じ AWS::DynamoDB::GlobalTable リソースを複数のリージョンにデプロイしないでください。デプロイはサポートされておらず、エラーが発生します。

アプリケーションテンプレートを複数のリージョンにデプロイする場合は、条件を使用して 1 つのリージョンにのみリソースを作成できます。または、アプリケーションスタックとは別のスタック内に AWS::DynamoDB::GlobalTable リソースを定義し、単一リージョンにのみデプロイされることを確認してください。詳細については、「 のグローバルテーブル」を参照してください。 CloudFormation

DynamoDB テーブルは AWS::DynamoDB::Table によって参照され、グローバルテーブルは AWS::DynamoDB::GlobalTable になります。 CloudFormation 関係する限り、これは基本的に 2 つの異なるリソースになります。そのため、1 つの方法として、グローバルになる可能性のあるすべてのテーブルを GlobalTable コンストラクトを使用して作成する方法があります。その後、最初はスタンドアロンテーブルとして保持し、必要に応じて後でリージョンに追加できます。

通常のテーブルがあり、 の使用中に変換する場合は CloudFormation、次の方法をお勧めします。

1. 削除ポリシーを保持するように設定します。

2. テーブルをスタックから削除します。

3. テーブルをコンソールでグローバルテーブルに変換します。

4. グローバルテーブルを新しいリソースとしてスタックにインポートします。

注記

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

グローバルテーブルを使用して、リージョンが停止する可能性への対処に役立てる

それぞれローカルの DynamoDB エンドポイントにアクセスする別のリージョンに、実行スタックの独立したコピーを所有、または迅速に作成できるようにします。

Route53 または AWS Global Accelerator を使用して、最も近い正常なリージョンにルーティングします。または、使用する可能性がある複数のエンドポイントをクライアントに認識させます。

各リージョンでヘルスチェックを行うと、DynamoDB のパフォーマンスが低下しているなど、スタックに問題があるかどうかを確実に判断できます。例えば、DynamoDB エンドポイントが稼働していることを、ping を実行するだけで確認しないでください。データベースフローが完全に成功するように、実際に呼び出しを行います。

ヘルスチェックに失敗した場合、トラフィックは他のリージョンにルーティングできます (DNS エントリを Route53 で更新するか、Global Accelerator のルートを変更するか、クライアントに別のエンドポイントを選択させます)。グローバルテーブルは、データが継続的に同期されるため RPO (復旧ポイント目標) が良好で、両方のリージョンで常に読み取りトラフィックと書き込みトラフィックの両方に対応できるため、RTO (目標復旧時間) も良好です。

ヘルスチェックの詳細については、「ヘルスチェックのタイプ」を参照してください。

注記

DynamoDB は、他のサービスが頻繁にコントロールプレーンオペレーションを構築するコアサービスであるため、DynamoDB がリージョン内のサービスを低下させているのに、他のサービスには影響がないというシナリオが発生することはほとんどありません。

グローバルテーブルのバックアップ

グローバルテーブルをバックアップする場合、1 つのリージョンのテーブルをバックアップするだけで十分です。すべてのリージョンのすべてのテーブルをバックアップする必要はありません。誤って削除または変更されたデータを回復することが目的であれば、1 つのリージョンの PITR で十分です。同様に、規制要件などの過去の目的でスナップショットを保存する場合は、1 つのリージョンにバックアップすれば十分です。バックアップされたデータは、AWS Backup を介して複数のリージョンにレプリケートできます。

レプリカと書き込みユニットの計算

計画を立てるには、あるリージョンが実行する書き込み数を取得し、それを他のリージョンごとに発生する書き込み数に加算する必要があります。1 つのリージョンで実行されるすべての書き込みは、すべてのレプリカリージョンでも実行する必要があるため、これは重要です。すべての書き込みを処理するのに十分なキャパシティがない場合、キャパシティの例外が発生します。さらに、リージョン間レプリケーションの待機時間が長くなります。

たとえば、オハイオ州のレプリカテーブルに 1 秒間に 5 回の書き込みを、バージニア北部のレプリカテーブルに 1 秒間に 10 回の書き込みを、アイルランドのレプリカテーブルに 1 秒あたり 5 回の書き込みを行うとします。この場合、オハイオ州、バージニア州北部、アイルランドの各リージョンで 20 rWCU または rWCU を消費すると予想されます。つまり、3 つのリージョンすべてで合計 60 rWCU を消費すると予想されます。

オートスケーリングによるプロビジョニングされたキャパシティと DynamoDB の詳細については、「DynamoDB Auto Scaling によるスループットキャパシティの自動管理」を参照してください。

注記

テーブルが自動スケーリングでプロビジョニングされたキャパシティーモードで実行されている場合、プロビジョニングされた書き込みキャパシティーは、各リージョンの自動スケーリング設定の範囲内で変動させることができます。