Amazon DynamoDB グローバルテーブルのベストプラクティス – Part 2: フェイルオーバー戦略

このシリーズの パート 1 では、Amazon DynamoDB グローバルテーブルによるリージョナルレジリエンスの基礎、つまりレプリケーションの仕組み、ワークロードにおける RPO と RTO の意味、そして制御されたフェイルオーバーと混乱状態のフェイルオーバーを分ける運用準備について取り上げました。パート 3 では、AWS Fault Injection Service (FIS) を使用してフェイルオーバー戦略を検証する方法を紹介します。

時刻は午前 2 時。ページャーが鳴りました。あるリージョンでサービスに障害が発生しており、アプリケーションは別のリージョンからトラフィックの提供を開始しなければなりません。

本投稿では、DynamoDB グローバルテーブルにおける 2 つの主要なフェイルオーバー戦略、それらのトレードオフ、およびフェイルオーバーの最中と後で認識すべき運用上の考慮事項について取り上げます。

フェイルオーバー戦略

中心となる問いはシンプルです。あるリージョンでサービスに障害が発生したとき、アプリケーションはどのようにして別のリージョンの使用を開始するのか? これには 2 つの主要なアプローチがあり、それぞれ異なる RTO 特性と運用上の複雑さを持ちます。どちらのアプローチも、フェイルオーバーの判断材料として、パート 1 で確立した監視シグナル、特に ReplicationLatency、SystemErrors、合成カナリアに依存しています。

戦略 1: Amazon Route 53 Application Recovery Controller (ARC)

協調的なマルチサービスのフェイルオーバーが必要なミッションクリティカルなワークロードには、Amazon Route 53 Application Recovery Controller (ARC) が最も堅牢なソリューションを提供します。ARC はマルチリージョンのリカバリのために専用に設計されており、そのアーキテクチャは、リージョン全体に障害が発生した場合でも、フェイルオーバー時に依存するコンポーネント自体が高可用性を持つように設計されています。

ARC のマルチリージョンリカバリ機能は、連携して動作するいくつかのコアコンポーネントを中心に構築されています。

Region switch (推奨)

Region switch は、複数の AWS アカウントにまたがる大規模で複雑なリカバリタスクをオーケストレートするための ARC の推奨機能です。Region switch は、リカバリを完了するために並列または順次に実行されるワークフローと実行ブロックを含むプランの概念を中心に構築されています。

Region switch プランは手動でトリガーすることも、Amazon CloudWatch アラームに関連付けて自動化することもできます。例えば、プライマリリージョンにおけるアプリケーションの 5xx エラー率、DynamoDB の SystemErrors、ReplicationLatency、SuccessfulRequestLatency を監視する 複合アラーム を設定できます。複合アラームが ALARM 状態になると、Region switch がリカバリプランを自動的に実行し、定義した順序で DynamoDB トラフィック、コンピューティングリソース、依存サービスのフェイルオーバーを協調させます。

Region switch は、アクティブ-パッシブ (フェイルオーバーとフェイルバック) およびアクティブ-アクティブ (シフトアウェイとリターン) の両方の構成をサポートし、リカバリプロセスをリアルタイムに可視化するダッシュボードを提供します。

ARC を採用するほとんどのチームにとって、Region switch は適切な出発点となります。マルチサービスのフェイルオーバーに必要な協調と自動化を提供しつつ、インシデント発生時に必要となる手作業のステップを削減します。

Routing controls

Routing controls は、クライアントトラフィックをあるリージョナルレプリカから別のレプリカへリダイレクトするために使用できる、シンプルなオン/オフのスイッチです。各 routing control は Amazon Route 53 ヘルスチェックに関連付けられており、それは各リージョンでアプリケーションのフロントに配置された DNS フェイルオーバーレコードに紐付けられています。routing control を On から Off に切り替えると、Route 53 は対応するヘルスチェックを unhealthy としてマークし、DNS フェイルオーバーがトラフィックを健全なリージョンへリダイレクトします。

routing controls の背後にある重要な設計判断は、それらが専用クラスター内の 5 つのリージョナルエンドポイントにわたってホストされている、極めて信頼性の高いデータプレーン上で動作することです。これは、フェイルオーバー元のリージョンが完全に利用不可能であっても、routing control の状態を更新できることを意味します。AWS は、実際のインシデント時に routing control の状態を更新するためにデータプレーン API を使用すること、および 5 つのクラスターエンドポイントのいずれかをランダムに選択し、5 つすべてに対するリトライロジックを使用することを推奨しています。

Safety rules

