失効済みコンテンツの配信

最終更新日 2024-10-07

Fastly では、オリジンサーバーに問題が発生している時、またはオリジンサーバーからの新しいコンテンツの取得に長い時間を要している場合に、失効済みコンテンツを配信するよう設定することができます。例えば、Fastly からオリジンサーバーに接続できない場合、Fastly POP はユーザーのリクエストに対してキャッシュ済みコンテンツの配信を続けます。これらの機能はデフォルトでは有効になっていません。

ヒント

失効済みコンテンツの配信に関する詳細は、失効済みコンテンツと再検証に関するドキュメントを参照してください。

新しいコンテンツの取得中に古いコンテンツを配信する

コンテンツの種類によっては、生成に時間がかかるものもあります。一度キャッシュされたコンテンツはすぐに配信されますが、最初にアクセスしようとしたユーザーはコンテンツが生成されるのを待たなければなりません。

キャッシング時間のペナルティ

これはコールドキャッシュの場合には避けられないことですが、オブジェクトがキャッシュにあり、TTL が期限切れになっている時にこのようなことが起こるのであれば、Fastly は新しいコンテンツがバックグラウンドで取得されている間、失効済みコンテンツを表示するように設定することができます。

バックグラウンドで新しいコンテンツを取得する

Fastly は、Google Chrome ブラウザへの搭載が検討されている Mark Nottingham 氏の RFC 5861『HTTP Cache-Control Extensions for Stale Content』で提案された動作をベースにしています。

失効済みの配信を有効にする

注意

すでにカスタム VCL でエラー時の失効済みコンテンツの配信を有効にしている場合、Fastly コントロールパネルでこの機能を追加すると、stale TTL (失効済みコンテンツが配信される期間) が別に設定されます。これを避けるため、Fastly コントロールパネルでこの機能を有効にする前に、カスタム VCL を確認し、stale-if-error ステートメントを削除してください。

Fastly のコントロールパネルで、エラー時にデフォルトの TTL 期間中 (43200秒または12時間)、失効済みコンテンツが配信されるように設定するには、以下の手順に従ってください。

Fastly コントロールパネルにログインします。
Home ページから、適切なサービスを選択します。検索ボックスで ID、名称、ドメインによる検索が行えます。
Edit configuration をクリックし、アクティブなバージョンをクローンするオプションを選択します。
Settings をクリックします。
Serve stale スイッチをオンにすると、デフォルト TTL 期間である43200秒 (12時間) の間、失効済みコンテンツの配信が自動的に有効になります。
Activate をクリックして設定への変更をデプロイします。

手動で失効済みの配信を有効にする

この手順では、3つのオリジンサーバーの障害のシナリオにて VCL を使って対応するための高度な設定を行います。

Varnish の場合、オリジン/オリジンサーバー障害には3つのケースが考えられます。

ヘルスチェックの失敗により、オリジン/オリジンサーバーに異常があると見なされる。
何らかの理由で Varnish がオリジン/オリジンサーバーに接続できない場合、503エラーが発生する。
オリジンからの HTTP レスポンスが、ユーザーへの配信に適さない内容である (503エラーなど)。

下記のカスタム VCL はこれら3種類のケースすべてに対応します。オリジンのヘルスステータスが異常の場合、デフォルトサーバーの失効済み動作が stale-if-error によって開始されます。オリジン/オリジンサーバー障害の発生からオリジンのヘルスステータスが異常と見なされるまでの間、Varnish は通常503エラーを返します。カスタム VCL を使用することで、失効済みのコピーがある場合には、代わりに失効済みを配信するか、シンセティックエラーページを返すことができます。エラーページはカスタマイズすることができます。3つ目のケースでは、vcl_fetch での 5XX エラーを遮断し、失効済みコンテンツを配信するか、シンセティックエラーページを配信することで対応することができます。

警告

503エラーが発生している場合、キャッシュされたコンテンツをすべてパージすることは避けてください。全コンテンツのパージを行うと stale-if-error がオーバーライドされ、オリジンサーバーへのリクエスト数が増加します。その結果、503エラーがさらに増える可能性があります。

必須ではありませんが、この VCL と一緒にヘルスチェック機能を有効にしてください。ヘルスチェックを有効にしていない場合でもすべての機能は動作しますが、失効済みのレスポンスやシンセティックレスポンスの配信には、オリジンのタイムアウトを待たなくてはいけないため、より長い時間がかかります。ヘルスチェックを有効にすると、オリジンに異常があるとマークされるため、この問題は回避されます。

以下のカスタム VCL は、Fastly 標準のボイラープレートを含んでいます。お客様のサービスにアップロードする前に、必要に合わせて以下の値をカスタマイズまたは削除してください。

if (beresp.status >= 500 && beresp.status < 600) は、失効済みコンテンツやシンセティックレスポンスを配信すべき HTTP レスポンスコードを含むように変更する必要があります。
set beresp.stale_if_error = 86400s; は、失効済みコンテンツが配信される期間を制御します。この値は、設定に応じて適切な値に設定する必要があります。オリジンから Surrogate-Control または Cache-Control にて stale_if_error を送信している場合は、この行全体を削除します。
set beresp.stale_while_revalidate = 60s; は、オブジェクト stale_while_revalidate に対して機能が有効になる時間を制御するもので、設定に意味のある量に設定する必要があります。この機能により、Varnish はキャッシュミスの際に失効済みとなり、バックグラウンドでオリジンから最新バージョンのオブジェクトを取得するようになります。これにより、TTL の短いオブジェクトや、一般的なキャッシュミスの際に、大きなパフォーマンスの向上が期待できます。stale_while_revalidate は、stale_if_error によって上書きされるので注意してください。つまり、オブジェクトが再検証中に失効済み (キャッシュしてから TTL に設定された時間が経過した) 状態で配信される資格がある限り、stale_if_error の効果はありません。オリジンから Surrogate-Control または Cache-Control にて stale_while_revalidate を送信している場合は、この行全体を削除します。
synthetic {"<!DOCTYPE html>Your HTML!</html>"}; は、失効済みバージョンのオブジェクトが存在しない場合に Varnish が返すシンセティックレスポンスであり、設定に応じて適切に設定する必要があります。ここには、お客様の HTML、CSS、JS を埋め込むことができます。外部の CSS や JS ドキュメントを参照する際には注意が必要です。オリジンがオフラインの場合は、それらも利用できない可能性があります。

