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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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