Amazon Web Services ブログ

レイテンシベースルーティングを使用して Amazon CloudFront で マルチリージョンのアクティブ – アクティブなアーキテクチャを実現する

2024 年 4 月 11 日にデプロイ手順を更新しました。

この記事では、Amazon Route 53 のレイテンシーに基づくルーティングと Amazon CloudFront を使用して、複数リージョンにまたがるアクティブ – アクティブなアプリケーション構成の AWS でのネットワーク層の設定方法について説明します。 これにより、ユーザに低レイテンシーで信頼性の高い環境を提供することができます。

AWS のネットワーキングサービスを使ってアクティブ – アクティブなアーキテクチャを構築することで、アプリケーションのレジリエンスとパフォーマンスが向上します。 ただし、コストと複雑さにはトレードオフがあるため、アーキテクチャの考慮事項と、アプリケーションの機能性、レジリエンス、パフォーマンスへの影響について検討するためのガイダンスも提供しています。

マルチリージョンのアクティブ – アクティブアーキテクチャのメリットとは？

マルチリージョンアクティブ – アクティブアーキテクチャは、地理的に離れた 2 つ以上の AWS リージョンでアプリケーションを実行するデプロイのことです。 両方(またはすべて)のリージョンに必要なコンポーネントとデータがあり、エンドユーザーとの近接性に基づいてリクエストに積極的に応答します。 あるリージョンでアプリケーションに障害が発生した場合、別のリージョンが自動的にユーザートラフィックを引き継ぎ、グローバルユーザーにダウンタイムを発生させることなく運用を継続できます。

どのような場合にマルチリージョンのアクティブ – アクティブアーキテクチャを採用すべきか？

マルチリージョンでアクティブ – アクティブなアーキテクチャを検討すべきなのは、アプリケーションの障害単位が AWS リージョン単位である場合のみです。 アクティブ – アクティブアーキテクチャでは、コストが高くなる可能性と複雑さの増大を慎重に検討する必要があります。リージョン間でデータレプリケーションが必要なステートフルなアプリケーションの場合は、データの不整合、高いレイテンシー、パフォーマンスの低下も考慮に入れる必要があります。

ビジネスの要求事項

厳しい目標復旧時間 (RTO) / 目標復旧点 (RPO) の要件: アクティブ – アクティブアーキテクチャを選択する理由の 1 つは、アクティブ – パッシブ、ウォームスタンバイ、パイロットライト構成などの他のディザスタリカバリ（DR）戦略では対応できないほど厳しい SLA 要件を満たすためです。また、事業継続の最小単位がリージョン単位になり、RTO を秒または分単位で測る必要がある場合にも、アクティブ – アクティブアーキテクチャを検討する可能性があります。

法的およびコンプライアンスの理由: 地方政府が施行するデータ主権に関する法律や規制により、エンドユーザーの近くにデータを物理的に保管する必要がある場合があります。データ主権の要件を満たすため、ユーザーの地理的な位置に基づいて、複数の AWS リージョンにアプリケーションを展開することがあります。

レイテンシと性能の改善

地理的に分散したユーザーベースに動的コンテンツを提供する場合、パフォーマンスを改善するためにアクティブ – アクティブ アーキテクチャを採用することがあります。 この場合、アクティブ – アクティブでは動的なデータを処理して提供できるため、長距離のネットワーク転送によるオーバーヘッドなしでレイテンシーを低減できます。

マルチリージョンアクティブ – アクティブアーキテクチャで使用される AWS ネットワークサービス

アクティブ – アクティブアーキテクチャでは、アプリケーションをマルチリージョン構成でデプロイした際のレイテンシを改善するために、Amazon CloudFront と AWS Global Accelerator を使用できます。Global Accelerator は、AWS のグローバルネットワークインフラストラクチャを利用することで、インターネットユーザーのパフォーマンスと可用性を改善できるネットワークサービスです。 Global Accelerator は、静的なエニーキャスト IP アドレスや瞬時の AWS リージョン障害から復旧が必要なユースケースに適していますが、コンテンツのキャッシングやエッジでの処理をサポートしていません。 そのため、アプリケーションによっては、このブログ記事で説明されているように、アーキテクチャの中で CloudFront を使用することをお勧めします。

