Amazon API Gateway マルチリージョンフェイルオーバーの実装

本投稿は Implementing multi-Region failover for Amazon API Gateway (記事公開日: 2024 年 7 月 8 日) を翻訳したものです。

本投稿は、プリンシパルソリューションアーキテクト Marcos Ortiz と、シニアソリューションアーキテクト Khubyar Behramsha によって書かれています。

この投稿では、AWS コントロールプレーンの操作に依存することなく、信頼性の高いフェイルオーバーメカニズムを使用して、単一リージョンの API Gateway アーキテクチャからマルチリージョンのアーキテクチャに進化する方法を学びます。AWS Well-Architected ベストプラクティスは、リカバリ中はデータプレーンに依存し、コントロールプレーンに依存しないことです。フェイルオーバーコントロールは、プライマリリージョンに依存しないように機能する必要があります。このパターンは、共有パブリック API の背後にデプロイされた個々のサービスに依存せずにフェイルオーバーする方法を示しています。さらに、GitHub で公開されているオープンソースコードを使用して、提案されたアーキテクチャをデプロイおよびテストする方法について順を追って解説します。

多くの組織にとって、AWS Well-Architected のベストプラクティスに沿って構築されたリージョナル Amazon API Gateway エンドポイントを使うことで、レジリエンス、シンプル性、および経済性のバランスが適切に保たれます。ただし、ビジネスの重要性、規制要件、または災害復旧目標によっては、一部の組織はマルチリージョンアーキテクチャを使用してAPIを展開する必要があります。

ビジネスクリティカルなアプリケーションを扱う際、組織は通常、フェイルオーバーをトリガーする方法とタイミングを完全に制御したいと考えます。手動でトリガーされるフェイルオーバーでは、依存関係を特定の順序でフェイルオーバーさせることができます。承認プロセスに沿ったフェイルオーバーの実施は、準備ができていないレプリカへのフェイルオーバーや、一時的な障害によるフラッピング問題を防ぐのに役立ちます。フェイルオーバーアクションやトリガーには人の判断を挟む要素がありますが、その後の処理はできるだけ自動化することが推奨されます。このアプローチにより、アプリケーションの所有者は、一時的な問題が発生した場合にフェイルオーバーを実行できるなど、フェイルオーバープロセスを制御できます。

概要

お客様にとって一般的なアプローチは、カスタムドメイン名を使用したパブリックリージョナル API をデプロイし、ユーザーにとってより直感的な URL を提供することです。バックエンド側では、API マッピングを使用して、複数の API ステージをカスタムドメインに接続します。このアプローチにより、サービス所有者は同一最上位 API ドメイン名を共有しながら、独立してサービスをデプロイできます。このパターンに従った典型的なアーキテクチャは次のとおりです。

リージョナルエンドポイントとマッピング

しかし、この構成をマルチリージョンアーキテクチャに進化させようとすると、組織は各サービスを個別にフェイルオーバーさせることに苦労することが多くあります。前述のアーキテクチャをそのままの形で 2 つのリージョンにデプロイした場合、API Gateway の背後にあるすべてのサービスを一気にフェイルオーバーするか、まったくフェイルオーバーを行わないかの、all-or-nothing シナリオになります。

マルチリージョンアーキテクチャへの進化

各チームが独立してサービスを管理およびフェイルオーバーできるようにするには、マルチリージョンアーキテクチャにこの新しいアプローチを実装できます。各サービスには独自のサブドメインが割り当てられ、API Gateway HTTP 統合を使用してリクエストを特定のサービスにルーティングします。この仕組みによって、各サービスのサービス API を使って個別にフェイルオーバーを実施するか、あるいは共有パブリック API を使って一括でフェイルオーバーを実施するかという柔軟性が得られます。

マルチリージョンアーキテクチャ

下記がサービスへのリクエストフローです:

