Amazon Route 53 を用いたディザスタリカバリ (DR) のメカニズム

多くのアプリケーションにとって、単一 AWS リージョンの複数のアベイラビリティーゾーン (AZ) にデプロイし、AWS Well-Architected Framework に準拠することが、可用性・シンプルさ・コストのバランスが取れた構成の実現につながります。ただし、お客様によっては規制上の理由等によりアクティブ / アクティブまたはアクティブ / スタンバイのディザスタリカバリ (DR) 構成で他のリージョンへの展開が必要となる場合があります。

このような DR のシナリオでは、障害を軽減して通常の運用に戻すためのシンプルで効果的なアプローチが必要です。迅速かつ確実に DR のプロセスを実行するためには、プロセスをわかりやすく、最小限の手順で済ませ、定期的に実践する必要があります。DNS レコードの更新によるフェイルオーバーは、多くの企業で用いられている方法です。このブログ記事では、DNS の更新により DR を効果的に行う方法について説明し、このアプローチを採用する際に考慮すべき原則とベストプラクティスについて説明します。

Amazon Route 53 のようなモダンな DNS サービスには、ヘルスチェックとフェイルオーバーレコードが用意されており、これらを使用して DR 計画を簡素化および強化できます。まず、AWS のサービスがコントロールプレーンとデータプレーンを使用してどのように信頼性を実現するかを概説し、次にフェイルオーバーのメカニズムを作成するための設計原則を紹介します。最後に、DR アプローチをより効果的にする Route 53 の機能について説明します。

コントロールプレーンとデータプレーン

ほとんどの AWS サービスには、サービスのコア機能を提供するデータプレーンと、リソースの作成、更新、削除を可能にするコントロールプレーンが含まれています。Amazon Elastic Compute Cloud (Amazon EC2) などのリージョン AWS サービスには、特定の AWS リージョンにあるサービスのコントロールプレーンに接続するリージョンエンドポイントがあります。ただし、Amazon CloudFront、AWS Identity and Access Management (IAM)、Route 53 など、一部の AWS サービスは世界中の多くの場所に分散されています。これらのグローバルサービスのコントロールプレーンは、米国東部 (バージニア北部) リージョン (us-east-1) でのみ使用できます。同様に、AWS Global Accelerator と Amazon Route 53 Application Recovery Controller (Route 53 ARC) は、コントロールプレーンが米国西部 (オレゴン) リージョン (us-west-2) にあるグローバルサービスです。これらのグローバルサービスでリソースを作成して設定するには、コントロールプレーンが配置されているリージョンの API エンドポイントを使用する必要があります。

Route 53 データプレーンは DNS クエリに応答し、ヘルスチェックを実行および評価します。これらはグローバルに分散されており、サービスレベルアグリーメント (SLA) として 100% の可用性を満たすように設計されています。Route 53 でリソースの作成・更新・削除を行うマネジメントコンソールおよび API は、DNS の管理に必要な強力な一貫性と耐久性を優先するように設計されたコントロールプレーン上で実行されます。これを実現するために、コントロールプレーンは単一リージョン (バージニア北部, us-east-1) に配置されます。どちらのシステムも信頼性が高いように構築されていますが、コントロールプレーンは SLA に含まれていません。データプレーンはそのレジリエントな設計のおかげで利用可能な一方で、コントロールプレーンは利用できなくなるような事態がごく稀に起き得ます。このため、ディザスタリカバリとフェイルオーバーのメカニズムを構築する際は、データプレーン機能を使用することで信頼性を最大限に高めることをお勧めします。

データプレーン、コントロールプレーン、および AWS が高可用性目標を達成するためのサービスを構築する方法の詳細については、アベイラビリティーゾーンを使用した静的安定性の解説と Amazon Builders’ Library を参照してください。

Route 53 には可用性 100% の SLA を目指して設計されたデータプレーンがあるため、フェイルオーバーはコントロールプレーンではなくデータプレーンに依存すべきです。この記事の後半で、Route53 に対して意図した変更をコントロールプレーンに依存せずに行う方法について説明します。その前に、効果的な DR のフェイルオーバーメカニズムを作成する際に従うべきベストプラクティスをいくつか見てみましょう。

信頼性の高いフェイルオーバーメカニズムの設計

