概要

AWS エッジサービスは、可用性の高いウェブアプリケーションを構築するための重要なコンポーネントです。AWS エッジサービスは、分散型の性質によるネイティブの高可用性に加えて、ウェブアプリケーションへのエントリポイントとして機能し、オリジンインフラストラクチャ (アベイラビリティーゾーンやリージョンなど) 内の利用可能なパーティションにリクエストをルーティングできます。

アーキテクチャ上の決定

高可用性 Web アプリケーションは、可用性 SLO、コスト、複雑さの観点からの要件に基づいて、さまざまな方法で設計できます。ミニマでは、ビジネス要件に基づいて次の技術的決定を下す必要があります。

  • アクティブ/アクティブまたはアクティブ/パッシブのアーキテクチャはありますか?
  • 起源は異なりますか？AZ は違うの？地域が違う？
  • アクティブ/アクティブアーキテクチャのオリジン間のルーティングロジックはどのようなものですか? アクティブ/パッシブアーキテクチャのフェイルオーバー基準はどのようなものですか?

一時的なオリジンエラーの管理

CloudFront は、ときどき少数のユーザーリクエストを損なう可能性のある一時的な 5xx エラーの影響を軽減するのに役立ちます。これは多くの場合、突然のトラフィックの急増や一時的なネットワークの問題によって配信元が圧倒されたことが原因です。CloudFront では、さまざまな方法で一時的な 5xx エラーを軽減できます。

再試行。CloudFront は、オリジンとの接続を確立できない場合に、設定可能な接続タイムアウトを使用して TCP 接続を最大 3 回再試行するように設定できます。また、CloudFront は、設定された再試行回数に応じて GET/HEAD を再試行します。

古いコンテンツで応答してください。オリジンで再試行が失敗した場合、CloudFront はデフォルトで、エラーレスポンスを返すのではなく、キャッシュに存在する場合は古いバージョンのオブジェクトを提供します。この動作は Cache-Control: stale-if-error=0 ディレクティブを使用して無効にすることができます。

セカンダリオリジンへのオリジンフェイルオーバー。オリジンフェイルオーバー機能を使用して、失敗した特定のリクエストについてセカンダリアリジョンで障害が発生するように CloudFront を設定できます。オリジンフェイルオーバーは、無能な GET/HEAD リクエストにのみ適用されます。オリジンイベントで Lambda @Edge を使用する場合、CloudFront はフェイルオーバー時にも関数を実行することに注意してください。このシナリオでは、Lambda @Edge 関数で、リクエストがプライマリのオリジンとセカンダリのオリジンのどちらに対するものかを推測して、ロジックを区別できます。そのためには、両方のオリジンで同じオリジンカスタムヘッダーを設定しましたが、Lambda @Edge が読み取れる値は異なります。

グレースフルフェールオーバー。別のオリジンへのオリジンフェイルオーバーが望ましくない場合 (別のオリジンインフラストラクチャを維持するなど)、カスタムエラーページを使用して別の場所 (S3 バケットなど) でホストされている静的ファイルにフェイルオーバーすることを検討してください。デフォルトでは、エラーになるすべてのリクエストに同じページが使用されますが、このブログの 3 番目のパターンに従うことで、より動的なレスポンスを作成できます。

オリジン停止中のステートフルフェイルオーバー

Route 53 ポリシーに基づくフェイルオーバー