sub vcl_recv {
#FASTLY recv
  # Normally, you should consider requests other than GET and HEAD to be uncacheable
  # (to this we add the special FASTLYPURGE method)
  if (req.method != "HEAD" && req.method != "GET" && req.method != "FASTLYPURGE") {
    return(pass);
  }
  # If you are using image optimization, insert the code to enable it here
  # See https://www.fastly.com/documentation/reference/io/ for more information.
  return(lookup);
}
sub vcl_hash {
  set req.hash += req.url;
  set req.hash += req.http.host;
  #FASTLY hash
  return(hash);
}
sub vcl_hit {
#FASTLY hit
  return(deliver);
}
sub vcl_miss {
#FASTLY miss
  return(fetch);
}
sub vcl_pass {
#FASTLY pass
  return(pass);
}
sub vcl_fetch {
  /* handle 5XX (or any other unwanted status code) */
  if (beresp.status >= 500 && beresp.status < 600) {
    /* deliver stale if the object is available */
    if (stale.exists) {
      return(deliver_stale);
    }
    if (req.restarts < 1 && (req.method == "GET" || req.method == "HEAD")) {
      restart;
    }
  }
  /* set stale_if_error and stale_while_revalidate (customize these values) */
  set beresp.stale_if_error = 86400s;
  set beresp.stale_while_revalidate = 60s;
#FASTLY fetch
  # Unset headers that reduce cacheability for images processed using the Fastly image optimizer
  if (req.http.X-Fastly-Imageopto-Api) {
    unset beresp.http.Set-Cookie;
    unset beresp.http.Vary;
  }
  # Log the number of restarts for debugging purposes
  if (req.restarts > 0) {
    set beresp.http.Fastly-Restarts = req.restarts;
  }
  # If the response is setting a cookie, make sure it is not cached
  if (beresp.http.Set-Cookie) {
    return(pass);
  }
  # By default we set a TTL based on the `Cache-Control` header but we don't parse additional directives
  # like `private` and `no-store`. Private in particular should be respected at the edge:
  if (beresp.http.Cache-Control ~ "(?:private|no-store)") {
    return(pass);
  }
  # If no TTL has been provided in the response headers, set a default
  if (!beresp.http.Expires && !beresp.http.Surrogate-Control ~ "max-age" && !beresp.http.Cache-Control ~ "(?:s-maxage|max-age)") {
    set beresp.ttl = 3600s;
    # Apply a longer default TTL for images processed using Image Optimizer
    if (req.http.X-Fastly-Imageopto-Api) {
      set beresp.ttl = 2592000s; # 30 days
      set beresp.http.Cache-Control = "max-age=2592000, public";
    }
  }
  return(deliver);
}
sub vcl_error {
#FASTLY error
  /* handle 503s */
  if (obj.status >= 500 && obj.status < 600) {
    /* deliver stale object if it is available */
    if (stale.exists) {
      return(deliver_stale);
    }
    /* otherwise, return a synthetic */
    /* include your HTML response here */
    synthetic {"<!DOCTYPE html><html>Replace this text with the error page you would like to serve to clients if your origin is offline.</html>"};
    return(deliver);
  }
}
sub vcl_deliver {
#FASTLY deliver
  return(deliver);
}
sub vcl_log {
#FASTLY log
}

ヘッダーを追加する

カスタム VCL を追加すると、オリジンサーバーからのレスポンス内の stale-while-revalidate または stale-if-error ヘッダーのいずれかに、Cache-Control または Surrogate-Control ディレクティブを追加することで、失効済みコンテンツの配信を手動で有効化することができます。例:

Cache-Control: max-age=600, stale-while-revalidate=30

この例では、一部のコンテンツを10分間キャッシュした後、新しいコンテンツが取得されるまでの間、最大30秒間失効済みコンテンツを配信するようになっています。

同様に、こちらのステートメント:

Surrogate-Control: max-age=3600, stale-if-error=86400

このステートメントでは、キャッシュのコンテンツが1時間 (3600秒) 毎に更新されますが、オリジンがダウンしている場合は期限切れのコンテンツを24時間 (86400秒) 配信するように指定されています。

また、vcl_fetch にて以下の変数を設定することで、VCL 内からこれらの動作を制御することもできます。。

set beresp.stale_while_revalidate = 30s;
set beresp.stale_if_error = 86400s;

grace によるインタラクション

Stale-if-error は、Varnish の変数 grace と全く同じ働きをするので、この2つの記述は同等です。

set beresp.grace = 86400s;
set beresp.stale_if_error = 86400s;

ただし、VCL に grace のステートメントがある場合は、Cache-Control や Surrogate-Control のレスポンスヘッダー内の stale-if-error ステートメントをオーバーライドします。