DR 計画を策定する際には、フェイルオーバーメカニズムがレジリエントで必要なときに利用可能であることを確認することが重要です。フェイルオーバーメカニズムはシンプルで、依存関係をできるだけ少なくし、徹底的にテストする必要があります。当たり前のように思えるかもしれませんが、テスト中は機能するものの、災害時には正しく動作しなくなる依存関係を見落としがちです。

現実世界で例えると、非常用発電機が最も必要になるのは商用電源が利用できないときです。したがって、信頼性の高いフェイルオーバーメカニズムでは、起動時に商用電源に依存したり、商用電源自体をフェイルオーバー電源としてはいけません。加えて、通常時にテストを行う際は商用電源が利用できる状態であることが多いですが、フェイルオーバー時に商用電源に対する隠れた依存関係がないことを確認しておく必要があります。

フェイルオーバーのメカニズムを構築する際には、次の原則を考慮してください。次のセクションでは、これらの原則を組み込んだ Route 53 ベースのソリューションを見ていきます。

データプレーン機能を使用してください。信頼性と耐障害性を最大限に高めるために、データプレーン機能を使用するようにフェイルオーバーメカニズムを設計してください。たとえば、DNS レコードやヘルスチェック設定を更新する (コントロールプレーン機能) のではなく、Route 53 ヘルスチェック (データプレーン機能) を使用するメカニズムを選択します。
スタンバイリージョンからフェイルオーバーを制御します。マルチリージョンのフェイルオーバーは、各 AWS リージョンが他のリージョンから独立・分離して構築されているため強力です。障害が起きたアプリケーションをフェイルオーバーするメカニズムを設計するときは、障害のあるリージョンに変更を加える必要がないことを確認してください。代わりに、正常なスタンバイリージョンに変更を加えてフェイルオーバーを開始してください。
依存関係を理解して減らし、フェイルオーバーの信頼性を高めます。フェイルオーバーを開始して正常に動作させるために必要な内部および外部の依存関係をすべて洗い出します。フェイルオーバープロセスの依存関係の数を最小限に抑えることで、潜在的にエラーが発生し得る箇所が減り、信頼性が向上します。たとえば、マネジメントコンソールを使用すると、(ブラウザを通して提供される) UI コンポーネントが追加の依存関係となるため、AWS CLI または SDK から直接操作することを検討してください。
重要なコンポーネントを事前にプロビジョニングします。事前に全部または一部のリソースをプロビジョニングすることで、災害イベント中に重要なコンポーネントを作成する必要がなくなり、コントロールプレーンへの依存を避けることができます。これにより、ディザスタリカバリ目標 (RTO と RPO) の達成に役立ちますが、コストとのバランスを取る必要があります。可能ならば事前にリソースを作成してスケーリングしておくと、スタンバイリージョンのキャパシティの制約を防ぐのにも役立ちます。
認証方法を確認してください。AWS サービスを管理するための認証方法をよく考えてください。たとえば、AWS Organization で AWS IAM Identity Center (旧 AWS SSO) を使う場合、1 つのリージョンでのみ使用可能です。そのリージョンで AWS IAM Identity Center に問題がある場合は、通常のプロセスを省略し、AWS IAM Identity Center に依存しない別の認証方法を使用する必要が生じます。この場合、緊急アクセス用の IAM User を用意しておくことで要件を満たすことができます。(IAM 認証はグローバルに利用可能な IAM データプレーンを用いるため)
定期的にテストしてください。障害発生時にフェイルオーバーメカニズムが機能するという確信を持てるようにするには、プロセスを定期的にテストすることが重要です。テストにより、DR 計画が最新であり、必要なときに正常に実行できることが検証されます。

次に、Route 53 のさまざまな機能を使用して、これらの原則に従ったフェイルオーバーメカニズムを構築する 3 つの方法を見てみましょう。

Route 53 ヘルスチェック

Route 53 ヘルスチェックは、8 つの異なる AWS リージョンからリソースにリクエストを行い、アクセスできるかを確認します。Route 53 では、世界中に分散されたデータプレーンにヘルスチェックを組み込むことで、高い信頼性を実現しています。Route 53 ヘルスチェックでは以下をモニタリングできます。