Safety rules は、ストレスの高いインシデント中に危険な routing control の状態変更を防ぐガードレールです。例えば、すべてのリージョンが同時に無効化されることを防ぐルールや、少なくとも 1 つのリージョンが常にアクティブであることを必須とするルールを定義できます。チームがプレッシャー下で迅速な判断を下している午前 2 時のインシデント中、safety rules はオペレーターのミスに対するバックストップとして機能します。safety rule が、あなたが正しいと判断した更新をブロックした場合、それを上書きすることはできますが、上書きは明示的かつ監査可能です。

Readiness checks

Readiness checks は、AWS リソースクォータ、キャパシティ設定、ネットワークルーティングポリシーなどを監査して、リージョンをまたいでアプリケーションのリソースを継続的に監視します。その目的は、スタンバイレプリカが構成とキャパシティの面で本番レプリカと一致していることを継続的に検証することです。フェイルオーバー先のリージョンの DynamoDB テーブルが本番より低いプロビジョニング済みキャパシティを持っていたり、Amazon Virtual Private Cloud (Amazon VPC) エンドポイントが欠落していたりすると、readiness checks はフェイルオーバーを必要とする前にそのドリフトを表面化させます。readiness checks は継続的な監視のために設計されており、アクティブなインシデント中にフェイルオーバーをトリガーするためのものではないことに注意することが重要です。

RTO とトレードオフ

ARC を使用した場合の RTO は、DNS TTL の伝播次第で数秒から数分の範囲です。Routing control の状態変更は数秒以内に有効になり、Route 53 は対応するヘルスチェックを healthy または unhealthy として直ちにマークします。ただし、クライアントは依然として DNS の変更を取得する必要があるため、実効的な RTO は TTL 設定に依存します (60〜120 秒を推奨)。他のフェイルオーバーアプローチに対する ARC の主要な利点は、フェイルオーバーメカニズム自体の信頼性です。極めて信頼性の高いデータプレーンにより、リージョン全体に障害が発生してもフェイルオーバーを実行できる上、safety rules がプレッシャー下でのオペレーターのミスを防ぎます。

ARC では、アプリケーションのモデリング (recovery groups、cells、readiness checks の定義)、routing controls と safety rules の構成、災害復旧タスク専用の長期 IAM 認証情報の維持に対する事前投資が必要です。AWS は、これらの認証情報を、ID プロバイダーに障害が発生してもアクセス可能となるよう、通常のフェデレーテッドアクセスとは別に、オンプレミスの物理金庫または仮想ボールトに保管することを推奨しています。この投資は、プレッシャー下で初めてフェイルオーバーを実行しなければならない時、ガードレールがオペレーターのミスを防ぐことで報われます。

運用上の推奨プラクティス

ARC のドキュメントから、強調すべきいくつかの運用上の推奨プラクティスを取り上げます。

• フェイルオーバーに関与するレコードの DNS TTL を 60 秒または 120 秒に設定する。
• ARC コントロールプレーンが利用不可能でもアクセスできるよう、5 つのリージョナル クラスターエンドポイントと routing control ARN をブックマークまたはハードコードする。
• クライアントがエンドポイントに接続し続ける時間を制限する (Application Load Balancer のデフォルトの keepalive 3,600 秒は高速なリカバリには長すぎるため、300 秒への削減を検討)。
• ARC で定期的にフェイルオーバーをテストし、構造がスタックの正しいリソースに揃っていることを確認する。

成熟した運用プラクティスを持ち、厳しい RTO SLA を持つミッションクリティカルなワークロードを扱うチームにとって、ARC は適切なツールです。

戦略 2: Amazon Route 53 を使用した DNS ベースのフェイルオーバー

よりシンプルな出発点を求めるチームには、Route 53 が障害のあるリージョンからトラフィックをルーティングするためのアプローチを提供します。

Amazon API Gateway、Elastic Load Balancing (ELB)、またはカスタムヘルスチェックエンドポイントなど、リージョナルアプリケーションエンドポイントを監視するように Route 53 ヘルスチェックを構成します。次に、フェイルオーバーのルーティングポリシーを使用して、Route 53 が通常状態ではプライマリリージョンにトラフィックを向け、ヘルスチェックが失敗するとセカンダリリージョンに自動的にルーティングするようにします。両方のリージョンにグローバルテーブルレプリカが存在するため、セカンダリリージョンは即座に読み取りを提供し、書き込みを受け付けることができます。

このアプローチを、単純なエンドポイントの到達可能性ではなく、実際のアプリケーションの健全性シグナルに反応させるには、CloudWatch アラームを監視する Route 53 ヘルスチェックを使用できます。例えば、API Gateway の 5XXError 率が連続する 3 つの 1 分間の評価期間にわたって 5% を超えた場合や、DynamoDB の SystemErrors メトリクスが一定期間ゼロを超えた場合に発火する CloudWatch アラームを作成できます。次に、CLOUDWATCH_METRIC タイプを使用してそのアラームを Route 53 ヘルスチェックに関連付けます。アラームが ALARM 状態に入ると、Route 53 はヘルスチェックを unhealthy としてマークし、DNS フェイルオーバーを自動的にトリガーします。

