次の方法で共有

キャッシュのしくみ

  • [アーティクル]

重要

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

Azure CDN from Edgio は、2025 年 11 月 4 日に廃止される予定です。 サービスの中断を回避するには、この日までに Azure Front Door へのワークロードの移行を完了する必要があります。 詳細については、「Azure CDN from Edgio の廃止に関する FAQ」を参照してください。

この記事では、キャッシュの全般的概念の概要と、Azure Content Delivery Network がキャッシュを使用してパフォーマンスを向上させるしくみについて説明します。 Content Delivery Network エンドポイントでのキャッシュの動作をカスタマイズする方法については、「Azure Content Delivery Network のキャッシュ動作をキャッシュ規則で制御する」および「クエリ文字列による Azure コンテンツ配信ネットワーク キャッシュ動作の制御」をご覧ください。

キャッシュの概要

キャッシュは、後でデータに対する要求があった場合により迅速にアクセスできるように、そのデータをローカルに保存するプロセスです。 キャッシュの種類として最も一般的な Web ブラウザー キャッシュでは、Web ブラウザーによって、静的なデータのコピーがローカルのハード ドライブに格納されます。 キャッシュを使用すると、Web ブラウザーは、サーバーとのラウンド トリップを何回も行わずに済みます。代わりに、ローカルで同じデータにアクセスすることで、時間とリソースを節約できます。 キャッシュは、静的なイメージ、CSS ファイル、JavaScript ファイルなど、小さな静的データをローカルで管理するのに適しています。

同様に、ユーザーに近いエッジ サーバー上のコンテンツ配信ネットワークによって使用されるキャッシュでは、要求が配信元に戻らないようにして、エンドユーザーの待機時間を短縮します。 1 人のユーザーを対象とした Web ブラウザーのキャッシュとは異なり、Content Delivery Network には共有キャッシュがあります。 Content Delivery Network 共有キャッシュでは、あるユーザーによるファイル要求を別のユーザーが使用できるため、配信元サーバーへの要求の数が大幅に少なくなります。

頻繁に変更される動的リソースや、個々のユーザーに固有の動的リソースをキャッシュすることはできません。 ただし、このような種類のリソースは、パフォーマンスを向上させるために、Azure Content Delivery Network で動的サイトの高速化 (DSA) による最適化を利用できます。

キャッシュは、配信元サーバーとエンド ユーザーの間の複数のレベルで発生します。

  • Web サーバー:共有キャッシュを使用します (複数のユーザーが対象)。
  • コンテンツ配信ネットワーク:共有キャッシュを使用します (複数のユーザーが対象)。
  • インターネット サービス プロバイダー (ISP):共有キャッシュを使用します (複数のユーザーが対象)。
  • Web ブラウザー:プライベート キャッシュを使用します (1 人のユーザーが対象)。

通常、各キャッシュが独自のリソース更新間隔を管理し、ファイルが古くなったときに検証を実行します。 この動作は、HTTP のキャッシュの仕様 RFC 7234 で定義されています。

リソースの更新間隔

キャッシュされたリソースは、(配信元サーバーの対応するリソースと比べて) 古くなっている可能性があるため、コンテンツを最新の情報に更新するタイミングの制御は、すべてのキャッシュ メカニズムにとって重要です。 キャッシュされたリソースは、アクセスされるたびに配信元サーバー上のバージョンと比較されるわけではなく、これにより時間と帯域幅の消費が節約されます。 代わりに、キャッシュされたリソースが新しいと見なされている間、それは最新バージョンであると見なされ、クライアントに直接送信されます。 キャッシュされたリソースは、その経過日数が、キャッシュ設定によって定義された経過日数や期間を下回る場合に新鮮であると見なされます。 たとえば、ブラウザーは、Web ページを再度読み込むとき、ハード ドライブ上のキャッシュされた各リソースが新鮮であることを確認したうえで、読み込みます。 リソースが新鮮でない (古くなっている) 場合は、最新のコピーがサーバーから読み込まれます。

検証

リソースが古くなっていると見なされると、配信元サーバーは、そのリソースを検証するように、つまりキャッシュ内のデータが、配信元サーバー上のものとまだ一致しているかどうかを確認するように求められます。 配信元サーバーのファイルが変更されていると、キャッシュは、そのバージョンのリソースを更新します。 それ以外の場合、つまりリソースが新鮮なときは、データは先に検証されることなく、キャッシュから直接配信されます。

Content Delivery Network キャッシュ

