Amazon Web Services ブログ

Amazon Route 53 アプリケーション復旧コントローラーの紹介

障害から復旧するアプリケーションの能力を継続的にモニタリングし、非常に高い可用性を提供する必要があるアプリケーションの構築を支援するために、複数の AWS アベイラビリティーゾーン、AWS リージョン、およびオンプレミス環境にわたるアプリケーションの復旧を制御するAmazon Route 53 機能のセットであるAmazon Route 53 アプリケーション復旧コントローラーを本日発表できることを嬉しく思います。

AWS では、データとワークロードのセキュリティと可用性が最優先事項です。当初から AWS グローバルインフラストラクチャでは、お客様がさまざまなタイプの障害に対して回復力のあるアプリケーションアーキテクチャを構築できるようにしています。ビジネスまたはアプリケーションが高可用性を必要としている場合、通常お客様は AWS グローバルインフラストラクチャを使用して、AWS リージョン内の AWS アベイラビリティーゾーンに冗長なアプリケーションレプリカをデプロイします。次に、Network または Application Load Balancer を使用して、トラフィックを適切なレプリカにルーティングします。このアーキテクチャは、大多数のワークロードの要件を処理します。

ただし、業界やワークロードによっては、高可用性の面でより高い要件があります。可用性率は 99.99% 以上で、目標復旧時間 (RTO) は秒または分単位で測定されます。リアルタイムの支払い処理や取引エンジンが混乱した場合、経済全体にどのような影響を与えるかを考えてみてください。これらの要件に対処するために、通常お客様は、さまざまな AWS アベイラビリティーゾーン、AWS リージョン、およびオンプレミス環境に複数のレプリカをデプロイします。次に、Amazon Route 53 を使用して、エンドユーザーを適切なレプリカに確実にルーティングします。

Amazon Route 53 アプリケーション復旧コントローラーを使用すると、非常に高い可用性と小さい RTO を必要とするアプリケーションを構築できます。通常それらはアクティブ/アクティブアーキテクチャを使用しますが、他のタイプの冗長性アーキテクチャを使用するアプリケーションも、Amazon Route 53 アプリケーション復旧コントローラーからの恩恵を受ける場合があります。それは、準備状況チェックとルーティング制御の 2 つの部分で構成されています。

準備状況チェックでは、AWS リソース設定、容量、およびネットワークルーティングポリシーを継続的にモニタリングするので、お客様は復旧オペレーションを実行する能力に影響する変更をモニタリングできるようになります。これらのチェックにより、復旧環境が拡張され、必要に応じて引き継がれるように設定されていることを確認します。それらは、Auto Scaling グループ、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon Elastic Block Store (EBS) ボリューム、ロードバランサー、Amazon Relational Database Service (RDS) インスタンス、 Amazon DynamoDB テーブル、およびその他いくつかの設定をチェックします。例えば、準備状況チェックでは AWS のサービスの制限を確認し、フェイルオーバー時に十分な容量を AWS リージョンにデプロイできるようにします。また、アプリケーションレプリカの容量とスケーリング特性が AWS リージョン全体で同じであることも確認します。

ルーティング制御は、障害時にアプリケーションレプリカ間のトラフィックをリバランスし、アプリケーションが確実に利用可能であるようにすることに役立ちます。ルーティング制御は、Amazon Route 53 ヘルスチェックと連携して、DNS レゾリューションを使用してトラフィックをアプリケーションレプリカにリダイレクトします。ルーティング制御は、次の 3 つの方法で、従来の自動 Amazon Route 53 ヘルスチェックベースのフェイルオーバーを改善します。

  • まず、ルーティング制御は、アプリケーションメトリクスまたは部分的な障害 (5% のエラー率の増加、ミリ秒単位のレイテンシーの増加など) に基づいて、アプリケーションスタック全体をフェイルオーバーする方法を提供します。
  • 次に、ルーティング制御により、安全で簡単なマニュアルオーバーライドが得られます。これらを使用して、メンテナンスの目的でトラフィックをシフトしたり、モニターが問題を検出できなかったときの障害からの復旧に使用できます。
  • 第3に、ルーティング制御では、安全ルールと呼ばれる機能を使用して、準備されていないレプリカへのフェイルオーバーやフラッピングの問題など、完全に自動化されたヘルスチェックに関連する一般的な副作用を防ぐことができます。

