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

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

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

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

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

キャッシュサーバーによって配信されたリクエスト数をキャッシュ可能なリクエスト数 (ヒット + ミス) で割り算した値をキャッシュヒット率と呼びます。キャッシュヒット率が高いということは、リクエストトラフィックによる無駄なオリジンサーバーへのヒットを防ぎ、代わりに、リクエストはキャッシュから配信できていることになります。そのため、一般的には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 コールでキャッシュから削除することができます (通常は約1ミリ秒程度で実行されます)。Surrogate-Control は最も優先されるキャッシュの指定方法となります。

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 レスポンスをすべてキャッシュできるようにします。

1
2
3
4
5
6
7

sub vcl_fetch {
  # ...
  if (beresp.status >= 200 && beresp.status < 300) {
    set beresp.cacheable = true;
  }
  # ...
}

Fastly のカスタマーサポートへの連絡

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

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

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