TCP、HTTP、または HTTPS エンドポイント
他の Route 53 ヘルスチェックのステータス
Amazon CloudWatch アラームのステータス
Route 53 Application Recovery Controller のルーティングコントロールの状態

18% を超えるヘルスチェッカーがエンドポイントを正常であるとレポートした場合、Route 53 ヘルスチェックは正常状態と判定されます。デフォルトでは、Route 53 がエンドポイントを正常と見なすには、16 のヘルスチェッカーのうち少なくとも 3 つ (18.75%) が正常であると報告する必要があります。

これにより障害だと誤って認識するのを防ぐことができます。ヘルスチェックが異常と判定されるのは、一貫して繰り返し接続が失敗する時に限られます。ヘルスチェックが正常と異常の間を行き来している場合や、ローカルネットワークの問題などで一部のチェッカーが異常と報告した場合でも、ヘルスチェックは異常と判定されません。ヘルスチェッカーのリージョンと異常のしきい値の両方を設定できます。

ヘルスチェック付きのフェイルオーバールーティングポリシーを使用して、DNS が自動的にフェイルオーバーするように設定できます。このシナリオでは、Route 53 のフェイルオーバーレコードは、リソースが正常な場合に DNS クエリのプライマリリソースを返します。リソースに異常が発生し、セカンダリが正常であれば、Route 53 は自動的にセカンダリレコードに更新し応答します (フェイルオーバー)。プライマリレコードとセカンダリレコードの両方に異常がある場合は、プライマリレコードを返します。

図 1 は、Route 53 DNS フェイルオーバーによるアクティブ / パッシブ構成を示しています。プライマリリージョンの問題によりヘルスチェック（HC-Primary）が失敗すると、セカンダリレコードへの自動フェイルオーバーが開始されます。

図 1. Route 53 ヘルスチェックによるシンプルな自動 DNS フェイルオーバー。

ヘルスチェックによる自動回復は設定が簡単で信頼性が高く、Route 53 コントロールプレーンに依存しません。ヘルスチェックのステータスが変わると、Route 53 は Route 53 データプレーンを使用してヘルスチェックに関連するレコードを更新します。

ただし、ヘルスチェックを使用して自動的にフェイルオーバーする場合、断続的にヘルスチェックが通らないような問題が発生していても強制的にフェイルオーバーすることはできません。また、Route 53 のヘルスチェック API を用いて強制的なフェイルオーバーを行うことは、コントロールプレーンに依存してしまいます。

ヘルスチェックを直接的に用いる方法は、アクティブ / アクティブアーキテクチャで最も効力を発揮します。このようなシナリオでは、障害が発生したエンドポイントをアクティブなエンドポイントのグループから取り除くだけで対応が完了します。エンドポイントがヘルスチェックで再度正常になった場合は、自動的にそのエンドポイントをサービスに戻しても問題ありません。この設定において、エンドポイントのフェイルオーバーと復帰はどちらも自動的に行われ、ユーザーの操作は必要ありません。

しかしながら、ほとんどの DR 計画では、アクティブ / スタンバイアーキテクチャを取るケースがより一般的です。フェイルオーバーが成功することは、多くの場合、必要なステップの 1 つに過ぎず、他にもデータベースのフェイルオーバーやスタンバイキャパシティのスケールアップなど、一連の手順を実行する必要があります。多段階のリカバリプロセスでは、自動ヘルスチェックを用いる方法よりも直接的にフェイルオーバーとフェイルバックを制御できる必要があります。

Route 53 ヘルスチェックはリソースの状態を直接調べるためによく使用されますが、シグナルを発するシステムとしても使用できます。S3 バケット内のファイルの有無など、管理する他のウェブサービスに対してヘルスチェックを設定することで、Route 53 DNS データプレーンにフェイルオーバーを開始するように確実に通知できます。次の 2 つのセクションでは、これを活用してフェイルオーバーを直接制御する方法について説明します。

Route 53 Application Recovery Controller

