site-failover#

Site-failoverは、エッジサーバがオリジンサーバと通信できない場合に、クライアントからのリクエストに対して代替レスポンスをすることができます。レスポンスはステータスコード301または302のリダイレクト、またはsite-failoverビヘイビアで定義する代替ロケーションから取得したコンテンツを返すことができます。

通信失敗時の動作として代替オリジンからコンテンツ取得する指定の場合、クライアントが通信失敗時のコンテンツをキャッシュに残すことを避けるため、ダウンストリームキャッシュの動作を指定することができます。

ユースケースの例#

www.example.comを配信FQDNとしてオリジンサーバorigin111.k5.comからコンテンツを配信する構成を例に考えます。さらにorigin111.k5.comのコンテンツはお客様の方でorigin222.k5.comにミラーしているものとします。このとき、コンテンツは2番目のサイトからも取得することが可能であり、このサイトを1番目のサイトが使用できない際のフェイルオーバー先としようとします。

上記を構成するには、以下の手順を実施します。

  • www.example.comの代替ホスト名として、例えばfailover.example.comをCNAME先とします。
  • 配信FQDNをfailover.example.comとする配信設定を作成します。originビヘイビアにはorigin222.k5.comを指定します。この際、downstream-cachingビヘイビアも使用できます。
  • www.example.comのルールにsite-failoverビヘイビアを記載します。この際、alternateHostnameとしてfailover.example.comを指定します。

※お客様が独自ドメインを保有しない場合、配信設定の作成により弊社が付与するドメインを2ヶ作成し、付与ドメインBをfailover.example.com、付与ドメインAを上記example.comに読み換える構成でも構いません。

前提条件と例外#

フェイルオーバー機能を構成するためには、下記typeの何れの場合でも、お客様が代替ホスト名、およびサイトのコンテンツ（必要に応じミラーリング）を有する代替オリジンサーバを用意できることを前提としています。この代替オリジンサーバは、site-failoverビヘイビアの設定よりも前に構成されていなければなりません。代替ホスト名については、IaaSのCDNで提供する配信FQDNであっても構いません。代替ホストにも到達できない場合、2段目のフェイルオーバーは動作しません。

※代替オリジンサーバは、別のリージョンに存在していても構いません。

typeパラメーター(必須)で指定可能な設定は以下の通りです。

  • serve-301 – フェイルオーバー時、ステータスコード301を応答し、クライアントをalternateHostnameとalternatePathにリダイレクトします。
  • serve-302 – フェイルオーバー時、ステータスコード302を応答し、クライアントをalternateHostnameとalternatePathにリダイレクトします。
  • serve-alternate – フェイルオーバー時、alternateHostnameとalternatePathにリクエストが自動的に送信され、代替のコンテンツを得ることができます。

paramsパラメーター(必須)で指定可能な設定は以下の通りです。

  • httpResponseStatus

    • ステータスコードのスペース区切りのリストです（範囲で指定することもできます）。
      エッジサーバからオリジンサーバに対する接続に失敗、読み込みのタイムアウト、または本パラメーターで指定するステータスコードである場合に、typeで指定するフェイルオーバー動作を発動させます。例: 500 503:504

  • alternateHostname

    • ハイフンの場合、alternateHostnameを割り当てません。この場合、オリジナルのホスト名が新しいURLの作成に使用されます。
    • 有効なFQDNを指定する場合、フェイルオーバー時に代替ホスト名として使用します。
      例: failover.example.com

  • alternatePath

    • ハイフンの場合、代替パスを割り当てません。alternateHostnameと共に、ファイル名を含むオリジナルのパスが新しいURLの作成に使用されます。
    • スラッシュで始まり、スラッシュで終わらない有効なパスの場合、元のリクエストのパスとファイル名がすべてalternatePathで置き換えられて新しいURLが作成されます。クエリ文字列を含む場合があるため、preserveQueryStringをfalseとすべきか、検討してください。例: /dir1/filename.ext
    • スラッシュで始まり、スラッシュで終わる有効なパスの場合、元のリクエストのうち、パスのみがalternatePathで置き換えられ新しいURLが作成されます。ファイル名は元のものが使用されます。例: /dir1/dir2/
  • preserveQueryString
    • true – リダイレクトやフォワード時、リクエストに含まれるクエリ文字列が保持されます。
    • false – リダイレクトやフォワード時、リクエストに含まれるクエリ文字列が除去されます。
       { 
         "rules": [
           {
             "matches": [
               {
                 "name": "http-method",
                 "value": "GET"
               }
             ],
             "behaviors": [
               {
                 "name": "site-failover",
                 "type": "serve-301",
                 "params": {
                   "httpResponseStatus": "404 500:504",
                   "alternateHostname": "www.alternatehostname.com",
                   "alternatePath": "/newdir1/newdir2",
                   "preserveQueryString": true
                 }
               }
             ]
           }
         ]
       }

alternateHostnameとalternatePathを両方をハイフンに指定してはいけません。その場合、フェイル状態である元のオリジンにフェイルオーバーしてしまいます。

preserveQueryStringがtrueの場合、alternatePathの中にクエリパラメーターを持つことができません。その場合、JSONのバリデーションエラーとなります。つまり、既にクエリ文字列が存在している状態で新しいクエリ文字列を追加することはできません。

downstream-caching#

downstream-cachingビヘイビアを使用することで、代替コンテンツのダウンストリームキャッシュを制御することができます。現在はダウンストリームキャッシュの無効化のみが指定可能です。

alternateHostnameの方のルールでこのビヘイビアを指定しない場合、デフォルトではオリジンサーバのCache-Controlヘッダーの値を使用します。

value指定可能な設定は以下の通りです。

  • no-store – 代替応答でCache-Control: no-storeヘッダーが付与されます。
  • no-cache – 代替応答でCache-Control: no-cacheヘッダーが付与されます。

以下の例では、代替コンテンツに対するすべてのGETリクエストに対し、ダウンストリームキャッシュ設定のno-storeが適用されます。

       {
        "rules": [ 
         {
          "matches": [
           {
            "name": "http-method",
            "value": "GET"
           }
          ],
          "behaviors": [
           {
            "name": "downstream-caching",
            "value": "no-store"
           }
          ]
         }
        ]
       }