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

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

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

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

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

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

フォールバック TTL の設定

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

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

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

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

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

を変更したい場合は、こちらの説明をご参照ください。

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

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

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

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

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

上記以外のステータスコードをキャッシュするには、beresp.cacheable = true; にて vcl_fetch を設定します。それによって、バックエンドの 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 のカスタマーサポートへの連絡

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

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

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

Back to Top