Amazon Route 53 Application Recovery Controller (Route 53 ARC) は、可用性の高いアプリケーションがフェイルオーバーのタイミングを制御する方法を提供します。Route53 ARC は、フェイルオーバーを管理して正常に実行するために、準備状況チェックとルーティングコントロールという 2つの機能を提供します。(訳注: 加えて、re:Invent 2022 においてゾーナルシフトが発表されました。ゾーナルシフトは ALB/NLB に対して指定した AZ へトラフィックを流すことを回避する機能を提供します) 準備状況チェックは、スタンバイシステムがフェイルオーバーする準備ができていることを確認するのに役立ちます。また、ルーティングコントロールを使用すると、Route 53 コントロールプレーンに依存することなく、可用性の高いデータプレーン API を使用して、手動またはプログラムからフェイルオーバーを開始できます。

Route 53 ARC ルーティングコントロールは、Route 53 ヘルスチェックの状態をオン/オフすることのできるスイッチのようなものです。これにより、DNS エントリが更新され、トラフィックがプライマリからスタンバイにリダイレクトされます。

Route 53 ARC では、専用クラスターが 5 つの AWS リージョンにまたがるデータプレーンを作成し、ルーティング制御機能をホストします。クラスターはクォーラムモデルで動作します。つまり、2 つのリージョンエンドポイントが使用できなくても、クラスターとルーティングコントロール機能は動作し続け、フェイルオーバー制御を提供します。各クラスターには、各リージョンに 1 つずつ、合計 5 つの独立した API エンドポイントがあり、5 つのエンドポイントのいずれかを使用してルーティングコントロールの状態を更新できます。

Route 53 ARC ルーティングコントロールは動作に必要な依存関係を最小限に留め、かつ、それぞれの依存関係はそれ自身が非常に信頼できます。ルーティングコントロールの状態を変更するときは、失敗する可能性が極めて低い以下の 3 つの条件に依存しています。

5 つのエンドポイントのうち少なくとも 3 つが使用可能で、クォーラムに参加している。
有効な IAM 認証情報があり、リージョン内のクラスターエンドポイントに対して認証できる。
Route 53 データプレーンは正常である。(Route 53 データプレーンは可用性 100% の SLA を満たすように設計されています)

ルーティングコントロールの状態を更新すると、その変更は Route 53 のヘルスチェックを通じて伝播され、Route 53 の DNS レコードに反映されます。Route 53 ARC のルーティングコントロールは可用性が高いように設計され、コントロールプレーン API 操作は不要なため、変更は信頼性高く実行されます。

ルーティングコントロールには、フェイルオーバー操作のガードレールを定義することができる、設定可能な安全ルールも含まれています。安全ルールを使用すると、明示的にガードレールを定義することができ、クラスターがルールに違反する状態変更を拒否することができます。ガードレールの例をいくつか以下に示します。

アクティブ / スタンバイアーキテクチャでは、一度に 1 つのエンドポイント (アクティブまたはスタンバイ) のみを有効にします。
アクティブ / アクティブアーキテクチャでは、一度にオフラインにするアプリケーションレプリカの数を制限します。これにより、さまざまなオペレーションや自動化コンポーネントがキャパシティを安全な閾値以下に減らすことを防ぐことができます。変更は要求された順序で処理され、必要な数のレプリカが稼働中であるかどうかがチェックされます。

Route 53 ARC 準備状況チェックは、アプリケーションレプリカが使うリソースのクォータ、キャパシティ、その他の設定を監査します。これらのチェックは、レプリカへのフェイルオーバーが必要になった場合に備えて、アプリケーション構成がプライマリに準拠した状態を維持することをサポートします。例えば、アクティブ / パッシブアーキテクチャでは、プライマリのアプリケーションをスケールアップ、もしくは変更せざるを得ない場合があります。準備状況チェックは、プライマリに変更が加えられたときにスタンバイも追随できることを保証する信頼性の高いメカニズムです。

図 2 は、Route 53 ARC をアクティブ / スタンバイ構成のアプリケーションとともにデプロイした場合の構成を示しています。

図 2. アプリケーションレプリカを含む Route 53 Application Recovery Controller の構成

この構成では、リージョン A (プライマリ) とリージョン B (スタンバイ) に、Application Load Balancer、EC2 Auto Scaling グループ、および DynamoDB テーブルから構成される同一のアプリケーションがあります。さらに、次の点にも注意してください。

