Amazon DynamoDB グローバルテーブルのベストプラクティス – パート 1: 運用準備

あなたがグローバルな e コマースプラットフォームを運営していると想像してみてください。北米、ヨーロッパ、アジア太平洋地域に 200 万人のアクティブユーザーが分散しています。今日はブラックフライデー。注文が毎秒 5,000 リクエストの勢いで流れてきています。お客様は、自分がどこにいようと、舞台裏で何が起ころうと、シームレスな体験を期待しています。

グローバル規模でビジネスを運営するということは、予期しない事態に備えなければならないということです。ある AWS リージョンでイベントが発生し、ワークロードが劣化状態で稼働することもあり得るため、データレイヤーはそのときに備えておく必要があります。多くの組織にとって、これが Amazon DynamoDB グローバルテーブルを採用する理由です。

DynamoDB グローバルテーブルは、複数の AWS リージョンとアカウントにまたがるフルマネージドのアクティブ-アクティブレプリケーションを提供します。しかし、マルチリージョンレプリケーションを持っているだけでは話の半分にすぎません。残りの半分は、問題が起きる「前」にインフラが準備できていることを把握しておくことです。

これは DynamoDB グローバルテーブルのベストプラクティスに関するシリーズのパート 1 です。特に明記がない限り、本記事ではデフォルトのレプリケーションモードであるマルチリージョン結果整合性 (multi-Region eventual consistency) (MREC) のグローバルテーブルについて議論します。ガイダンスが異なる場合はマルチリージョン強整合性 (multi-Region strong consistency) (MRSC) について明示的に言及します。本記事では準備に焦点を当てます。レプリケーションの仕組み、レジリエンスポスチャの理解、そしてコントロールされたフェイルオーバーと慌てふためく対応を分ける運用上の基盤づくりについて説明します。パート 2 では、フェイルオーバー戦略と、午前 2 時にアラートが鳴ったときに何をすべきかを取り上げます。

グローバルテーブルのレプリケーションの仕組み

準備について話す前に、まずグローバルテーブルがどのようにデータをレプリケートするかについての共通理解を確立しておきましょう。DynamoDB グローバルテーブルはアクティブ-アクティブアーキテクチャを使用します。すべてのリージョンのすべてのレプリカテーブルが読み取りと書き込みの両方を受け付けることができます。あるリージョンに項目を書き込むと、DynamoDB はその変更を他のすべてのレプリカリージョンにレプリケートします。レプリケーションがどのように機能するかは、使用する整合性モードによって異なります。

MREC レプリケーション

デフォルトのマルチリージョン結果整合性 (MREC) モデルでは、書き込みは非同期にレプリケートされます。このモデルにはレジリエンスの計画に直接影響を与えるいくつかの特性があります。第一に、MREC は項目レベルのタイムスタンプに基づく Last-writer-wins (最後の書き込みが勝つ) の競合解決戦略を採用しています。同じ項目が 2 つのリージョンでほぼ同時に更新された場合、最新のタイムスタンプを持つ書き込みが優先されます。

第二に、通常の状況下では、変更は通常 1 秒以内にリージョン間でレプリケートされますが、項目サイズ、書き込み量、レプリカ間の物理的距離によって変動する可能性があります。

第三に、レプリカリージョンからの読み取りは、他のリージョンで行われた書き込みに対して結果整合性を持ちます。eu-west-1 での読み取りは、us-east-1 で発生したばかりの書き込みを即座に反映しない場合があります。このモデルにより各リージョンで低レイテンシのローカル読み書きが可能になりますが、結果整合性モデルはレジリエンス戦略の計画方法、特にデータ損失許容度に直接影響を与えます。

MRSC レプリケーション

マルチリージョン強整合性 (MRSC) では、書き込みは同期的にレプリケートされます。書き込み操作が成功レスポンスを返す前に、項目変更は少なくとも 1 つの他のリージョンに同期的にレプリケートされます。

