DynamoDB グローバルテーブルによる書き込みモード - Amazon DynamoDB

DynamoDB グローバルテーブルによる書き込みモード

グローバルテーブルは、テーブルレベルでは常にアクティブ/アクティブです。ただし、書き込みリクエストのルーティング方法を制御して、アクティブ/パッシブで構成することをお勧めします。特に MREC テーブルの場合にその方法が当てはまります。例えば、MREC テーブルで発生しかねない書き込みの競合を避けるには、書き込みリクエストを単一リージョンにルーティングするように設定すると良いでしょう。

マネージド書き込みには、主に 3 つのパターンがあります。これについては、次の 3 つのセクションで説明します。どの書き込みパターンがユースケースに適しているかを検討する必要があります。この選択は、リクエストのルーティング、リージョンの退避、ディザスタリカバリの処理方法に影響します。以降のセクションでは、アプリケーションの書き込みモードによって異なるガイダンスを提示します。

任意のリージョンへの書き込みモード (プライマリなし)

次の図に示す、任意のリージョンへの書き込みモードは、完全にアクティブ/アクティブの構成であり、書き込みが発生する場所に制限は適用されません。任意のリージョンにいつでも書き込むことができます。これは最もシンプルなモードですが、これを使用できるのは、一部のタイプのアプリケーションのみです。このモードは、すべての MRSC テーブルに適しています。すべてのライターが冪等であるため、安全に繰り返し実行可能であり、リージョンをまたいでの同時または繰り返しの書き込みオペレーションが競合しないという場合にも MREC テーブルに適しています。例えば、ユーザーが連絡先データを更新する場合などに使用できます。このモードは、冪等である特殊なケースとして、確定的なプライマリキーにおけるすべての書き込みが一意の挿入であるという、追加専用のデータセットにも適しています。最後に、このモードは、書き込みの競合リスクを許容できる場合に MREC 適しています。

クライアントが任意のリージョンに書き込む仕組みを示す図。

任意のリージョンへの書き込みモードは、実装が最も簡単なアーキテクチャです。いつでも任意のリージョンを書き込み先にすることができるため、ルーティングが容易になります。フェイルオーバーも容易に行えます。なぜなら、MRSC テーブルの場合、その項目は常に同期され、MRSC テーブルの場合、最近の書き込みを任意のセカンダリリージョンで何度も実行できるからです。可能な限り、この書き込みモード向けの設計を行うようにします。

例えば、ビデオストリーミングサービスの一部では、グローバルテーブルを使用して、ブックマーク、レビュー、視聴ステータスフラグなどを追跡しています。こうしたデプロイで MREC テーブルが使用されるのは、世界中にレプリカを分散させ、各レプリカで、低レイテンシーの読み取りおよび書き込みオペレーションを行う必要があるからです。こうしたデプロイでは、すべての書き込みオペレーションがべき等である限り、任意のリージョンへの書き込みモードを使用できます。この方法を適用できるのは、いずれの更新によってもユーザーの新しい状態が直接割り当てられ、ある項目の次の正しい値が現在の値に依存しない場合です。最新のタイムコードの設定、新しいレビューの割り当て、新しい監視ステータスの設定などがその例と言えます。万が一、ユーザーの書き込みリクエストが異なるリージョンにルーティングされた場合でも、最後の書き込みオペレーションが保持され、最後の割り当てに従ってグローバル状態が確定します。このモードでの読み取りオペレーションは、最新の ReplicationLatency 値に応じた遅延の後、最終的に一貫性が保たれます。

別の例として、ある金融サービス会社では、システムの一部としてグローバルテーブルを使用し、各顧客のデビットカード購入の累計を管理して、その顧客のキャッシュバック特典を計算しています。また、顧客ごとに RunningBalance 項目を保持したいと考えています。この書き込みモードは、本質的に、べき等ではありません。トランザクションを次々と受け付け、ADD 式を使用してバランスを変更するからです。この式では、正しい新規の値が現在の値に依存します。そうした状況でも、MRSC テーブルでは、任意のリージョンへの書き込みモードを維持できます。いずれの ADD 呼び出しでも、常に項目の最新値がオペレーションの対象になるからです。

