オリジンシールド

Fastly のコンテンツ配信ネットワークは、リクエストがオリジンサーバーに直接送信される代わりに、世界中に点在する Fastly の配信拠点 (POP) のいずれかがリクエストに応答することで機能します。各 POP は独立して動作するため、リクエストされたリソースのキャッシュ版がない場合は、他の POP が同じリクエストを行っている場合でもオリジンに直接リクエストを行います。Fastly の POP の1つをオリジンの「シールド」として指定すると、オリジンサーバーの負荷を軽減することができます。シールド POP を指定することで、オリジンへのリクエストが1つの POP から来るようになり、エンドユーザーからのリクエストがキャッシュ HIT になる確率が上がります。

例えば、リヨン (フランス)、ワシントン DC (米国)、東京 (日本) の3つのリージョンにエンドユーザーがいると仮定してください。これらのリージョンにはデフォルトで、ユーザーが利用できる情報をキャッシュするローカル Fastly POP が存在します。ただし、リヨンのユーザーがパリの Fastly POP でキャッシュされていないリソースをリクエストすると、その POP はオリジンサーバーへリクエストを送信し、返ってきたリソースをキャッシュして、キャッシュされたリソースをユーザーに返します。

しかし、オリジンシールドが有効化されていれば、指定した POP が代わりにオリジンサーバーへのすべてのリクエストを収集します。この例では、バージニアにある Fastly POP が AWS の us-east-1 リージョンにあるサーバーのシールドとして指定されています (下記のイラストを参照)。

このシナリオでは、リヨンのユーザーがパリにある Fastly POP にキャッシュされていないリソースをリクエストすると、パリの POP はそのリクエストをシールド POP (この例ではバージニアにある POP) に転送します。リソースが過去にシールド POP でキャッシュされていた場合、リージョン POP はそれを受け取り、キャッシュしてからユーザーに返します。そうでない場合、シールド POP はリソースのオリジンサーバーへリクエストを送信し、レスポンスをキャッシュしてリージョン POP に返し、そこでもユーザーに返す前にキャッシュされます。

より高度なユースケースについては、高度なオリジンシールドのシナリオを参照してください。

オリジンシールドを有効にする

オリジンシールドを以下の手順に従って有効にします。

1. 組織でオリジンシールドを有効にすることによる影響と潜在的な危険性については、以下のオリジンシールドの注意点をご覧ください。

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

6. 編集するホストの名前をクリックします。

7. Shielding メニューからシールドとして使用するデータセンターを選択します。

   • 通常はバックエンドに近いデータセンターを選ぶことを推奨します。これにより、選択したシールド POP (サーバーに近い POP) とエッジ POP (リクエストを発行するユーザーに最寄りの POP) 間のリクエストが最適化され、より高速なコンテンツ配信が可能になります。詳細については、オリジンシールドの場所の選択に関するガイドをご覧ください。
   • 複数のバックエンドに別々のシールドを定義できます。地域別のバックエンドに対して異なるシールド POP を設定する要件にも、フレキシブルに対応可能です。

8. Update をクリックして変更を保存します。

9. デフォルトホストを変更した場合や、ヘッダーを追加してホストを変更した場合は、変更後のホスト名を Domains のリストに追加してください。Domains をクリックし、当該ホスト名がそのページに表示されていることを確認します。ページに表示されていない場合、Create domain をクリックして追加します。

   

   オリジンシールドを有効にすると、他の POP からそのシールド POP へのリクエストが発生します。変更後のホスト名が登録されていないと、シールドがこのリクエストをどのサービスに適用するのか判断できません。Domains のリストにオリジンのホスト名を追加することで、この問題を防ぐことができます。

10. Activate をクリックして設定への変更をデプロイします。

オリジンシールドの注意点

オリジンシールドによる影響はトラフィックとヒット率だけでなく、設定とパフォーマンスにも及びます。オリジンシールドの設定の際、以下の注意点にご留意ください。

インバウンドトラフィックの課金

シールド POP へのインバウンドトラフィックは、エッジ POP への配信分を含め、通常のトラフィックとして請求対象となります。オリジンシールドを有効にすると、Fastly のデータ転送量料金が追加で発生しますが、オリジンのデータ転送量 (およびオリジンサーバーの負荷) を節約することで、これらの料金が相殺される可能性があります。PASS (キャッシュ対象外) となるリクエストも直接オリジンには送られず、最初にシールド POP を経由することにもご留意ください。