MREC の Last-writer-wins アプローチとは異なり、MRSC での書き込みは任意のリージョンからの最新の書き込みに対して評価され、異なるリージョンから同じ項目への同時書き込みは競合を引き起こす可能性があります。MRSC は任意のアクティブリージョンからの強整合性のある読み取り (ConsistentRead=true を設定) をサポートし、読み取りが常に最新のコミット済み書き込みを反映するという確信を提供します。デフォルトは引き続き結果整合性のある読み取りです。

グローバルテーブルでの RPO と RTO の理解

フェイルオーバー時のレジリエンスポスチャを定義する 2 つのメトリクスがあります。

目標復旧地点 (Recovery Point Objective, RPO) はどれだけのデータ損失を許容できるかを時間ウィンドウで表します。RPO が 1 秒であれば、最大で直近 1 秒間の書き込みの損失を許容できることを意味します。
目標復旧時間 (Recovery Time Objective, RTO) はアプリケーションがどれだけ速く回復しなければならないかを表します。RTO が 60 秒であれば、ユーザーは障害発生から 1 分以内に通常の状態に戻れる必要があることを意味します。

マルチリージョン結果整合性 (MREC)

MREC では、書き込みはソースリージョンで受理された後、他のリージョンに非同期でレプリケートされます。それらの書き込みがフェイルオーバー先のリージョンに到達する前に障害が発生した場合、フェイルオーバー後に一部の最近の書き込みが失われる可能性があります。RPO の観点から、MREC はゼロ RPO を提供しません。確認された書き込みが障害発生時にまだ転送中である可能性があるためです。ReplicationLatency Amazon CloudWatch メトリクスはレプリケーションの健全性を監視するのに役立ちますが、フェイルオーバー時のデータ損失の正確な指標ではなく、方向性のシグナルとして扱うべきです。多くのワークロードにとって、これは許容可能なトレードオフです。

マルチリージョン強整合性 (MRSC)

MRSC グローバルテーブルレプリカでの項目変更は、書き込み操作が成功レスポンスを返す前に少なくとも 1 つの他のリージョンに同期的にレプリケートされます。これは MRSC がゼロ RPO を提供することを意味します。フェイルオーバー時にコミット済みの書き込みが失われることはありません。MRSC は 2 つの構成をサポートします。3 つのアクティブリージョン、または 2 つのアクティブリージョンとレプリケーションには参加するが読み取りや書き込みは処理しない witness リージョン、です。

トレードオフはレイテンシです。同期的なクロスリージョンレプリケーションは、すべての書き込みに往復時間を追加します。小さな RPO ウィンドウを許容できるレイテンシ重視のワークロードには、MREC が依然として正しい選択です。ゼロデータ損失が交渉の余地のない要件であるワークロード、つまり金融取引、在庫システム、規制コンプライアンスシナリオには MRSC を推奨します。

MREC を使用するか MRSC を使用するかにかかわらず、RTO は選択するフェイルオーバー戦略に完全に依存します。本シリーズのパート 2 で、3 つの主要なアプローチとその RTO の特性を取り上げます。

モニタリングとオブザーバビリティ

何かが間違っていることを知らなければ、混乱に効果的に対応することはできません。モニタリングは準備の基盤であり、インシデントが発生するずっと前に注意を払う必要があります。

ReplicationLatency

ReplicationLatency CloudWatch メトリクスは MREC グローバルテーブルで利用可能で、項目があるリージョンから別のリージョンにレプリケートされる時間 (ミリ秒単位) を追跡します。これはレプリケーションの健全性の主要な指標であり、結果整合性モデルにおける RPO の最良の代理指標です。

ReplicationLatency メトリクスはリージョンペアごとに発行されます。グローバルテーブルが us-east-1、us-west-2、eu-west-1 にレプリカを持つ場合、us-east-1 の CloudWatch には 2 つの別々の ReplicationLatency メトリクスが表示されます。1 つは us-west-2 へのレプリケーション用、もう 1 つは eu-west-1 へのレプリケーション用です。各ペアに対して独立してアラームを設定してください。レイテンシはリージョン間の物理的距離によって大きく異なるためです。