3 番目の例は、オンライン広告掲載サービスを提供する企業を示しています。この企業は、任意のリージョンへの書き込みモードによる設計の簡素化を実現するには、低リスクのデータ損失は許容できると判断しました。広告の配信時には、わずか数ミリ秒で十分なメタデータを取得してどの広告を表示するか決定すると共に、広告インプレッションを記録して同じ広告が何度もすぐに表示されないようにしています。グローバルテーブルを使用して、低レイテンシーの読み取りオペレーションで世界中のエンドユーザーに配慮し、低レイテンシーの書き込み操作も実現しています。ユーザーの広告インプレッションはすべて、単一の項目に記録し、それを成長するリストと見なしています。項目コレクションに追加する代わりに 1 つの項目を使用できます。これにより、各書き込みオペレーションの一部として古い広告インプレッションを削除できるため、削除オペレーションにコストが発生しません。この書き込み操作は、べき等ではありません。なぜなら、同じエンドユーザーに、ほぼ同時に複数のリージョンから配信された広告が表示された場合、広告インプレッションの 1 つの書き込みオペレーションによって別の書き込みオペレーションが上書きされる可能性があるからです。ここでのリスクは、ときどき、特定の広告が繰り返し表示される可能性があることです。これは許容できると同社は判断しました。

単一プライマリ (「1 つのリージョンへの書き込み」)

次の図に示すように、1 つのリージョンへの書き込みモードでは、アクティブ/パッシブの処理を行い、すべてのテーブルの書き込みを 1 つのアクティブなリージョンにルーティングします。DynamoDB には 1 つのアクティブリージョンという概念がないことに注意してください。DynamoDB の外部のアプリケーションルーティングがこれを管理します。1 つのリージョンへの書き込みモードは、書き込みオペレーションを一度に 1 つのリージョンにのみルーティングすることで、書き込みの競合を防ぐ必要がある MREC テーブルで効果を発揮します。この書き込みモードは、条件式を使用する場合や、何らかの理由で MRSC を使用できない場合、またはトランザクションの実行が必要な場合に有用です。これらの式は、オペレーション対象のデータが最新であることを把握していない限り、実行できないため、すべての書き込みリクエストを、最新のデータがある単一のリージョンに送信しなければなりません。

MRSC テーブルを使用する場合、利便性を考慮して、多くの場合、1 つのリージョンへの書き込みを選択できます。例えば、これにより、DynamoDB 以外のインフラストラクチャの構築を最小限に抑えられます。そうした状況でも、書き込みは任意のリージョンへの書き込みモードを維持できます。なぜなら、MRSC を使用すると、いつでも任意のリージョンに安全に書き込める一方で、MREC テーブルで 1 つのリージョンへの書き込みを選択した場合の競合解決を懸念する必要がないからです。

結果整合性のある読み込みは、任意のレプリカリージョンに送信してレイテンシーを短縮できます。強力な整合性のある読み込みは、単一のプライマリリージョンに送信する必要があります。

1 つのリージョンへの書き込みの仕組みを示す図。

場合によっては、リージョンの障害に応じてアクティブリージョンを変更する必要があります。一部のユーザーは、フォローザサンデプロイの実装などで、現在のアクティブリージョンを定期的に変更しています。これにより、アクティビティが最も多い地域 (フォローザサンの名前のとおり、一般的に、日中である地域) の近くにアクティブリージョンを配置して、読み取りおよび書き込みオペレーションのレイテンシーを最小化しています。これには、リージョン変更コードを毎日呼び出して、ディザスタリカバリに備えたテストをそうしたコードに十分に行えるという副次的な利点もあります。

パッシブリージョンでは、DynamoDB を取り巻くインフラストラクチャをダウンスケールしたままにして、アクティブリージョンになったときにのみ構築を行う場合があります。このガイドでは、パイロットライトとウォームスタンバイの設計は取り上げていません。詳細については、「AWS でのディザスタリカバリ (DR) アーキテクチャ、パート III: パイロットライトとウォームスタンバイ」を参照してください。

1 つのリージョンへの書き込みモードが適しているのは、グローバルに分散された低レイテンシーの読み取りオペレーションにグローバルテーブルを使用する場合です。例としては、世界中のすべてのリージョンで同じ参照データを用意する必要がある大規模ソーシャルメディア企業が挙げられます。データが頻繁に更新されることはありませんが、更新されると、書き込みは、競合を避けるために 1 つのリージョンにのみ実行されます。読み取りオペレーションは、いずれのリージョンからでも常に許可されます。