CloudFront は、キャッシュ可能なコンテンツ (画像やビデオなど) と動的コンテンツ (API の高速化やウェブサイトの動的配信など) の両方のパフォーマンスを向上させます。 CloudFront には次のような追加の利点もあります。

セキュリティ

アクセス制御: CloudFront の地理的制限機能を使うと、CloudFront で配信されるコンテンツへのアクセスを、特定の地理的位置のユーザーに対して制限できます。

エッジコンピューティング

CloudFront はAWS Lambda@Edge および CloudFront Functions を通じて、プログラム可能かつセキュアなエッジ CDN コンピューティング機能を提供します。
Lambda@Edge: AWS Lambda@Edge は、エッジで実行される幅広い計算ニーズとカスタマイズをサポートするサーバーレスのコンピューティングサービスです。
CloudFront Functions: CloudFront Functions は、HTTP ヘッダー操作、URL の書き換え/リダイレクト、キャッシュキーの正規化などのサブミリ秒のスケーラブルなコンピューティング操作に最適です。

ソリューションの概要

図 1: クライアントブラウザからリージョン内のオリジンサービスへのユーザーフロー

図 1: クライアントブラウザからリージョン内のオリジンサービスへのユーザーフロー

図 1 に示したダイアグラムは、アクティブ – アクティブアーキテクチャにおいてエンドユーザーからの API 呼び出しがどのように流れているかを概説しています。ユーザーリクエストが最も近い AWS エッジロケーション [1] に到着し、CloudFront [2] を通じて Amazon API Gateway [3] に渡されます。CloudFront は、Elastic Load Balancing ロードバランサー、Amazon Elastic Compute Cloud (Amazon EC2) サーバー、または Amazon Simple Storage Service (Amazon S3) バケットなど、他のオリジンも使用できます。

この処理フローで CloudFront の代わりに Global Accelerator を使っていた場合、エッジロケーションからアプリケーションまでの最適なパスを探索し、必要に応じて AWS リージョンを自動的にフェイルオーバーします。現時点では、CloudFront には、アクティブ・アクティブのマルチリージョンアーキテクチャで別の AWS リージョンにフェイルオーバーさせるための既製のソリューションはありません。このブログ投稿の後の節で、Global Accelerator と同様のフェイルオーバー機能をどのように設計し実装するかを説明します。Route 53 のレイテンシーベース ルーティングを使用したアクティブ・アクティブ構成により、このリージョン間のフェイルオーバー機能を実現します。

全体の仕組み

マルチリージョンのアクティブ – アクティブ設定を実装する際は、次の 2 点に特に注意が必要です。

  • クライアントがアプリケーションにアクセスするためのカスタムドメインの SSL/TLS (Secure Sockets Layer/Transport Layer Security) 証明書
  • クライアントのリクエストを AWS リージョンへルーティングする、レイテンシーに基づくルーティングロジック

先ず SSL/TLS 証明書の設定方法をご説明します。その後、クライアントのトラフィックを AWS リージョンにルーティングするロジックについて解説します。

SSL/TLS 証明書で AWS ウェブサイトおよびアプリケーションを保護する

マルチリージョン構成で転送中のトラフィックを暗号化するには、アプリケーションをデプロイする各リージョンで一致する SSL/TLS 証明書が利用可能である必要があります。この項では、AWS でこれを実現する方法について説明します。

アプリケーションをデプロイする各リージョンで、同じ SSL/TLS 証明書を作成する必要があります。 証明書は、マルチリージョン環境下で、トラフィックを暗号化して転送できるようにします。これにより、AWS のウェブサイトとアプリケーションを保護できます。 AWS Certificate Manager (ACM) を使用して証明書を作成できます。

ACM は、AWS サービスや内部接続リソースで使用するためのパブリックおよびプライベートの SSL/TLS 証明書を簡単にプロビジョニング、管理、デプロイできるサービスです。 SSL/TLS 証明書は、インターネット上のウェブサイトおよびプライベートネットワークのリソースの身元を確認し、ネットワーク通信を保護するために使用されます。

ACM が AWS でホストされるウェブサイトやアプリケーションを保護するためには、AWS サービスが通信の暗号化を行う各リージョンで証明書は存在する必要があります。たとえば、カスタムドメイン名のリージョンエンドポイントタイプを使用して、API Gateway を米国東部(オハイオ) と米国西部 (オレゴン) の両リージョンにデプロイする場合、両リージョンの ACM に証明書を作成またはインポートしなければなりません。ACM についてさらに詳しくは、AWS Certificate Manager とはをご覧ください。