このメトリクスに対して 2 つのしきい値でアラームを設定することを推奨します。3,000 ms を 5 分以上持続する場合の警告と、5,000 ms を 3 分以上持続する場合のクリティカルアラームです。これらは出発点であり、ワークロードのベースラインに基づいてチューニングすることを推奨します。警告により、状況が緊急になる前にチームが調査する時間を得られます。レプリケーションレイテンシの上昇は必ずしもリージョン障害によって引き起こされるわけではないことに注意してください。キャパシティ不足によるスロットリングの持続もレプリケーションラグを増加させる可能性があるため、リージョンの問題があると結論付ける前に、ReplicationLatency と並行してテーブルのスロットリングメトリクスを調査してください。

リージョン障害中でもレプリカは ACTIVE ステータスを示すことができることに注意してください。レプリカステータスだけでは不十分です。レプリケーションレイテンシのモニタリングが、必要なリアルタイムシグナルを提供します。

このメトリクスは MRSC では利用できません。MRSC グローバルテーブルでは、強整合性のある読み書き API 呼び出しのレイテンシを監視してリージョンの健全性を評価します。これらの操作のレイテンシ上昇やタイムアウトは、潜在的なリージョン障害を示します。

SystemErrors

SystemErrors CloudWatch メトリクスは、DynamoDB から HTTP 500 エラーが返されたリクエスト数を追跡します。通常の運用中でも時折システムエラーは発生し得ますが、持続的な増加は劣化の強い指標です。

適切なアラームしきい値はスループットによって異なります。毎秒 100 万リクエストを処理するテーブルは、毎秒 5 リクエストを処理するテーブルよりも自然に多くの一過性のシステムエラーを見るため、絶対的なエラー数だけでは意味がありません。代わりに、SystemErrors の総リクエストに対する割合でアラームを設定することを推奨します。5 分間で持続的なエラー率が 0.5% を超える場合の警告と、3 分間で 1% を超える場合のクリティカルアラームが妥当な出発点ですが、ワークロードのベースラインに基づいてこれらのしきい値をチューニングすべきです。一過性のシステムエラーは珍しくなく、必ずしもリージョンの問題を示すわけではないため、しきい値は寛容にすべきです。探しているのはエラー上昇の「パターン」であり、ReplicationLatency の上昇など他のシグナルと組み合わさって、対応すべき劣化の状況を描き出すものです。

MREC では、ReplicationLatency アラームと組み合わせると、SystemErrors はリージョンの健全性に対する 2 番目の独立したシグナルを提供します。MRSC では、SystemErrors と強整合性のある読み書きのレイテンシが主な健全性指標として機能します。

これは、自動フェイルオーバーの決定を駆動する複合アラーム (composite alarms) を構築する際に特に有用です。これはパート 2 で取り上げるトピックです。

Synthetic canaries

最も予防的なモニタリングのために、クロスリージョンレプリケーションを継続的に検証する synthetic canary をデプロイしましょう。これらの canary は既知の項目をソースリージョンに書き込み、その項目が現れるまでターゲットリージョンをポーリングし、アプリケーションの観点から実際のエンドツーエンドのレプリケーション時間を計測します。次の Python スクリプトは、項目を書き込み、ターゲットリージョンでポーリングし、計測されたラグをカスタム CloudWatch メトリクスとして公開する基本的なレプリケーション canary を示しています。

import time
import uuid
from datetime import datetime, timezone
import boto3

def replication_canary(source_region, target_regions, table_name):
    source = boto3.resource("dynamodb", region_name=source_region)
    cloudwatch = boto3.client("cloudwatch", region_name=source_region)
    canary_id = str(uuid.uuid4())
    write_time = datetime.now(timezone.utc)
    ttl_value = int(write_time.timestamp()) + 86400

    # Write to source Region
    source.Table(table_name).put_item(Item={
        "PK": "CANARY",
        "SK": canary_id,
        "written_at": write_time.isoformat(),
        "ttl": ttl_value,
    })

    # Poll each target Region independently
    pending = {r: boto3.resource("dynamodb", region_name=r) for r in target_regions}
    results = {}
    for attempt in range(10):
        time.sleep(1)
        for region, client in list(pending.items()):
            response = client.Table(table_name).get_item(
                Key={"PK": "CANARY", "SK": canary_id}
            )
            if "Item" in response:
                lag = (datetime.now(timezone.utc) - write_time).total_seconds()
                results[region] = lag
                del pending[region]
        if not pending:
            break

    for region in pending:
        results[region] = None
    return results

