ミッション クリティカルなグローバル HTTP イングレス

ミッション クリティカルなアプリケーションでは、ネットワーク コンポーネントが使用できない場合や機能低下している場合でも、高いレベルのアップタイムを維持する必要があります。 Web トラフィックのイングレス、ルーティング、セキュリティを設計する場合は、複数の Azure サービスを組み合わせて、より高いレベルの可用性を実現し、単一障害点を回避することを検討できます。

この方法を採用する場合は、アプリケーション サーバーに個別のネットワーク パスを実装する必要があり、各パスを個別に構成してテストする必要があります。 このアプローチのすべての影響を慎重に検討する必要があります。

この記事では、Azure Front Door と Azure Application Gateway を介してグローバル HTTP トラフィックのイングレスをサポートする方法について説明します。 このアプローチは、ソリューションで次が必要な場合に、ニーズに適合する可能性があります。

• グローバル トラフィック ルーティング用の Azure Front Door。 これは、アプリケーションの複数のインスタンスが別々の Azure リージョンに存在するか、1 つのリージョンからすべてのグローバル ユーザーにサービスを提供していることを意味する可能性があります。
• トラフィックが配信元サーバーに到達するためのパスに関係なくアプリケーションを保護するための Web アプリケーション ファイアウォール (WAF)。

ネットワーク エッジでのキャッシュは、アプリケーション配信の重要な部分ではありません。 キャッシュが重要な場合は、代替アプローチについて「ミッション クリティカルなグローバル コンテンツ配信」を参照してください。

アプローチ

この DNS ベースの負荷分散ソリューションでは、複数の Azure Traffic Manager プロファイルを使用して Azure Front Door を監視します。 万一、可用性の問題が発生した場合、Traffic Manager はトラフィックを Application Gateway 経由でリダイレクトします。

ソリューションには、次のコンポーネントが含まれています。

• 優先順位ルーティング モードを使用する Traffic Manager には、2 つのエンドポイントがあります。 既定では、Traffic Manager は Azure Front Door を介して要求を送信します。 Azure Front Door を使用できない場合は、2 つ目の Traffic Manager プロファイルによって要求の転送先が決まります。 2 つ目のプロファイルについては、以下で説明します。

• Azure Front Door は、ほとんどのアプリケーション トラフィックを処理してルーティングします。 Azure Front Door は、トラフィックを適切な配信元アプリケーション サーバーにルーティングし、アプリケーションへのプライマリ パスを提供します。 Azure Front Door の WAF は、一般的なセキュリティ上の脅威からアプリケーションを保護します。 Azure Front Door を使用できない場合、トラフィックはセカンダリ パスを介して自動的にリダイレクトされます。

• パフォーマンス ルーティング モードを使用する Traffic Manager には、Application Gateway インスタンスごとにエンドポイントがあります。 この Traffic Manager は、クライアントの場所から最高のパフォーマンスで Application Gateway インスタンスに要求を送信します。

• Application Gateway は各リージョンにデプロイされ、そのリージョン内の配信元サーバーにトラフィックを送信します。 Application Gateway の WAF は、セカンダリ パスを通過するすべてのトラフィックを保護します。

• 配信元アプリケーション サーバーは、Azure Front Door と Azure Application Gateway の両方からのトラフィックをいつでも受け入れる準備ができている必要があります。

考慮事項

この後のセクションでは、この種類のアーキテクチャに関するいくつかの重要な考慮事項について説明します。 また、ミッション クリティカルなソリューションで Azure Front Door を使用する場合は、ミッション クリティカルなグローバル Web アプリケーションに関するその他の重要な考慮事項とトレードオフについても確認する必要があります。

Traffic Manager の構成

このアプローチでは、入れ子になった Traffic Manager プロファイルを使用して、アプリケーションの代替トラフィック パス用に、優先度ベースとパフォーマンスベースの両方のルーティングを一緒に実現します。 配信元が 1 つのリージョンにある単純なシナリオでは、優先度ベースのルーティングを使用するように構成された 1 つの Traffic Manager プロファイルのみで必要が満たされる場合があります。

地域の配分

Azure Front Door はグローバル サービスですが、Application Gateway はリージョン サービスです。

Azure Front Door の Point of Presence はグローバルにデプロイされており、TCP 接続と TLS 接続はクライアントに最も近い Point of Presence で終了します。 この動作により、アプリケーションのパフォーマンスが向上します。 これに対し、クライアントが Application Gateway に接続すると、TCP 接続と TLS 接続は、トラフィックの配信元に関係なく、要求を受信する Application Gateway で終了します。

クライアントからの接続

グローバル マルチテナント サービスとして、Azure Front Door はさまざまな脅威に対する固有の保護を提供します。 Azure Front Door では、有効な HTTP トラフィックと HTTPS トラフィックのみが受け入れられ、その他のプロトコルのトラフィックは受け入れられません。 Microsoft は、Azure Front Door が受信接続に使用するパブリック IP アドレスを管理しています。 これらの特性により、Azure Front Door はさまざまな攻撃の種類から配信元を保護するのに役立ち、配信元は Private Link 接続を使用するように構成できます。

