次の方法で共有

Azure Front Door でのキャッシュ

  • [アーティクル]

重要

Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。

Azure Front Door は最新のコンテンツ配信ネットワーク (CDN) であり、動的サイト アクセラレーションと負荷分散機能を備えています。 ルートでキャッシュが構成されている場合、各要求を受信したエッジ サイトは有効な応答があるかキャッシュを確認します。 キャッシュは、配信元サーバーに送信されるトラフィックの量を減らすのに役立ちます。 キャッシュされた応答に利用できるものがない場合、要求は配信元に転送されます。

各 Front Door エッジ サイトは独自のキャッシュを管理し、要求は異なるエッジ サイトによって処理される場合があります。 その結果、キャッシュされた応答を提供した場合でも、一部のトラフィックが配信元に到達する可能性があります。

キャッシュを使用すると、待機時間が大幅に短縮され、配信元サーバーの負荷が軽減されます。 ただし、すべての種類のトラフィックがキャッシュの利点を得られるわけではありません。 イメージ、CSS、JavaScript ファイルなどの静的アセットは、キャッシュに最適です。 認証された API エンドポイントなどの動的資産は、個人情報の漏洩を防ぐためにキャッシュしないでください。 静的資産と動的資産には別々のルートを使用し、後者の場合はキャッシュを無効にすることをお勧めします。

警告

キャッシュを有効にする前に、公開に関するドキュメントを十分に確認し、キャッシュを有効にする前に考えられるすべてのシナリオをテストしてください。 前に説明したように、構成ミスにより、複数のユーザーが共有できるユーザー固有のデータを誤ってキャッシュして、プライバシー インシデントが発生する可能性があります。

要求メソッド

GET 要求メソッドを使用する要求のみキャッシュ可能です。 その他のすべての要求メソッドは、常にネットワーク経由でプロキシ化されます。

大きなファイルの配信

Azure Front Door では、ファイル サイズの制限なしで、大きなファイルが配信されます。 キャッシュが有効になっている場合、Azure Front Door では、"オブジェクト チャンク" と呼ばれる方法が使用されます。 大きなファイルが要求されると、Front Door は配信元からファイルを分割して取得します。 完全なファイル要求またはバイト範囲を指定したファイル要求を受け取った後、Front Door 環境は、8 MB のチャンク単位で配信元にファイルを要求します。

Azure Front Door 環境に届いたチャンクはキャッシュされ、即座にユーザーに提供されます。 その後、Front Door は並列処理で次のチャンクをプリフェッチします。 このプリフェッチにより、コンテンツはチャンク 1 つ分だけ常にユーザーより先行することになるため、待ち時間が短縮されます。 このプロセスは、ファイル全体がダウンロードされるか (要求された場合)、クライアントが接続を閉じるまで続行されます。 バイト範囲の要求の詳細については、RFC 7233 を参照してください。

Front Door は受け取ったチャンクをそのままキャッシュするため、ファイル全体を Front Door キャッシュにキャッシュする必要はありません。 ファイルまたはバイト範囲に対する後続の要求に対しては、キャッシュの内容が提供されます。 チャンクがすべてキャッシュされていない場合は、プリフェッチを使用して配信元にチャンクが要求されます。

この最適化は、配信元サーバーのバイト範囲要求をサポートする配信元の能力に依存します。 配信元がバイト範囲要求をサポートしていない場合、または範囲要求を正しく処理しない場合、この最適化は効果的ではありません。

配信元が Range ヘッダーを使用して要求に応答する場合は、次のいずれかの方法で応答する必要があります。

  • 範囲指定された応答を返します。 応答では HTTP 状態コード 206 を使用する必要があります。 また、Content-Range 応答ヘッダーが存在する必要があり、配信元から返されるコンテンツの実際の長さと一致する必要があります。 配信元が有効な値を持つ正しい応答ヘッダーを送信しない場合、Azure Front Door は応答をキャッシュしないため、動作に一貫性がなくなる可能性があります。

    ヒント

    配信元が応答を圧縮する場合は、Content-Range ヘッダー値が圧縮された応答の実際の長さと一致していることを確認してください。

  • 範囲指定されていない応答を返します。 配信元が範囲要求を処理できない場合は、Range ヘッダーを無視して、範囲指定されていない応答を返すことができます。 配信元が 206 以外の応答状態コードを返していることを確認してください。 たとえば、配信元から 200 OK 応答が返される場合があります。

