Azure Front Door のアーキテクチャのベスト プラクティス

デプロイ戦略を選択します。 The fundamental deployment approaches are active-active and active-passive. アクティブ/アクティブデプロイとは、ワークロードを実行する複数の環境またはスタンプがトラフィックを処理することを意味します。 アクティブ/パッシブデプロイとは、プライマリ リージョンのみがすべてのトラフィックを処理することを意味しますが、必要に応じてセカンダリ リージョンにフェールオーバーします。 マルチリージョンデプロイでは、スタンプまたはアプリケーション インスタンスが異なるリージョンで実行され、トラフィックを分散するグローバル ロード バランサー (Azure Front Door など) を使用して高可用性を実現します。 そのため、適切なデプロイ 方法に合わせてロード バランサーを構成することが重要です。

Azure Front Door では、アクティブ/アクティブまたはアクティブ/パッシブ モデルでトラフィックを分散するように構成できる複数のルーティング方法がサポートされています。

上記のモデルには多くのバリエーションがあります。 たとえば、ウォーム スペアを使用してアクティブ/パッシブ モデルをデプロイできます。 この場合、セカンダリ ホステッド サービスは、可能な限り最小限のコンピューティングとデータのサイズ設定でデプロイされ、負荷なしで実行されます。 フェールオーバー時に、コンピューティング リソースとデータ リソースがスケーリングされ、プライマリ リージョンからの負荷が処理されます。 詳細については、 マルチリージョン設計の主要な設計戦略を参照してください。

一部のアプリケーションでは、ユーザー セッション中に同じ配信元サーバーにユーザー接続を維持する必要があります。 信頼性の観点からは、ユーザー接続を同じ配信元サーバーに保持することはお勧めしません。 セッション アフィニティはできるだけ避けてください。

各レイヤーで同じホスト名を使用します。 Cookie またはリダイレクト URL が正しく機能することを確認するには、Web アプリケーションの前で Azure Front Door などのリバース プロキシを使用するときに、元の HTTP ホスト名を保持します。

正常性エンドポイントの監視パターンを実装します。 アプリケーションは正常性エンドポイントを公開する必要があります。これは、アプリケーションが要求を処理するために必要な重要なサービスと依存関係の状態を集計します。 Azure Front Door 正常性プローブは、エンドポイントを使用して配信元サーバーの正常性を検出します。 詳細については、「正常性エンドポイント監視パターン」を参照してください。

静的コンテンツをキャッシュします。 Azure Front Door のコンテンツ配信機能には数百のエッジロケーションがあり、トラフィックの急増や分散型サービス拒否 (DDoS) 攻撃に耐えることができます。 これらの機能は、信頼性の向上に役立ちます。

冗長なトラフィック管理オプションを検討してください。 Azure Front Door は、環境でシングルトンとして実行されるグローバル分散サービスです。 Azure Front Door は、システムで単一障害点となる可能性があります。 サービスが失敗した場合、クライアントはダウンタイム中にアプリケーションにアクセスできません。

冗長な実装は複雑でコストがかかる場合があります。 停止に対する許容度が非常に低いミッション クリティカルなワークロードに対してのみ考慮してください。 Carefully consider the tradeoffs.

• 冗長ルーティングが絶対に必要な場合は、「 グローバル ルーティングの冗長性」を参照してください。
• キャッシュされたコンテンツを提供するだけの冗長性が必要な場合は、「 グローバル コンテンツ配信」を参照してください。

Azure Front Door のセキュリティ ベースラインを確認します。

配信元サーバーを保護します。 Azure Front Door はフロントエンドであり、アプリケーションへの単一のイングレス ポイントです。

Azure Front Door では、Azure Private Link を使用してアプリケーションの配信元にアクセスします。 Private Link では、配信元がパブリック IP アドレスとエンドポイントを公開する必要がないようにセグメント化が作成されます。 詳しくは、「Azure Front Door Premium で Private Link を使用して配信元を保護する」をご覧ください。

Azure Front Door が外部で使用するのと同じホスト名の要求のみを受け入れるようにバックエンド サービスを構成します。

コントロール プレーンへの承認されたアクセスのみを許可します。 Azure Front Door ロールベースのアクセス制御 (RBAC) を 使用して、アクセスを必要とする ID のみに制限します。

エッジで一般的な脅威をブロックします。 WAF は Azure Front Door と統合されています。 フロントエンドで WAF ルールを有効にして、攻撃元に近いネットワーク エッジの一般的な悪用や脆弱性からアプリケーションを保護します。 国または地域によって Web アプリケーションへのアクセスを制限するには、geo フィルタリングを検討してください。

詳細については、「Azure Front Door 上の Azure Web Application Firewall」を参照してください。