イメージ、フォント、ビデオなどの静的アセットの配信を高速化し、配信元の負荷を軽減する Content Delivery Network のしくみにとって、キャッシュは不可欠です。 Content Delivery Network キャッシュでは、静的リソースが、ユーザーのより近い場所に戦略的に配置されたサーバーに選択的に保存されます。これには、次の利点があります。

  • Web トラフィックのほとんどが静的であるため (イメージ、フォント、ビデオなど)、Content Delivery Network キャッシュでは、ユーザーの近くにコンテンツを移動し、データの移動距離を短くすることで、ネットワークの待ち時間を短縮します。

  • Content Delivery Network に作業をオフロードすることで、キャッシュを通じて、ネットワーク トラフィックと配信元サーバーの負荷を削減できます。 これにより、ユーザー数が多くても、アプリケーションのコストとリソース要件が軽減されます。

Web ブラウザーでキャッシュを実装する方法と同様、キャッシュ ディレクティブ ヘッダーを送信することによって Content Delivery Network でのキャッシュの実行方法を制御できます。 キャッシュ ディレクティブ ヘッダーは HTTP ヘッダーであり、通常は、配信元サーバーによって追加されます。 元来、こうしたヘッダーのほとんどはクライアント ブラウザーでのキャッシュに対応するためのものでしたが、現在は Content Delivery Network などのすべての中間キャッシュでも使用されます。

2 つのヘッダー (Cache-Control と Expires) を使用して、キャッシュの更新間隔を定義できます。 Cache-Control が最新で、Expires に優先します (両方が存在する場合)。 検証に使用されるヘッダーの種類も 2 つあります (検証コントロールと呼ばれます)。これは、ETag と Last-Modified です。 ETag が最新で、Last-Modified に優先します (両方が定義されている場合)。

キャッシュ ディレクティブ ヘッダー

重要

既定では、DSA 用に最適化された Azure Content Delivery Network エンドポイントは、キャッシュ ディレクティブ ヘッダーを無視し、キャッシュをバイパスします。 Azure CDN Standard from Edgio プロファイルの場合、Content Delivery Network キャッシュ規則を使ってキャッシュを有効にすることで、Azure Content Delivery Network エンドポイントがこれらのヘッダーを処理する方法を調整できます。 Azure CDN Premium from Edgio プロファイルの場合のみ、ルール エンジンを使ってキャッシュを有効にします。

Azure Content Delivery Network では、次の HTTP キャッシュ ディレクティブ ヘッダーがサポートされます。こうしたヘッダーを使用して、キャッシュ期間やキャッシュ共有を定義します。

Cache-Control:

  • HTTP 1.1 で導入されました。Web 発行元がコンテンツを詳細に制御できるようにします。また、Expires ヘッダーの制限に対処します。
  • Expires ヘッダーをオーバーライドします (これと Cache-Control の両方が定義されている場合)。
  • クライアントから Content Delivery Network POP への HTTP 要求で Cache-Control を使用すると、既定ですべての Azure Content Delivery Network プロファイルによって無視されます。
  • 配信元サーバーから Content Delivery Network POP への HTTP 応答で使用された場合は、次のようになります。

Expires:

  • HTTP 1.0 で導入されたレガシ ヘッダー。下位互換性のためにサポートされています。
  • 日付ベースの期限切れ日時 (秒単位) を使用します。
  • Cache-Control: max-age に似ています。
  • Cache-Control が存在しない場合に使用されます。

Pragma:

  • 既定では、Azure Content Delivery Network では受け入れられません。
  • HTTP 1.0 で導入されたレガシ ヘッダー。下位互換性のためにサポートされています。
  • no-cache ディレクティブを含むクライアント要求ヘッダーとして使用されます。 このディレクティブは、最新バージョンのリソースを配信するようにサーバーに指示します。
  • Pragma: no-cache は Cache-Control: no-cache に相当します。

検証コントロール

キャッシュが古い場合は、HTTP キャッシュ検証コントロールを使用して、キャッシュされたバージョンのファイルと、配信元サーバーのバージョンが比較されます。 Azure CDN Standard/Premium from Edgio は、既定で ETag と Last-Modified の両方の検証コントロールをサポートしますが、Azure CDN Standard from Microsoft は Last-Modified のみをサポートします。

