キャッシュ設定のベストプラクティス

需要の増加や計画的なサーバーメンテナンス時でもオリジンサーバーのパフォーマンスを維持するための、サービスのキャッシュ設定のベストプラクティスをご紹介します。

アプリケーションプラットフォームと Fastly の統合

ご利用のアプリケーションプラットフォームの設定をカスタマイズすることで、Fastly のキャッシュを最適化することができます。手順については、サードパーティサービスの統合Web サーバーソフトウェアの設定に関するドキュメントをご覧ください。また、Fastly とコンテンツ管理システムを直接統合するための各種プラグインもご用意しています。

キャッシュヒット率の確認

キャッシュサーバーによって配信されたリクエスト数をキャッシュ可能なリクエスト数 (ヒット+ミス) で割り算した値を「キャッシュヒット率」と呼びます。キャッシュヒット率が高いということは、リクエストトラフィックによる無駄なオリジンサーバーへのヒットを防ぎ、代わりに、リクエストはキャッシュから配信できていることになります。そのため、一般的には90%以上の高いキャッシュヒット率が好ましいです。キャッシュヒット率は、サービスの Stats ページについて確認することができます。

フォールバック TTL の設定

キャッシュメモリにキャッシュを保持することができる有効期限のことを「time to live」または TTL といいます。TTL はオリジンサーバーから返されるキャッシュ関連のヘッダー情報に基づいて設定されます。フォールバック TTL (まれに「デフォルト TTL」とも呼ばれます) を別途設定可能です。

警告

カスタム VCLを使用している場合のフォールバック TTL は、VCL ボイラープレートで指定され、コントロールパネルや API で設定されたフォールバック TTL は適用されませ。詳細については、キャッシュのフレッシュネスと TTLに関するドキュメントを参照してください。

ヒント

レスポンスに他のフレッシュネスがない場合に、コントロールパネルにてフォールバック TTL を0秒に設定すると、 return(pass)にてvcl_fetchが設定されます。

TTLはいつでも以下の方法で変更可能です。

  1. Fastly コントロールパネルにログインします。
  2. Home ページから、適切なサービスを選択します。検索ボックスで ID、名称、ドメインでの検索が行えます。
  3. Edit configuration ボタンをクリックし、アクティブなバージョンをクローンするオプションを選択します。ドメインページが表示されます。
  4. Settings をクリックします。Settings ページが表示されます。
  5. Fallback TTLにある TTL 設定の横にある鉛筆マークをクリックします。

フォールバックTTLクイック設定

  1. Fallback TTL (sec)の枠に新しい TTL を秒で入力してください。
  2. Saveをクリックして設定を保存します。
  3. Activate ボタンをクリックして設定変更をデプロイします。
注意

Google Cloud Storage を利用していて、GCS バケットに対するデフォルト TTLを変更したい場合は、こちらの説明をご参照ください。

キャッシュコントロールヘッダーの仕組みを理解

キャッシュコントロールヘッダーを使用して、データのキャッシュ期間を決定するポリシーを設定することができます。

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

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

Surrogateヘッダー

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ミリ秒程度で実行されます)。

Cache-Controlヘッダー

RFC 7234 のセクション5.2で定義されているように、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 そして privateCache-Control ヘッダーのみが Fastly のキャッシングに影響を与えます。他のすべての Cache-Control ヘッダーはキャッシュに影響は与えずに、そのままブラウザに渡されます。Fastly がこれらの Cache-Control ヘッダーにどのようにレスポンスを行うか、またこれらのヘッダーが Expires や Surrogate-Control とどのように相互作用するかについての詳細な情報は、キャッシュの鮮度に関するドキュメントをご覧ください。

注意

ここに記載されていないその他の Cache-Control ヘッダーについては、Mark Nottingham 氏のキャッシュに関するチュートリアルをご参照ください。

Expiresヘッダー

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

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

Cache-Control ヘッダーの期間を長くする

Cache-Control ヘッダーに設定する期間を長くすることにより、需要が高い時などにより長時間 Fastly にコンテンツをキャッシュさせることができます。max-ageまたはCache-ControlヘッダーのSurrogate-Controlの変更をご検討ください。詳細については、キャッシュのフレッシュネスに関するドキュメントを参照してください。

Fastly で一時的に失効済みコンテンツを配信する設定