予期しないトラフィックから保護します。 Azure Front Door のアーキテクチャでは、DDoS 攻撃からアプリケーション エンドポイントを保護するための DDoS 保護が組み込まれています。 アプリケーションから他のパブリック IP アドレスを公開する必要がある場合は、高度な保護と検出機能のために、これらのアドレスの Azure DDoS Protection 標準プランを追加することを検討してください。

また、ボット のトラフィックや、悪意のある可能性がある大量のトラフィックを検出する WAF ルール セットもあります。

転送中のデータを保護します。 必要に応じて、エンドツーエンドのトランスポート層セキュリティ (TLS)、HTTP から HTTPS へのリダイレクト、およびマネージド TLS 証明書を有効にします。 詳細については、 Azure Front Door の TLS のベスト プラクティスに関するページを参照してください。

異常なアクティビティを監視します。 定期的にログを確認して、攻撃と誤検知を確認します。 Azure Front Door から組織の一元化されたセキュリティ情報とイベント管理 (SIEM) (Microsoft Sentinel など) に WAF ログを送信して、脅威パターンを検出し、ワークロード設計に予防措置を組み込みます。

サービス レベルと価格を確認します。 Use the pricing calculator to estimate the realistic costs for each tier of Azure Front Door. シナリオの各レベルの機能と適合性を比較します。 たとえば、Private Link 経由で配信元に接続できるのは Premium レベルのみです。

Standard SKU はコスト効率が高く、中程度のトラフィック シナリオに適しています。 Premium SKU では、より高い単価を支払いますが、WAF や Private Link のマネージド ルールなどのセキュリティ上の利点や高度な機能にアクセスできます。 Consider the tradeoffs on reliability and security based on your business requirements.

帯域幅のコストを考慮してください。 Azure Front Door の帯域幅コストは、選択したレベルとデータ転送の種類によって異なります。 Azure Front Door の課金については、「 Azure Front Door の課金について」を参照してください。

Azure Front Door には、課金対象メトリックの組み込みレポートが用意されています。 帯域幅に関連するコストと最適化作業に集中できる場所を評価するには、 Azure Front Door レポートを参照してください。

受信要求を最適化します。 Azure Front Door は、受信要求に課金します。 デザイン構成で制限を設定できます。

フロントエンドのバックエンドやゲートウェイの集計などの設計パターンを使用して、要求の数を減らします。 これらのパターンにより、操作の効率が向上する可能性があります。

WAF ルールは受信トラフィックを制限し、コストを最適化できます。 たとえば、レート制限を使用して異常に高いレベルのトラフィックを防いだり、geo フィルタリングを使用して特定の地域や国からのアクセスのみを許可したりできます。

リソースを効率的に使用する。 Azure Front Door では、リソースの最適化に役立つルーティング方法が使用されます。 ワークロードが非常に待機時間の影響を受けやすい場合を除き、デプロイされたリソースを効果的に使用するために、すべての環境にトラフィックを均等に分散します。

Azure Front Door エンドポイントは、多くのファイルを処理できます。 帯域幅コストを削減する方法の 1 つは、圧縮を使用する方法です。

頻繁に変更されないコンテンツには、Azure Front Door でキャッシュを使用します。 コンテンツはキャッシュから提供されるため、要求が配信元に転送されるときに発生する帯域幅コストを節約できます。

組織によって提供される共有インスタンスの使用を検討してください。 一元化されたサービスから発生したコストは、ワークロード間で共有されます。 However, consider the tradeoff with reliability. 高可用性要件を持つミッション クリティカルなアプリケーションの場合は、自律型インスタンスをお勧めします。

ログに記録されるデータの量に注意してください。 帯域幅とストレージの両方に関連するコストは、特定の要求が必要ない場合、またはログ データが長期間保持されている場合に発生する可能性があります。

コードとしてのインフラストラクチャ (IaC) テクノロジを使用します。 Bicep テンプレートや Azure Resource Manager テンプレートなどの IaC テクノロジを使用して、Azure Front Door インスタンスをプロビジョニングします。 これらの宣言型アプローチは、一貫性と簡単なメンテナンスを提供します。 たとえば、IaC テクノロジを使用すると、新しいルールセット バージョンを簡単に採用できます。 常に最新の API バージョンを使用します。

Simplify configurations. Azure Front Door を使用して構成を簡単に管理します。 たとえば、アーキテクチャがマイクロサービスをサポートするとします。 Azure Front Door supports redirection capabilities, so you can use path-based redirection to target individual services. もう 1 つのユース ケースは、ワイルドカード ドメインの構成です。

