CDN とキャッシュの仕組み

Fastly は、コンテンツ配信ネットワーク (CDN) です。一度生成されたコンテンツはしばらくの間、再度生成される必要がないという原則に基づき、CDN はキャッシュにコピーを保存しておくことができます。キャッシュマシンは、小さなリソースを非常に高速に配信するように最適化されています。CDN は通常、世界各地のデータセンターにキャッシュを設置しています。エンドユーザーがサイトにリクエストを送信すると、リクエストはオリジンサーバーではなく、ユーザーに最も近いキャッシュサーバーににリダイレクトされています。これにより、ヨーロッパのユーザーがアメリカのサイトからコンテンツを取得する場合、200ミリから500ミリ秒程度早くコンテンツを取得できることになります。また、CDN はキャッシュミスの影響を最小限に抑えるように設計されています。キャッシュミスは、ユーザーがコンテンツをリクエストした際に、キャッシュサーバー上にキャッシュが存在しない場合に発生します。これは有効期限が切れていた、過去に一度もそのコンテンツがリクエストされていない、キャッシュスペースがいっぱいになって古いキャッシュコンテンツが削除された場合などに発生します。

キャッシュ可能なコンテンツ

CDN は、小規模で静的なリソース (静的なイメージ、CSS ファイル、Javascript、アニメーション GIF など) のキャッシュを管理するのに適しています。また、ビデオやオーディオメディアなどの配信に負荷のかかるファイルをオフロードするためにもよく利用されます。

Fastly の (_リバースプロキシ_とも呼ばれる) アーキテクチャは、静的なコンテンツだけではなく、お客様が一歩進んでウェブページ全体をキャッシュできるように設計されており、トラフィックをさらに効率的に処理します。

キャッシュの管理

キャッシングはサイトを高速に配信するための強力な武器となります。ただし、キャッシュ内のオブジェクトが永続的にそこに留まるわけではありません。新しいコンテンツを配信できるように期限切れにする必要があります。そのコンテンツがキャッシュに留まるべき期間はほんの数秒、または数分、1年以上かもしれません。

どのコンテンツが、どこで、どのくらいの期間キャッシュされるのかを管理するにはどうしたらよいでしょうか ?そのためには、キャッシュされたデータを制御するポリシーを設定します。ほとんどのキャッシュポリシーは、Web サーバーがコンテンツとともに送信する HTTP ヘッダーのセットとして実装されます (設定またはアプリケーションで指定されます)。これらのヘッダーはクライアント (ブラウザ) を考慮して設計されていますが、 Fastly のような CDN もこれらのヘッダーをキャッシュポリシーのガイドとして使用します。

Expires

Expiresヘッダーは、コンテンツをキャッシュ (通常はブラウザのキャッシュ) する時間を伝えるキャッシュ関連の HTTP ヘッダーです。その後、ブラウザはソースからコンテンツを再要求します。このヘッダーの欠点はそれが静的な日付であるため、サーバー側で更新を行わなかった場合、指定された日時を過ぎるとブラウザは毎回リクエストを送信することになります。

Fastly は、Surrogate-ControlまたはCache-Controlヘッダーがリクエストに見つからない場合にのみ、Expiresヘッダー値を尊重します。

Cache-Control ヘッダー

HTTP/1.1 の仕様で導入された Cache-Control ヘッダーは、ブラウザのキャッシュをカバーしており、ほとんどの場合、中間キャッシュもカバーしています。

  • Cache-Control: public - どのキャッシュもコンテンツのコピーを保存できます。
  • Cache-Control: private - 単一のユーザーのためのものなので、保存してはいけません。
  • Cache-Control: no-cache - このコンテンツを配信する前に再確認してください。
  • Cache-Control: no-store - このコンテンツは絶対に保存しないでください。
  • Cache-Control: public, max-age=[seconds] - キャッシュはこのコンテンツを n 秒間保存することができます。
  • Cache-Control: s-maxage=[seconds] - max-age と同じですが、特にプロキシのキャッシュに適用されます。

max-ages-maxage そして private Cache-Control ヘッダーのみが Fastly のキャッシングに影響を与えます。他のすべての Cache-Control ヘッダーはキャッシュに影響は与えずに、そのままブラウザに渡されます。Fastly がこれらの Cache-Control ヘッダーにどのようにレスポンスを行うか、またこれらのヘッダーが Expires や Surrogate-Control とどのように相互作用するかについての詳細な情報は、キャッシュの鮮度に関するドキュメントをご覧ください。