これに対し、Application Gatewayは、専用のパブリック IP アドレスを持つ、インターネットに接続するサービスです。 ネットワークと配信元サーバーを、さまざまな攻撃の種類から保護する必要があります。 詳細については、「配信元のセキュリティ」を参照してください。

配信元サーバーに対する Private Link 接続

Azure Front Door Premium では、配信元へのPrivate Link 接続が提供されるため、パブリック インターネットに接続する、ソリューションの外部からのアクセスを削減できます。

Private Link を使用して配信元に接続する場合は、仮想ネットワークにプライベート エンドポイントをデプロイし、そのプライベート エンドポイントをアプリケーションのバックエンドとして使用するように Application Gateway を構成することを検討してください。

スケーリング

Application Gateway をデプロイするときは、ソリューションのために専用のコンピューティング リソースをデプロイします。 大量のトラフィックが予期せずに Application Gateway に到着すると、パフォーマンスや信頼性の問題が発生する可能性があります。

このリスクを軽減するには、Application Gateway インスタンスをスケーリングする方法を検討してください。 自動スケーリングを使用するか、またはフェールオーバー後に受信する可能性があるトラフィックの量を処理できるように手動でスケーリングします。

キャッシュ

Azure Front Door のキャッシュ機能を使用する場合は、トラフィックが代替パスに切り替わり、Application Gateway を使用するようになると、コンテンツが Azure Front Door キャッシュから提供されなくなることに注意する必要があります。

ソリューションがキャッシュに依存している場合は、Azure Front Door へのフォールバックとしてパートナー CDN を使用する代替アプローチについて、「ミッション クリティカルなグローバル コンテンツ配信」を参照してください。

または、キャッシュを使用するものの、それがアプリケーション配信戦略の重要な部分ではない場合は、フェールオーバー中のキャッシュ ミスの増加によって発生した負荷の増大に対処するために配信元をスケールアウトまたはスケールアップできるかどうかを検討します。

トレードオフ

この種類のアーキテクチャは、要求処理ルール、WAF、TLS オフロードなどの機能を代替トラフィック パスで使用する場合に最も便利です。 Azure Front Door と Application Gateway の両方で同様の機能が提供されています。

ただし、以下のトレードオフがあります。

• 操作の複雑さ。 これらの機能のいずれかを使用する場合は、Azure Front Door と Application Gateway の両方でそれらの機能を構成する必要があります。 たとえば、Azure Front Door WAF の構成を変更する場合は、Application Gateway WAF にも同じ構成変更を適用する必要があります。 2 つの個別のシステムを再構成してテストする必要がある場合は、操作の複雑さが大幅に増します。

• 機能パリティ。 Azure Front Door と Application Gateway が提供する機能には類似点がありますが、多くの機能はパリティが異なります。 これらの違いは、その後のトラフィック パスに基づいてアプリケーションが配信される方法に影響を与える可能性があるため、注意が必要です。

  Application Gateway ではキャッシュが提供されません。 この違いの詳細については、「キャッシュ」を参照してください。

  Azure Front Door と Application Gateway は別個の製品であり、ユース ケースが異なります。 特に、この 2 つの製品は、Azure リージョンへのデプロイ方法が異なります。 各製品の詳細と使用方法を理解していることを確認してください。

• コスト。 通常、Application Gateway インスタンスは、配信元がある各リージョンにデプロイする必要があります。 各 Application Gateway インスタンスは個別に課金されるため、配信元を複数のリージョンにデプロイしている場合、コストが高くなる可能性があります。

  コストがソリューションの重要な要素である場合は、Azure Front Door へのフォールバックとしてパートナー コンテンツ配信ネットワーク (CDN) を使用する代替アプローチについて、「ミッション クリティカルなグローバル コンテンツ配信」を参照してください。 一部の CDN では使用量ベースでトラフィックに課金されるため、このアプローチの方がコスト効率が高い場合があります。 ただし、ソリューションに Application Gateway を使用する他の利点がいくつか失われる可能性があります。

  または、Traffic Manager がサービスとしてのプラットフォーム (PaaS) アプリケーション サービスにトラフィックを直接ルーティングできる代替アーキテクチャをデプロイして、Application Gateway の必要性を回避し、コストを削減することを検討することもできます。 ソリューションに Azure App Service や Azure Container Apps などのサービスを使用する場合は、このアプローチを検討できます。 ただし、このアプローチを採用する場合は、考慮するべき重要なトレードオフがいくつかあります。

  • WAF: Azure Front Door と Application Gateway はどちらも WAF 機能を提供します。 アプリケーション サービスをインターネットに直接公開すると、WAF でアプリケーションを保護できない可能性があります。
  • TLS オフロード: Azure Front Door と Application Gateway はどちらも TLS 接続を終了します。 TLS 接続を終了するようにアプリケーション サービスを構成する必要があります。
  • ルーティング: Azure Front Door と Application Gateway はどちらも、パスベースのルーティングを含む、複数の配信元またはバックエンドにわたるルーティングを実行し、複合ルーティング規則をサポートしています。 アプリケーション サービスがインターネットに直接公開されている場合は、トラフィックのルーティングを実行できません。

次の手順

グローバル コンテンツ配信のシナリオを確認して、ソリューションに適用されるかどうかを把握します。