全ヒット率の計算

全ヒット率の計算値は、実際のヒット率より低くなることがあります。全ヒット率の計算時にオリジンシールドの有無は考慮されません。エッジ POP がリクエストされたファイルをまだキャッシュしていなかった場合、1回のキャッシュミスとして計上されます。ローカルミス/シールドヒットは、バックエンドへのリクエストが発生しないにもかかわらず、統計には1回のキャッシュミスおよび1回のキャッシュヒットとして計上されます。ここで、エッジノードからシールドへのリクエストは1つのリクエストとして計上されます。ローカルミス/シールドミス時のリクエストは2回計上されます。これは、オリジンから後でリソースを取得するためです。オリジンシールドによるキャッシュの詳細については、オリジンシールドに関する開発者ドキュメントを参照してください。

シールドフェイルオーバー

指定したシールド POP にアクセスしてリクエストが処理できない場合 (ネットワーク障害など)、そのリクエストはシールドをバイパスし、エッジノードからオリジンサーバーに直接送信されます。

VCL によるバックエンドの手動定義

VCL を使用してマニュアルでバックエンドを定義することはできません。このレベルのオリジンシールドは、コントロールパネルまたは API によって実際のオブジェクトとして定義されるバックエンドに完全に依存しています。その他のカスタム VCL は問題なく機能します。

自動ロードバランシング

自動ロードバランシングの選択時、選択できるシールドは1つだけです。自動ロードバランシングを有効にした上でシールドを複数用いるには、カスタム VCL を使用する必要があります。

スティッキーロードバランシング

オリジンシールドをスティッキーロードバランシングと併用するにはカスタム VCL が必要です。スティッキーロードバランサーは、client.identity を使ってセッションの送信先を選択します。client.identity は、IP リクエストヘッダーのデフォルト値となります。通常ではこれで適切に動作しますが、オリジンシールドを有効にすると、この IP はクライアントの IP ではなく元の POP の IP となるため注意が必要です。そこで、オリジンシールドとともにカスタムのスティッキーロードバランサーを用いる場合は、以下の設定が必要です。

1if (req.http.fastly-ff) {
2  set client.identity = req.http.Fastly-Client-IP;
3}

Host ヘッダー

シールドにリクエストが到達する前の Host ヘッダーの変更には注意が必要です。Fastly はリクエストと Host ヘッダーを照合します。Host ヘッダーがサービス内のドメインに一致しない場合、500 エラーが予想されます。Fastly を通じて提供されるお客様のサービスとオリジンの動作に矛盾がないよう、 サブルーチンの Host vcl_hashヘッダーの値はすべて小文字に正規化されます。これにより、リクエスト内でお客様のサイトのドメイン名に大文字が使用されていても、ハッシュサブルーチンは予測通りの動作をすることになります。ただし、これ以外の URL 部分には適用されず、大文字と小文字が区別されます。

Host ヘッダーが別サービスに属するドメイン名に変更された場合、パージの競合が発生する恐れがあります。例えば、サービス A のホスト名が a.example.com で、サービス B のホスト名が b.example.com だとします。サービス B が Host ヘッダーを a.example.com に変更すると、エッジはリクエストがサービス B に対するものであると判断しますが、シールドはリクエストがサービス A に対するものであると判断します。予防策として、サービス A と B の両方からのオブジェクトをパージし、後続のリクエストで Fastly が最新バージョンを取得できるようにすることをお勧めします。シールドに達する前に Host ヘッダーを変更している場合、a.example.com と b.example.com が別のオブジェクトとして処理されるため、オブジェクトは両方のサービス間で分割されます。Host ヘッダーを変更する際の注意事項については、オーバーライドホストの指定に関する記事を参照してください。

VCL の実行

VCL はエッジ POP で1回とシールド POP で1回の、計2回実行されます。beresp と resp を変更すると、シールドとエッジの URL のキャッシュに影響する可能性があります。以下の例を考慮してください。