ETag:

  • Azure CDN Standard/Premium from Edgio は既定で ETag をサポートしますが、Azure CDN Standard from Microsoft ではサポートされません。
  • ETag は、すべてのファイルとファイルのバージョンに対して一意の文字列を定義します。 たとえば、「 ETag: "17f0ddd99ed5bbe4edffdd6496d7131f" 」のように入力します。
  • HTTP 1.1 で導入され、Last-Modified よりも新しいものです。 最終更新日を判断するのが難しいときに便利です。
  • 強い検証と弱い検証の両方をサポートしますが、Azure Content Delivery Network では、強い検証のみがサポートされます。 強い検証では、2 つのリソース表現がバイト単位で同一である必要があります。
  • キャッシュは、要求で 1 つ以上の ETag 検証コントロールを含む If-None-Match ヘッダーを送信することで、ETag が使用されているファイルを検証します。 たとえば、If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f" のようにします。 サーバーのバージョンが一覧の ETag 検証コントロールと一致する場合、応答で状態コード 304 (変更なし) が送信されます。 バージョンが異なる場合、サーバーは、状態コード 200 (OK) と、更新されたリソースで応答します。

Last-Modified:

  • Azure CDN Standard/Premium from Edgio でのみ、ETag が HTTP 応答に含まれない場合に、Last-Modified が使用されます。
  • リソースが最後に更新されたことが配信元サーバーによって確認された日時を指定します。 たとえば、Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT のようにします。
  • 8 MB を超えるコンテンツの場合、配信元バックエンド サーバーはアセットごとに一貫した Last-Modified タイムスタンプを維持する必要があります。 バックエンド サーバーから一貫性のない Last-Modified 時間を返すと、検証コントロールの不一致エラーが発生し、HTTP 5XX エラーが発生します。 Azure Storage では、レプリカ間で一貫性のある Last-Modified タイムスタンプがサポートされない場合があり、これにより同様の検証コントロールの不一致エラーが発生する可能性があります。
  • キャッシュは、要求で日時を含む If-Modified-Since ヘッダーを送信することで、Last-Modified が使用されているファイルを検証します。 配信元サーバーは、その日付と、最新リソースの Last-Modified ヘッダーを比較します。 指定した時刻以降にリソースが変更されていない場合、サーバーは、応答で状態コード 304 (変更なし) を返します。 リソースが変更されている場合、サーバーは、状態コード 200 (OK) と、更新されたリソースを返します。

キャッシュできるファイルの確認

すべてのリソースをキャッシュできるわけではありません。 次の表は、HTTP 応答の種類に基づいて、どのリソースをキャッシュできるかを示しています。 HTTP 応答で配信されるリソースで、これらの条件のすべてを満たしていないものは、キャッシュできません。 Azure CDN Premium from Edgio でのみ、ルール エンジンを使って、これらの条件の一部をカスタマイズできます。

Azure Content Delivery Network from Microsoft Azure Content Delivery Network from Edgio
HTTP 状態コード 200、203、206、300、301、410、416 200
HTTP メソッド GET、HEAD GET
ファイル サイズ制限 300 GB 300 GB

Microsoft Azure CDN Standard キャッシュをリソースに対して機能させるには、元のサーバーで、すべての HEAD および GET HTTP 要求をサポートしている必要があり、コンテンツ長の値は、アセットのすべての HEAD および GET HTTP 応答で同じである必要があります。 HEAD 要求の場合、配信元サーバーが HEAD 要求をサポートしている必要があり、GET 要求を受信したかのように、同じヘッダーで応答する必要があります。

Note

Authorization ヘッダーを含む要求はキャッシュされません。

既定のキャッシュ動作

次の表では、Azure Content Delivery Network 製品の既定のキャッシュ動作とその最適化について説明します。

Microsoft:一般的な Web 配信 Edgio: 一般的な Web 配信 Edgio: DSA
配信元を優先 はい はい いいえ
Content Delivery Network キャッシュ期間 2 日間 7 日間 なし

配信元を優先:サポートされているキャッシュ ディレクティブ ヘッダーを優先するかどうかを指定します (配信元サーバーからの HTTP 応答にそれらのヘッダーが存在する場合)。

CDN キャッシュ期間: Azure Content Delivery Network でリソースをキャッシュする期間を指定します。 ただし、配信元を優先が "はい" で、配信元サーバーからの HTTP 応答にキャッシュ ディレクティブ ヘッダー Expires または Cache-Control: max-age が含まれている場合、Azure Content Delivery Network は、ヘッダーによって指定された期間の値を代わりに使用します。

Note

Azure Content Delivery Network では、オブジェクトがキャッシュに格納される最小時間については保証されません。 キャッシュされたコンテンツは、より頻繁に要求されるコンテンツの領域を確保するために、それほど頻繁に要求されない場合、期限切れになる前に、Content Delivery Network キャッシュから削除される可能性があります。

次のステップ