Azure Front Door を設計および構成する
Azure Front Door は、Microsoft の最新のクラウド コンテンツ配信ネットワーク (CDN) であり、世界中のユーザーとアプリケーションの静的および動的 Web コンテンツの間で、高速で信頼性が高く、セキュリティで保護されたアクセスを提供します。 Azure Front Door は、Microsoft のグローバル エッジ ネットワークを使用してコンテンツを配信します。このネットワークでは、数百のグローバルおよびローカル POP が、企業とコンシューマー エンド ユーザーの両方に近い世界各地の場所に分散配置されています。
多くの組織には、顧客、サプライヤー、そしてほとんどの場合にそのユーザーが利用できるアプリケーションがあります。 厄介な部分は、これらのアプリケーションが高可用性であることを確認することです。 さらに、これらは、適切なセキュリティで保護され、迅速に応答する必要があります。 Azure Front Door には、これらの要件を満たすさまざまな SKU (価格レベル) が用意されています。 ご自分の要件に最適なオプションを決定できるように、これらの SKU の機能と利点を簡単に確認することにしましょう。
セキュリティで保護された最新のクラウド CDN により、サーバーの分散型プラットフォームが提供されます。 これは、ユーザーが Web ページにアクセスしているときの待機時間を最小限に抑えるのに役立ちます。 これまで、IT スタッフは、CDN と Web アプリケーション ファイアウォールを使用して、ターゲット アプリケーションとの間の HTTP および HTTPS トラフィック フローを制御したことがあるかもしれません。
組織で Azure を使用している場合、次の表で説明する製品を実装することにより、これらの目標を達成することができます
| Product | 説明 |
|---|---|
| Azure Front Door | Microsoft グローバル エッジ ネットワーク内に配置されたアプリへのエントリ ポイントを有効にします。 Web アプリへのより高速かつ安全で、スケーラブルなアクセスを提供します。 |
| Azure Content Delivery Network | 世界中の戦略的に配置された物理ノードでコンテンツをキャッシュすることにより、ユーザーに高帯域幅のコンテンツを配信します。 |
| Azure Web アプリケーション ファイアウォール | 一般的な悪用や脆弱性からの Web アプリの保護を一元化してより強力にします。 |
Azure Front Door のレベルの比較
Azure Front Door には、Azure Front Door Standard と Azure Front Door Premium の 2 つのレベルがあります。 Azure Front Door Standard および Premium レベルは、Azure Front Door (クラシック)、Microsoft の Azure CDN Standard (クラシック)、Azure WAF の機能を、インテリジェントな脅威保護を用いて、セキュリティで保護された 1 つのクラウド CDN プラットフォームに統合したものです。 Azure Front Door は、エッジの場所にあり、ホストされているアプリケーションに対するユーザー要求を管理します。 ユーザーは、Microsoft グローバル ネットワークを介してアプリケーションに接続します。 その後、Azure Front Door により、ユーザー要求は、最も高速で、最も可用性の高いアプリケーション バックエンドにルーティングされます。
Azure Front Door でサポートされている機能の比較については、機能比較表をご確認ください。
Azure portal でフロント ドアを作成する
次のクイックスタートを確認すると、Azure portal を利用して Azure Front Door プロファイルを作成する方法がわかります。 Azure Front Door プロファイルは、基本構成による簡易作成を使用して作成することも、より詳細な構成を可能にするカスタム作成を使用して作成することもできます。
ルーティング アーキテクチャの概要
Front Door トラフィックのルーティングは、複数のステージで行われます。 まず、トラフィックがクライアントから Front Door にルーティングされます。 次に、Front Door では構成を使用して、トラフィックを送信する配信元を判断します。 Front Door Web アプリケーションのファイアウォール、ルーティング規則、ルール エンジン、キャッシュ構成のすべてが、ルーティング プロセスに影響します。 次の図は、このルーティングのアーキテクチャを示しています。
Front Door でリダイレクト規則を構成する
接続の確立と TLS ハンドシェイクが行われ、要求が Front Door 環境に届いたときに、Front Door で最初に行われることの 1 つとして、その要求と一致するルーティング規則が特定され、構成内で定義されているアクションが実行されます。
Front Door ルーティング規則の構成構造
Front Door のルーティング規則の構成は、大きく分けて「左側」と「右側」の 2 つの部分から成っています。 Front Door は、着信要求をルートの左側と照合します。 右側では、Front Door が要求をどのように処理するかが定義されます。
着信の照合
以下のプロパティにより、着信要求がルーティング規則 (または左側) と一致するかどうかが判断されます。
- HTTP プロトコル (HTTP/HTTPS)
- ホスト (www.foo.com、*.bar.com など)
- パス (/、/users/、/file.gif など)
これらのプロパティは、内部で展開されているので、Protocol/Host/Path のすべての組み合わせが照合の対象となります。
ルート データ
Front Door は、キャッシュを使用して要求の処理を高速化します。 特定のルートに対してキャッシュが有効になっている場合、キャッシュされた応答が使用されます。 要求に対するキャッシュされた応答が存在しない場合、Front Door は、構成されたバックエンド プール内の適切なバックエンドに要求を転送します。
ルートの照合
Front Door はルートの左側のみを見て、最初に最もよく一致するものとの照合を試みます。 最初に HTTP プロトコルに基づいて照合し、次にフロントエンド ホスト、パスの順で照合します。
フロントエンド ホストの照合
- ホストに完全に一致するルートを探します。
- 完全に一致するフロント エンドのホストが存在しない場合は、要求を拒否し、400 Bad Request エラーを送信します。
パスの照合
- 当該パス上で、完全に一致するルーティング規則を探します。
- 完全に一致するパスが存在しない場合、一致するワイルドカード パスが含まれるルーティング規則を探します。
- Path が一致するルーティング規則が存在しない場合、要求を拒否し、400: Bad Request エラー HTTP 応答を返します。
キャッチオール ルートのパス (/*) でフロントエンド ホストと完全に一致するルーティング規則が存在しない場合、いずれのルーティング規則とも一致しません。
Azure Front Door は、プロトコル、ホスト名、パス、クエリ文字列の各レベルでトラフィックをリダイレクトします。 リダイレクトはパス ベースであるため、これらの機能を個々のマイクロサービスに対して構成できます。 これにより、リソースの使用を最適化することで、アプリケーションの構成を簡略化し、グローバルなパスベースのリダイレクトを含む、新しいリダイレクト シナリオをサポートすることができます。
リダイレクトの種類
リダイレクトの種類では、クライアントがリダイレクトの目的を理解するための応答の状態コードが設定されます。 次の種類のリダイレクトがサポートされています。
| リダイレクトの種類 | 操作 | 説明 |
|---|---|---|
| 301 | 完全な移動 | ターゲット リソースに新しい永続的な URI が割り当てられていることを示します。 このリソースへの今後の参照によって、囲まれた URI のいずれかが使用されます。 状態コード 301 は HTTP から HTTPS へのリダイレクトに使用します。 |
| 302 | Found | ターゲット リソースが一時的に別の URI に存在することを示します。 リダイレクトは場合によっては変更される可能性があるため、クライアントは今後の要求のために有効な要求 URI を引き続き使用する必要があります。 |
| 307 | 一時リダイレクト | ターゲット リソースが一時的に別の URI に存在することを示します。 ユーザー エージェントからその URI への自動リダイレクトを行う場合、要求メソッドを変更することはできません。 リダイレクトは時間が経つにつれて変更される可能性があるため、クライアントは今後の要求のために元の有効な要求 URI を引き続き使用する必要があります。 |
| 308 | 永続的リダイレクト | ターゲット リソースに新しい永続的な URI が割り当てられていることを示します。 このリソースへの今後の参照によって、囲まれた URI のいずれかが使用される必要があります。 |
リダイレクト プロトコル
リダイレクトに使用されるプロトコルを設定できます。 リダイレクト機能の最も一般的なユース ケースでは、HTTP から HTTPS へのリダイレクトを設定します。
- HTTPS のみ: トラフィックを HTTP から HTTPS にリダイレクトしようとする場合、プロトコルを HTTPS のみに設定します。 Azure Front Door では、リダイレクトを常に HTTPS のみに設定することが推奨されています。
- HTTP のみ: 着信要求を HTTP にリダイレクトします。 この値は、トラフィックを HTTP (暗号化されていない) のままにする場合のみ使用します。
- 一致要求: このオプションを使用すると、着信要求によって使用されるプロトコルが保持されます。 そのため、HTTP 要求は HTTP のままになり、HTTPS 要求はリダイレクト後も HTTPS のままになります。
宛先ホスト
リダイレクト ルーティングを構成する一環として、リダイレクト要求のホスト名またはドメインを変更することもできます。 このフィールドを設定して、リダイレクトのために URL のホスト名を変更したり、あるいは着信要求のホスト名を保持したりできます。 したがって、このフィールドを使用すると、https://www.contoso.com/* に送信されるすべての要求を https://www.fabrikam.com/* にリダイレクトできます。
宛先のパス
リダイレクトの一環として、URL のパス セグメントを置換する必要がある場合、このフィールドに新しいパスの値を設定できます。 そうしない場合、リダイレクトの一環として、パスの値を保持することを選択できます。 したがって、このフィールドを使用すると、https://www.contoso.com/* に送信されるすべての要求を https://www.contoso.com/redirected-site* にリダイレクトできます。
宛先フラグメント
宛先フラグメントは URL の '#' より後の部分のことで、これはブラウザーが Web ページの特定のセクションに移動するために使用されます。 このフィールドを設定して、リダイレクト URL にフラグメントを追加できます。
クエリ文字列パラメーター
リダイレクトされる URL のクエリ文字列パラメーターを置き換えることもできます。 着信要求 URL の既存のクエリ文字列を置換するには、このフィールドを [置換] に設定して適切な値を設定します。 そうしない場合、このフィールドを [保持] に設定することによって、元のクエリ文字列のセットを保持できます。 例として、このフィールドを使用すると、https://www.contoso.com/foo/bar に送信されたすべてのトラフィックを https://www.contoso.com/foo/bar?&utm_referrer=https%3A%2F%2Fwww.bing.com%2F にリダイレクトできます。
書き換えポリシーを構成する
Azure Front Door を使用すると、バックエンドに転送する要求を作成するときに使用するオプションのカスタム転送パスを構成することで、URL 書き換えを行うことができます。 既定では、カスタム転送パスが指定されていない場合、Front Door により、転送された要求で使用される URL に受信 URL パスがコピーされます。 転送された要求で使用されるホスト ヘッダーは、選択されたバックエンド用に構成されています。 その機能と構成方法については、「バックエンド ホスト ヘッダー」をご覧ください。
URL 書き換えの強力な部分は、カスタム転送パスが、ワイルドカード パスに一致する受信パスのすべての部分を転送パスにコピーすることです。
正常性プローブを構成する (HTTP 応答コードのカスタマイズを含む)
それぞれの Front Door 環境では、特定の Front Door 環境の各バックエンドの正常性と近接性を確認するために、構成されている各バックエンドに合成 HTTP/HTTPS 要求を定期的に送信します。 Front Door は、プローブからのこれらの応答を使用して、クライアント要求のルーティング先として "最適な" バックエンドリソースを決定します。
Front Door は世界中に多くのエッジ環境があるので、バックエンドに対する正常性プローブの量が極めて多くなる可能性があります。構成されている正常性プローブの頻度にもよりますが、毎分 25 回要求されることもあれば、多いときは毎分 1200 回要求されることもあります。 既定のプローブ頻度は 30 秒であり、バックエンドのプローブ量は毎分 200 要求程度になるはずです。
正常性プローブでサポートされている HTTP メソッド
Front Door では、HTTP または HTTPS プロトコルを使用したプローブの送信をサポートしています。 これらのプローブは、クライアント要求のルーティング用に構成された同じ TCP ポートを介して送信され、オーバーライドすることはできません。
Front Door では、正常性プローブを送信するための次の HTTP メソッドがサポートされています。
GET: GET メソッドでは、Request-URI によって特定された情報 (エンティティ形式) がすべて取得されます。
HEAD: HEAD メソッドは、サーバーからは応答でメッセージ本文を返すことが禁止されるという点を除き、GET と同じです。 バックエンドの負荷とコストをより低く抑えられるため、新しい Front Door プロファイルの場合、既定では、プローブ メソッドは HEAD と設定されます。
正常性プローブの応答
次の表で、正常性プローブへの応答について説明します。
| Response | 説明 |
|---|---|
| 正常性の特定 | 200 OK 状態コードは、バックエンドが正常であることを示します。 他のすべての状態コードは、エラーとみなされます。 (ネットワーク障害を含む) 何らかの理由で有効な HTTP 応答がプローブに対して受信されない場合、そのプローブはエラーとしてカウントされます。 |
| 待ち時間の測定 | 待ち時間は、プローブ要求が送信される直前から応答の最後のバイトが受信される瞬間までの実時間です。 要求ごとに新しい TCP 接続が使用されるため、この測定値が既存のウォーム接続のあるバックエンドに偏ることはありません。 |
Azure Front Door では、すべてのアルゴリズムで次の同じ 3 段階のプロセスを使用して、正常性を判定します。
無効なバックエンドを除外します。
正常性プローブ エラーが発生したバックエンドを除外します。
- この選択は、最後の n 個の正常性プローブ応答を調べることによって行われます。 少なくとも x 個以上が正常であれば、バックエンドは正常であると見なされます。
- n を構成するには、負荷分散の設定の SampleSize プロパティを変更します。
- x を構成するには、負荷分散の設定の SuccessfulSamplesRequired プロパティを変更します。
Front Door は、さらに、バックエンド プール内の正常なバックエンドのセットを対象に、各バックエンドの待ち時間 (ラウンドトリップ時間) を測定し、維持します。
バックエンド プールにバックエンドが 1 つある場合、正常性プローブを無効にし、アプリケーション バックエンドの負荷を減らすことができます。 バックエンド プールに複数のバックエンドがあるが、そのうちの 1 つだけが有効な状態にある場合でも、正常性プローブを無効にできます。
SSL を使用して Front Door をセキュリティで保護する
カスタム ドメイン (たとえば https://www.contoso.com) で HTTPS プロトコルを使用すると、インターネット経由での送信時に、機密データが TLS/SSL 暗号化によって確実にセキュリティ保護されて配信されます。 Web ブラウザーが HTTPS 経由で Web サイトに接続しているときに、Web サイトのセキュリティ証明書を検証し、正当な証明機関によって発行されていることを確認します。 このプロセスによりセキュリティを確保し、Web アプリケーションを攻撃から保護します。
カスタム HTTPS の機能の主な特性は次のとおりです。
- 追加コストなし: 証明書の取得または更新のコストや、HTTPS トラフィックの追加コストが発生しません。
- シンプルな有効化: Azure portal からワンクリックのプロビジョニングを利用できます。 REST API やその他の開発者ツールを使用して機能を有効にすることもできます。
- 証明書の完全な管理: すべての証明書の調達と管理がユーザーに代わって実施されます。 証明書は自動的にプロビジョニングされ、有効期限になる前に更新されます。これにより、証明書の期限切れによりサービスが中断されるリスクがなくなります。
フロントエンド ホスト セクションで、Front Door に関連付けられたカスタム ドメインに対して HTTPS プロトコルを有効にできます。
Front door で HTTPS を構成する方法の詳細については、「チュートリアル - Azure Front Door のカスタム ドメインで HTTPS を構成する | Microsoft Docs」を参照してください。