これにより、TCP 接続が成功するかどうかだけでなく、アプリケーションにとって実際に重要な健全性シグナルによって駆動される自動フェイルオーバーが実現します。複数の CloudWatch アラームを 複合アラーム に組み合わせて、複数の条件が同時に満たされた場合のみフェイルオーバーをトリガーできるため、誤検知のリスクを低減できます。例えば、5xx エラー率の上昇、DynamoDB の SystemErrors の増加、ReplicationLatency の持続的なスパイクのすべてを必要とする複合アラームは、単一のシグナルだけよりも信頼性が高くなります。

RTO に関する考慮事項

このアプローチの RTO は複数の要因に依存します。CloudWatch アラーム自体は、評価期間と datapoints-to-alarm の構成によって、評価して発火するまでに数分かかることがあります。アラームが発火すると、DNS TTL の伝播が追加の遅延を加えます。低い TTL (一般的には 60 秒) を使用していても、クライアント側の DNS キャッシュとリゾルバーキャッシュが実際のフェイルオーバー時間を延長する可能性があります。一部のクライアントやリゾルバーは TTL をまったく尊重しない場合があり、その場合トラフィックの一部は予想よりも長く障害のあるリージョンに到達し続ける可能性があります。実際には、アラーム評価、DNS 伝播、クライアントキャッシュを考慮すると、エンドツーエンドのフェイルオーバー時間は数分になると想定してください。

このアプローチは、数分間のサービス低下が許容できるシンプルなアーキテクチャや、最小限のアプリケーションコード変更でマネージドかつインフラレベルのソリューションを希望するチームに適しています。ヘルスチェックがエンドポイントの到達可能性だけでなく、実際のアプリケーション機能を検証することを確認し、DNS TTL を実用上可能な限り低く設定してください。

アプローチの比較

ミッションクリティカルなワークロードの場合、Region switch をプライマリのフェイルオーバーメカニズムとして使用し、ARC から始めることをお勧めします。レジリエンスの取り組みの初期段階にあるチームにとって、Route 53 を使用した DNS ベースのフェイルオーバーは現実的な出発点であり、要件が成熟するにつれて ARC へと進化させていくことができます。

フェイルオーバー中および後に予想されること

堅実なフェイルオーバー戦略があっても、備えておくべき運用上の現実があります。

フェイルオーバー後の古いデータの読み取り

結果整合性モデル (MREC) でフェイルオーバーした直後、アプリケーションは、障害のあるリージョンからの最新の書き込みをまだ受け取っていない項目を新しいリージョンから読み取る場合があります。これは結果整合性モデルの本質的な結果であり、レプリケーションラグのために最新の状態をまだ反映していない可能性のあるレコードを、アプリケーションは処理できなければなりません。

操作を冪等になるように設計し、項目にバージョン属性を含め、MRSC を使用していない限りリージョン間の強整合性を仮定しないでください。例えば、アプリケーションが注文を処理し、その直後にフェイルオーバー先のリージョンから読み戻した場合、読み取りが古いデータを返す可能性があります。バージョンチェックや条件付き書き込みは、古い状態に対して動作することを防ぎます。

コンフリクト解決の意外な結果

ラストライターウィンズはほとんどの場合うまく機能しますが、同時書き込みでは予期しない結果を生むことがあります。2 つのリージョンが同じ項目属性を同時に更新すると、一方の書き込みは静かに「失われ」ます。ほとんどのワークロードでは、書き込み間隔が秒単位であり最新の値が正しい値であるため、これは問題ありません。しかし、金融元帳や在庫カウンターなど、すべての書き込みが重要なワークロードの場合は、より慎重になる必要があります。条件付き書き込みの使用、同じ項目に対するクロスリージョンのコンフリクトを避けるためのデータモデルの設計、またはコンフリクトウィンドウを完全に排除するための MRSC の使用を検討してください。

フェイルオーバー後の高いレプリケーションレイテンシ

リージョンが復旧した後、混乱中に蓄積された書き込みのバックログによって引き起こされる、上昇したレプリケーションレイテンシが見られる場合があります。パート 1 の ReplicationLatency アラームと合成カナリアがこれを追跡するのに役立ちます。メトリクスを監視し、バックログがドレインするのを待ちます。レイテンシが 5 分を超え、低下傾向にない場合は、AWS Support にお問い合わせください。

ターゲットリージョンでのスロットリング

