次の方法で共有

キャッシュのしくみ

  • [アーティクル]

重要

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 年 1 月 15 日に廃止されました。 詳細については、「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 に優先します (両方が定義されている場合)。

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

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 プロファイルによって無視されます。
  • 配信元サーバーからコンテンツ配信ネットワーク POP への HTTP 応答で使用される場合は、すべての Azure Content Delivery Network プロファイルで、既定で Cache-Control が優先されます。 また、Azure CDN でも、RFC 7234 - ハイパーテキスト転送プロトコル (HTTP/1.1): キャッシュ (ietf.org) の Cache-Control ディレクティブのキャッシュ動作が優先されます。

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 from Microsoft は、Last-Modified のみサポートしています。

Note

Microsoft Azure CDN (クラシック) は、ETag をサポートしていません。

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 応答で配信されるリソースで、これらの条件のすべてを満たしていないものは、キャッシュできません。

条件 値
HTTP 状態コード 200、203、206、300、301、410、416
HTTP メソッド GET、HEAD
ファイル サイズ制限 300 GB

キャッシュがリソースに対して機能するには、配信元サーバーがすべての HEAD 要求と GET HTTP 要求をサポートしている必要があり、content-length 値が資産のすべての HEAD 応答と GET HTTP 応答で同じである必要があります。 HEAD 要求の場合、配信元サーバーが HEAD 要求をサポートしている必要があり、GET 要求を受信したかのように、同じヘッダーで応答する必要があります。

Note

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

既定のキャッシュ動作

Azure CDN での既定のキャッシュ動作は、[配信元を優先] であり、コンテンツを 2 日間キャッシュします。

配信元を優先: この設定では、キャッシュ ディレクティブ ヘッダー (Cache-Control または Expires) を優先するかどうかを指定します (配信元サーバーからの HTTP 応答内に存在している場合)。

CDN キャッシュ期間: この設定では、Azure CDN でリソースをキャッシュする期間を指定します。 [配信元を優先] が有効になっており、配信元サーバーからの HTTP 応答に Cache-Control: max-age ヘッダーまたは Expires ヘッダーが含まれている場合、Azure CDN では、既定の 2 日間ではなく、これらのヘッダーで指定されている期間を使用します。

Note

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

次のステップ