ユーザーは、URL サフィックスを使用してパブリック共有 API ドメイン名を介して特定のサービスにアクセスします。たとえば、service1 にアクセスするには、エンドユーザーは http://example.com/service1 にリクエストを送信します。
Amazon Route 53 には、プライマリおよびセカンダリフェイルオーバーレコードが登録されたトップレベルドメイン example.com があります。これにより、リクエストがプライマリリージョン (us-east-1) の API Gateway 外部 API エンドポイントにルーティングされます。
API Gateway は HTTP 統合を使用して、リクエストを https://service1.example.com の service1 に転送します。
Amazon Route 53 には、プライマリおよびセカンダリフェイルオーバーレコードが登録されたドメイン service1.example.com があります。これにより、正常な場合はリクエストがプライマリリージョン (us-east-1) の API Gateway service1 API リージョナルエンドポイントにルーティングされ、異常な場合はセカンダリリージョン (us-west-2) の service1 API リージョナルエンドポイントにルーティングされます。
Amazon Route 53 で構成された service1 のプライマリルートを表します。
Amazon Route 53 で構成された service1 のセカンダリルートを表します。

このソリューションでは、各サービスAPIをプライマリリージョン(us-east-1)とセカンダリリージョン(us-west-2)の両方にデプロイする必要があります。両リージョンで同じカスタムドメイン構成が使用されます。プライマリリージョンでは、各サービスのプライマリDNSレコードがリージョナルAPIゲートウェイディストリビューションエンドポイントを指します。セカンダリリージョンでは、各サービスのセカンダリDNSレコードがセカンダリリージョンのリージョナルAPIゲートウェイディストリビューションエンドポイントを指します。

Route 53 レコード

アクティブ/パッシブ手動フェイルオーバー

ここで紹介する例は、Amazon Route 53 のコントロールプレーンに依存しない、信頼性の高いフェイルオーバーメカニズムを可能にします。
5 つの異なる AWS リージョンにまたがる 5 つのリージョナルエンドポイントを持つクラスターを提供するAmazon Route 53 Application Recovery Controller (Route 53 ARC) を使用しています。フェイルオーバープロセスではこれらのエンドポイントを使用し、コントロールプレーン操作であるAmazon Route 53 DNSレコードの手動編集は行いません。Route 53 ARC のルーティングコントロールにより、プライマリリージョンからセカンダリリージョンへのトラフィックのフェイルオーバーが行われます。

Route 53 ARC ルーティングコントロール

ルーティングコントロールは、トラフィックをワークロードの 1 つのインスタンスから別のインスタンスに転送可能とする on/off スイッチです。トラフィックの再ルーティングは、関連する DNS ヘルスチェックを正常または異常に設定した結果です。

Route 53 ARC の on/off 切り替え

サンプルアプリケーションのデプロイ

前提条件

Amazon Route 53 に登録されたパブリックドメイン (example.com) が必要です。ドメインを登録する方法の手順に従ってドメインを登録してください。また、Amazon Route 53 を DNS サービスとして構成する手順に従ってAmazon Route 53 を構成してください。
プライマリリージョンとセカンダリリージョンの両方で、サンプル API をデプロイする予定のドメイン名 (*.example.com) に対する AWS Certificate Manager 証明書が必要です。

Amazon Route 53 ARC スタックのデプロイ

まず、Amazon Route 53 ARC スタックをデプロイし、クラスターと API のフェイルオーバーを可能にするルーティング制御を作成します。

Amazon Route 53 Application Recovery Controller (ARC) スタックをデプロイするに記載されている詳細手順に従ってAmazon Route 53 ARC スタックをデプロイしてください。

プライマリリージョンとセカンダリリージョンへの Service1 API のデプロイ

各リージョンにAPI Gateway リージョナルエンドポイントをデプロイし、リクエストを処理するサービス名と現在のAWSリージョンを返すAWS Lambda 関数を呼び出します。

{"service": "service1", "region": "us-east-1"}

下記は Lambda 関数のソースコードです:

 import json 
 import os 

 def lambda_handler(event, context):
    return {
 "statusCode": 200,
 "body": json.dumps({
   "service": "service1",
   "region": os.environ['AWS_REGION']}),
 }

service1 のスタックをデプロイにある詳細手順に従ってデプロイしてください。

プライマリリージョンとセカンダリリージョンへの Service2 API のデプロイ

このスタックはservice1と似ていますが、ドメイン名が異なり、サービス名としてservice2を返します。

{"service": "service2", "region": "us-east-1"}

service2 スタックをデプロイにある詳細手順に従ってデプロイしてください。