配信元がチャンク転送エンコード (CTE) を使用してデータを Azure Front Door POP に送信する場合、8 MB より大きい応答サイズはサポートされません。

ファイル圧縮

Azure Front Door でのファイル圧縮によるパフォーマンスの向上に関するページを参照してください。

Azure Front Door (クラシック) は、エッジのコンテンツを動的に圧縮できるため、クライアントへの応答時間が短く高速になります。 ファイルを圧縮できるようにするには、キャッシュを有効にする必要があり、ファイルは、圧縮できるように MIME の種類でなければなりません。 現在、Front Door (クラシック) ではこのリストは変更できません。 現在のリストは、次のとおりです。

  • "application/eot"
  • "application/font"
  • "application/font-sfnt"
  • "application/javascript"
  • "application/json"
  • "application/opentype"
  • "application/otf"
  • "application/pkcs7-mime"
  • "application/truetype"
  • "application/ttf",
  • "application/vnd.ms-fontobject"
  • "application/xhtml+xml"
  • "application/xml"
  • "application/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype"
  • "application/x-font-ttf"
  • "application/x-httpd-cgi"
  • "application/x-mpegurl"
  • "application/x-opentype"
  • "application/x-otf"
  • "application/x-perl"
  • "application/x-ttf"
  • "application/x-javascript"
  • "font/eot"
  • "font/ttf"
  • "font/otf"
  • "font/opentype"
  • "image/svg+xml"
  • "text/css"
  • "text/csv"
  • "text/html"
  • "text/javascript"
  • "text/js"、"text/plain"
  • "text/richtext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

また、ファイルのサイズは 1 KB 以上 8 MB 以下である必要があります。

これらのプロファイルでは、次の圧縮エンコードがサポートされています。

要求で gzip 圧縮と Brotli 圧縮がサポートされている場合は、Brotli 圧縮が優先されます。

アセットの要求で圧縮が指定され、その要求がキャッシュ ミスになった場合、Azure Front Door (クラシック) は POP サーバーで直接アセットを圧縮します。 その後、圧縮ファイルがキャッシュから提供されます。 結果として得られる項目は、Transfer-Encoding: chunked 応答ヘッダー付きで返されます。

配信元がチャンク転送エンコード (CTE) を使用してデータを Azure Front Door POP に送信する場合、圧縮はサポートされません。

Note

範囲の要求は、さまざまなサイズに圧縮される場合があります。 Azure Front Door では、どの GET HTTP 要求でも content-length 値を同じにする必要があります。 クライアントが Accept-Encoding ヘッダーを使用してバイト範囲要求を送信し、その結果、配信元からさまざまなコンテンツの長さで応答があった場合、Azure Front Door により 503 エラーが返されます。 配信元で圧縮を無効にするか、バイト範囲要求の要求から Accept-Encoding ヘッダーを削除するルール エンジン ルールを作成することができます。

クエリ文字列の動作

Azure Front Door を使用すると、クエリ文字列を含む Web 要求のためにファイルをキャッシュする方法を制御できます。

クエリ文字列を含む Web 要求で、クエリ文字列は要求の疑問符 (?) の後に指定されます。 クエリ文字列には、フィールド名とその値を等号 (=) で区切って指定される、キーと値のペア (複数可) を含めることができます。 キーと値のペアはそれぞれ、アンパサンド (&) で区切られます。

たとえば、URL http://www.contoso.com/content.mov?field1=value1&field2=value2 には次の 2 つのクエリ文字列が含まれています。

  • field1 (値 value1)。
  • field2 (値 value2)。

要求のクエリ文字列にキーと値のペアを複数指定する場合、どのような順序で指定してもかまいません。