スタンバイリージョンのフェイルオーバーレプリカを継続的に監査する準備状況チェックを作成しました。
各準備状況チェックごとに、NOT READY 値が返された場合に通知する EventBridge ルールを作成しました。
リージョン A のアプリケーションに問題が発生した場合、5 つのリージョンにそれぞれ用意されている Route 53 ARC クラスターエンドポイントのいずれかにルーティングコントロール API の呼び出しを行うことができます。ルーティングコントロールの状態を更新すると、アプリケーションの Route 53 リソースレコードのヘルスチェックステータスが変更され、トラフィックがリージョン B に移動します。

Route 53 ARC ルーティングコントロールでフェイルオーバーを行うようにアプリケーションを設定したら、予期せぬ事態に備えた準備が整っていることを確認しましょう。例えば、ルーティングコントロール API の操作を Route 53 ARC データプレーンから行い、ルーティングコントロールの状態を取得・更新する計画を立てましょう。また、Route 53 ARC コンソールやリカバリコントロール設定 API の操作は、コントロールプレーンが米国西部 (オレゴン) リージョン (us-west-2) にのみあるため、これらに依存しないようにする必要があります。

DR のシナリオに備えて Route 53 ARC の使用を準備するための詳細なガイダンスについては、Route 53 ARC 開発者ガイドのベストプラクティスを参照してください。

Route 53 ARC は、この記事で説明した中で最も機能が豊富なフェイルオーバーソリューションを提供します。ただし、場合によってはセットアップが複雑になり、マルチリージョンの Route 53 ARC クラスターは他のソリューションよりもコストがかかる可能性があります。

次に、独立した Route 53 ヘルスチェックを使用してスタンバイリージョンからフェイルオーバーを開始する簡単で費用対効果の高い方法を見てみましょう。

Standby takes over primary (スタンバイがプライマリを引き継ぐ)

Route 53 の機能を使用してフェイルオーバーを行う3つ目の方法として、“standby takes over primary” (STOP) と呼ばれる方法が挙げられます。この戦略は、スタンバイリージョンとアプリケーションが正常に動作することを前提とします。このソリューションでは、スタンバイリージョンのリソース (ヘルスチェック) を使用してフェイルオーバーを制御します。これにより、プライマリリージョンのリソースに依存せずにフェイルオーバーを開始できます。

このソリューションでは、少なくとも 1 つのヘルスチェックを使用して、スタンバイリージョン内のリソースのステータスをチェックします。このアーキテクチャの例を見てみましょう。

一連の流れは、プライマリリージョン (リージョン A とします) のアプリケーションの Route 53 DNS レコードに関連付けられた Route 53 ヘルスチェックである HC-Initiate-Disaster-Recovery からスタートします。このヘルスチェックは、運用者 (または自動化された運用プロセス) がプライマリアプリケーションを異常と宣言できる条件かどうかを判定し、フェイルオーバーを開始します。この条件は単純なもので良く、ここではスタンバイリージョンで作成または削除したファイルの有無、という条件を採用します。