別の例として、毎日のキャッシュバック計算を実装した金融サービス会社 (前述) を考えてみましょう。同社では、任意のリージョンへの書き込みモードを使用して残高を計算する一方で、1 つのリージョンへの書き込みモードを使用して支払いを追跡していました。この処理には、MRSC テーブルではサポートされていないトランザクションが必要であり、この処理を効果的に行うために、別の MREC テーブルと、1 つのリージョンへの書き込みモードを使用しています。

自分のリージョンへの書き込み (「混合プライマリ」)

次の図に示す自分のリージョンへの書き込みモードは、MREC テーブルで機能します。このモードでは、異なるデータサブセットを異なるホームリージョンに割り当て、そのホームリージョンを介してのみ項目への書き込みオペレーションを許可します。運用はアクティブ/パッシブで行いますが、項目に基づいてアクティブなリージョンを割り当てます。各リージョンは重複しない独自のデータセットを持つプライマリとして機能するため、書き込み操作を制限して適切な局所性を確保しなければなりません。

このモードは 1 つのリージョンへの書き込みと似ていますが、各ユーザーに関連するデータを、そのユーザーに近いネットワークに配置できるため、書き込みオペレーションのレイテンシーを削減できる点が異なります。また、周囲のインフラストラクチャがリージョン間でより均等に分散され、すべてのリージョンでインフラストラクチャの一部が既にアクティブになっているため、フェイルオーバーシナリオ時にインフラストラクチャを構築する作業が少なくなります。

クライアントが 1 つのリージョンで各項目に書き込む仕組みを示す図。

項目のホームリージョンは、いくつかの方法で決定できます。

  • 組み込み: 特殊な属性や、パーティションキーに埋め込まれた値といった、データの一面により、ホームリージョンが明確になります。この手法については、ブログ記事「リージョンのピン留めを使用して Amazon DynamoDB グローバルテーブル内の項目のホームリージョンを設定する」の解説をご覧ください。

  • ネゴシエート済み: 各データセットのホームリージョンは、割り当てを管理する別のグローバルサービスなど、何らかの外部的な方法でネゴシエート済みです。割り当てには有限の期間があり、その後は再ネゴシエーションの対象となります。

  • テーブル指向: レプリケートするグローバルテーブルを 1 つ作成するのではなく、レプリケートするリージョンと同じ数のグローバルテーブルを作成します。各テーブルの名前はホームリージョンを示します。標準オペレーションでは、すべてのデータがホームリージョンに書き込まれ、他のリージョンは読み取り専用のコピーを保持します。フェイルオーバー中、別のリージョンがそのテーブルの書き込みタスクを一時的に引き継ぎます。

例えば、ゲーム会社で働いているとしましょう。世界中のすべてのゲーマーに配慮して、低レイテンシーの読み取りおよび書き込みオペレーションを可能にする必要があります。各ゲーマーに最も近いリージョンに各ゲーマーを割り当てます。そのリージョンでは、すべての読み取りおよび書き込みオペレーションを実行すると同時に、書き込み後の読み取りで、優れた一貫性を維持できます。ただし、ゲーマーが旅行中の場合や、ホームリージョンで障害が発生した場合は、代替リージョンでもデータの完全なコピーを利用可能にし、ゲーマーを別のホームリージョンに割り当てることができます。

別の例として、ビデオ会議会社で働いているとしましょう。各電話会議のメタデータは、特定のリージョンに割り当てられます。発信者は、最も近いリージョンを利用してレイテンシーを最小限に抑えることができます。リージョンが停止した場合、グローバルテーブルを使用していると、呼び出し処理が、レプリケート済みのデータコピーが既に存在する別のリージョンに移動されるため、迅速な復旧が可能になります。

要約
  • 任意のリージョンへの書き込みモードは、MRSC テーブルと、MREC テーブルへのべき等呼び出しに適しています。

  • 1 つのリージョンへの書き込みモードは、MREC テーブルへのべき等でない呼び出しに適しています。

  • 自分のリージョンへの書き込みモードは、MREC テーブルへのべき等でない呼び出しに適しています。ここでは、クライアントが自身に近いリージョンに書き込みを行えるようにすることが重要です。