LOG IN SIGN UP
Documentation

オリジンシールド

  Last updated August 09, 2018

Fastly のオリジンシールドを使うと、オリジンに対するシールドとして POP (Point of Presence) をいずれか 1 つ指定できます。シールド POP の指定後は、当該オリジンへのリクエストはすべてシールド POP 経由となるため、キャッシュのヒット率が高くなります。シールドに指定されていない POP がキャッシュを持っていない場合、その POP はオリジンではなくシールド POP へリクエストを行います (ただしシールド POP がダウンしていないことが条件です)。

オリジンシールドのしくみ

あるユーザーが顧客のサーバーへ新しいコンテンツをリクエストし、そのコンテンツがどの Fastly POP にもキャッシュされたことがない場合の、オリジンシールドの有無による処理の違いを以下に説明します。

オリジンシールドが有効ではない場合

オリジンシールドが有効ではない場合、コンテンツへの初回のリクエストが POP A に届いた時に、そのコンテンツは POP A にキャッシュされていません。そこで POP A はそのリクエストを顧客のオリジンサーバーへ送信し、コンテンツを取得します。取得したコンテンツを POP A はキャッシュして、かつユーザーへ配信します。

caching behavior on the first request, without shielding enabled

同じコンテンツに対する 2 回目のリクエストが POP A へ届くと、そのコンテンツはすでにキャッシュされています。顧客のオリジンサーバーへのリクエストは発生せず、キャッシュから配信が行われます。

caching behavior on subsequent requests, without shielding enabled

ただし、2 回目のリクエストが POP A ではなく POP B へ届いたとすると、そのリクエストは再度、顧客のオリジンサーバーへ送られます。POP A における初回リクエストと同様に、そのレスポンスはキャッシュされ、ユーザーへ配信されます。

オリジンシールドが有効な場合

オリジンシールド が有効な場合、コンテンツへの初回のリクエストが POP A に届いた時に、そのコンテンツは POP A にキャッシュされていません。POP A はそのリクエストをシールド POP へ送信しますが、そこにもコンテンツはキャッシュされていません。そこでシールド POP はそのリクエストを顧客のオリジンサーバーへ送信します。そのレスポンスはシールド POP にてキャッシュされた上で、POP A へ配信されます。続いて POP A はコンテンツをユーザーへ配信します。

caching behavior on the first request, with shielding enabled

同じコンテンツに対する 2 回目のリクエストが POP A へ届くと、そのコンテンツはすでにキャッシュされています。シールド POP にも、顧客のオリジンサーバーに対してもリクエストは発生しません。

caching behavior on subsequent requests, with shielding enabled

ただし、2 回目のリクエストが POP A ではなく POP B へ届いたとすると、そのリクエストはシールド POP へ送られます。シールド POP は POP A への初回リクエストによりすでにキャッシュを持っています。よって、シールド POP 上のキャッシュが期限切れとなるまで、顧客のオリジンサーバーに対するリクエストは発生しません。

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

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

  1. オリジンシールドを有効にすることによる影響とよくある間違いについては、オリジンシールドの注意点をお読みください。
  2. Fastly コントロールパネルにログインし、Configure のリンクをクリックします。
  3. サービスメニューから設定対象のサービスを選択します。
  4. Configuration ボタンをクリックし、Clone active を選択すると設定画面が開きます。
  5. Origins のリンクをクリックし、Origins 設定画面を開きます。
  6. 対象となる host 名をクリックし、Edit this host 設定画面を開きます。
  7. Shielding メニューからシールドとして用いるデータセンターを選択します。

    • 通常はバックエンドに近いデータセンターを選ぶことを推奨します。エッジ POP(ユーザー最寄りの POP)とシールド POP(オリジン近くの POP)の間の接続最適化により、高速なコンテンツ配信が行われます。
    • 複数のバックエンドに対し、別々のシールドを定義できます。地域別のバックエンドに対して異なるシールド POP を設定する要件にも、フレキシブルに対応可能です。
  8. Update をクリックし、変更内容を保存します。
  9. Override host 設定等の Host ヘッダーを操作する変更を追加した場合、変更後のホスト名も Domains のリストに追加してください。Domains タブをクリックし、当該ホスト名がその画面に表示されるているか確かめます。リスト内に含まれない場合は、Create domains ボタンをクリックして追加してください。

    the Domains area

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

  10. Activate ボタンをクリックしてサービスをデプロイします。

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

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

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

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

ヒット率の計算

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

VCL によって手動で定義されたバックエンド

カスタム VCL 内のコードにてバックエンドを定義することはできません。オリジンシールドの実装は、コントロールパネルもしくは API を通じて定義されるバックエンドのオブジェクトに完全に依存しています。その他のカスタム VCL は問題なく機能します。

自動ロードバランス

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

Sticky なロードバランス

オリジンシールドを Sticky なロードバランスと併用するにはカスタム VCL が必要です。ロードバランス機能は Sticky な動作(セッション維持)を設定するために client.identity 変数を参照します。この変数にはクライアントの IP アドレスが保持されます。通常これは適切に動作しますが、オリジンシールドと併用する場合、この変数はクライアントの IP アドレスではなくエッジ POP のアドレスとなるため、注意が必要です。そこで、オリジンシールドと共に Sticky なロードバランス機能を用いる場合は、以下の設定が必要です。

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

Host ヘッダー

シールドへのリクエスト以前に Host ヘッダーを変更するには注意が必要です。Fastly は Host ヘッダーの値に応じてリクエストを処理します。Host ヘッダーがサービスの Domains いずれにも一致しない場合、500 エラーが返されます。また、Host ヘッダーが別サービスに属するドメイン名に変更された場合、パージの競合が発生する恐れがあります。

例えば、サービス A に Domain a.example.com が、サービス B には b.example.com が設定されているとします。サービス B が Override host により Host ヘッダーを a.example.com に変更すると、そのリクエストはエッジノードではサービス B、シールドノードではサービス A が処理することになります。

この例で、あるオブジェクトのパージをサービス B に対して実行し、サービス A に対して行わなかった場合、パージされたはずの古いオブジェクトがシールドノードからエッジノードへ配信されることになります。シールドノード上でこのオブジェクトはサービス A に属するため、パージされないからです。よって、パージはサービス A とサービス B の両方で実行すべきなのですが、それもまた分かりにくく、別の問題を引き起こす可能性があります。

VCL の実行

VCL はシールドノードで 1 回とエッジノードで 1 回の、計 2 回実行されます。berespresp の変更は、シールドノードとエッジノードのキャッシュに影響します。以下の例を考慮してください。

あるオブジェクトを Fastly にて1時間 (3600秒間)、続いてブラウザにて10秒間に渡ってキャッシュさせるとします。オリジンサーバーではレスポンスヘッダー Cache-Control: max-age=3600 を返し、VCL では 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 がブラウザに対する指示を伝えます。オリジンからのレスポンスヘッダーの具体例は次の通りとなります。

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

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

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 を含んでいます)。

# 上記のコード例と同じ vcl_recv がここに必要です

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");
  }
}

Additional resources:


Back to Top