どのようにRoute 53 アプリケーション復旧コントローラーが動作するかを理解してもらうために、自分の高可用性アプリケーションの設定に使用したプロセスを説明します。

仕組み
デモの目的で、ロードバランサー、2 つの EC2 インスタンスを持つ Auto Scaling グループ、およびグローバル DynamoDB テーブルで構成されたアプリケーションを構築しました。米国東部 (バージニア北部) と米国西部 (オレゴン) の 2 つの AWS リージョンにアプリケーションをデプロイする CDK スクリプトを作成しました。グローバル DynamoDB テーブルにより、2 つの AWSリージョン間でデータが確実にレプリケートされます。前述したように、これはアクティブ/スタンバイアーキテクチャです。

このアプリケーションはマルチプレイヤーの TicTacToe ゲームであり、通常は 99.99% 以上の可用性を必要とするアプリケーションです :-)。1 つの DNS レコード (tictactoe.seb.go-aws.com) は、米国東部 (バージニア北部) リージョンのロードバランサーを指します。次の図は、このアプリケーションのアーキテクチャを示しています。

アプリケーションアーキテクチャの例

アプリケーションの準備
Route 53 アプリケーション復旧コントローラーを自分のアプリケーション用に設定するために、最初にアプリケーションスタックの独立したレプリカをデプロイして、スタック全体のトラフィックをフェイルオーバーできるようにしました。これらのコピーは、アベイラビリティーゾーンや AWS リージョンなどの AWS 高可用性の境界にデプロイされます。複数の AWS リージョンにアプリケーションレプリカをデプロイすることを選択しました

次に、これらの独立したレプリカ間でデータレプリケーションを設定しました。DynamoDB グローバルテーブルを使用して、データをレプリケートしています。

最後に、各独立したスタックに DNS 名を公開するように設定しました。この DNS 名は、リージョナルロードバランサー DNS 名などの、アプリケーションへのエントリポイントです。

関連用語
準備状況チェックを設定する前に、基本的な関連用語をいくつか共有しましょう。

セルは、アプリケーションのフェイルオーバーの独立した単位を含むサイロを定義します。これは、アプリケーションが独立して動作するために必要なすべての AWS リソースをグループ化します。デモでは、2 つのセルがあります。アプリケーションがデプロイされている AWS リージョンごとに 1 つです。セルは、通常、AWS リージョンやアベイラビリティーゾーンなどの AWS 高可用性の境界に合わせられますが、小さくすることもできます。1 つのアベイラビリティーゾーンに複数のセルを含めることができます。これは、爆発半径を減らす効果的な方法です。特に、一度に 1 セルずつ変更する管理手順に従う場合です。

セルの定義

復旧グループは、フェイルオーバーの準備状況をチェックするアプリケーションまたはアプリケーショングループを表すセルの集合です。復旧グループは、通常、機能面で相互にミラーリングする 2 つ以上のセルで構成されます。

復旧グループの定義

リソースセットは、複数のセルにまたがることができる AWS リソースのセットです。このデモでは、3 つのリソースセットがあります。1 つは us-east-1 と us-west-2 の 2 つのロードバランサー用、次は 2 つのリージョンの 2 つの Auto Scaling グループ用、もう 1 つはグローバル DynamoDB テーブル用です。

準備状況チェックは、フェイルオーバーされる一連の AWS リソースの準備状況を検証します。この例では、ロードバランサー、Auto Scaling グループ、および DynamoDB テーブルの準備状況を監査します。Auto Scaling グループの準備状況チェックを作成します。このサービスは、グループ内のインスタンスタイプとカウントを常にモニタリングし、各グループが均等にスケーリングされていることを確認します。ロードバランサーとグローバル DynamoDB テーブルのプロセスを繰り返します。

リソースセットの定義

