オリジンシールド

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 が AWSus-east-1 リージョンにあるサーバーのシールド (下記のイラストを参照) として指定されています。

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

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

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

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

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

  1. 組織でオリジンシールドを有効にすることによる影響と潜在的な危険性については、オリジンシールドの注意点をお読みください。
  2. Fastly コントロールパネルにログインします。
  3. All services ページから、該当するサービスを選択します。検索ボックスを使用して 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 が必要です。

Sticky なロードバランス

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

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

Host ヘッダー

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

Host ヘッダーが別サービスに属するドメイン名に変更された場合、パージの競合が発生する恐れがあります。例えば、サービス A のホスト名が a.example.com で、サービス B のホスト名がb.example.com だとします。サービス B が Host ヘッダーを に変更するとa.example.com、エッジはリクエストがサービス B 向けであると判断しますが、シールドはリクエストがサービス A 向けであると判断します。シールドに達する前に 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-Control は、Cache-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 CookieVary ヘッダーに Cookie が設定されるため、ヒット率が極端に低下します。これを回避するには、もう1つの 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 内の個々のマシンを停止したり再開したりすることがあります。Fastly は、POP を廃止することもあります。これが発生すると、Fastly はシールドのロケーションを、代わりに隣接のデータセンターに移動します。標準メンテナンスが開始する前に、status.fastly.com に最新の通知を掲載しますが、メンテナンスが起こる前に個別に通知を受けたい場合、にメールを送信してサポートチケットを開きsupport@fastly.comお客様のカスタマー IDを伝え、シールドしている場所でシールドの移行が予定されている場合に通知を受けるようリクエストできます。 そうすることで、移行の予定があればメールでお伝えいたします。必要に応じて、お客様に都合の良いタイミングで特定のアクションを実行していただくようお願いすることがあります。

Back to Top