CloudFront はグローバルサービスであり、リージョナルサービスではないため、証明書は ACM で米国東部（バージニア北部）リージョンで発行される必要があります。

Route 53 は高可用性かつスケーラブルな Domain Name System (DNS) ウェブサービスです。Route 53 を使って、ドメインの登録、DNS ルーティング、ヘルスチェックの 3 つの主要な機能性を任意の組み合わせで実行できます。Route 53 Traffic Flow を使うと、さまざまなルーティングタイプを使って世界中のトラフィックを管理できます。この投稿では、Latency ルーティングポリシーに焦点を当てます。サポートされているすべてのルーティングタイプの詳細については、ルーティングポリシーの選択をご覧ください。

図 2: カスタムドメインを使用した DNS 解決とリクエスト フロー

図 2 の図に示されているように、ユーザーリクエストの流れを見てみましょう。

  1. Route 53 のエイリアスレコードを作成し、カスタムドメイン example.com を、CloudFront ディストリビューションのデフォルトのドメイン名に向けます。Route 53 のエイリアスレコードと CNAME について詳しくは、エイリアスレコードの値をご覧ください。
  2. CloudFront で代替ドメイン名 (CNAME) を設定し、米国東部 (バージニア北部) リージョンの ACM 上の証明書をインポートします。Route 53 のエイリアスレコードと CNAME について詳しくは、代替ドメイン名を追加して、カスタム URL を使用するをご覧ください。
  3. リージョナル AWS サービス用の Route 53 レコードセットを設定します。この例では、api.example.com という同じドメイン名で 2 つのレコードを作成し、ルーティングポリシーを latency に設定します。同時に複数のリージョンでアクティブな設定では、レイテンシーを最小限に抑えるために、トラフィックはラウンドトリップ時間の短いリージョンに誘導されます。レイテンシーに基づくルーティングポリシーについて詳しくは、ルーティングポリシーの選択をご覧ください。
  4. パブリックに公開されている AWS サービスがあるそれぞれのリージョンで、ACM 上にパブリック証明書を発行します。この例では、リージョン 1 と リージョン 2 の ACM で証明書を発行する必要があります。
  5. また、オリジンとして Application Load Balancer を使用することもできます。上記のステップは S3 以外のすべての AWS オリジンに適用できます。

クライアントリクエストを AWS リージョンにルーティングするためのルーティングロジック

提案された流れでは、リクエストが API Gateway によって処理される前に、2 回の DNS 解決が行われます:

  • クライアントのブラウザで、ドメイン名を CloudFront の IP アドレスに解決します。
  • CloudFront のエッジロケーションで、API Gateway または Application Load Balancer のカスタムドメイン名を解決します (オリジンの種類に依存)。

図 3 は、CloudFront と Route 53 を使用したマルチリージョンアクティブ – アクティブレイテンシベースのルーティングを示しています。

図 3: CloudFront と Route 53 を使用したマルチリージョンのアクティブ - アクティブレイテンシベースのルーティング

図 3: CloudFront と Route 53 を使用したマルチリージョンのアクティブ – アクティブレイテンシベースのルーティング

上の図に示されているように、DNS 解決のフローを見ていきましょう。

  1. クライアントが example.com ドメインに HTTPS リクエストを行います。Route 53 サービスがドメインを解決します。
  2. クライアントは、クライアントに最も近い CloudFront ポイント・オブ・プレゼンス (PoP) 拠点にリクエストを行います。
  3. CloudFront は AWS のグローバルネットワークを通じて、コンテンツを最も効率的に配信できるエッジロケーションにリクエストを転送することで、コンテンツの配信を高速化します。通常はユーザーに最も近い CloudFront エッジサーバーがコンテンツを配信します。
  4. CloudFront PoP 拠点は、Route 53 サービスにオリジンドメイン名 example.com の DNS リクエストを行います。このドメイン名には、Route 53 サービスでレイテンシーに基づくルーティングポリシーが設定されているため、CloudFront PoP 拠点に最も近い地域の API Gateway の IP アドレスが返されます。この例では、オリジンとして API Gateway を使用していますが、他のオリジンタイプ (Amazon Simple Storage Service を除く) を使用しても、データフローは同じです。
  5. CloudFront PoP 拠点は、最も近い地域の対象のオリジン (API Gateway や Application Load Balancer など) に HTTP リクエストを転送します。