サロゲートヘッダー

Surrogateヘッダーは、比較的新しくキャッシュ管理のためのヘッダーとして追加されました。詳細は W3C テクニカルノートに記載されています。これらのヘッダーは、 処理パス内にあるプロキシキャッシュに対して特定のキャッシュポリシーを提供します。Surrogate-Control は、Cache-Controlと同じ値の多く、そしてさらに難解な値も受け入れることができます(すべてのオプションについては、テクニカルノートをご参照ください)。

この技術の1つの用途は、ブラウザに保守的なキャッシュの相互作用を提供することです (Cache-Control: no-cache など)。これによって、ブラウザはコンテンツが必要になる度に、コンテンツが更新されていないか再度確認を行います。これにより、ユーザーには常に最新のコンテンツが表示されます。‎同時に Surrogate-Control ヘッダーに長い max-age を設定することで、オリジンソースの前にあるプロキシキャッシュがブラウザからのトラフィックのほとんどを処理し、プロキシのキャッシュが期限切れになった場合にのみオリジンソースにコンテンツをリクエストします。

Fastly では、最も便利な Surrogateヘッダーの一つが Surrogate-Key です。Fastly がリクエストを処理中に Surrogate-Key  ヘッダーを見つけると、スペースで区切られた値をタグのリストとして使用し、キャッシュ内のリクエスト URL に関連付けます。Fastly の Purge APIと組み合わせることで、URL のコレクション全体を1回の API コールでキャッシュから削除することができますSurrogate-Control(通常は約1ミリ秒程度で実行されます)。

Fastly と Cache Control ヘッダー

Fastly は、キャッシュの鮮度に関するドキュメントで説明されているように、これらの各ヘッダーでキャッシュ情報を探します。優先順位は次のとおりです。

  • Surrogate-Control:
  • Cache-Control: s-maxage
  • Cache-Control: max-age
  • Expires:

デフォルトでキャッシュされる HTTP ステータスコード

Fastly は、以下のレスポンスステータスコードをデフォルトでキャッシュします。これらのステータスに加えて、条件およびレスポンスを使用して、他のステータス下のオブジェクトをキャッシュさせることができます。

コード メッセージ
200 OK
203 信頼できない情報
300 複数の選択
301 恒久的に移動した
302 一時的に移動した
404 未検出
410 消滅した

上記以外のステータスコードをキャッシュするには、vcl_fetch にて beresp.cacheable = true; を設定します。それによって、バックエンドの HTTP キャッシュヘッダーやその他のカスタム ttl ロジックに従うように Varnish に伝達します。一般的なパターンでは、以下のように 2XX レスポンスをすべてキャッシュ可能にできるようにします。

1
2
3
4
5
6
7
sub vcl_fetch {
  # ...
  if (beresp.status >= 200 && beresp.status < 300) {
    set beresp.cacheable = true;
  }
  # ...
}

オリジンシールド

キャッシュしたオブジェクトに設定された有効期限が経過した後に、それらのオブジェクトに対して次のリクエストを受けると、そのリクエストはオリジンサーバーに送られます。正しくキャッシュ設定が行われている場合、この処理で問題は発生しません。ただし、人気のあるオブジェクトが一斉にキャッシュ期限切れになると、キャッシュノードがオリジンからオブジェクトを再取得するために、バックエンドに大量のトラフィックが流入する可能性があります。

ほとんどの場合、取得されるオブジェクトはリクエスト間で異なることはありませんが、なぜすべてのキャッシュノードがバックエンドから独自のコピーを取得しなければならないのでしょうか?シールドノードがあれば、その必要はありません。オリジンシールドの設定は、Fastly のコントロールパネルから、特定のデータセンター (オリジンアプリケーションに地理的に近いものが最も有効) を指定することで行います。キャッシュ内のオブジェクトが期限切れになった場合、シールドノードがオリジンのアプリケーションからコンテンツを取得する唯一のノードになります。他のすべてのキャッシュノードはシールドノードからオブジェクトを取得するため、オリジンでのトラフィックが大幅に削減されます。

リソース

Back to Top