これにより、CloudWatch メトリクスとは独立した、ニアリアルタイムのアプリケーションレベルでのレプリケーションヘルスのビューが得られます。これは、ダッシュボードよりも先に何か問題があることを教えてくれる種類のシグナルです。canary 項目が時間とともに蓄積するのを防ぐため、テーブルで Time to Live (TTL) を有効にし、各 canary 項目に TTL 属性を含めてください。

重要な考慮事項は、モニタリングインフラがどこで実行されるかです。canary、アラーム、フェイルオーバー判断ロジックがすべてプライマリリージョンで実行されている場合、そのリージョンが障害状態のときに利用できなくなります。まさに最も必要なときに動作しないのです。synthetic canary と複合アラームを別のリージョンからデプロイし、障害のあるリージョン自体に依存することなく障害を検出して対応できるようにしましょう。

ワークロードの依存関係をマッピングする

DynamoDB はワークロードが依存する唯一のサービスであることはほとんどありません。自信を持ってフェイルオーバーする前に、依存関係の完全なセットを理解する必要があります。コンピュート、ネットワーキング、認証、キャッシング、メッセージング、その他アプリケーションが必要とするあらゆるサービスです。各依存関係はフェイルオーバーリージョンで利用可能で、正しく構成されている必要があります。アプリケーションが到達できなければ、健全な DynamoDB レプリカは役に立ちません。これらの依存関係をフェイルオーバーランブックの一部として文書化し、GameDay の際に検証してください。

レプリカが健全であることを確認する

別のリージョンにアプリケーションをフェイルオーバーする前に、そのリージョンがトラフィックを受け入れる準備ができていることを確認する必要があります。レプリカテーブルが ACTIVE 状態であることを定期的に確認する習慣をつけましょう。

aws dynamodb describe-table \
    --table-name YourGlobalTableName \
    --region us-west-2

出力で、TableStatus が ACTIVE であることと、Replicas 配列の各エントリで ReplicaStatus: ACTIVE が表示されていることを確認してください。レプリカが CREATING、UPDATING、REPLICATION_NOT_AUTHORIZED、または INACCESSIBLE_ENCRYPTION_CREDENTIALS などの異なる状態にある場合、フェイルオーバーターゲットとして機能する準備ができていません。レプリカが非アクティブな状態にある「理由」を理解することが重要です。たとえば、UPDATING 状態は進行中の設定同期またはスケーリングイベントを示している可能性があり、原因によって対処方法は異なります。

フェイルオーバーリージョンでキャパシティが準備できていることを確認する

キャパシティモードと Auto Scaling を掘り下げる前に、すべてのレプリカリージョンで AWS Service Quotas が一貫していることを確認してください。プライマリより低い DynamoDB クォータを持つリージョンは、キャパシティ構成が正しくてもフェイルオーバー時のボトルネックになる可能性があります。予想されるピークイベントの十分前にこれらのクォータを確認して揃えてください。

私たちが目にする最も一般的なギャップの 1 つは、通常の読み取りトラフィックに対してプロビジョニングされたフェイルオーバーリージョンです。これは定常状態でのコスト面の改善として合理的です。しかし、プライマリリージョンが障害になり、そのレプリカがリダイレクトされたトラフィックを突然吸収する必要が生じると、数秒でスロットリングに到達します。

グローバルテーブルでは、すべてのレプリカが通常のレプリケーションの一部としてすでに本番の書き込みトラフィック全体を処理していることを理解することが重要です。懸念は主に読み取りキャパシティに関するものです。アプリケーションがすべての読み取りをフェイルオーバーリージョンに移すなら、そのリージョンはそれに応じてプロビジョニングされている必要があります。

テーブルがオンデマンドキャパシティモードを使用している場合、キャパシティが自動的にスケールするため、より良い状況にあります。しかし、プロビジョニングキャパシティモードを使用している場合は、必要になる前にフェイルオーバーリージョンが本番レベルのトラフィックを処理できることを確認する必要があります。