あるオブジェクトを Fastly に1時間 (3600秒間)、続いてブラウザで10秒間キャッシュするとします。オリジンは Cache-Control: max-age=3600 を送信します。beresp.http.Cache-Control の設定を解除してから、Cache-Control をリセットして max-age=10 にします。ただし、これはオリジンシールドが有効になっている場合、意図した動作にはなりません。オブジェクトはシールド上では max-age=3600 になり、エッジに到達する際には max-age=10 になります。

このインスタンスのより適切なオプションとして Surrogate-Control と Cache-Control のレスポンスヘッダーを併用できます。Surrogate-Control は Cache-Control をオーバーライドし、エッジノード後に削除されます。その後、Cache-Control からの max-age がブラウザと通信します。以下は、オリジンからのレスポンスヘッダーの具体例です。

Surrogate-Control: max-age=3600
Cache-Control: max-age=10

他のよくある間違いとしては、不適切な Vary ヘッダーをエッジ POP に送るというものがあります。例えば、Cookie から特定の値を読み取り、その値をヘッダーに追加し、そのヘッダーを Vary ヘッダーに追加するという VCL について考えてみましょう。お客様の管理下にないキャッシュサーバー (大企業でよく利用されている共有プロキシなど) と最大限の互換性を得るには、Vary ヘッダーを vcl_deliver で更新し、そのカスタムヘッダーの値を Cookie で置き換えます。コードは次のようになります。

1vcl_recv {
2  # Set the custom header
3  if (req.http.Cookie ~ "ABtesting=B") {
4    set req.http.X-ABtesting = "B";
5  } else {
6    set req.http.X-ABtesting = "A";
7  }
8  ...
9}
10...
11sub vcl_fetch {
12  # Vary on the custom header
13  if (beresp.http.Vary) {
14    set beresp.http.Vary = beresp.http.Vary ", X-ABtesting";
15  } else {
16    set beresp.http.Vary = "X-ABtesting";
17  }
18  ...
19}
20...
21sub vcl_deliver {
22  # Hide the existence of the header from downstream
23  if (resp.http.Vary) {
24    set resp.http.Vary = regsub(resp.http.Vary, "X-ABtesting", "Cookie");
25  }
26}

ただし、上記のコードをオリジンシールドと組み合わせると、エッジ POP で Vary ヘッダーに Cookie が設定されるため、キャッシュヒット率が極端に低下します。これを回避するには、別の Fastly キャッシュからのリクエストでない場合にのみ Vary が Cookie で更新されるように上記の VCL を修正します。Fastly-FF ヘッダーをご覧いただくとわかりやすいでしょう。コードは次のようなものになります (上の例と同じ vcl_recv を含んでいます)。

1# Same vcl_recv from above code example
2sub vcl_fetch {
3  # Vary on the custom header, don't add if shield POP already added
4  if (beresp.http.Vary !~ "X-ABtesting") {
5    if (beresp.http.Vary) {
6      set beresp.http.Vary = beresp.http.Vary ", X-ABtesting";
7    } else {
8      set beresp.http.Vary = "X-ABtesting";
9    }
10  }
11  ...
12}
13...
14sub vcl_deliver {
15  # Hide the existence of the header from downstream
16  if (resp.http.Vary && !req.http.Fastly-FF) {
17    set resp.http.Vary = regsub(resp.http.Vary, "X-ABtesting", "Cookie");
18  }
19}

POP メンテナンス

標準メンテナンス手順の一環として、Fastly はオリジンシールドのロケーションとして指定されている POP のメンテナンスを行う場合があります。これが発生しても POP は稼働を続けますが、Fastly は必要に応じて POP 内の個々のマシンを停止したり再開したりすることがあります。また、POP を廃止することもあります。この場合、Fastly はオリジンシールドのロケーションを、お客様のパフォーマンスを損なわないよう、近隣のデータセンターに移動します。標準的なメンテナンスが開始される前に、サービスステータスページに通知更新を掲載しますが、メンテナンスが行われる前に個別に通知を受けたい場合、https://support.fastly.com/ にアクセスしてサポートチケットを開き、お客様の カスタマー ID をお伝えいただくことで、シールドしている場所でオリジンシールドの移行が予定されている場合に通知を受信できるようにリクエストできます。そうすることで、移行の予定があればメールでお伝えいたします。必要に応じて、お客様に都合の良いタイミングで特定のアクションを実行していただくようお願いすることがあります。