Route 53 フェイルオーバールーティングポリシーは、CloudFront でオリジンとして設定されているオリジンドメイン名のヘルスチェックで使用できます。プライマリのオリジンに異常が生じると、Route 53 はそれを検出し、セカンダリストイ元の IP アドレスを使用してオリジンドメイン名の解決を開始します。CloudFront はオリジン DNS TTL を尊重します。つまり、トラフィックは DNS TTL 内のセカンダリオリンに流れ始めるということです。最適な構成 (Fast Checkを有効にし、フェイルオーバーのしきい値を1、DNSのTTLを60秒) に設定すると、フェイルオーバーが発生するまでに最低70秒かかります。その場合、ステートフルフェールオーバーなので、すべてのトラフィックがセカンダリオリジンに切り替わります。この設計は Route 53 Application Recovery Control によってさらに拡張でき、複数の AWS リージョン、アベイラビリティーゾーン、オンプレミスにわたるより高度なアプリケーションフェイルオーバーが可能であることに注意してください。このアプローチを GET/HEAD リクエストの CloudFront オリジンフェイルオーバー機能と組み合わせることで、Route 53 がセカンダリアリジョンにフェイルオーバーする際のエラーを減らすことができます。このパターンは、このブログで説明されています。

S3 ベースのオリジンの場合など、異なるオリジンが同じドメイン名を共有していない場合、Route 53 は上記の方法では使用できません。このシナリオでは、オリジンリクエストイベントで Lambda @Edge 関数を設定して、選択するオリジンを Route 53 にクエリし、オリジンドメイン名と Host ヘッダーを変更して、選択したオリジンにリクエストを再ルーティングする必要があります。この実装の詳細については、以下のコンテンツフルケーススタディをご覧ください。

グローバルアクセラレータによるフェイルオーバー

Global Accelerator を使用しているアプリケーションは、ネイティブフェイルオーバー機能の恩恵を受けることができます。Global Accelerator を使用すると、アプリケーションを単一の AWS リージョン、複数のアベイラビリティーゾーン、または複数の AWS リージョンにデプロイできます。Global Accelerator は、ヘルスチェックを使用してアプリケーションエンドポイントの状態を監視し、異常なエンドポイントから数十秒以内にトラフィックをルーティングします。

アクティブ-アクティブアーキテクチャ

レイテンシーベースのルーティング

CloudFront を Route 53 レイテンシーベースのポリシーと組み合わせて使用すると、アクティブ-アクティブマルチリージョンアーキテクチャでオリジンをレプリケートした最も近い AWS リージョンにユーザーリクエストをルーティングできます。これを行うには、Route 53 のレイテンシーベースのポリシーを使用して CloudFront のオリジンドメイン名を設定します。CloudFront がオリジンドメイン名を解決してオリジンに接続してリクエストを送信すると、Route 53 はレイテンシーに基づいて最も近いオリジン IP を返します。CloudFront がオリジンドメイン名を解決する場所は、ディストリビューション設定とトラフィックタイプによって異なることに注意してください。一般に、ドメイン名は動的リクエストの場合はエッジロケーションで、キャッシュ可能なコンテンツの場合はリージョナルエッジキャッシュで解決されます。このブログでは、API Gateway のアクティブ-アクティブマルチリージョンのデプロイについて説明します。

S3 ベースのオリジンの場合など、異なるオリジンが同じドメイン名を共有していない場合、Route 53 は上記の方法では使用できません。このシナリオでは、最も近いオリジンにルーティングするには、オリジンリクエストイベントで Lambda @Edge を設定する必要があります。この実装について詳しくは、以下のブログをご覧ください。

高度なルーティング

特定のシナリオでは、リクエストのルーティングにはアプリケーションレベルのロジックが必要です。パスに基づいて異なるオリジンにルーティングする (例:/api1 をオリジン 1 に、/api2 をオリジン 2 にルーティングする) など、ロジックが単純な場合は、CloudFront のネイティブキャッシュ動作機能を簡単に使用できます。ロジックがもっと高度な場合は、Lambda @Edge on Origin リクエストイベントを使用すると、URL、クッキー、ヘッダー、国などのアプリケーションレベルの属性に基づいてトラフィックをルーティングできます。ロジックはステートレスで関数コードに完全に埋め込むことも、S3 や DynamoDB などの外部の場所に保存して、Lambda @Edge がルーティングルールを取得して実行することもできます。

リソース

このページはお役に立ちましたか?

 フィードバック