プライマリリージョンとセカンダリリージョンへの共有パブリック API のデプロイ

この手順では、example.com/service1 または example.com/service2 を呼び出したときに、service1 と service2 のために設定した各自のパブリック DNS レコードにリクエストをルーティングするように HTTP エンドポイントを構成します。

外部 API スタックをデプロイにある詳細手順に従ってデプロイしてください。

フェイルオーバーテスト

デプロイされたサンプルアプリケーションをテストするには、提供されているテストスクリプトを変更して実行してください。

test.sh ファイルの 3 行目から 5 行目を、APIs 用に設定したドメイン名を参照するように更新してください。
実行権限を付与してスクリプトを実行します:

chmod + x ./test/sh 
./test.sh

このスクリプトは5秒ごとに3つのエンドポイントそれぞれにHTTPリクエストを送信します。Amazon Route 53 ARCを使用すると、サービスを個別にフェイルオーバーでき、異なるリージョンからのレスポンスを確認できます。

最初は、すべてのサービスがトラフィックを us-east-1 リージョンにルーティングしています。

初期ルーティング

次のコマンドで、service1 の 2 つのルーティングコントロールを更新し、プライマリリージョン (us-east-1) のヘルスチェック状態を off に、セカンダリリージョン (us-west-2) のヘルスチェック状態を on に設定します。

aws route53-recovery-cluster update-routing-control-states \ 
 --update-routing-control-state-entries \ 
 '[{"RoutingControlArn":"arn:aws:route53-recovery-control::111122223333:controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/abcdefg1234567","RoutingControlState":"On"},
{"RoutingControlArn":"arn:aws:route53-recovery-control:: 111122223333:controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/hijklmnop987654321","RoutingControlState":"Off"}]' \ 
 --region ap-southeast-2 \ 
 --endpoint-url https://abcd1234.route53-recovery-cluster.ap-southeast-2.amazonaws.com/v1

数秒後、スクリプトターミナルに service1 が us-west-2 にトラフィックをルーティングしていることが表示されますが、他のサービスは引き続き us-east-1 リージョンにトラフィックをルーティングしています。

service1 をセカンダリリージョンに切り替えている

service1 を us-east-1 リージョンにフェイルバックするには、次のコマンドを実行し、service1 のプライマリリージョン (us-east-1) のヘルスチェック状態を on に、セカンダリリージョン (us-west-2) のヘルスチェック状態を off に設定します。

aws route53-recovery-cluster update-routing-control-states \ 
 --update-routing-control-state-entries \ 
 '[{"RoutingControlArn":"arn:aws:route53-recovery-control::111122223333:controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/abcdefg1234567","RoutingControlState":"Off"},
{"RoutingControlArn":"arn:aws:route53-recovery-control:: 111122223333:controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/hijklmnop987654321","RoutingControlState":"On"}]' \ 
 --region ap-southeast-2 \ 
 --endpoint-url https:// abcd1234.route53-recovery-cluster.ap-southeast-2.amazonaws.com/v1

数秒後、スクリプトターミナルに service1 が他のサービスと同様に us-east-1 リージョンにトラフィックをルーティングしていることが表示されます。

ルーティングの復旧

クリーンアップ

作業が完了したら、GitHub のクリーンアップ手順に従ってクリーンアップを実施してください。

結論

このソリューションは、API Gateway を使用してクリティカルワークロードを管理するチームに制御権を取り戻すのに役立ちます。フロントエンドとバックエンドを分離することによって、このソリューションは Amazon Route 53 ARC を使用してサービスレベルでフェイルオーバーを細かく制御し、コントロールプレーンアクションへの依存関係を排除することで、組織に粒度の細かい制御を与えます。

また、説明したパターンでは、シングルリージョンからマルチリージョンアーキテクチャに移行する際に、同じパブリック API とトップレベルドメインを使用できるため、サービス利用者への影響も軽減されます。

より多くの AWS レジリエンスについて学ぶには、AWS Architecture ブログ – レジリエンスをご覧ください。

サーバーレスの学習をさらに深めたい方は、Serverless Land をご覧ください。

本ブログはソリューションアーキテクトの銭敏娟が翻訳しました。原文はこちらです。

Amazon Web Services ブログ