

# グローバルテーブルの重要な概念
<a name="globaltables-CoreConcepts"></a>

以下のセクションでは、Amazon DynamoDB におけるグローバルテーブルの概念および動作について説明します

## 概念
<a name="globaltables-CoreConcepts.KeyConcepts"></a>

*グローバルテーブル*は、AWS リージョン間でテーブルデータをレプリケートする DynamoDB 機能です。

*レプリカテーブル* (または、レプリカ) は、グローバルテーブルの一環として機能する DynamoDB テーブルです。グローバルテーブルは、異なる AWS リージョンにまたがる 2 つ以上のレプリカテーブルで構成されます。各グローバルテーブルは、AWS リージョンごとに 1 つのレプリカのみを持つことができます。グローバルテーブル内のすべてのレプリカは、同じテーブル名、プライマリキースキーマ、および項目データを共有します。

アプリケーションが 1 つのリージョンのレプリカにデータを書き込むと、DynamoDB は自動的にその書き込みをグローバルテーブル内の他のすべてのレプリカにレプリケートします。グローバルテーブルの詳しい使用方法については、「[チュートリアル: グローバルテーブルの作成](V2globaltables.tutorial.md)」または「[チュートリアル: マルチアカウントグローバルテーブルの作成](V2globaltables_MA.tutorial.md)」を参照してください。

## バージョン
<a name="globaltables-CoreConcepts.Versions"></a>