ターゲットリージョンで ThrottlingException エラーが発生した場合、原因はほぼ常にリダイレクトされたトラフィックに対する読み取りキャパシティの不足です。オンデマンドテーブルの場合、これらのエラーはキャパシティが自動スケールするにつれて一時的なものであるはずです。プロビジョニング済みテーブルの場合は、パート 1 で説明したように DynamoDB Auto Scaling API を使用してプロビジョニング済みキャパシティを直ちに増やしてください。これがキャパシティを事前に準備することが非常に重要である理由です。

接続の失敗

アプリケーションがターゲットリージョンに接続できない場合は、IAM ポリシーがターゲットリージョンでの DynamoDB アクセスを許可していることを確認してください。プライベート接続のために Amazon VPC エンドポイント を使用している場合は、エンドポイントがフェイルオーバーリージョンにも構成されていることを確認してください。セキュリティグループとネットワーク ACL ルールは、実際のフェイルオーバー時にのみ表面化する接続失敗のもう 1 つの一般的な原因です。

データの不整合

フェイルオーバー後にデータの不整合を観察した場合、これは結果整合性モデルを使用している場合の予想される動作です。障害のあるリージョンからの処理中の書き込みは、混乱前にレプリケートされていなかった可能性があります。アプリケーションレベルの整合性チェックを実装し、バージョン番号を伴う条件付き書き込みを使用し、即時の整合性を仮定するのではなく、正しい状態に収束するようにアプリケーションを設計してください。

まとめ

DynamoDB グローバルテーブルでのフェイルオーバーは、複数のリージョンにレプリカを持つことだけが重要なのではありません。ワークロードに適したフェイルオーバー戦略を選び、トレードオフを理解し、いざという時に実行できる運用上の自信を構築することが重要です。

Route 53 ARC は、ミッションクリティカルなワークロードに最も堅牢で協調的なフェイルオーバーを提供し、Region switch がサービスをまたぐリカバリをオーケストレートする推奨メカニズムです。極めて信頼性の高いデータプレーンにより、リージョナルな障害中であってもフェイルオーバーメカニズム自体が利用可能であり続けます。

Route 53 を使用した DNS ベースのフェイルオーバーは、最小限のアプリケーション変更でよりシンプルな出発点を提供しますが、アラーム評価と DNS 伝播を考慮するとエンドツーエンドのフェイルオーバー時間は数分になります。データ損失ゼロを必要とするワークロードの場合、MRSC は RPO を完全に排除します。

どの戦略を選んでも、メカニズムと同じくらい準備が重要です。まだの場合は、このシリーズの パート 1 から始めて、インフラストラクチャの準備が整っていることを確認してください。次に、パート 3 の FIS 実験のウォークスルーを使用して、エンドツーエンドのフェイルオーバーを検証してください。

始めましょう

次のステップは、現在の状況によって異なります。フェイルオーバーメカニズムがまったくない場合は、Route 53 を使用した DNS ベースのフェイルオーバーから始めてください。SystemErrors と ReplicationLatency を監視する複合 CloudWatch アラームによって支えられたヘルスチェックを、フェイルオーバーのルーティングポリシーと組み合わせます。すでに DNS ベースのフェイルオーバーがある場合は、Route 53 Application Recovery Controller に移行し、Region switch プランを構成してください。

いずれにしても、フェイルオーバーが機能するかどうかをインシデントが起きるまで確認しないでください。AWS Fault Injection Service を使用して GameDay をスケジュールし、リージョナルな混乱をシミュレートしてエンドツーエンドのフェイルオーバーを実行してください。MRSC と MREC の両方の構成を含む、DynamoDB グローバルテーブルに対する FIS 実験の実行に関するステップバイステップガイドについては、このシリーズの パート 3 を参照してください。

パート 1 で説明した監視とキャパシティの準備をまだ設定していない場合は、まずそこから始めてください。これがなければ何も機能しません。

より深いガイダンスについては、DynamoDB グローバルテーブルの使用 と AWS Well-Architected Framework の信頼性の柱 をご覧ください。

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

原文: https://aws.amazon.com/blogs/database/best-practices-for-amazon-dynamodb-global-tables-part-2-failover-strategies/

著者について

	Lee Hannigan Lee は、アイルランドを拠点とする AWS DynamoDB チームのシニアデータベースエンジニアです。データモデリング、分散システム、開発者向けツーリングにわたる 7 年の経験を持ち、大規模に構築する顧客にとって DynamoDB をより利用しやすくすることに注力しています。
	Shiladitya Mandal Shiladitya は、AWS DynamoDB チームのソフトウェア開発マネージャーで、Data Movement グループを率いています。Amazon に 10 年以上在籍し、分散システムの構築とスケーリングに携わってきました。シアトルを拠点とする Shiladitya は、グローバルテーブルやその他のクロスリージョン機能を支える DynamoDB のレプリケーションおよびデータムーブメント機能に注力しています。