具体的には、このヘルスチェックは公開されている S3 Web サイト上のファイル (
https://<FAILOVER-BUCKET>.s3.<STANDBY-REGION>.amazonaws.com/initiate-failover.html ) を探します。ファイルが存在しない場合、このヘルスチェックの結果は正常となり、フェイルオーバーは行われません。

スタンバイリージョンのリソースに障害が発生した場合に、誤ってフェイルオーバーを開始しないように、反転されたヘルスチェックを使用しています。このヘルスチェックはプライマリリージョン (アプリケーション) の DNS レコードに関連付けられていますが、スタンバイリージョンのリソース (ファイル) の状態を調べるように設定し、ヘルスチェックの状態を制御します。

フェイルオーバーを開始するには、initiate-failover.html をスタンバイリージョンの S3 に作成します。これにより、プライマリリージョンが異常な状態であることがヘルスチェックに伝わり、プライマリリージョン (リージョン A) からセカンダリリージョン (リージョン B) にトラフィックが切り替わります。

図 3 は、この “standby takes over primary” フェイルオーバー戦略の Route 53 ヘルスチェック、ルーティングポリシー、およびフェイルオーバーレコードの設定を示しています。

図 3. standby takes over primary フェイルオーバー戦略

ヘルスチェックには次の設定があります。

ヘルスチェック: HC-Initiate-Disaster-Recovery
- プライマリリージョンのアプリケーションの DNS レコードに関連付けられています。
- スタンバイリージョンにあるリソースをチェックします。
- 応答が HTTP 4xx、5xx、またはタイムアウトの場合、この反転されたヘルスチェックは常に正常です。これにより、トラフィックが引き続きプライマリリージョンに向かうようになります。
- 運用者が操作 (ファイルの作成など) を行うと、HTTP 2xx または 3xx を返すようにリソースが更新され、フェイルオーバーが開始されます。

フェイルオーバーのプロセスを閉域で完結させるには、S3 上のファイルによるトリガーの代わりに Amazon CloudWatch アラームを使用する方法があります。この方法では、スタンバイリージョンの特定の CloudWatch メトリクスを監視するアラームを作成し、CloudWatch アラームを監視する Route 53 ヘルスチェックを作成します。S3 の場合と同様に、反転されたヘルスチェックを使用して、スタンバイリージョンが正常かつ特定のメトリクス値を返した場合にのみスタンバイがプライマリを引き継ぐようにします。

CloudWatch アラームをフェイルオーバーのトリガーとして使用すると、Amazon Virtual Private Cloud (VPC) 内でフェイルオーバーできます。たとえば、VPC エンドポイントを経由して CloudWatch を呼び出し、Route 53 のプライベートホストゾーンでヘルスチェック用の DNS エントリを作成し、VPC 内でプライベートにフェイルオーバーを実行できます。

可能であれば、フェイルオーバーを開始する操作をスタンバイアプリケーションの既存の依存関係に合わせることをお勧めします。たとえば、スタンバイアプリケーションがすでに S3 への読み込み / 書き込みアクセスに依存している場合、ファイルを S3 バケットに入れることをフェイルオーバー開始の操作としても新しい依存関係を追加することにはなりません。もし、スタンバイアプリケーションが DynamoDB に依存している場合は、DynamoDB テーブルで更新したレコードに基づいて応答するヘルスチェックのハンドラーをアプリケーション内に作成することもできます。

既に AWS Systems Manager Automation を使用してフェイルオーバーに備えてリソースを準備している場合は、フェイルオーバーを開始する操作を既存の自動化されたフェイルオーバーメカニズムに簡単に統合できます。フェイルオーバーを開始する操作の呼び出しをドキュメントの最後に追加すると、運用担当者はリソースの準備とフェイルオーバーの実行の両方を自動化することができます。

プライマリが回復したら、元に戻す方法が 2 つあります。プライマリリージョンにフェイルバックする場合は、行った変更を元に戻して Route 53 を元に戻します。または、2 回目のフェイルオーバーの影響を避けたい場合は、Route 53 レコードセットを更新して、プライマリとスタンバイのフェイルオーバーレコードセットの役割を入れ替えて対応することもできます。

このソリューションでは Route 53 のヘルスチェックとフェイルオーバールーティングを使用するため、Route 53 の制御や安全対策の機能を活用することができます。さらに、この戦略を取る場合の主なコストは Route 53 のヘルスチェックとなるため、コストを最小限に抑えることができます。フェイルオーバーの準備状況を定期的に監査する必要がある場合 (推奨)、Route 53 ARC 準備状況チェックもこのフェイルオーバー戦略で使用することができます。

サマリー

このブログ記事では、インシデントによるダウンタイムを最小限に抑えるために Amazon Route 53 の機能を使用して迅速かつ確実にフェイルオーバーする 3 つの DR 戦略について説明しました。

それぞれの戦略に伴うトレードオフについても説明しました。Route 53 ヘルスチェックは世界中に分散され、サービスに対する重大なイベントが発生しても信頼性高く機能します。Route 53 Application Recovery Controller のデータプレーンはマルチリージョンであり、最大 2 つのリージョンのエンドポイントの障害を許容できます。最後に、“standby takes over primary” アプローチにより、プライマリリージョンに依存せずにフェイルオーバーできます。

これら 3 つの戦略は、レジリエントで障害発生時にシステムへの依存関係を最小限に留める DR メカニズムを構築する際に、検討すべき選択肢を提供します。

翻訳は Solutions Architect 合田が担当しました。原文はこちらをご覧ください。

Amazon Web Services ブログ