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

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

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

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

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

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

フォールバック TTL の設定

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

デフォルトのフォールバック TTL はいつでも以下の方法で変更可能です。

1. Fastly コントロールパネルにログインします。
2. Home ページから、適切なサービスを選択します。検索ボックスで ID、名称、ドメインによる検索が行えます。
3. Edit configuration をクリックし、アクティブなバージョンをクローンするオプションを選択します。
4. Settings をクリックします。

5. Fallback 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: private, no-store- Fastly や Web ブラウザでこのコンテンツをキャッシュしないでください。
• Cache-Control: public, max-age=[seconds] - キャッシュはこのコンテンツを n 秒間保存することができます。
• Cache-Control: s-maxage=[seconds] - max-age と同じですが、特にプロキシのキャッシュに適用されます。

max-age、s-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 をクリックします。
5. Hosts エリアでオリジンサーバーを見つけ、鉛筆をクリックしてホストを編集します。
6. ページの下部にある 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 は、以下のレスポンスステータスコードをデフォルトでキャッシュします。これらのステータスに加えて、条件およびレスポンスを使用して、他の状態にあるオブジェクトをキャッシュさせることができます。

上記以外のステータスコードをキャッシュするには、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 のサービス

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