アプリケーションの復旧の準備状況を判断するために、Route 53 アプリケーション復旧コントローラーは、アプリケーションセル全体で容量、AWS リソース制限、および AWS スロットル制限の不一致を継続的に監査します (アベイラビリティーゾーンまたはリージョン)。 Route 53 アプリケーション復旧コントローラーが制限の不一致を検出すると、セル全体でリソースに対する AWS サービスクォータリクエストが送られます。Route 53 アプリケーション復旧コントローラーがリソースの容量の不一致を検出した場合、セル全体で容量を合わせるためのアクションを実行できます。例えば、Auto Scaling グループのスケーリングの増加をトリガーできます。

準備状況チェックの作成
準備状況チェックを作成するには、AWS マネジメントコンソールを開き、Route 53 の下の [アプリケーション復旧コントローラー] セクションに移動します。

復旧グループの作成

アプリケーションの復旧グループを作成するには、[はじめに] セクションに移動し、[復旧グループの作成] を選択します。

復旧グループの作成 - 名前を入力します。

名前 (例えば、awsNewsBlogDemo) を入力し、[次へ] を選択します。

復旧準備状況の作成 - セルを作成します

[アーキテクチャの設定] で、[セルの追加] を選択し、セル名 (awsNewsBlogDemo-regionWest) を入力してから、[セルの追加] をもう一度選択して 2 番目のセルを追加します。2 番目のセルに awsNewsblogDemo-RegionEast と入力します。[次へ] を選択して入力内容を確認し、[復旧グループの作成] を選択します。

ロードバランサー、Auto Scaling グループ、DynamoDB テーブルなどのリソースを復旧グループに関連付ける必要があります。

リソースセットの作成

左側のナビゲーションペインで、[リソースセット] を選択してから、[作成] を選択します。

リソースセットの作成 - ロードバランサー

最初のリソースセットの名前を入力します (例えば、load_balancers)。[リソースタイプ] で、[ネットワークロードバランサー] または [Application Load Balancer] を選択してから、[追加] を選択してロードバランサー ARN を追加します。

もう一度 [追加] を選択して 2 番目のロードバランサー ARN を入力し、[リソースセットの作成] を選択します。

このプロセスを繰り返して、2 つの Auto Scaling グループに対して 1 つのリソースセットを作成し、グローバル DynamoDB テーブル (1 つの ARN) に 3 番目のリソースセットを作成します。現在、3 つのリソースセットがあります。

リソースセットの作成 - 3 つのリソースセット

最後のステップは、準備状況チェックを作成することです。これにより、リソースが Resource Groups 内のセルに関連付けられます。

準備状況チェックの作成

準備状況チェックで、画面の右上にある [作成] を選択してから、[準備状況チェック] を選択します。

準備状況チェックの作成ステップ 1

ステップ 1 (準備チェックの作成) では、名前 (例えば、load_balancers) を入力します。[リソースタイプ] で、 [ネットワークロードバランサー] または [Application Load Balancer] を選択してから、[次へ] を選択します。

準備状況チェックの作成ステップ 2

ステップ 2 (リソースセットの追加) では、デフォルトの [既存のリソースセットを使用する] を選択し、[リソースセット名] で load_balancers を選択してから、[次へ] を選択します。

ステップ 3 (準備状況ルールの適用) では、ルールを確認してから、[次へ] を選択します。

復旧グループオプション

ステップ 4 (復旧グループオプション) では、デフォルトの選択を [既存の復旧グループに関連付ける] のままにします。[復旧グループ名] で、 [AWSNewsBlog] を選択します。次に、2 つのセル (EAST および WEST) を 2 つのロードバランサー ARN に関連付けます。正しいロードバランサーを各セルに関連付けてください。リージョン名は ARN に含まれます。

ステップ 5 (確認して作成) では、選択内容を確認してから、[準備状況チェックの作成] を選択します。

3 つの準備状況チェック

Auto Scaling グループと DynamoDB グローバルテーブルでこのプロセスを繰り返します。

準備完了モードの復旧グループ

グループ内のすべての準備状況チェックが緑色の場合、グループのステータスは [準備完了] になります。

これで、ルーティング制御を設定してテストできます。

関連用語
ルーティング制御を設定する前に、基本的な関連用語をいくつか共有しましょう。