確認すべき重要なメトリクスは現在プロビジョニングされているものではなく、Auto Scaling の上限が許容するものです。現在のプロビジョニングキャパシティは、最近のトラフィックに基づいて Auto Scaling が落ち着いた状態を反映しており、いつでも変わる可能性があります。フェイルオーバーの準備にとって重要なのは、Auto Scaling が本番トラフィックを吸収するのに十分な高さまでスケール「できる」かどうかです。Auto Scaling 構成を確認してください。

aws dynamodb describe-table-replica-auto-scaling \
    --table-name YourGlobalTableName \
    --region us-west-2

出力で、フェイルオーバーリージョンの読み取りおよび書き込みキャパシティの MinimumUnits と MaximumUnits を確認してください。MaximumUnits がプライマリリージョンのピークプロビジョニングキャパシティより低い場合、フェイルオーバー時に Auto Scaling が天井に到達し、スロットリングが発生します。

状況に応じて、これに対処する 2 つのアプローチがあります。

計画されたイベントまたは予想されるリスク期間の場合、フェイルオーバーリージョンの MinimumUnits を一時的にプライマリリージョンの現在のプロビジョニングキャパシティに合わせて引き上げます。これによりキャパシティが事前にウォームアップされ、急激なトラフィック急増に Auto Scaling が反応するのを数分待つのではなく、フェイルオーバー時に即座に利用可能になります。イベント後に下げ戻すことができます。

継続的な準備の場合、すべてのレプリカリージョン全体で MaximumUnits が一貫しており、本番の負荷を完全に処理できるほど十分に高いことを確認してください。こうすれば、事前にウォームアップしなくても、Auto Scaling にスケールアップする余地があります。

グローバルテーブルでは、これらの境界を調整するには DynamoDB の Auto Scaling API (UpdateTable API や AWS Application Auto Scaling API を直接使用するのではなく) を使用してください。UpdateTable を通じてスループットに行われた更新は Auto Scaling によって上書きされる可能性があります。次のコマンドが推奨アプローチを示しています。

aws dynamodb update-table-replica-auto-scaling \
    --table-name YourGlobalTableName \
    --replica-updates '[
        {
            "RegionName": "us-west-2",
            "ReplicaProvisionedReadCapacityAutoScalingUpdate": {
                "MinimumUnits": 5000,
                "MaximumUnits": 40000,
                "AutoScalingDisabled": false,
                "ScalingPolicyUpdate": {
                    "TargetTrackingScalingPolicyConfiguration": {
                        "TargetValue": 70.0
                    }
                }
            }
        }
    ]'

グローバルテーブルは Auto Scaling 設定を含む特定の設定をレプリカ間で同期します。これは、非プライマリリージョンの読み取りキャパシティを下げるカスタム Auto Scaling ポリシーを作成していない限り、読み取りキャパシティ設定も同期されることを意味します。キャパシティ戦略を計画する際には、この動作に注意してください。

計画されたイベントの前にオンデマンドモードへの切り替えを検討してください。これによりすべてのレプリカが同一のキャパシティ動作を持つようになり、高ストレスインシデント中にリージョン間で Auto Scaling を管理する必要がなくなります。

障害中はコントロールプレーン操作を避ける

これは重要であり、しばしば見落とされます。リージョン障害中は次のことを避けてください。

テーブルに構造的変更を加えない
グローバルセカンダリインデックス (Global Secondary Index) を追加または削除しない
グローバルテーブルレプリカを追加または削除しない
キャパシティモードを変更しない (プロビジョニングとオンデマンドの間の切り替え)
テーブルタグや TTL 設定を更新しない

これらはレプリカ間の調整を必要とするコントロールプレーン操作です。グローバルテーブルはデフォルトですべてのレプリカ間で設定を同期するため、レプリカの 1 つにアクセスできない場合は設定変更が許可されません。これらはすべてのレプリカが健全である場合にのみ行えます。データプレーン操作 (読み書き) は、健全なリージョンへのフェイルオーバー後に安全であり期待されています。しかし、構造的変更は全クリアまで待つべきです。これが、インシデント中にリソースを作成または変更しようとするのではなく、障害が発生する前にスタンバイインフラストラクチャを完全に構成して準備しておくことがベストプラクティスである理由です。

