オリジンシールド

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

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

オリジンシールドを使用しない場合、各リージョンの POP はオリジンサーバーへ個別にリクエストを送信します

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

オリジンシールドを使用すると、指定されたシールド POP のみがオリジンサーバーへリクエストを送信します

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

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

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

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

  1. 組織でオリジンシールドを有効にすることによる影響と潜在的な危険性については、オリジンシールドの注意点をお読みください。
  2. Fastly コントロールパネルにログインします。
  3. Home ページから、該当するサービスを選択します。検索ボックスを使用して ID、名前、またはドメインで検索することができます。
  4. Edit configuration ボタンをクリックし、アクティブなバージョンをクローンするオプションを選択します。ドメインページが表示されます。
  5. Origins をクリックします。Origins ページが表示されます。
  6. 編集するホストの名前をクリックします。 Edit this Host ページが表示されます。
  7. Shielding メニューからシールドとして用いるデータセンターを選択します。

    • 通常はバックエンドに近いデータセンターを選ぶことを推奨します。これにより、選択したシールド POP (サーバーに近い POP) とエッジ POP (リクエストを発行するユーザーに最寄りの POP) 間のリクエストが最適化され、コンテンツ配信の高速化を実現します。詳細については、オリジンシールドの場所の選択に関するガイドをご覧ください。
    • 複数のバックエンドに別々のシールドを定義できます。地域別のバックエンドに対して異なるシールド POP を設定する要件にも、フレキシブルに対応可能です。
  8. Update をクリックして変更を保存します。
  9. デフォルトホストを変更した場合や、ヘッダーを追加してホストを変更した場合は、変更後のホスト名を Domains のリストに追加してください。Domains **リンクをクリックし、当該ホスト名がそのページに表示されていることを確認します。リストになければ、Create domains** ボタンをクリックして追加してください。

    ドメインエリア

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

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

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

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

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

シールド POP へのインバウンドトラフィックは通常のトラフィックとして、エッジ POP への配信分を含め、請求対象となります。オリジンシールドを有効にすると追加のデータ転送料金が発生しますが、これはオリジンのデータ転送コスト (およびオリジンサーバー負荷) が減少することによって埋め合わされます。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 となるため注意が必要です。そこで、オリジンシールドとともにカスタムのスティッキーロードバランサーを用いる場合は、以下の設定が必要です。

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

Host ヘッダー

シールドにリクエストが到達する前の Host ヘッダーの変更には注意が必要です。Fastly は リクエストと Host ヘッダーを照合します。Host ヘッダーがサービス内のドメインに一致しない場合、500 エラーが予想されます。 Fastly を通じて提供されるお客様のサービスとオリジンの動作に矛盾がないよう、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.comb.example.com が別のオブジェクトとして処理されるため、オブジェクトは両方のサービス間で分割されます。Host ヘッダーを変更する際の注意事項については、オーバーライドホストの指定に関する記事を参照してください。

VCL の実行

VCL はエッジ POP で1回とシールド POP で1回の、計2回実行されます。berespresp を変更すると、シールドとエッジの 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-ControlCache-Control のレスポンスヘッダーを併用できます。Surrogate-ControlCache-Control をオーバーライドし、エッジノード後に削除されます。その後、Cache-Control からの max-age がブラウザと通信します。以下は、オリジンからのレスポンスヘッダーの具体例です。

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
vcl_recv {
  # Set the custom header
  if (req.http.Cookie ~ "ABtesting=B") {
    set req.http.X-ABtesting = "B";
  } else {
    set req.http.X-ABtesting = "A";
  }
  ...
}

...

sub vcl_fetch {
  # Vary on the custom header
  if (beresp.http.Vary) {
    set beresp.http.Vary = beresp.http.Vary ", X-ABtesting";
  } else {
    set beresp.http.Vary = "X-ABtesting";
  }
  ...
}

...

sub vcl_deliver {
  # Hide the existence of the header from downstream
  if (resp.http.Vary) {
    set resp.http.Vary = regsub(resp.http.Vary, "X-ABtesting", "Cookie");
  }
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Same vcl_recv from above code example

sub vcl_fetch {
  # Vary on the custom header, don't add if shield POP already added
  if (beresp.http.Vary !~ "X-ABtesting") {
    if (beresp.http.Vary) {
      set beresp.http.Vary = beresp.http.Vary ", X-ABtesting";
    } else {
      set beresp.http.Vary = "X-ABtesting";
    }
  }
  ...
}

...

sub vcl_deliver {
  # Hide the existence of the header from downstream
  if (resp.http.Vary && !req.http.Fastly-FF) {
    set resp.http.Vary = regsub(resp.http.Vary, "X-ABtesting", "Cookie");
  }
}

POP メンテナンス

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

Back to Top