クラスターは、5 つの冗長リージョンエンドポイントのセットであり、それに対して API コールを実行して、ルーティング制御の状態を更新または取得できます。1 つのクラスターで複数のコントロールパネルとルーティング制御をホストできます。

ルーティング制御は、クラスター上でホストされるシンプルなオン/オフスイッチであり、セル内外のクライアントトラフィックのルーティングを制御するために使用します。ルーティング制御を作成するときは、Route 53 アプリケーション復旧コントローラーでルーティング制御を更新するときにトラフィックを再ルーティングできるように、Route 53 にヘルスチェックを追加します。ヘルスチェックは、ルーティング制御を使用してトラフィックをルーティングするために使用する場合、各アプリケーションレプリカの前にある DNS フェイルオーバーレコードに関連付ける必要があります。

コントロールパネルは、関連するルーティング制御のセットをグループ化します。

ルーティング制御の設定
Route 53 コンソールまたは API アクションを使用して、アプリケーション用に各 AWS リージョンでルーティング制御を作成できます。ルーティング制御を作成した後、 Amazon Route 53 アプリケーション復旧コントローラーのヘルスチェックをそれぞれ 1 つ作成してから、各ヘルスチェックを各リージョンでロードバランサーの DNS フェイルオーバーレコードに関連付けます。次に、リージョン間のトラフィックをフェイルオーバーするために、1 つのルーティング制御のルーティング制御状態をオフに、もう 1 つのルーティング制御状態をオンに変更します。

最初のステップは、クラスターを作成することです。クラスターは 2.5 USD/時間で課金されます。 Route 53 アプリケーション復旧コントローラーを使用するクラスターを作成するときは、実験後にクラスターを削除してください。

クラスターの作成

左側のナビゲーションペインで、クラスターパネルに移動してから、[作成] を選択します。

クラスターの作成 - 名前を入力

クラスターの名前を入力し、[クラスターの作成] を選択します。

クラスターは数分間 [ペンディング] 状態になっています。しばらくすると、そのステータスが [デプロイ済み] に変わります。

デプロイ後、クラスター名を選択して 5 つの冗長 API エンドポイントを見つけます。復旧ツールを構築してルーティング制御状態を取得または設定する場合は、これらのエンドポイントの 1 つを指定する必要があります。クラスターエンドポイントはどれでも使用できますが、複雑なシナリオや自動化されたシナリオでは、再試行リクエストごとに異なるエンドポイントを使用して、使用可能な各エンドポイントでシステムを再試行できるように準備することをお勧めします。

ルーティング制御クラスターエンドポイント

トラフィックルーティングは、コントロールパネルにグループ化されたルーティング制御によって管理されます。1 つ作成するか、または自分用に作成されたデフォルトのものを使用できます。

デフォルトのコントロールパネル

DefaultControlPanel を選択します。

デフォルトのコントロールパネル - ルーティング制御を追加する

[ルーティング制御の追加] を選択します。

ルーティング制御の作成

ルーティング (FailToWEST) 制御の名前を入力し、[ルーティング制御の作成] を選択します。2 番目のルーティング制御 (FailToEAST) の操作を繰り返します。

コントロールパネル - ヘルスチェックの作成

ルーティング制御が作成されたならば、リストからそれを選択します。詳細ページで、[ヘルスチェックの作成] を選択して Route 53 でヘルスチェックを作成します。

コントロールパネル - ヘルスチェックの作成

ヘルスチェックの名前を入力してから、[作成] を選択します。Route 53 コンソールに移動して、ヘルスチェックが正しく作成されたことを確認します。

ルーティング制御ごとに 1 つのヘルスチェックを作成します。

コントロールパネルには、安全ルールを追加できる場所があることにお気付きかもしれません。 複数のルーティング制御で同時に作業する場合、それらを有効または無効にするときに、いくつかのセーフガードを設定する必要がある場合があります。これにより、レプリカの準備ができていないときにフェイルオーバーを開始したり、ルーティング制御の両方をオフにしてすべてのトラフィックフローを停止したりするなどの意図しない結果を回避できます。これらのセーフガードを作成するには、安全ルールを作成します。 使用例を含む安全ルールの詳細については、「 Route 53 アプリケーション復旧コントローラーデベロッパーガイド」を参照してください。