イベント前チェックリストとランブックを構築する

レジリエンスポスチャを強化するには、フェイルオーバー手順を文書化したフェイルオーバーランブックを作成することを推奨します。これにはフェイルオーバーをいつ開始するかについての事前決定したしきい値と基準が含まれます。フェイルオーバーの判断は最終的にビジネス上の判断であり、各お客様の要件とリスク許容度に固有のものです。これらの判断を午前 2 時のインシデント中ではなく事前に行っておくことが、準備されたチームと反応的なチームを分けるものです。

そのランブックの一部として、計画されたイベント、ピークトラフィック期間、または AWS が AWS Health Dashboard を通じて潜在的な障害を伝える際にレビューする、イベント前チェックリストを維持してください。

影響を受けるリージョンにレプリカを持つすべてのグローバルテーブルを特定する
代替リージョンのレプリカステータス (ACTIVE 状態) を確認する
ReplicationLatency メトリクスを確認してレプリケーションが最新であることを確認する
ターゲットリージョンでプロビジョニングキャパシティまたはオンデマンドモードが適切であることを確認する
レプリカリージョン間でサービスクォータが一貫していることを確認する
DynamoDB テーブルの CloudWatch アラームをレビューする
現在のアプリケーションエンドポイント構成を文書化する
運用チームが利用可能で、フェイルオーバーランブックに精通していることを確認する
ステークホルダーとのコミュニケーションチャネルを確立する

これはオーバーヘッドのように思えるかもしれませんが、航空会社のパイロットがどれほど経験豊富であっても、すべての離陸前にプリフライトチェックリストを実行することを考えてください。チェックリストはパイロットが飛行方法を知らないからではなく、ステップが省略されるのは高ストレス状況で起こるからこそ存在します。同じ原則がここに適用されます。実際のインシデント中に、このリストがすでに完了していることが、5 分のフェイルオーバーと 45 分の慌ただしい対応の違いになり得ます。

よくある準備の落とし穴

最善の意図があっても、準備中にチームを油断させる罠があります。

負荷時のレプリケーションラグスパイク

高い書き込みボリューム時 (フラッシュセールやバッチインポートを考えてください) には、レプリケーションレイテンシが通常のサブセカンドの範囲を超えてスパイクする可能性があります。これらのスパイク中に障害が発生すると、RPO ウィンドウは予想より大きくなります。これはレジリエンス戦略が壊れていることを意味するものではありませんが、それを認識する必要があることを意味します。ピークトラフィック期間中に ReplicationLatency CloudWatch メトリクスを綿密に監視し、これらのスパイクを RPO 計算に織り込んでください。負荷に関係なくビジネスがハードなゼロ RPO 保証を必要とする場合、DynamoDB マルチリージョン強整合性 (MRSC) が答えです。

キャパシティプランニングの失敗

フェイルオーバーリージョンが通常の読み取りトラフィック向けにプロビジョニングされていて、突然本番の読み取りトラフィック全体を処理しなければならなくなった場合、スロットリングに到達します。Auto Scaling は役立ちますが、反応するのに数分かかり、突然のフェイルオーバーサージには遅すぎます。レプリカテーブルにオンデマンドキャパシティモードを使用するか、すべてのリージョンのプロビジョニングキャパシティが常に本番の負荷を完全に処理できることを確認してください。フェイルオーバーリージョンで高いキャパシティを維持するには実際のコストがかかり、適切なバランスはワークロードとリスク許容度に依存します。レプリカテーブルにオンデマンドキャパシティモードの使用を検討してください。これは過剰プロビジョニングを維持する必要なく自動的にスケールします。プロビジョニングモードを使用する場合、定常状態で MinimumUnits が低く設定されていても、Auto Scaling の MaximumUnits が本番の負荷を完全に処理できることを確認してください。重要なのは、フェイルオーバーリージョンが必要なときに需要に応えてスケールできることであり、常にフルキャパシティで稼働していることではありません。

フェイルオーバーをテストしない

