DynamoDB Global Tables

global tableとは、複数のAWSリージョンにレプリケートされた単一のDynamoDBテーブルで、どのレプリカも書き込み可能です。DynamoDBが自動的に同期を保つので、各リージョンでの低レイテンシなローカル読み書きに加えて、自前のレプリケーションを運用することなくリージョン間のディザスタリカバリが得られます。

監査ログのシナリオでは、あるEUの顧客がデータをeu-west-1に置くことを要求し、残りはus-east-1で動作します。さらにコンプライアンス上重要なログとして、リージョン全体の障害を生き延びる必要があります。global tableは1つの機能で両方に応えます。

DynamoDB Global Tablesとは?

DynamoDB Global Tablesとは、複数のAWSリージョンにレプリケートされた単一のテーブルで、どのレプリカも読み書き可能です。DynamoDBは結果整合性のある非同期レプリケーションでこれらを自動的に同期し、競合はlast-writer-winsで解決します。各リージョンでの低レイテンシなローカル読み書きに加えて、リージョン間のディザスタリカバリが得られ、DynamoDBの99.999%可用性SLAを支えます。

• マルチリージョン、アクティブ-アクティブ。 各レプリカは完全に読み書き可能で、どのリージョンでの書き込みも他へ伝播します。
• レプリケーションは非同期で、リージョン間では結果整合性です — 通常は1秒以内ですが、即時ではありません。
• 競合はlast-writer-winsで解決されます。 2つのリージョンで同じアイテムへ並行に書き込まれた場合、最新のものに収束します。
• 99.999%の可用性SLAを支えます — マルチリージョンのglobal tableはDynamoDBで最も可用性の高い構成です。

問題:1つのリージョンでは足りない

シングルリージョンのテーブルには、監査ログが受け入れられない制約が2つあります。1つ目はデータレジデンシーです。EUの顧客のイベントはEUに保存しなければなりませんが、アプリはUSで動作しています。2つ目はディザスタリカバリです。us-east-1で障害が発生すると、シングルリージョンの監査ログはその間ずっと読み書き不能になります — 何が起きたかの記録が最も必要なまさにそのときに、です。

どちらを自前で構築するにせよ — リージョン間レプリケーション、フェイルオーバー、競合処理 — それは大規模でミスの起きやすいプロジェクトになります。global tablesはそれを設定の選択肢に変えます。

global tablesの仕組み

テーブルにレプリカリージョンを追加すると、DynamoDBがそこにコピーを作成し、すべてのレプリカを同期し続けます。AWS DynamoDB FAQによれば、global tablesは最大99.999%の可用性でマルチリージョンレプリケーションを提供し、各リージョンのレプリカがローカルの読み書きを処理します。

2つの整合性ルールが動作を定義します:

• リージョン間レプリケーションは非同期です。 us-east-1での書き込みはローカルで確認応答され、その後eu-west-1へ伝播されます — 通常は1秒以内ですが、書き込み直後に他のリージョンで読み取ってもまだ見えないことがあります。(強い整合性のある読み取りは依然として機能しますが、単一リージョン内に限られます。)
• 競合はlast-writer-winsです。 ほぼ同時に2つのリージョンで同じアイテムが書き込まれた場合、DynamoDBは最新のタイムスタンプを持つ書き込みを保持し、もう一方を破棄します。

実例:DRも兼ねるEUレプリカ

監査ログテーブルのレプリカとしてeu-west-1を追加します。これで:

EUの顧客のアプリはローカルのeu-west-1レプリカへ書き込み、そこから読み取ります — 低レイテンシかつデータはリージョン内に常駐します。レジデンシーを満たすのと同じレプリケーションが、ディザスタリカバリも兼ねます。us-east-1がダウンしても、eu-west-1レプリカは依然として完全なログを保持しトラフィックを処理するので、そこへフェイルオーバーします。

監査ログは追記専用かつテナント単位でパーティション分割されているため、ここではlast-writer-winsは実質的に問題になりません — あるテナントのイベントは1つのリージョンから書き込まれ、イベントキーは一意なので、2つのリージョンが同じアイテムで競合することはまれです。これは運ではなく、追記専用ログがglobal tablesに最もきれいに適合する理由です。一方、可変なカウンターであれば、並行するリージョン間書き込みの下では注意が必要でしょう。

DynoTableでの実践

レプリカを追加した後は、データが実際に新しいリージョンに到達しソースと一致していること — EUレプリカが本当にacmeのイベントを正しい属性で保持し、遅延していないこと — を確認したくなります。

DynoTableは各々の認証情報で任意のリージョンへ接続できるので、片方のウィンドウをus-east-1に、もう片方をeu-west-1に向け、同じテナントのアイテムを並べて比較してレプリケーションを検証できます。

各レプリカに対して実行するリージョン単位のクエリは、DynamoDB Expression Builderでプロトタイプできます。

落とし穴と次のステップ

• リージョンをまたいで自分の書き込みを読み取らないでください。 レプリケーション遅延により、あるリージョンの書き込みが他のリージョンに現れるまで約1秒かかることがあります。USへ書き込んだ直後にEUから読み取ってそれが見えると期待しないでください。強い整合性は単一リージョン内のみです。
• last-writer-winsは黙ってデータを破棄します。 2つのリージョンで並行に書き込まれた可変アイテムでは、敗者がエラーなしで破棄されます。追記専用や、アイテムごとに単一の書き込み元とする設計(このような監査ログ)はこの問題を避けられます。共有された可変状態には競合を意識した設計が必要です。
• レプリカごとにコストがかかります。 各リージョンはフルコピーを保存し、それぞれのキャパシティとストレージを課金します — レプリカはおおよそコストを2倍にします。実際のレジデンシーやDRのニーズに応じてリージョンを追加し、既定で追加しないでください。
• バックアップはレプリカ単位です。 リストアされたglobal tableは独立したテーブルになります — リカバリはリージョン単位で計画してください。バックアップとポイントインタイムリカバリを参照してください。

global tablesはリージョンの喪失から守ります。最後の運用上の懸念は、不正なデプロイや誤った削除によるデータの喪失から守ることで、それにはバックアップとポイントインタイムリカバリを使います。

複数のリージョンに接続し、global tableのレプリカが同じデータを保持していることを検証するには、DynoTableをダウンロードしてください。