DynamoDB グローバルテーブルには、[グローバルテーブルバージョン 2019.11.21 (現行)](GlobalTables.md) と [グローバルテーブルバージョン 2017.11.29 (レガシー)](globaltables.V1.md) の 2 つのバージョンがあります。可能な限り、グローバルテーブルバージョン 2019.11.21 (現行) を使用する必要があります。このドキュメントセクションの情報は、バージョン 2019.11.21 (現行) 用です。詳細については、「グローバルテーブルのバージョンを確認する[グローバルテーブルのバージョンを確認する](V2globaltables_versions.md#globaltables.DetermineVersion)」を参照してください。

## 利用可能な状況
<a name="globaltables-CoreConcepts.availability"></a>

グローバルテーブルは、マルチリージョンの高可用性アーキテクチャの実装を容易にすることで、ビジネス継続性の向上に役立ちます。1 つの AWS リージョンのワークロードに障害が発生した場合、アプリケーショントラフィックを別のリージョンに移行し、同じグローバルテーブル内の別のレプリカテーブルに対して読み取りと書き込みを実行できます。

グローバルテーブル内の各レプリカテーブルは、単一リージョンの DynamoDB テーブルと同じ耐久性と可用性を提供します。グローバルテーブルは 99.999% の可用性[サービスレベルアグリーメント (SLA)](https://aws.amazon.com//dynamodb/sla/) を提供しますが、単一リージョンテーブルでは 99.99% です。

## フォールトインジェクションテスト
<a name="fault-injection-testing"></a>

MREC と MRSC のグローバルテーブルはどちらも、制御されたフォールトインジェクション実験を実行してアプリケーションの耐障害性を向上させるためのフルマネージドサービスである [AWS Fault Injection Service](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) (AWS FIS) と統合されています。AWS FIS を使用すると、次のことができます。
+ 特定の障害シナリオを定義する実験テンプレートを作成します。
+ アプリケーションの耐障害性を検証するため、リージョンの分離 (つまり、選択したレプリカとのレプリケーションを一時停止すること) をシミュレートして障害を注入し、エラー処理、復旧メカニズム、1 つの AWS リージョンで中断が発生した場合のマルチリージョントラフィックシフトの動作をテストします。

例えば、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン) にレプリカがあるグローバルテーブルでは、米国東部 (バージニア北部) と米国西部 (オレゴン) が通常のオペレーションを継続している間に、米国東部 (オハイオ) で実験を実行してリージョンの分離をテストできます。この制御されたテストは、本番稼働用ワークロードに影響を与える前に潜在的な問題を特定して解決するのに役立ちます。

AWS FIS でサポートされているアクションの完全なリストについては、「*AWS FIS ユーザーガイド*」の「[アクションターゲット](https://docs.aws.amazon.com/fis/latest/userguide/action-sequence.html#action-targets)」を参照してください。また、リージョン間の DynamoDB レプリケーションを一時停止するには、「[クロスリージョン接続](https://docs.aws.amazon.com/fis/latest/userguide/cross-region-scenario.html)」を参照してください。

AWS FIS で使用できる Amazon DynamoDB グローバルテーブルアクションの詳細については、「*AWS FIS ユーザーガイド*」の「[DynamoDB グローバルテーブルアクションリファレンス](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dynamodb-actions-reference)」を参照してください。

フォールトインジェクション実験の実行を開始するには、「AWS FIS ユーザーガイド」の「[AWS FIS 実験の計画](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-planning.html)」を参照してください。

**注記**  
MRSC での AWS FIS 実験中は、結果整合性のある読み込みが許可されますが、MREC と同様に請求モードの変更やテーブルスループットの設定などのテーブル設定の更新は許可されません。エラーコードの詳細については、CloudWatch メトリクス [`FaultInjectionServiceInducedErrors`](metrics-dimensions.md#FaultInjectionServiceInducedErrors) を確認してください。

## 有効期限 (TTL)
<a name="global-tables-ttl"></a>

MREC 用に設定されたグローバルテーブルは[有効期限](TTL.md) (TTL) 削除の設定をサポートしています。TTL 設定は、グローバルテーブル内のすべてのレプリカに対して自動的に同期されます。TTL がリージョン内のレプリカから項目を削除すると、削除はグローバルテーブル内の他のすべてのレプリカにレプリケートされます。TTL は書き込み容量を消費しないため、削除が発生したリージョンでは TTL 削除に対して課金されません。ただし、グローバルテーブルのレプリカが存在する他のリージョンでレプリケートされた削除に対しては課金されます。

TTL 削除レプリケーションは、削除がレプリケートされるレプリカの書き込み容量を消費します。プロビジョンドキャパシティ用に設定されたレプリカは、書き込みスループットと TTL 削除スループットの組み合わせがプロビジョンド書き込みキャパシティを超える場合、リクエストをスロットリングすることがあります。

マルチリージョンの強力な整合性 (MRSC) 用に設定されたグローバルテーブルは、有効期限 (TTL) 削除の設定をサポートしていません。

## Streams
<a name="global-tables-streams"></a>

マルチリージョンの結果整合性 (MREC) 用に設定されたグローバルテーブルは、レプリカテーブルの [DynamoDB Stream](Streams.md) からこれらの変更を読み取り、その変更を他のすべてのレプリカテーブルに適用することで、変更をレプリケートします。したがって、Streams は MREC グローバルテーブル内のすべてのレプリカでデフォルトで有効になっており、それらのレプリカで無効にすることはできません。MREC レプリケーションプロセスでは、短期間に複数の変更を 1 つのレプリケートされた書き込みに結合する場合があり、各レプリカの Stream にわずかに異なるレコードが含まれる場合があります。MREC レプリカのストリームレコードは、同じ項目に対するすべての変更の順序を維持しますが、異なる項目に対する変更の相対的な順序はレプリカによって異なる場合があります。

グローバルテーブル内の他のリージョンではなく、特定のリージョンで発生した変更について Streams レコードを処理するアプリケーションを作成する場合は、各項目にその項目の変更が発生したリージョンを定義する属性を追加できます。この属性を使用して、特定のリージョンの変更に対してのみ Lambda 関数を呼び出す Lambda イベントフィルターの使用など、他のリージョンで発生した変更について Streams レコードをフィルタリングできます。

マルチリージョンの強力な整合性 (MRSC) 用に設定されたグローバルテーブルは、レプリケーションに DynamoDB Streams を使用しないため、MRSC レプリカでは Streams はデフォルトで有効になっていません。MRSC レプリカで Streams を有効にできます。MRSC レプリカの Streams レコードは、Stream レコードの順序付けを含め、すべてのレプリカで同じです。

## トランザクション
<a name="global-tables-transactions"></a>

MREC 用に設定されたグローバルテーブルでは、DynamoDB トランザクションオペレーション ([https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html) および [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html)) は、操作が呼び出されたリージョン内でのみアトミックです。トランザクション書き込みはリージョン間でユニットとしてレプリケートされません。つまり、特定の時点で、トランザクション内の書き込みの一部のみが、他のレプリカでの読み取り操作によって返される可能性があります。

例えば、米国東部 (オハイオ) リージョンと米国西部 (オレゴン) リージョンにレプリカを持つグローバルテーブルがある場合、米国東部 (オハイオ) リージョンで `TransactWriteItems` オペレーションを実行すると、変更がレプリケートされたときに米国西部 (オレゴン) では部分的に完了したトランザクションが観察されることがあります。変更は、ソースリージョンでコミットされた場合にのみ、他のリージョンにレプリケートされます。

マルチリージョンの強力な整合性 (MRSC) 用に設定されたグローバルテーブルはトランザクションオペレーションをサポートしておらず、これらのオペレーションが MRSC レプリカで呼び出されるとエラーが返されます。

## 読み取りおよび書き込みスループット
<a name="globaltables-CoreConcepts.Throughput"></a>

### プロビジョニングモード
<a name="gt_throughput.provisioned"></a>

レプリケーションは書き込み容量を消費します。プロビジョンドキャパシティ用に設定されたレプリカは、アプリケーションの書き込みスループットとレプリケーションスループットの組み合わせがプロビジョンド書き込みキャパシティを超えると、リクエストをスロットリングすることがあります。プロビジョニングモードを使用するグローバルテーブルの場合、読み取り容量と書き込み容量の両方の自動スケーリング設定がレプリカ間で同期されます。

レプリカレベルで [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughputOverride.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughputOverride.html) パラメータを使用して、グローバルテーブル内の各レプリカの読み取り容量設定を個別に設定できます。デフォルトでは、プロビジョニングされた読み取り容量への変更は、グローバルテーブル内のすべてのレプリカに適用されます。グローバルテーブルに新しいレプリカを追加する場合、レプリカレベルのオーバーライドが明示的に指定されていない限り、ソーステーブルまたはレプリカの読み取り容量が初期値として使用されます。

### オンデマンドモード
<a name="gt_throughput.on-demand"></a>

オンデマンドモードに設定されたグローバルテーブルの場合、書き込み容量はすべてのレプリカ間で自動的に同期されます。DynamoDB はトラフィックに基づいて容量を自動的に調整するため、レプリカ固有の読み取りまたは書き込み容量設定を管理する必要はありません。

## グローバルテーブルのモニタリング
<a name="monitoring-global-tables"></a>

マルチリージョンの結果整合性 (MREC) 用に設定されたグローバルテーブルは [`ReplicationLatency`](metrics-dimensions.md#ReplicationLatency) メトリクスを CloudWatch に発行します。このメトリクスは、項目がレプリカテーブルに書き込まれてから、その項目がグローバルテーブルの別のレプリカに表示されるまでの経過時間を追跡します。`ReplicationLatency` はミリ秒単位で表し、グローバルテーブル内のすべての送信元と送信先のリージョンペアに対して出力されます。

一般的な `ReplicationLatency` 値は、選択した AWS リージョン間の距離と、ワークロードタイプやスループットなどの他の変数によって異なります。例えば、米国西部 (北カリフォルニア) (us-west-1) リージョンのソースレプリカは、アフリカ (ケープタウン) (af-south-1) リージョンと比較して、米国西部 (オレゴン) (us-west-2) リージョンへの `ReplicationLatency` が低くなります。

`ReplicationLatency` の値が上昇している場合、1 つのレプリカからの更新が他のレプリカテーブルにタイムリーに伝播されていないことを示している可能性があります。この場合、アプリケーションの読み込みおよび書き込みアクティビティを別の AWS リージョンに一時的にリダイレクトすることができます。

マルチリージョンの強力な整合性 (MRSC) 用に設定されたグローバルテーブルは、`ReplicationLatency` メトリクスを発行しません。

## グローバルテーブルの管理に関する考慮事項
<a name="management-considerations"></a>

新しいグローバルテーブルレプリカの追加に使用したテーブルは、新しいレプリカが作成されてから 24 時間が経過するまで削除できません。

グローバルテーブルレプリカを含む AWS リージョンを無効にすると、それらのレプリカは、リージョンが無効になってから 20 時間後に単一リージョンテーブルに永続的に変換されます。