デプロイ手順

デプロイ手順は 4 ステップのアプローチに従います。パート 1 ではオリジンと DNS レジストラのセットアップを行い、パート 2 では Route 53 のパブリックホストゾーンと AWS ACM の設定を紹介します。パート 3 では Route53 のパブリックホストゾーンにカスタムドメインを追加し、最後のパート 4 では CloudFront ディストリビューションのセットアップを行います。

パート 1 – API Gateway/Application Load Balancerのデプロイ、レジストラへのドメインの登録、Route 53 レコードの構成

Web サイト www.example.com をホストする各リージョンのバックエンドサーバを設定してください。

  1. 上記の 2 つのリージョンで 2 つの API Gateway を作成するステップに従ってください。動的ウェブサイトのパフォーマンスとセキュリティを向上させるための AWS エッジサービスのセットアップ方法については、このブログを参照してください。
  2. Application Load Balancer をオリジンとして使う予定の場合は、上記の 2 つのリージョンで 2 つの Application Load Balancer (ALB) を作成するステップに従ってください。

パート2 – Route 53 で独自ドメインのパブリックホストゾーンを作成し、公開証明書を追加する

  1. Route 53 を使用してインターネット向けのドメイン名 (例: example.com) のパブリックホストゾーンを作成します。ドメイン名を登録するには、Route 53 または他のドメインレジストラを使用できます。ただし、DNS 管理に Route 53 を使用する場合は、サードパーティーレジストラのウェブサイトで DNS サーバーを更新する必要があります。
  2. 登録したドメイン名に対して、バージニア北部リージョン (us-east-1) で公開証明書をリクエストします。重要: リソースが他のリージョンにあっても、ACM のコントロールプレーンが us-east-1 にあるため、us-east-1 で公開証明書を要求することが重要です。

パート3 – カスタムオリジンドメインの Public Hosted ゾーンへの A レコードの追加