もしオリジンサーバーが長時間利用不可能な状態になる場合 (例:メンテナンスの実施など)、一時的に失効済みコンテンツの配信をすることが有効です。失効済みコンテンツの配信は、高頻繁でコンテンツの更新及び公開を実施するような場合にも有用です。

stale-while-revalidateまたはstale-if-errorステートメントをCache-ControlまたはSurrogate-Controlヘッダーに追加することで、Fastly に失効済みコンテンツを配信させることができます。失効済みコンテンツの配信により詳細な内容が記載されてます。

ファーストバイトタイムアウト時間を減らす

一時的に失効済みコンテンツの配信の設定をした後に、ファーストバイトタイムアウト時間を短く設定します。そうすることで、オリジンサーバーから新しいコンテンツを取得している間に、ユーザーに対してより迅速に失効済みコンテンツの配信をするようになります。ファーストバイトタイムアウト時間の削減と同時に失効済みコンテンツの配信を設定することで、503 ファーストバイトタイムアウトエラーを回避することができます。オリジンサーバーに対するファーストバイトタイムアウト時間を減らす方法は以下のとおりです。

  1. Fastly コントロールパネルにログインします。
  2. Home ページから、適切なサービスを選択します。検索ボックスで ID、名称、ドメインでの検索が行えます。
  3. Edit configuration ボタンをクリックし、アクティブなバージョンをクローンするオプションを選択します。ドメインページが表示されます。
  4. Origins をクリックします。Origins ページが表示されます。
  5. Hostsから対象オリジンサーバーを探したら、ホストを編集するために鉛筆マークをクリックします。Edit this host ページが表示されます。
  6. ページの下部にあるAdvanced optionsリンクをクリックします。Advanced options のオプションが表示されます。
  7. First byte timeoutの枠に新しいファーストバイトタイムアウトをミリ秒で入力します。15000 ミリ秒くらいが、初期値として十分な値です。
  8. Updateをクリックして変更を保存します。
  9. Activate ボタンをクリックして設定変更をデプロイします。

特定のワークフローのキャッシュアクションを設定する

キャッシュ設定を作成する際、Actionの設定によってリクエストの処理方法を決めることができます。Action 設定と、それぞれの一般的なワークフローは以下のとおりです。

  • Do nothing now - このオプションを選択するとリクエスト設定のオプションが適用されますが、ルックアップやパスアクションは強制されません。

  • Pass (do not cache) - このオプションを選択すると、リクエストとそれに続くレスポンスがキャッシュをバイパスしてオリジンに直接送られます。ぺージを条件的にキャッシュすることを防ぐ場合や、条件を使用する場合は、このオプションを選んでください。

  • Restart processing (not common) - このオプションを選択すると、リクエストの処理が再開します。単一のリクエストに対して複数のバックエンドを確認する必要がある場合は、このオプションを使用してください。

  • Deliver (not common) - このオプションを選択すると、オブジェクトをクライアントに配信します。オバーライド条件を作成する必要がある場合は、このオプションを使用してください。

カスタムエラーの処理

サイトのダウンタイムが避けられない場合、標準のエラーメッセージはユーザーにとって不十分である場合があります。ユーザーにとって適切で具体的な情報が記されたカスタムエラーメッセージの作成をご検討ください。カスタムエラーページの作成 により詳細な記載があります。

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

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

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

バックエンドのレスポンスに基づいて、デフォルトのキャッシュ設定をオーバーライドすることができます。例えば、1日の全キャッシュ期間に404エラーレスポンスをキャッシュしたくない場合は、キャッシュオブジェクトを追加し、その条件を作成します。

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

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

イベントに向けた Fastly のカスタマーサポートへの連絡

大規模なイベントを実施される場合には、事前にご連絡を頂くことで、より的確なサポートをご提供できます。イベントの詳細について、あらかじめカスタマーサポートまでお知らせください。その際、以下の詳細情報をお伝えください。

  • イベント予定日時
  • 開催するイベントの種類
  • 予定期間 (計画されている場合)
  • 影響を受ける可能性がある Fastly のサービス

もし オリジンサーバーに対するセキュリティのバリデーションテストのようなイベントを予定されている場合には、ペネトレーションテストガイドを先にご確認ください。


翻訳についての注意事項
このガイドは役に立ちましたか?

このフォームを使用して機密性の高い情報を送信しないでください。サポートが必要な場合はお問い合わせください : support@fastly.com