Azure Front Door の Azure Well-Architected Framework のパースペクティブ
Azure Front Door は、HTTP トラフィックと HTTPS トラフィックをルーティングするグローバル ロード バランサーとコンテンツ配信ネットワークです。 Azure Front Door は、アプリケーション ユーザーに最も近いトラフィックを配信して配布します。
この記事では、アーキテクトとして 負荷分散オプションを 確認し、ワークロードのロード バランサーとして Azure Front Door を選択していることを前提としています。 また、アプリケーションがアクティブ/アクティブまたはアクティブ/パッシブ モデル内の複数のリージョンにデプロイされていることを前提としています。 この記事のガイダンスでは、 Azure Well-Architected Framework の柱の原則にマップされるアーキテクチャに関する推奨事項について説明します。
重要
このガイドを使用する方法
各セクションには、テクノロジスコープにローカライズされたアーキテクチャの関心領域と設計戦略を示す設計 チェックリスト があります。
この記事には、これらの戦略を具体化するのに役立つテクノロジ機能に関する 推奨事項 も含まれています。 推奨事項は、Azure Front Door で使用できるすべての構成とその依存関係の完全な一覧を表しているわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項を一覧表示します。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化します。
主要な推奨事項を示す基本的なアーキテクチャ: ネットワーク制御を使用したミッション クリティカルなベースライン アーキテクチャ。
テクノロジスコープ
このレビューでは、次の Azure リソースに関する相互に関連する決定に焦点を当てます。
- Azure Front Door
[信頼性]
信頼性の柱の目的は、 十分な回復性と障害から迅速に回復する機能を構築することで、継続的な機能を提供することです。
信頼性設計の原則は、個々のコンポーネント、システム フロー、およびシステム全体に適用される高レベルの設計戦略を提供します。
設計チェック リスト
信頼性の設計レビュー チェックリストに基づいて 、設計戦略を開始します。 階層と Azure Content Delivery Network の機能を念頭に置きながら、ビジネス要件との関連性を判断します。 戦略を拡張して、必要に応じてより多くのアプローチを含めます。
トラフィック パターンとボリュームを見積もります。 クライアントから Azure Front Door エッジへの要求の数が、レベルの選択に影響する可能性があります。 大量の要求をサポートする必要がある場合は、パフォーマンスが最終的に可用性に影響を与えるので、Azure Front Door Premium レベルを検討してください。 ただし、コストのトレードオフがあります。 これらのレベルについては、「 パフォーマンス効率」を参照してください。
デプロイ戦略を選択します。 基本的な展開方法は、 アクティブ/アクティブ と アクティブ/パッシブです。 アクティブ/アクティブデプロイとは、ワークロードを実行する複数の環境またはスタンプがトラフィックを処理することを意味します。 アクティブ/パッシブデプロイとは、プライマリ リージョンのみがすべてのトラフィックを処理することを意味しますが、必要に応じてセカンダリ リージョンにフェールオーバーします。 マルチリージョンデプロイでは、スタンプは異なるリージョンで実行され、トラフィックを分散する Azure Front Door などのグローバル ロード バランサーを使用して高可用性を実現します。 そのため、適切なデプロイ アプローチ用にロード バランサーを構成することが重要です。
Azure Front Door では、アクティブ/アクティブまたはアクティブ/パッシブ モデルでトラフィックを分散するように構成できるいくつかのルーティング方法がサポートされています。
上記のモデルには多くのバリエーションがあります。 たとえば、ウォーム スペアを使用してアクティブ/パッシブ モデルをデプロイできます。 この場合、セカンダリ ホステッド サービスは、可能な限り最小限のコンピューティングとデータサイズ設定でデプロイされ、負荷なしで実行されます。 フェールオーバー時に、コンピューティング リソースとデータ リソースがスケーリングされ、プライマリ リージョンからの負荷が処理されます。 詳細については、「 マルチリージョン設計の主な設計戦略」を参照してください。
一部のアプリケーションでは、ユーザー セッション中に同じ配信元サーバーにユーザー接続を維持する必要があります。 信頼性の観点からは、ユーザー接続を同じ配信元サーバーに保持することはお勧めしません。 セッション アフィニティはできるだけ避けてください。
Azure Front Door サーバーと配信元サーバーで同じホスト名を使用します。 Cookie またはリダイレクト URL が正しく機能することを確認するには、ロード バランサーなどのリバース プロキシを Web アプリケーションの前で使用するときに、元の HTTP ホスト名を保持します。
正常性エンドポイントの監視パターンを実装します。 アプリケーションで正常性エンドポイントを公開する必要があります。これにより、アプリケーションが要求を処理するために必要な重要なサービスと依存関係の状態が集計されます。 Azure Front Door 正常性プローブでは、エンドポイントを使用して配信元サーバーの正常性を検出します。 詳細については、「正常性エンドポイントの監視パターン」を参照してください。
Azure Front Door の組み込みのコンテンツ配信ネットワーク機能を利用します。 Azure Front Door のコンテンツ配信ネットワーク機能には数百のエッジロケーションがあり、分散型サービス拒否 (DDoS) 攻撃に耐えることができます。 これらの機能は、信頼性の向上に役立ちます。
冗長なトラフィック管理オプションを検討してください。 Azure Front Door は、環境でシングルトンとして実行されるグローバルに分散されたサービスです。 Azure Front Door は、システム内の単一障害点の可能性があります。 サービスが失敗した場合、クライアントはダウンタイム中にアプリケーションにアクセスできません。
冗長な実装は複雑でコストがかかる場合があります。 障害に対する許容度が非常に低いミッション クリティカルなワークロードに対してのみ考慮してください。 トレードオフを慎重に検討 してください。
- 冗長ルーティングが絶対に必要な場合は、「 グローバル ルーティングの冗長性」を参照してください。
- キャッシュされたコンテンツを提供するために冗長性のみが必要な場合は、「 グローバル コンテンツ配信」を参照してください。
Recommendations
| 推奨 | 特長 |
|---|---|
| デプロイ戦略をサポートする ルーティング方法 を選択します。 構成された重み係数に基づいてトラフィックを分散する重み付け方式では、アクティブ/アクティブ モデルがサポートされます。 すべてのトラフィックを受信し、バックアップとしてセカンダリ リージョンにトラフィックを送信するようにプライマリ リージョンを構成する優先度ベースの値は、アクティブ/パッシブ モデルをサポートします。 前の方法と待機時間を組み合わせて、最も短い待機時間の配信元がトラフィックを受信するようにします。 |
一連の決定手順と設計を使用して、最適な配信元リソースを選択できます。 選択した配信元は、指定された重みの比率で許容される待機時間範囲内のトラフィックを処理します。 |
|
1 つ以上のバックエンド プールに複数の配信元を含めることで、冗長性をサポートします。 アプリケーションの冗長なインスタンスを常に持ち、各インスタンスがエンドポイントまたは配信元を公開していることを確認します。 これらの配信元は、1 つ以上のバックエンド プールに配置できます。 |
複数の配信元は、アプリケーションの複数のインスタンスにトラフィックを分散することで冗長性をサポートします。 1 つのインスタンスが使用できない場合でも、他のバックエンドの配信元はトラフィックを受信できます。 |
|
配信元に正常性プローブを設定します。 バックエンド インスタンスが使用可能で、要求を受け取り続ける準備ができているかどうかを判断するための正常性チェックを実行するように Azure Front Door を構成します。 |
有効な正常性プローブは、正常性監視パターンの実装の一部です。 正常性プローブを使用すると、Azure Front Door によって、要求を処理するのに十分な正常なインスタンスにのみトラフィックがルーティングされます。 詳細については、「 正常性プローブのベスト プラクティス」を参照してください。 |
| バックエンドへの要求の転送時にタイムアウトを設定します。 エンドポイントのニーズに応じてタイムアウト設定を調整します。 そうでない場合は、配信元が応答を送信する前に、Azure Front Door によって接続が閉じる可能性があります。 すべての配信元のタイムアウトが短い場合は、Azure Front Door の既定のタイムアウトを小さくすることもできます。 詳細については、「 応答しない要求のトラブルシューティング」を参照してください。 |
タイムアウトは、予想以上に完了するまでに時間がかかる要求を終了することで、パフォーマンスの問題と可用性の問題を防ぐのに役立ちます。 |
| Azure Front Door と配信元で同じホスト名を使用します。 Azure Front Door では、受信要求のホスト ヘッダーを書き換えることができます。これは、1 つの配信元にルーティングする複数のカスタム ドメイン名がある場合に便利です。 ただし、ホスト ヘッダーを書き換えることで、要求 Cookie と URL リダイレクトに関する問題が発生する可能性があります。 |
同じホスト名を設定して、セッション アフィニティ、認証、承認の誤動作を防ぎます。 詳細については、「リバース プロキシとそのバックエンド Web アプリケーション の間で元の HTTP ホスト名を保持 する」を参照してください。 |
| アプリケーションで セッション アフィニティが必要かどうかを決定します。 信頼性の高い要件がある場合は、セッション アフィニティを無効にすることをお勧めします。 | セッション アフィニティを使用すると、ユーザー接続はユーザー セッション中も同じ配信元に維持されます。 その配信元が使用できなくなった場合、ユーザー エクスペリエンスが中断される可能性があります。 |
| Web アプリケーション ファイアウォール (WAF) に含まれる レート制限規則 を利用します。 | クライアントがアプリケーションに送信するトラフィックが多くなりすぎないように要求を制限します。 レート制限は、再試行ストームなどの問題を回避するのに役立ちます。 |
セキュリティ
セキュリティの柱の目的は 、ワークロードに機密性、整合性、可用性の 保証を提供することです。
セキュリティ設計の原則は、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 を予期しないトラフィックから保護します。 Azure Front Door では、Azure DDoS 保護の基本計画を使用 して、DDoS 攻撃からアプリケーション エンドポイントを保護します。 アプリケーションから他のパブリック IP アドレスを公開する必要がある場合は、高度な保護と検出機能のために、これらのアドレスの DDoS Protection 標準プランを追加することを検討してください。
また、ボット トラフィックや、悪意のある可能性がある大量のトラフィックを検出する WAF ルール セットもあります。
転送中のデータを保護します。 必要に応じて、エンドツーエンドのトランスポート層セキュリティ (TLS)、HTTP から HTTPS へのリダイレクト、およびマネージド TLS 証明書を有効にします。 詳細については、「 Azure Front Door の TLS のベスト プラクティス」を参照してください。
異常なアクティビティを監視します。 定期的にログを確認して、攻撃と誤検知をチェックします。 Azure Front Door から、Microsoft Sentinel などのorganizationの一元化されたセキュリティ情報とイベント管理 (SIEM) に WAF ログを送信して、脅威パターンを検出し、ワークロード設計に予防措置を組み込みます。
Recommendations
| 推奨 | 特長 |
|---|---|
| 悪意のある可能性のあるトラフィックを検出してブロックする WAF ルール セットを有効にします。 この機能は Premium レベルで使用できます。 次のルール セットをお勧めします。 - 既定 - ボット保護 - IP 制限 - geo フィルター処理 - レート制限 |
既定のルール セットは、OWASP の上位 10 件の攻撃の種類と Microsoft Threat Intelligence からの情報に基づいて頻繁に更新されます。 特殊化されたルール セットは、特定のユース ケースを検出します。 たとえば、ボット ルールは、クライアントの IP アドレスに基づいて、ボットを適切、不適切、または不明として分類します。 また、不適切なボットや既知の IP アドレスをブロックし、呼び出し元の地理的な場所に基づいてトラフィックを制限します。 ルール セットを組み合わせて使用すると、さまざまな意図を持つ攻撃を検出してブロックできます。 |
| マネージド ルール セットの除外を作成します。 検出モードで数週間 WAF ポリシーをテストし、展開する前に誤検知を調整します。 |
誤検知を減らし、アプリケーションの正当な要求を許可します。 |
| ホスト ヘッダーをバックエンドに送信します。 | バックエンド サービスはホスト名を認識して、そのホストからのトラフィックのみを受け入れるルールを作成できるようにする必要があります。 |
| 必要に応じて、エンド ツー エンド TLS、HTTP から HTTPS へのリダイレクト、およびマネージド TLS 証明書を有効にします。 Azure Front Door の TLS のベスト プラクティスを確認します。 TLS バージョン 1.2 を、アプリケーションに関連する暗号を使用して許可される最小バージョンとして使用します。 操作を容易にするために、Azure Front Door マネージド証明書を既定で選択する必要があります。 ただし、証明書のライフサイクルを管理する場合は、Azure Front Door カスタム ドメイン エンドポイントで独自の証明書を使用し、Key Vaultに格納します。 |
TLS を使用すると、改ざんを防ぐために、ブラウザー、Azure Front Door、バックエンドの配信元間のデータ交換が暗号化されます。 Key Vaultでは、マネージド証明書のサポートと、簡単な証明書の更新とローテーションが提供されます。 |
コストの最適化
コストの最適化では、支出パターンの検出、重要な領域への投資の優先順位付け、ビジネス要件を満たしながらorganizationの予算を満たすように他のユーザーでの最適化に重点を置いています。
コスト最適化設計原則は、Azure Front Door とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。
設計チェック リスト
投資の コスト最適化の設計レビュー チェックリスト に基づいて、設計戦略を開始します。 ワークロードがワークロードに割り当てられている予算に合わせて設計を微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。
Azure Front Door のレベルと価格を確認します。 価格計算ツールを使用して、各レベルの現実的なコストを見積もります。 シナリオの各レベルの機能と適合性を比較します。 たとえば、Private Linkを介した配信元への接続は Premium レベルでのみサポートされます。
Standard SKU はコスト効率が高く、中程度のトラフィック シナリオに適しています。 Premium SKU では、より高い単価を支払いますが、WAF やPrivate Linkのマネージド ルールなどのセキュリティ上の利点と高度な機能にアクセスできます。 ビジネス要件に基づいて 、信頼性 と セキュリティ に関するトレードオフを検討します。
帯域幅のコストを考慮してください。 Azure Front Door の帯域幅コストは、選択した層とデータ転送の種類によって異なります。 Azure Front Door には、課金対象のメトリックに関する組み込みのレポートが用意されています。 帯域幅と最適化作業に集中できる場所に関連するコストを評価するには、「 Azure Front Door レポート」を参照してください。
受信要求を最適化します。 Azure Front Door では、受信要求に課金されます。 設計構成で制限を設定できます。
フロントエンドのバックエンドやゲートウェイ集計などの設計パターンを使用して、要求の数を減らします。 これらのパターンにより、操作の効率が向上する可能性があります。
WAF ルールによって受信トラフィックが制限され、コストが最適化される可能性があります。 たとえば、レート制限を使用して異常に高いレベルのトラフィックを防ぐか、geo フィルタリングを使用して特定のリージョンまたは国からのアクセスのみを許可します。
リソースを効率的に使用する。 Azure Front Door では、リソースの最適化に役立つルーティング方法が使用されます。 ワークロードが非常に待機時間の影響を受けやすい場合を除き、デプロイされたリソースを効果的に使用するために、すべての環境にトラフィックを均等に分散します。
Azure Front Door エンドポイントは、多くのファイルを提供できます。 帯域幅コストを削減する方法の 1 つは、圧縮を使用することです。
頻繁に変更されないコンテンツには、Azure Front Door でキャッシュを使用します。 コンテンツはキャッシュから提供されるため、要求がバックエンドに転送されるときに発生する帯域幅コストを節約できます。
organizationによって提供される共有インスタンスの使用を検討してください。 一元化されたサービスから発生したコストは、ワークロード間で共有されます。 ただし、 信頼性とのトレードオフを検討してください。 高可用性要件を持つミッション クリティカルなアプリケーションの場合は、自律インスタンスをお勧めします。
ログに記録されるデータの量に注意してください。 帯域幅とストレージの両方に関連するコストは、特定の要求が必要ない場合、またはログ データが長期間保持されている場合に発生する可能性があります。
Recommendations
| 推奨 | 特長 |
|---|---|
| それをサポートする エンドポイントにはキャッシュを使用します。 | キャッシュを使用すると、Azure Front Door インスタンスから配信元への呼び出しの数が減るため、データ転送コストが最適化されます。 |
|
ファイル圧縮を有効にすることを検討してください。 この構成では、アプリケーションが圧縮をサポートし、キャッシュを有効にする必要があります。 |
圧縮により、帯域幅の消費が削減され、パフォーマンスが向上します。 |
| 単一バックエンド プールの正常性チェックを無効にします。 Azure Front Door 配信元グループで構成されている配信元が 1 つだけの場合、これらの呼び出しは不要です。 |
ルーティングの決定に必要ない要求を無効にすることで、帯域幅コストを節約できます。 |
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、主に 開発プラクティス、監視、リリース管理の手順に焦点を当てています。
オペレーショナル エクセレンス設計原則は、ワークロードの運用要件に対してこれらの目標を達成するための高レベルの設計戦略を提供します。
設計チェック リスト
Azure Front Door に関連する監視、テスト、デプロイのプロセスを定義するための オペレーショナル エクセレンスの設計レビュー チェックリスト に基づいて設計戦略を開始します。
コードとしてのインフラストラクチャ (IaC) テクノロジを使用します。 Bicep や Azure Resource Manager テンプレートなどの IaC テクノロジを使用して、Azure Front Door インスタンスをプロビジョニングします。 これらの宣言型アプローチは、一貫性と簡単なメンテナンスを提供します。 たとえば、IaC テクノロジを使用すると、新しいルールセット バージョンを簡単に採用できます。 常に最新の API バージョンを使用してください。
構成を簡略化します。 Azure Front Door を使用して構成を簡単に管理します。 たとえば、アーキテクチャでマイクロサービスがサポートされているとします。 Azure Front Door では リダイレクト機能がサポートされているため、パスベースのリダイレクトを使用して個々のサービスをターゲットにすることができます。 もう 1 つのユース ケースは、ワイルドカード ドメインの構成です。
Azure Front Door ルーティング方法を使用して、プログレッシブ 露出を処理します。 重み付け負荷分散アプローチでは、カナリア デプロイを使用して、トラフィックの特定の割合をバックエンドに送信できます。 このアプローチは、制御された環境で新しい機能とリリースをロールアウトする前にテストするのに役立ちます。
ワークロードの監視の一環として、Azure Front Door の運用データを収集して分析します。 Azure Monitor ログを使用して、関連する Azure Front Door のログとメトリックをキャプチャします。 このデータは、トラブルシューティング、ユーザーの動作の理解、操作の最適化に役立ちます。
証明書管理を Azure にオフロードします。 認定のローテーションと更新に伴う運用上の負担を軽減します。
Recommendations
| 推奨 | 特長 |
|---|---|
| HTTP から HTTPS へのリダイレクトを使用して 、前方互換性をサポートします。 | リダイレクトが有効になっている場合、Azure Front Door は、セキュリティで保護されたエクスペリエンスのために HTTPS を使用するために、古いプロトコルを使用しているクライアントを自動的にリダイレクトします。 |
|
ログとメトリックをキャプチャします。 リソース アクティビティ ログ、アクセス ログ、正常性プローブ ログ、WAF ログを含めます。 アラートを設定します。 |
イングレス フローの監視は、アプリケーションの監視の重要な部分です。 要求を追跡し、パフォーマンスとセキュリティを向上させたいと考えています。 Azure Front Door 構成をデバッグするにはデータが必要です。 アラートを設定すると、重要な運用上の問題に関する通知をすぐに受け取ることができます。 |
| 組み込みの分析レポートを確認します。 | Azure Front Door プロファイルの全体像は、WAF メトリックを通じてトラフィックとセキュリティ レポートに基づいて改善を推進するのに役立ちます。 |
| 可能な場合は、マネージド TLS 証明書を使用します。 | Azure Front Door では、証明書の発行と管理を行うことができます。 この機能により、証明書の更新が不要になり、無効または期限切れの TLS 証明書による停止のリスクが最小限に抑えられます。 |
| ワイルドカード TLS 証明書を使用します。 | 各サブドメインを個別に追加または指定するように構成を変更する必要はありません。 |
パフォーマンス効率
パフォーマンス効率は、容量を管理することで 負荷が増加した場合でも、ユーザー エクスペリエンスを維持 することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計原則は、予想される使用に対してこれらの容量目標を達成するための高レベルの設計戦略を提供します。
設計チェック リスト
パフォーマンス効率の設計レビュー チェックリストに基づいて、設計戦略を開始します。 Azure Front Door の主要業績評価指標に基づくベースラインを定義します。
予想されるトラフィック パターンを分析して容量を計画します。 さまざまな負荷の下でアプリケーションがどのように実行されるかを理解するために、徹底的なテストを実施します。 同時トランザクション、要求レート、データ転送などの要因を考慮してください。
SKU の選択は、その計画に基づいて行います。 Standard SKU はコスト効率が高く、中程度のトラフィック シナリオに適しています。 負荷の増加が予想される場合は、Premium SKU をお勧めします。
Azure Front Door レポートを定期的に確認して、パフォーマンス データを分析します。 これらのレポートは、テクノロジ レベルで業績評価指標として機能するさまざまなメトリックに関する分析情報を提供します。
Azure Front Door レポートを使用して、ワークロードの現実的なパフォーマンス目標を設定します。 応答時間、スループット、エラー率などの要因を考慮してください。 ターゲットをビジネス要件とユーザーの期待に合わせます。
データ転送を最適化します。
キャッシュを使用して、画像、スタイルシート、JavaScript ファイル、頻繁に変更されないコンテンツなどの静的コンテンツの提供の待機時間を短縮します。
キャッシュ用にアプリケーションを最適化します。 クライアントとプロキシによってコンテンツをキャッシュする期間を制御するキャッシュ有効期限ヘッダーをアプリケーションで使用します。 キャッシュの有効性が長いということは、配信元サーバーに対する要求の頻度が低くなることを意味します。これにより、トラフィックが減少し、待機時間が短くなります。
ネットワーク経由で送信されるファイルのサイズを小さくします。 ファイルが小さいと、読み込み時間が短縮され、ユーザー エクスペリエンスが向上します。
アプリケーション内のバックエンド要求の数を最小限に抑えます。
たとえば、Web ページには、ユーザー プロファイル、最近の注文、残高、その他の関連情報が表示されます。 情報のセットごとに個別の要求を行う代わりに、設計パターンを使用してアプリケーションを構造化し、複数の要求が 1 つの要求に集約されるようにします。
要求を集計することで、フロントエンドとバックエンドの間の送信データが少なくなり、クライアントとバックエンド間の接続が少なくなり、オーバーヘッドが軽減されます。 また、Azure Front Door では処理される要求の数が少ないため、オーバーロードが防止されます。
正常性プローブの使用を最適化します。 配信元の状態が変更された場合にのみ、正常性プローブから正常性情報を取得します。 監視の精度と不要なトラフィックの最小化のバランスを取る。
正常性プローブは、通常、グループ内の複数のオリジンの正常性を評価するために使用されます。 Azure Front Door 配信元グループに 1 つの配信元のみを構成している場合は、正常性プローブを無効にして、配信元サーバー上の不要なトラフィックを減らします。 インスタンスは 1 つしかないため、正常性プローブの状態はルーティングに影響しません。
配信元のルーティング方法を確認します。 Azure Front Door には、配信元への待機時間ベース、優先度ベース、重み付け、セッション アフィニティベースのルーティングなど、さまざまなルーティング方法が用意されています。 これらの方法は、アプリケーションのパフォーマンスに大きく影響します。 シナリオに最適なトラフィック ルーティング オプションの詳細については、「 配信元へのトラフィック ルーティング方法」を参照してください。
配信元サーバーの場所を確認します。 配信元サーバーの場所は、アプリケーションの応答性に影響します。 配信元サーバーは、ユーザーの近くに存在する必要があります。 Azure Front Door を使用すると、特定の場所のユーザーが最も近い Azure Front Door エントリ ポイントにアクセスできるようになります。 パフォーマンス上の利点には、ユーザー エクスペリエンスの向上、Azure Front Door による待機時間ベースのルーティングの使用の向上、キャッシュを使用したデータ転送時間の最小化が含まれます。これにより、ユーザーに近いコンテンツが格納されます。
詳細については、「 場所別トラフィック レポート」を参照してください。
Recommendations
| 推奨 | 特長 |
|---|---|
|
キャッシュを有効にします。 キャッシュ用にクエリ文字列を最適化できます。 純粋に静的なコンテンツの場合は、クエリ文字列を無視してキャッシュの使用を最大化します。 アプリケーションでクエリ文字列を使用する場合は、キャッシュ キーに含めることを検討してください。 キャッシュ キーにクエリ文字列を含めると、Azure Front Door は、構成に基づいて、キャッシュされた応答やその他の応答を提供できます。 |
Azure Front Door は、ネットワークのエッジでコンテンツをキャッシュする堅牢なコンテンツ配信ネットワーク ソリューションを提供します。 キャッシュを使用すると、バックエンド サーバーの負荷が軽減され、ネットワーク全体のデータ移動が減り、帯域幅の使用量のオフロードに役立ちます。 |
| ダウンロード可能なコンテンツにアクセスするときは、ファイル圧縮を使用します。 | Azure Front Door での圧縮は、最適な形式でコンテンツを配信し、ペイロードが小さく、ユーザーにコンテンツをより迅速に配信するのに役立ちます。 |
Azure Front Door で正常性プローブを構成する場合は、要求ではなく要求をGET使用HEADすることを検討してください。 正常性プローブは、コンテンツではなく状態コードのみを読み取ります。 |
HEAD 要求を使用すると、コンテンツ全体をフェッチせずに状態変更を照会できます。 |
| 同じユーザーからの要求を同じバックエンド サーバーに送信する必要がある場合に 、セッション アフィニティ を有効にする必要があるかどうかを評価します。 信頼性の観点からは、このアプローチはお勧めしません。 このオプションを使用する場合、アプリケーションはユーザー セッションを中断することなく正常に回復する必要があります。 また、複数のバックエンドにトラフィックを均等に分散する柔軟性が制限されるため、負荷分散にもトレードオフがあります。 |
パフォーマンスを最適化し、ユーザー セッションの継続性を維持します。特に、アプリケーションが状態情報をローカルで維持することに依存している場合。 |
Azure のポリシー
Azure には、Azure Front Door とその依存関係に関連する広範な組み込みポリシーセットが用意されています。 上記の推奨事項の一部は、Azure ポリシーを使用して監査できます。 たとえば、次の場合にチェックできます。
- Azure Front Door プロファイルでマネージド WAF ルールとPrivate Linkをサポートするには、Premium レベルが必要です。
- 最小 TLS バージョン (バージョン 1.2) を使用する必要があります。
- Azure Front Door Premium と Azure PaaS サービス間のセキュリティで保護されたプライベート接続が必要です。
- リソース ログを有効にする必要があります。 WAF で要求本文検査が有効になっている必要があります。
- WAF 規則セットを適用するには、ポリシーを使用する必要があります。 たとえば、ボット保護を有効にし、レート制限ルールを有効にする必要があります。
包括的なガバナンスについては、「組み込みのポリシー定義」に記載されている Azure Content Delivery Network およびその他の Azure Front Door ポリシーの組み込み定義Azure Policy確認してください。
Azure Advisor の推奨事項
Azure Advisor は、ベスト プラクティスに従って Azure デプロイメントを最適化できるようにする、個人用に設定されたクラウド コンサルタントです。 Azure Front Door の信頼性、セキュリティ、コスト効率、パフォーマンス、オペレーショナル エクセレンスの向上に役立つ推奨事項をいくつか次に示します。
次の手順
この記事で強調表示されている推奨事項を示すリソースとして、次の記事を検討してください。
- この記事のガイダンスをワークロードに適用する方法の例として、次の参照アーキテクチャを使用します。
- 次の製品ドキュメントを使用して、実装の専門知識を構築します。