DynamoDB Global Tables：マルチリージョンレプリケーション解説
グローバルテーブル とは、複数の AWS リージョンにまたがって複製された単一の DynamoDB テーブルで、すべてのレプリカが書き込み可能です。DynamoDB はそれらを自動的に同期に保ちます — 各リージョンで低レイテンシのローカルな読み書きに加えて、自前のレプリケーションを運用する ことなくクロスリージョンの災害復旧を得られます。
監査ログのシナリオでは、EU の顧客が自分のデータを eu-west-1 に置くことを要求し、残りは
us-east-1 で動いています。そしてコンプライアンス上重要なログとして、リージョン全体の
障害を生き延びる必要があります。グローバルテーブルは、その両方に 1 つの機能で答えます。
DynamoDB グローバルテーブルはどう機能するのか？
DynamoDB グローバルテーブルは、複数の AWS リージョンにまたがって複製された単一のテーブルで、すべてのレプリカが読み書き可能です。DynamoDB は のある非同期レプリケーションでそれらを自動的に同期し、競合を last-writer-wins で解決します。リージョンごとの低レイテンシのローカルな読み書きに加えて、クロスリージョンの災害復旧を得られ、これが DynamoDB の 99.999% の可用性 SLA を支えます。
- マルチリージョン、アクティブ-アクティブ。 各レプリカは完全に読み書き可能で、どの リージョンへの書き込みも他のリージョンへ伝播します。
- デフォルトモードでは、レプリケーションは非同期で がある — リージョン間で通常 1 秒以内ですが、瞬時ではありません。（強い整合性モードも存在します — 下記参照。）
- 競合は last-writer-wins で解決される。 2 つのリージョンで同じアイテムへの並行書き込みが あると、最も新しいものに調停されます。
- 99.999% の可用性 SLA を支える — マルチリージョンのグローバルテーブルは DynamoDB の 最高可用性構成です。
問題：1 つのリージョンでは足りない
シングルリージョンのテーブルには、監査ログが受け入れられない 2 つの限界があります。第一に、
データレジデンシー：EU の顧客のイベントは EU に保存されなければなりませんが、アプリは
US で動いています。第二に、災害復旧：us-east-1 に障害があると、シングルリージョンの
監査ログはその間ずっと読めず書けなくなります — まさに、何が起こったかの記録が最も必要な
ときにです。
どちらかを自前で構築すること — クロスリージョンのレプリケーション、フェイルオーバー、競合 処理 — は、大規模でエラーを起こしやすいプロジェクトです。グローバルテーブルはそれを構成上の 選択にします。
レプリケーションの仕組み
テーブルに レプリカリージョン を追加すると、DynamoDB はそこにコピーを作成し、すべての レプリカを同期に保ちます。
デフォルト（MREC）の振る舞いを定義する整合性ルールが 2 つあります。
- クロスリージョンのレプリケーションは非同期。
us-east-1への書き込みはローカルで 承認され、その後eu-west-1へ伝播されます — 通常 1 秒以内ですが、書き込み直後に別の リージョンで読み取ると、まだそれが見えないことがあります。（デフォルトの MREC モードでは、 強い は依然として機能しますが、単一リージョン 内 でのみです。） - 競合は last-writer-wins。 ほぼ同時に 2 つのリージョンで同じアイテムが書き込まれると、 DynamoDB は最新のタイムスタンプを持つ書き込みを保持し、もう一方を破棄します。
実践例：DR も兼ねる EU レプリカ
監査ログのテーブルのレプリカとして eu-west-1 を追加します。すると：
| write region | item | visible in | |
|---|---|---|---|
| us-east-1 | TENANT#acme | EVENT#…#a1 | both regions (~1s lag to EU) |
| eu-west-1 | TENANT#bmw | EVENT#…#e7 | both regions (~1s lag to US) |
EU の顧客のアプリはローカルの eu-west-1 レプリカに書き、そこから読みます — 低レイテンシで、
データはリージョン内に常駐します。レジデンシーを満たすのと同じレプリケーションが 災害
復旧 も兼ねます。us-east-1 がダウンしても、eu-west-1 のレプリカはなお完全なログを
保持しトラフィックを処理します。そこへフェイルオーバーします。
監査ログは 追記専用でテナントごとにパーティション分けされている ため、last-writer-wins は ここでは本質的に問題になりません — 特定のテナントのイベントは 1 つのリージョンから書かれ、 イベントキーは一意なので、2 つのリージョンが同じアイテムで競合することはめったにありません。 それは幸運ではありません。追記専用のログがグローバルテーブルに最もきれいに適合するものの 1 つである理由です。対照的に、可変のカウンターは、並行するクロスリージョン書き込みの下で 注意を要します。
DynoTable でやってみる
レプリカを追加した後、データが実際に新しいリージョンに着地しソースと一致していること —
EU レプリカが本当に acme のイベントを、正しい属性で保持し、遅れていないこと — を確認したく
なります。
DynoTable は独自の認証情報でどのリージョンにも接続するので、1 つのウィンドウを
us-east-1 に、別のウィンドウを eu-west-1 に向けて、同じテナントのアイテムを並べて比較し、
レプリケーションを検証できます。
各レプリカに対して実行するリージョンごとのクエリは、DynamoDB 式ビルダー でプロトタイプできます。
落とし穴と次のステップ
- リージョンをまたいで read-your-own-write をしない。 レプリケーション遅延は、あるリー ジョンへの書き込みが別のリージョンに ~1 秒現れないことを意味します。US に書いてすぐに EU から読み、それが見えると期待してはいけません。デフォルトの MREC モードでは、強い整合性の ある読み取りは単一リージョン内でのみ機能します。MRSC は強い読み取りをリージョンをまたいで 拡張します。
- last-writer-wins は静かにデータを落とす。 2 つのリージョンで並行して書き込まれる可変 アイテムでは、敗者はエラーなしで破棄されます。追記専用またはアイテムごとに単一の書き手の 設計（このような監査ログ）は問題を回避します。共有された可変状態には、競合を意識した設計が 必要です。
- すべてのレプリカにコストがかかる。 各リージョンが完全なコピーを保存し、自身のキャパ シティとストレージを課金します — レプリカはおおよそコストを 2 倍にします。実際のレジデン シーや DR の必要のためにリージョンを追加し、デフォルトで追加しないでください。
- バックアップはレプリカごと。 復元されたグローバルテーブルは独立したテーブルになります — リージョンごとに復旧を計画してください。 バックアップとポイントインタイムリカバリ を参照。
グローバルテーブルはリージョンを失うことから守ります。最後の運用上の懸念は データ を 失うこと — 不正なデプロイや誤削除 — から守ることで、これは バックアップとポイントインタイムリカバリ で行います。
DynoTable をダウンロード して複数のリージョンに接続し、グローバルテーブルの レプリカが同じデータを保持していることを検証しましょう。