カスタムオリジンドメインのパブリックホストゾーンへの A レコードを追加する手順について説明します。
アクティブ – アクティブ構成のアーキテクチャはカスタムドメイン名から構成されるので、パブリックホストされたゾーンでカスタムオリジンドメインの A レコードを追加してください。上記の例に従えば、CloudFront ディストリビューションのオリジンとして機能するカスタムオリジンドメイン (例: api.example.com) 用に 2 つの A レコードが必要になります。
2 つのAPI Gateway/Application Load Balancerに対してレイテンに基づくルーティングを使用し、2 つの A レコードを作成してください:

  1. パブリックホストゾーン example.com で、[ レコードの作成 ] を選択します。
  2. レコード名を api として追加し、レコードタイプで A レコードを選択します。
  3. エイリアスをオンにし、トラフィックのルーティング先の下で使用している適切なオリジンを選択します。
  4. リージョン us-east-1 (現在の例の場合 を選択し、設定されたオリジンを選択します。
  5. ルーティングポリシーでレイテンシーを選択し、設定を行います。
  6. 別のレコードを追加し、上記の手順を繰り返して 2 番目のリージョン us-west-2 (現在の例の場合) を設定します。
  7. 完了したら、レコードを作成します。

パート 4 – API Gateway/Application Load Balancer をオリジンとして CloudFront ディストリビューションをセットアップする

カスタムドメイン名の A レコードをパブリックホストゾーンに追加したら、CloudFront ディストリビューションでオリジンとして設定します。

  1. AWS コンソールから Amazon CloudFront のナビゲーションペインに移動し、「ディストリビューションを作成」を選択します。
  2. CloudFront ディストリビューションを作成する手順に従います。
  3. Origin domain では、カスタムサブドメイン api.example.com を追加します。
  4. ビューワープロトコルポリシーでは、「Redirect HTTP to HTTPS」(あるいは適用可能な他のポリシー) を選択します。
  5. キャッシュキーとオリジンリクエストの下で、Cache policy and origin request policy (recommended) を選択し、次に適切なキャシュポリシーを Cache policy から選択します。
    ※ テストを行う場合は CachingDisabled にしてください。
  6. 設定セクションの下で、代替ドメイン名 (CNAME) を選択し、次に Part 2 で設定したドメイン名 (www.example.com) を 項目を追加の下に追加します。
  7. Custom SSL certificate では、パート 2.2 で作成したドメインの ACM 証明書を選択します。
  8. 「ディストリビューションを作成」を選択します。
  9. ディストリビューションがデプロイされた後、ディストリビューションのオリジンタブに移動し、オリジンを選択して Edit をクリックします。選択されているプロトコルが HTTPS のみになっていることを確認します。

レイテンシーに基づくルーティングのテスト

異なる地理的位置からのクライアントをシミュレートするため、サンプルアプリケーションをデプロイした AWS リージョン (us-east-1 と us-west-2) に Amazon EC2 インスタンスを 2 つ起動します。 それぞれのインスタンスから、アプリケーションにアクセスするために使用するドメイン名に対して curl を実行します。 今回の演習では、us-east-1リージョンのインスタンス 172-31-56-168 と、us-west-2リージョンのインスタンス 172-31-16-193 からそれぞれ、次のコマンドを実行します。

図 4: クライアントリクエストが最も近い地域から応答される

図 4: クライアントリクエストが最も近い地域から応答される

両方のリージョンが正常に動作して通信を受け入れていたため、それぞれのクライアントリクエストは近くのリージョンから処理されました。

リージョナルフェイルオーバーのテスト

ここで、us-east-1 のアプリケーションがメンテナンス中になり、容量に制限のある状況を想定しましょう。テスト目的のため、この リージョンへの通常のトラフィックを別の場所に振り向けるために、ヘルスチェック ステータスを「メンテナンス中」に変更して示しています。172-31-16-193 から curl リクエストを実行しても結果は同じですが、us-east-1 リージョンの 172-31-56-168 インスタンスからリクエストすると、異なる応答が得られます。

図 5: 最も近い Region が利用できない場合は、次に近い Region へクライアント リクエストが転送される

図 5: 最も近い Region が利用できない場合は、次に近い Region へクライアント リクエストが転送される

us-east-1 リージョンがリクエストを処理できないため、リクエストは最も近いリージョンに転送されます。
この例では、サンプルアプリケーションは 2 つのリージョンにしかデプロイされておらず、リクエストは 2 番目のリージョンで処理されています。 3 つ以上のリージョンで構成される環境では、使用できないリージョンからのトラフィックは、エンドユーザーに次に近いリージョンに転送されます。

リージョン間のフェイルオーバーを機能させるには、ヘルスチェックが正しく動作することが不可欠です。つまり、アプリケーション層での信頼できるヘルスチェックのみが、アプリケーションが期待どおり動作し、クライアントリクエストに対応できることを保証します。 最大の信頼性と障害許容性を確保するために、フェイルオーバーメカニズムのデータプレーン機能を活用するよう設計することをお勧めします。 たとえば、ホストゾーンの DNS レコードの更新やヘルスチェック設定 (コントロールプレーン機能) ではなく、Route 53 ヘルスチェックを利用するメカニズム (データプレーン機能) を選択してください。 Route 53 ヘルスチェックを使ってフェイルオーバーシナリオに対処する方法の詳細については、Amazon Route 53 を使用した災害復旧メカニズムの作成をご覧ください。

まとめ

この投稿では、CloudFront と Route 53 を使用してマルチリージョンのアクティブ – アクティブアーキテクチャを設計する方法について学びました。 CloudFront は AWS のグローバルネットワークを活用し、セキュリティ、エッジ機能、可用性など他の利点も兼ね備えた高速なコンテンツ配信に使用されます。 Route 53 は、ユーザーの場所から最も近接したリージョンにアプリケーションがデプロイされているレイテンシーに基づくルーティングを設定するために使用されます。 マルチリージョンのアクティブ – アクティブアーキテクチャにこれらのサービスを組み合わせることで、ユーザーに低レイテンシーのエクスペリエンスを提供するのに役立ちます。

開始するためには、Route 53コンソールを使用したレコードの作成とCloudFrontディストリビューションの作成をご覧ください。

本記事は、「Using latency-based routing with Amazon CloudFront for a multi-Region active-active architecture」と題された記事の翻訳となります。
翻訳は Solutions Architect の長谷川 純也が担当しました。