フェイルオーバーは火災訓練のようなものです。練習したことがなければ、本番でスムーズに実行できません。リージョン障害をシミュレートしてフェイルオーバーランブックを練習する GameDay を定期的に実施してください。AWS Fault Injection Service (FIS) を使用して障害を注入し、レジリエンスポスチャを継続的にテストできます。実際のインシデントが強制する前に、自動化、ドキュメント、チームの準備のギャップを特定してください。私たちは、GameDay 中にフェイルオーバーリージョンのセキュリティグループがアプリケーションの DynamoDB への接続をブロックしていることを発見したお客様と仕事をしたことがあります。何ヶ月も気づかれなかった構成のドリフトです。土曜日の夜の障害中にではなく、火曜日の午後にそれを見つけるほうがよいでしょう。

より一般的に、アドバイスはフェイルオーバー戦略は定期的に実行される必要があるということです。これらを確認するだけでは不十分です。フェイルオーバーは何らかの定期的な間隔で実行する必要があります。

まとめ

DynamoDB グローバルテーブルでリージョン障害に備えることは、複数のリージョンにレプリカを持つことだけではありません。レプリケーションモデルを理解し、RPO と RTO の要件を知り、レプリケーションの健全性を継続的に監視し、重要なときに決断的に行動するための運用上の筋力を構築することについてです。

単一リージョン障害後でもデータは引き続き利用可能です。それがグローバルテーブルの約束です。しかし、復旧の速度とスムーズさは、今日行う準備に完全に依存します。

このシリーズのパート 2 では、フェイルオーバー戦略そのものを取り上げます。Amazon Route 53 を使った DNS ベースのフェイルオーバー、アプリケーションレベルのサーキットブレーカー、Amazon Route 53 Application Recovery Controller (ARC) です。各アプローチのトレードオフ、実装の詳細、運用上の考慮事項を順を追って説明します。

さらに学ぶには

DynamoDB グローバルテーブルを今日運用しているなら、まず CloudWatch で ReplicationLatency メトリクスを確認することから始めてください。アラームを設定していない場合、今すぐ作成してください。次に、フェイルオーバーリージョンで describe-table-replica-auto-scaling を実行し、MaximumUnits をプライマリリージョンのピークトラフィックと比較してください。ギャップがある場合、次のピークイベント前に解消してください。

フェイルオーバーランブックがまだない場合、本記事のチェックリストを出発点として使用してください。ワークロードでフェイルオーバーをトリガーするしきい値を書き留め、チームにレビューしてもらい、テストするための GameDay をスケジュールしてください。AWS Fault Injection Service は制御された方法でリージョン障害をシミュレートするのに役立ちます。

グローバルテーブルの構成と設計の詳細については、DynamoDB グローバルテーブルのベストプラクティスと AWS Well-Architected フレームワークの信頼性の柱 (Reliability Pillar) を参照してください。ワークロードでゼロ RPO が要件である場合、マルチリージョン強整合性 (multi-Region strong consistency) (MRSC) を検討してください。

パート 2 では、3 つのフェイルオーバー戦略でこの準備を実践します。

本記事は 2026 年 05 月 20 日に公開された “Best practices for Amazon DynamoDB Global Tables – Part 1: Operational readiness” を翻訳したものです。

原文: https://aws.amazon.com/blogs/database/best-practices-for-amazon-dynamodb-global-tables-part-1-operational-readiness/

著者について

Lee Hannigan

Lee はアイルランドを拠点とする AWS DynamoDB チームのシニアデータベースエンジニアです。データモデリング、分散システム、開発者ツールにわたる 7 年間の経験を持ち、スケールで構築するお客様にとって DynamoDB をよりアクセスしやすいものにすることに焦点を当てています。

Shiladitya Mandal

Shiladitya は AWS DynamoDB チームのソフトウェア開発マネージャーで、Data Movement グループを率いています。Amazon に 10 年以上在籍し、分散システムの構築とスケーリングに従事してきました。シアトルを拠点とする Shiladitya は、グローバルテーブルやその他のクロスリージョン機能を支える DynamoDB のレプリケーションおよびデータ移動機能に焦点を当てています。

Amazon Web Services ブログ