キャッシュを構成するときは、クエリ文字列をキャッシュがどのように処理するかを指定します。 次の動作がサポートされています。

  • [クエリ文字列を無視する]: このモードでは、Azure Front Door はクライアントからのクエリ文字列を最初の要求時に配信元に渡して、アセットをキャッシュします。 Front Door 環境から提供されるアセットに対する今後の要求では、キャッシュされたアセットの有効期限が切れるまで、クエリ文字列が無視されます。

  • [クエリ文字列を使用する]: このモードでは、クエリ文字列を含む一意の URL が指定された各要求は、独自のキャッシュがある一意の資産として扱われます。 たとえば、www.example.ashx?q=test1 の要求に対する配信元からの応答は Front Door 環境にキャッシュされ、同じクエリ文字列を持つ後続のキャッシュに対して返されます。 www.example.ashx?q=test2 の要求は、独自の有効期限設定を持つ個別の資産としてキャッシュされます。

    クエリ文字列パラメーターの順序は関係ありません。 たとえば、Azure Front Door 環境に www.example.ashx?q=test1&r=test2 という URL に対するキャッシュされた応答が含まれている場合、www.example.ashx?r=test2&q=test1 に対する要求もキャッシュから提供されます。

  • [指定したクエリ文字列を無視する] および [指定したクエリ文字列を含める]: このモードでは、キャッシュ キーの生成時に指定したパラメーターを含めるか除外するように Azure Front Door を構成できます。

    たとえば、既定のキャッシュ キーが /foo/image/asset.html で、URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200 に対して要求が行われたとします。 userid クエリ文字列パラメーターを除外するルール エンジンルールがある場合、クエリ文字列キャッシュ キーは /foo/image/asset.html?language=EN&sessionid=200 になります。

Front Door のルートでクエリ文字列の動作を構成します。

キャッシュの消去

キャッシュの消去を構成する方法については、「Azure Front Door でキャッシュを消去する」を参照してください。

Azure Front Door は、アセットの Time-to-Live (TTL) が期限切れになるまで、そのアセットをキャッシュします。 クライアントが TTL の期限が切れたアセットを要求すると、Front Door 環境はアセットの更新された最新コピーを取得し、要求に対応して、更新されたキャッシュを格納します。

ユーザーが常にアセットの最新コピーを取得するのを確実にするベスト プラクティスは、更新ごとにアセットにバージョンを付け、新しい URL として発行することです。 Front Door では、次のクライアント要求のための新しいアセットが直ちに取得されます。 必要に応じて、すべてのエッジ ノードのキャッシュされたコンテンツを消去し、すべてのエッジ ノードが新しい更新されたアセットを取得するように強制することもできます。 そうする理由に、Web アプリケーションの更新に対応する場合や、正しくない情報を含むアセットをすばやく更新する場合があります。

キャッシュの消去ボタンとページのスクリーンショット。

エッジ ノードから消去するアセットを選択します。 すべてのアセットをクリアするには、 [Purge all](すべて消去) を選択します。 それ以外の場合は、 [パス] で、消去する各アセットのパスを入力します。