プログレッシブ 露出を処理します。 Azure Front Door には 、複数のルーティング方法が用意されています。 加重負荷分散アプローチでは、カナリア デプロイを使用して、特定の割合のトラフィックを配信元に送信できます。 このアプローチは、制御された環境で新しい機能とリリースをロールアウトする前にテストするのに役立ちます。

ワークロードの監視の一環として、運用データを収集して分析します。 Azure Monitor ログを使用して、関連する Azure Front Door のログとメトリックをキャプチャします。 このデータは、トラブルシューティング、ユーザーの動作の理解、操作の最適化に役立ちます。

証明書管理を Azure にオフロードします。 認定のローテーションと更新に伴う運用上の負担を軽減します。

予想されるトラフィック パターンを分析して容量を計画します。 さまざまな負荷の下でアプリケーションがどのように実行されるかを理解するために、徹底的なテストを実施します。 同時トランザクション、要求率、データ転送などの要因を考慮してください。

SKU の選択は、その計画に基づいて行います。 Standard SKU はコスト効率が高く、中程度のトラフィック シナリオに適しています。 負荷の増加が予想される場合は、Premium SKU をお勧めします。

パフォーマンス メトリックを定期的に確認して、パフォーマンス データを分析します。 Azure Front Door レポート は、テクノロジ レベルでパフォーマンス インジケーターとして機能するさまざまなメトリックに関する分析情報を提供します。

Azure Front Door レポートを使用して、ワークロードの現実的なパフォーマンス 目標を設定します。 応答時間、スループット、エラー率などの要因を考慮してください。 ビジネス要件とユーザーの期待に合わせてターゲットを調整します。

データ転送を最適化します。

• キャッシュを使用して、画像、スタイルシート、JavaScript ファイル、頻繁に変更されないコンテンツなどの静的コンテンツの提供の待機時間を短縮します。

  キャッシュ用にアプリケーションを最適化します。 クライアントとプロキシによってコンテンツをキャッシュする期間を制御するキャッシュ有効期限ヘッダーをアプリケーションで使用します。 キャッシュの有効性が長いほど、配信元サーバーへの要求の頻度が低くなり、トラフィックが減少し、待機時間が短縮されます。

• ネットワーク経由で送信されるファイルのサイズを小さくします。 ファイルが小さいと、読み込み時間が短縮され、ユーザー エクスペリエンスが向上します。

• アプリケーション内のバックエンド要求の数を最小限に抑えます。

  たとえば、Web ページには、ユーザー プロファイル、最近の注文、残高、その他の関連情報が表示されます。 情報のセットごとに個別の要求を行う代わりに、設計パターンを使用してアプリケーションを構成し、複数の要求が 1 つの要求に集約されるようにします。

  Update clients to use the HTTP/2 protocol, which can combine multiple requests into a single TCP connection.

  Use WebSockets to support realtime full-duplex communication, rather than making repeated HTTP requests or polling.

  要求を集計することで、フロントエンドとバックエンドの間の送信データが少なくなり、クライアントとバックエンドの間の接続が少なくなり、オーバーヘッドが削減されます。 また、Azure Front Door は処理する要求の数を減らします。これにより、オーバーロードが回避されます。

正常性プローブの使用を最適化します。 配信元の状態が変化した場合にのみ、正常性プローブから正常性情報を取得します。 監視の精度と不要なトラフィックの最小化のバランスを取る。

正常性プローブは、通常、グループ内の複数のオリジンの正常性を評価するために使用されます。 Azure Front Door 配信元グループで構成されている配信元が 1 つしかない場合は、正常性プローブを無効にして、配信元サーバー上の不要なトラフィックを減らします。 インスタンスが 1 つしかないため、正常性プローブの状態はルーティングに影響しません。

配信元のルーティング方法を確認します。 Azure Front Door には、配信元への待機時間ベース、優先度ベース、重み付け、セッション アフィニティベースのルーティングなど、さまざまなルーティング方法が用意されています。 これらのメソッドは、アプリケーションのパフォーマンスに大きく影響します。 シナリオに最適なトラフィック ルーティング オプションの詳細については、「 配信元へのトラフィック ルーティング方法」を参照してください。

配信元サーバーの場所を確認します。 配信元サーバーの場所は、アプリケーションの応答性に影響します。 配信元サーバーは、ユーザーに近い必要があります。 Azure Front Door を使用すると、特定の場所のユーザーが最も近い Azure Front Door エントリ ポイントにアクセスできるようになります。 パフォーマンス上の利点には、ユーザー エクスペリエンスの向上、Azure Front Door による待機時間ベースのルーティングの使用の向上、ユーザーに近いコンテンツを格納するキャッシュを使用したデータ転送時間の最小化などがあります。

詳細については、「 場所別のトラフィック」レポートを参照してください。