ミッション クリティカルなアプリケーションでは、ネットワーク コンポーネントが使用できない場合や機能が低下している場合でも、高いレベルのアップタイムを維持する必要があります。 Web トラフィックのイングレス、ルーティング、セキュリティを設計する場合は、複数の Azure サービスを組み合わせて、より高いレベルの可用性を実現し、単一障害点を回避することを検討できます。
Microsoft では、 Azure Front Door の業界をリードするサービス レベル アグリーメント (SLA) を提供しています。 別のプロバイダーが 100% アップタイム SLA を提供する場合でも、ダウンタイムがゼロになる保証ではなく、停止が発生した場合に SLA によってサービス クレジットが提供されることに注意することが重要です。 このため、Microsoft の競合他社でも、ミッション クリティカルなワークロードに複数のイングレス パスを使用することをお勧めします。
この方法を採用する場合は、アプリケーション サーバーへの個別のネットワーク パスを実装する必要があり、各パスを個別に構成してテストする必要があります。 このアプローチの完全な影響を慎重に検討する必要があります。
この記事では、Azure Front Door と Azure Application Gateway を介したグローバル HTTP トラフィックの受信をサポートする方法について説明します。 このアプローチは、あなたのソリューションが以下の条件を満たしている場合に、ニーズに適しているかもしれません。
- グローバル トラフィック ルーティング用の Azure Front Door。 これは、アプリケーションの複数のインスタンスが別々の Azure リージョンにある場合や、1 つのリージョンのすべてのグローバル ユーザーにサービスを提供することを意味する場合があります。
- トラフィックが配信元サーバーに到達するためのパスに関係なく、アプリケーションを保護するための Web アプリケーション ファイアウォール (WAF)。
ネットワーク エッジでのキャッシュは、アプリケーション配信の重要な部分ではありません。 キャッシュが重要な場合は、 ミッション クリティカルなグローバル コンテンツ配信 に関するページを参照して、別のアプローチを検討してください。
注
このユース ケースは、Azure Front Door が使用できない場合の代替アプローチをカバーする全体的な設計戦略の一部です。 コンテキストと考慮事項については、「 ミッション クリティカルなグローバル Web アプリケーション」を参照してください。
方法
この DNS ベースの負荷分散ソリューションでは、複数の Azure Traffic Manager プロファイルを使用します。 Azure Front Door で可用性の問題が発生した場合、Azure 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 つのリージョンにある単純なシナリオでは、優先順位ベースのルーティングを使用するように構成された Traffic Manager プロファイルが 1 つだけ必要な場合があります。
リージョンの分布
Azure Front Door はグローバル サービスですが、Application Gateway はリージョン サービスです。
Azure Front Door のプレゼンス ポイントはグローバルにデプロイされ、TCP 接続と TLS 接続は クライアントに最も近いプレゼンス ポイントで終了します。 この動作により、アプリケーションのパフォーマンスが向上します。 これに対し、クライアントが Application Gateway に接続すると、トラフィックの送信元に関係なく、要求を受信する Application Gateway で TCP 接続と TLS 接続が終了します。
クライアントからの接続
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 に大量のトラフィックが予期せず到着した場合は、パフォーマンスまたは信頼性の問題が発生する可能性があります。
このリスクを軽減するには、 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 はどちらも、パスベースのルーティングを含む複数の配信元またはバックエンド間でルーティングを実行し、複雑なルーティング規則をサポートします。 アプリケーション サービスがインターネットに直接公開されている場合、トラフィック ルーティングを実行することはできません。
警告
アプリケーションをインターネットに直接公開することを検討する場合は、徹底的な脅威モデルを作成し、アーキテクチャがセキュリティ、パフォーマンス、回復性の要件を満たしていることを確認します。
仮想マシンを使用してソリューションをホストする場合は、仮想マシンをインターネットに公開しないでください。
貢献者
この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。
主要な著者:
- Dave Burkhardt |プリンシパル プログラム マネージャー、Azure Front Door
- John Downs | プリンシパル ソフトウェア エンジニア
- プリヤンカ・ウィルキンス |プリンシパル コンテンツ開発者
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
グローバル コンテンツ配信シナリオを確認して、それがソリューションに適用されるかどうかを理解します。