消去するパスの一覧では、次の形式がサポートされています。

  • 1 つのパスの消去: (プロトコルとドメインを除く) アセットの完全なパスをファイル拡張子と共に指定して、個々のアセットを消去します (例: /pictures/strasbourg.png)。
  • ワイルドカードによる消去: アスタリスク (*) をワイルドカードとして使用できます。 パスに /* を付けてエンドポイントの下にあるすべてのフォルダー、サブフォルダー、ファイルを消去するか、フォルダーに続けて /* を指定して (例: /pictures/*)、特定のフォルダーの下にあるすべてのサブフォルダーとファイルを消去します。
  • ルート ドメインの消去: パスに "/" を付けてエンドポイントのルートを削除します。

注意

ワイルドカード ドメインの消去:このセクションで説明するように、消去用にキャッシュされたパスを指定することは、Front Door に関連付けられているワイルドカード ドメインには適用されません。 現在、ワイルドカード ドメインを直接消去することはサポートされていません。 特定のサブドメインからパスを消去するには、その特定のサブドメインと消去するパスを指定します。 たとえば、Front Door に *.contoso.com が付いている場合、サブドメイン foo.contoso.com のアセットを削除するには、「foo.contoso.com/path/*」と入力します。 現在のところ、コンテンツ パスの消去でのホスト名の指定は、ワイルドカード ドメインのサブドメイン (該当する場合) に限定されています。

Front Door でのキャッシュの消去では、大文字と小文字が区別されます。 また、クエリ文字列に依存しません。つまり、URL を消去すると、そのすべてのクエリ文字列バリエーションが消去されます。

キャッシュの有効期限

キャッシュに項目が格納される期間を判断するために、次のヘッダーの順序が使用されます。

  1. Cache-Control: s-maxage=<seconds>
  2. Cache-Control: max-age=<seconds>
  3. Expires: <http-date>

一部の Cache-Control 応答ヘッダー値は、応答がキャッシュできないことを示します。 これらの値には、private、no-cache、no-store が含まれます。 ルール エンジンを使用してキャッシュ動作をオーバーライドした場合でも、Front Door はこれらのヘッダー値を受け入れ、応答をキャッシュしません。

Cache-Control ヘッダーが配信元からの応答に存在しない場合、既定では、Front Door は 1 日から 3 日間のキャッシュ期間をランダムに決定します。

注意

キャッシュの有効期限を 366 日より長くすることはできません。

Cache-Control 応答ヘッダーに REVALIDATED_HIT が表示される場合があります。 これは、クライアントに提供される前に、Azure Front Door のキャッシュされたコンテンツが配信元サーバーで再検証されたことを示します。 これは、キャッシュされたコンテンツの有効期限が切れているが、コンテンツが変更されていないことを配信元サーバーが示している場合に発生する可能性があります。 この場合、キャッシュされたコンテンツがクライアントに提供され、キャッシュの有効期限がリセットされます。

要求ヘッダー

キャッシュが有効になっている場合、次の要求ヘッダーは配信元に転送されません。

  • Content-Length
  • Transfer-Encoding
  • Accept
  • Accept-Charset
  • Accept-Language

Note

応答にキャッシュを許可する Cache-Control ディレクティブが含まれていない限り、Authorization ヘッダーを含む要求はキャッシュされません。 Cache-Control ディレクティブの must-revalidate、public、s-maxage には、この効果があります。

応答ヘッダー

配信元の応答がキャッシュ可能な場合、応答がクライアントに送信される前に Set-Cookie ヘッダーが削除されます。 配信元の応答がキャッシュ可能でない場合、Front Door はヘッダーを削除しません。 たとえば、配信元の応答に max-age 値を持つ Cache-Control ヘッダーが含まれている場合、これは Front Door に応答がキャッシュ可能であることを示し、Set-Cookie ヘッダーは削除されます。

さらに、Front Door は X-Cache ヘッダーをすべての応答に追加します。 X-Cache 応答ヘッダーには、次のいずれかの値が含まれます。

  • TCP_HIT または TCP_REMOTE_HIT: 応答の最初の 8 MB のチャンクはキャッシュ ヒットであり、コンテンツは Front Door キャッシュから提供されます。
  • TCP_MISS: 応答の最初の 8 MB のチャンクはキャッシュ ミスであり、コンテンツは配信元からフェッチされます。
  • PRIVATE_NOSTORE: Cache-Control 応答ヘッダーが private または no-store のいずれかに設定されているため、要求をキャッシュできません。
  • CONFIG_NOCACHE: 要求は Front Door プロファイルでキャッシュなしに構成されています。

ログとレポート

アクセス ログには、要求ごとのキャッシュ状態が含まれています。 また、レポートには、Azure Front Door のキャッシュがアプリケーションでどのように使用されるかに関する情報が含まれています。

アクセス ログには、要求ごとのキャッシュ状態が含まれています。

キャッシュの動作と期間

キャッシュの動作と期間は、ルール エンジンで構成できます。 ルール エンジンのキャッシュ構成により、ルート構成は常にオーバーライドされます。

  • キャッシュが無効になっている場合、Azure Front Door は、配信元の応答ディレクティブに関係なく、応答コンテンツをキャッシュしません。

  • キャッシュが有効になっている場合、キャッシュのビヘイビアーは、ルール エンジンによって適用されるキャッシュ ビヘイビアー値に従って以下のように異なります。

    • 配信元を優先: Azure Front Door は常に配信元の応答ヘッダー ディレクティブを優先します。 配信元のディレクティブがない場合、Azure Front Door は、1 日から 3 日の間、任意の場所でコンテンツをキャッシュします。
    • [Override always] (常にオーバーライド): Azure Front Door は、常にキャッシュ期間でオーバーライドします。つまり、配信元の応答ディレクティブの値を無視して、キャッシュ期間中、コンテンツをキャッシュします。 この動作は、応答がキャッシュ可能な場合にのみ適用されます。
    • [Override if origin missing] (配信元が見つからない場合にオーバーライド): 配信元がキャッシュの TTL 値を返さない場合、Azure Front Door は指定されたキャッシュ期間を使用します。 この動作は、応答がキャッシュ可能な場合にのみ適用されます。

Note

  • Azure Front Door では、コンテンツがキャッシュに格納される期間については保証されません。 コンテンツが頻繁に使用されない場合、キャッシュされたコンテンツは、コンテンツの有効期間の前にエッジ キャッシュから削除される可能性があります。 Front Door では、キャッシュされたデータの有効期限が切れていても、キャッシュからデータを提供できる場合があります。 この動作は、発信元がオフラインのときにサイトの一部を引き続き使用できる状態にする助けになります。
  • 配信元は、値が no-cache、private、または no-store の Cache-Control ヘッダーを使用して、特定の応答をキャッシュしないように指定できます。 配信元サーバーから Azure Front Door POP への HTTP 応答で使われるときは、Azure Front Door は Cache-Control ディレクティブをサポートし、RFC 7234 - ハイパーテキスト転送プロトコル (HTTP/1.1): キャッシュ (ietf.org) で示されている Cache-Control ディレクティブのキャッシュ動作を尊重します。

キャッシュの動作と期間は、Front Door デザイナー ルーティング規則とルール エンジンの両方で構成できます。 ルール エンジンのキャッシュ構成は、常に Front Door デザイナー ルーティング規則の構成をオーバーライドします。

  • キャッシュが無効になっている場合、Azure Front Door (クラシック) は、配信元の応答ディレクティブに関係なく、応答コンテンツをキャッシュしません。

  • キャッシュが有効になっている場合、キャッシュの動作は、[キャッシュの既定の期間を使用する] の値によって異なります。

    • [キャッシュの既定の期間を使用する] が [はい] に設定されている場合、Azure Front Door (クラシック) は、配信元の応答ヘッダー ディレクティブを常に優先します。 配信元のディレクティブがない場合、Front Door は、1 日から 3 日の間、任意の場所でコンテンツをキャッシュします。
    • [キャッシュの既定の期間を使用する] が [いいえ] に設定されている場合、Azure Front Door (クラシック) は、常に "キャッシュ期間" (必須フィールド) でオーバーライドします。つまり、配信元の応答ディレクティブの値を無視して、キャッシュ期間中、コンテンツをキャッシュします。

Note

  • Azure Front Door (クラシック) では、コンテンツがキャッシュに格納される期間については保証されません。 コンテンツが頻繁に使用されない場合、キャッシュされたコンテンツは、コンテンツの有効期間の前にエッジ キャッシュから削除される可能性があります。 Azure Front Door (クラシック) では、キャッシュされたデータの有効期限が切れていても、キャッシュからデータを提供できる場合があります。 この動作は、発信元がオフラインのときにサイトの一部を引き続き使用できる状態にする助けになります。
  • Front Door デザイナー ルーティング規則で設定される "キャッシュ期間" は最小キャッシュ期間です。 配信元のキャッシュ制御ヘッダーの TTL がオーバーライド値より大きい場合、このオーバーライドは機能しません。

次のステップ