これで、ルーティング制御と DNS ヘルスチェックが行われます。最後のステップは、トラフィックをアプリケーションにルーティングすることです。

DNS 設定を調整する
トラフィックをアプリケーションにルーティングするには。セル内のアプリケーションのトップレベルエントリポイントに DNS エイリアスを割り当てます。この例では、Route 53 コンソールを使用して、タイプ FAILOVER の 2 つの ALIAS A レコードを作成し、各ヘルスチェックを各 DNS レコードに関連付けます。2 つのレコードには同じレコード名が付いています。1 つはプライマリレコードで、もう 1 つはセカンダリレコードです。Amazon Route 53 ヘルスチェックの詳細については、「Amazon Route 53 デベロッパーガイド」を参照してください。

DNS エイリアスレコードプライマリ DNS エイリアスレコードセカンダリ

「アプリケーション復旧ルーティング制御ページ」で、2 つのルーティング制御のうちの 1 つを有効にします。

アプリケーション復旧制御 - 1 つの制御状態を有効にする

実施するとすぐに、tictactoe.seb.go-aws.com を指すすべてのトラフィックは、us-east-1 にデプロイされているインフラストラクチャに送信されます。

セットアップをテストする
セットアップをテストするには、まずターミナルで dig コマンドを使用します。これは、us-east-1 にデプロイされたロードバランサーを指す DNS CNAME レコードを示します。

us-east-1 のエイリアスをテストする

ウェブブラウザでアプリケーションもテストします。tictactoe.seb.go-aws.com という名前が us-east-1 に送信されるのを観察します。

Tic Tac Toe アプリケーション

ここで、update-routing-control-state API アクション、CLI、またはコンソールを使用して、us-east-1 リージョンへのルーティング制御をオフにし、us-west-2 リージョンへのルーティングコントロールをオンにします。CLI を使用する場合、クラスターによって提供されるエンドポイントを使用します。

aws route53-recovery-cluster update-routing-control-state \
     --routing-control-arn arn:aws:route53-recovery-control::012345678:controlpanel/xxx/routingcontrol/abcd \
     --routing-control-state On \
     --region us-west-2 \
     --endpoint-url https://host-xxx.us-west-2.cluster.routing-control.amazonaws.com/v1

コンソールで、コントロールパネルに移動し、変更するルーティング制御を選択し、[ルーティング制御状態の変更] をクリックします。

ルーティング制御状態の変更

1 分も経たないうちに、DNS アドレスが更新されます。アプリケーショントラフィックが us-west-2 リージョンにルーティングされました。

ルーティング制御状態が変更された後に DNS がチェックされる

準備状況チェックとルーティング制御は、アプリケーショントラフィックの制御されたフェイルオーバーを提供し、アクティブなレプリカから別の AWS リージョンのスタンバイレプリカにトラフィックをリダイレクトします。デモで示したように、トラフィックルーティングをマニュアルで変更することも、アプリケーションの技術およびビジネスメトリクスに基づいて Amazon CloudWatch アラームを使用して自動化することもできます。

料金
この新しい機能は、オンデマンドで課金されます。前払い費用はかかりません。準備状況チェックごとに、1 時間あたりのクラスターごとに課金されます。準備状況チェックには 0.045 USD/時間が課金されます。クラスターには 2.5 USD/時間が課金されます。このブログ記事で使用されているデモ例では、3 つの準備状況チェックと 1 つのクラスターがあります。このセットアップの 1 時間あたりの料金は、アプリケーション自体を除き、3 x 0.045 USD + 1 x 2.5 USD = 2.635 USD/時間です。例を含む料金の詳細については、「Route 53 の料金ページ」をご覧ください。

この新しい機能は、公共商用の AWS リージョンで実行されているアプリケーションのアプリケーション復旧をモニタリングおよび制御するために使用できるグローバルサービスです。ぜひお試しいただき、ご意見をお聞かせください。いつものように、通常の AWS Support 連絡先を通じてフィードバックを送信するか、Route 53 アプリケーション復旧コントローラーの AWS フォーラムに投稿できます。

— seb