Skip navigation
All Places > ジャパンユーザーグループ (Japan User Group) > Blog

Akamai設定の検証やデバッグ方法(Firefox編)を以前ご紹介しました。今回はChromeブラウザでの検証方法についてご紹介します。

 

Chromeでは例として以下のModHeaderと呼ばれる拡張機能を利用することで、Chromeからのリクエストに対してPragma Headerに特定の値を送信できるようにします。まずはModHeaderの設定についてご紹介します。

 

インストール後、以下の通りModHeaderアイコンをクリックします。

 

Profileにリクエストヘッダが指定されていることを確認します。

 

Nameの箇所に"Pragma"と入力します。Valueの箇所には以下の値を入力します。

akamai-x-cache-on,akamai-x-cache-remote-on,akamai-x-check-cacheable,akamai-x-get-cache-key,akamai-x-get-extracted-values,akamai-x-get-request-id,akamai-x-serial-no, akamai-x-get-true-cache-key

 

これで事前準備が完了しました。それではデベロッパーツールを表示した状態でアカマイ化されたサイトにアクセスしてみます。デフォルト設定ではWindowsの場合はF12キーを、Macの場合はCommand+Option+Iキーを押すとデベロッパーツールが表示されます。

 

デベロッパーツールのNetworkセクションを見てみると、Request Headers内のPragma HeaderにModHearderで入力した値が入った状態でリクエストをするように変わっているのが分かります。

 

AkamaiのEdgeサーバーはPragma Headerに特定の値が入った状態でリクエストするとその値に応じてデバッグに利用可能な情報を付けたレスポンスヘッダを返します。以下の通りです。

 

これでChromeを利用した場合にデバッグ情報を取得する方法が分かりました。Chromeでデバッグをする際にはぜひこちらの方法でもお試し下さい。

1. はじめに

 

前回はFailover機能において最もよく用いられるNetStorageを用いたSorryコンテンツの配信設定について説明しました.特に,Failoverが発生した時点からSorryコンテンツがブラウザに返されるまでのプロセスについて詳細に見ていきました.これでLuna上での配信設定については問題なく実装できそうですが,設定後のテストはどうするのでしょうか?Failover動作を実際にテストするということは,オリジンサーバ側でタイムアウトもしくはエラーレスポンスを発行する必要があるということなので,現実的に不可能そうです.

 

アカマイでは,こうした場合でも配信設定のテストを可能にするために,オリジンサーバのタイムアウトやエラーレスポンスを擬似的に作り出す機能を提供しています.今回はその中の一つである"Break Forward Connection"を用いて,Failoverをテストする方法を見ていきたいと思います.前回の記事で扱った配信設定をベースにして,Failoverテストのための設定を追加することにします.

 

 

2. Failoverテストのための配信設定

 

具体的に配信設定を見ていきましょう.下記のルールを追加します.

 

Artificially Break Connectionルール

このルールを"Site Failover"ルールの子ルールになるように配置してください(つまり,"Failover Trigger"ルールや"Sorry Content"ルールの兄弟ルールになります).以下,設定項目の詳細になります.

 

マッチ条件

2つのマッチ条件があり,両者の条件を満たした時に後述のBreak Forward Connectionビヘイビアが適用されることになります(AND条件).それぞれ見ていきましょう.

 

一つ目のQuery String Parameter条件では,リクエストに"simbreakconn-a1xE4=true"というクエリストリングがある場合をマッチ条件とします.この特別なクエリストリングが付加されたリクエストに対してFailoverテストを実施するというフラグとして使用します.注意すべき点として,このクエリストリングによってFailoverが動作してしまうため,一般ユーザーには推測されにくい文字列にする必要があります.今回はFailoverテストを実施するためのフラグとしてクエリストリングを用いましたが,クエリストリング以外にリクエストヘッダを用いることも可能です.また,もっと制限を厳しくしたい場合には,マッチ条件で"Client IP"を使用することでリクエストの送信元IPで制限することも可能です.

 

もう一方の,Path条件では,Sorryコンテンツに該当する"/sorrycontent/*"および"/sorry.html"以外のパスに対してのアクセスであることをマッチ条件とします.Sorryコンテツへのアクセスに関しては,既にFailoverが発生した後のことになるので,この条件が必要になります.

 

Break Forward Connectionビヘイビア

このビヘイビアを有効(ON)にすることで,エッジサーバから先のリクエストが意図的に遮断されます(タイムアウトと同等).そうなると,"Failover Trigger"ルールの条件にマッチすることになり,結果としてFailoverが発動します.

 

以上がFailoverテストのための追加設定になります.

 

 

3. Failoverテストの実施

 

上記で設定した配信設定を用いてFailoverテストを実施してみましょう.ここでは例として"http://site.myexample.com/jp/example.html"を使いたいと思います(注意: このURLは本記事のために内部テスト環境で構築したウェブサイトであり,実際にはアクセスできません.参考として読み進めてください).

 

まずはじめに,通常のアクセスをしてみます.

ブラウザのアドレスバーおよびデバッグウィンドウにある通り,htmlページが200 OKで正常に取得できていることがわかります.

 

続いて,Failoverテストを実施するために上記のURLにクエリストリング"simbreakconn-a1xE4=true"を付加してアクセスしてみます.

ブラウザのアドレスバーには元のアクセスURLのままでSorryコンテンツが表示されています.デバッグウィンドウを見て分かる通り,Sorryコンテンツのベースページはレスポンスコード503で返され,組み込みコンテンツは200 OKで返されていることがわかります.また,アカマイデバッグ用のレスポンスヘッダに含まれるX-Cache-Keyを参照することでNetstorageからコンテンツが提供されていることも確認することができます.前回の記事で説明した仕様で実際に動作していることが確認できました.

 

 

4. むすび

 

今回はエッジサーバ上で擬似的にオリジンサーバがダウンしている状況を作り出す機能("Break Forward Connection")を用いて,Failoverのテストを実施する方法を説明しました.これによって,オリジンサーバに手を加えずにFailover時のSorryコンテンツの配信設定を検証することが可能になります.Failover時のSorryコンテンツは通常のウェブサイトの配信とは異なり,オリジンサーバ,URLパス,レスポンスコードなどをアカマイのエッジサーバで変更してリクエストを生成します.それ故,Sorryコンテンツ内のパス指定を間違いやすく,組み込みコンテンツが読み込まれないなどの問題がよく発生します.そのため,今回説明した方法を用いてSorryコンテンツが問題なく配信され,ブラウザ上で表示されるかテストすることを強くお勧めいたします.

 

注意: LUNAの表示する言語をEnglishとしております.日本語の場合には表示されるメニュー名が翻訳されていることがあります.

以前、 Image Managerの設定方法について(配信設定編) をご紹介しました。今回はImage ManagerのPolicy Managerを設定する方法についてご紹介します。Policyの設定手順としては以下の流れとなります。

 

  1. 対象となるPolicy Setを選択
  2. Default/Custom Policyを編集
    2-1. Derivative Image Widthsを設定 
    2-2. Derivative Image Qualityを設定
    2-3. 必要に応じてTransformationsを設定
  3. Transformationを設定した場合はGenerate PreviewでImage確認
  4. Staging環境へ展開
  5. Staging環境にてテスト
  6. Production環境へ展開

 

1. 対象となるPolicy Setを選択

ConfigureからImage ManagerにあるPolicy Managerをクリックします。

 

該当するContractから配信設定と関連するPolicy Set Nameを選択し、「Manage Policies」をクリックします。

 

2. Default/Custom Policyを編集

Policy Manager上のPolicy設定においてもStagingおよびProduction環境があります。初期のDefault Policy(一般的な設定の入ったポリシー)は配信設定をStagingおよびProduction環境へ展開するタイミングでPolicyがそれぞれの環境へ展開されます。Default PolicyではTransportationはNone、Image WidthsおよびImage Qualityはデフォルト設定となります。Default Policyの設定を変更するために、右上の歯車アイコンから「View/Edit Staging Policy」をクリックします。

 

2-1. Derivative Image Widthsを設定

Derivative Image Widthsではエンドユーザ向けに対して、用意する必要のある画像サイズに応じて自動生成させたい横幅(ピクセル単位)をカンマ区切りで記入します。デフォルトでは320, 640, 1024, 2048, 5000となります。横幅が500ピクセル、750ピクセル、1024ピクセルの3つのみ必要の場合には、500, 750, 1024となります。1つのPolicy Setに対して、デフォルトポリシーおよびカスタムポリシーを含めて最大32個までご利用いただけます。

 

2-2. Derivative Image Qualityを設定

続いて、Derivative Image Qualityから画質レベルを設定します。画像の品質とファイルサイズを見ながら、最適な値を調整して下さい。

 

Quality Level :  1〜100の間で品質レベルを選択できます。値を小さくするほど品質は下がりますが、ファイルサイズも減少します。

Perceptual Quality : 知覚的イメージ品質レベルを「High」から「Low」の5段階の中から選択できます。Lowに下げていくほど品質は下がりますが、ファイルサイズも減少します。

Use Default : 品質レベルが90となります。

 

 

 

2-3. 必要に応じてTransformationsを設定

画質に加えて画像変換を行いたい場合は、「Add a transformation」から変換方法を選びます。対応している画像変換の種類はこちら(Available Transformations)にて詳細をご紹介しております。

 

本ブログではWatermarkの機能を使い、Akamaiロゴをイメージ上に追加してみます。「Add a transformation」から「Watermark/Composite」を選択します。

 

Watermark/Compositeの詳細設定を確定します。ここではAkamaiのロゴを右下に表示される形で設定してみます。

 

3. Transformationを設定した場合はGenerate PreviewでImage確認

設定後はサンプルイメージの下にある「Generate Preview」からサンプルイメージでどのように画像が変換されるか確認できます。

 

4. Staging環境へ展開

Preview画面で問題なければ、右上の「Test On Staging」をクリックしてStaging環境へ展開します。

 

展開中のポリシーはStaging側で確認できる黄色い表示となります。緑色になればポリシーの展開が完了した意味になります。

 

5. Staging環境にてテスト

Staging環境展開後にブラウザ等でテストを実施し、問題ないことを確認します。Staging環境でのテストについては、別ブログ記事Staging環境での動作検証手順についてにてご紹介しております。

 

6. Production環境へ展開

Go-Live On ProductionをクリックしてProduction環境へ展開開始となります。なお、事前にImage Managerを有効にした配信設定をProduction環境へ展開しておく必要があります。

 

Custom Policyの設定について

ここまでDefault PolicyのPolicy設定の手順をご紹介しました。追加でCustom Policyを追加する場合は「Add New Policy」をクリックします。

 

ポリシーの名前を確定し、OKをクリックして画面を進めます。

 

あとはCustom Policyが追加されれば、Default Policyと同様の手順で設定・テストを進める手順となります。

 

なお、Custom Policyは配信設定で以下のようなBehaviorを設定することで、Default PolicyではなくCustom Policyを適用できます。

 

また配信設定ではなくクエリ文字列を指定することでCustom Policyを適用することも可能です。

 

http://www.example.com/image/image001.jpg?impolicy=thumbnail

 

Image Managerに対応するクエリ文字列についてはこちら(Available Image Manager Parameters)でも紹介しております。

 

なお、LUNAの表示する言語をEnglishとしております。日本語の場合には表示されるメニュー名が翻訳されていることがあります。

AkamaiのImageManagerは、イメージ最適化とその自動化を行って、ユーザー状況ごとに最適のイメージを配信し、かつ派生ファイルにまつわる負荷を解消するソリューションとなります。Image Managerの設定は既にある貴社の設定から数ステップで設定いただくことが可能です。手順としては以下のステップとなります。

 

  1. Property Managerの配信設定上でImage Managerのルールを設定し、Staging環境へ展開する

  2. Image ManagerのPolicy Managerを設定し、PolicyをStaging環境へ展開する

  3. Staging環境でテストを行う

  4. 配信設定およびImage ManagerのPolicyをProduction環境へ展開する

 

本記事では1にあるProperty Managerの配信設定上でImage Managerのルールを設定する方法についてご紹介します。

 

まず貴社の配信設定をEdit New Versionを行います。Property ManagerのProperty Configuration Settingsにある「Add Rule」からImage Mangerのテンプレートルールを追加します。

 

検索ボックスに「Image Manager」と入力し、「Insert Rule」をクリックしてルールを追加します。

 

本テンプレートでは以下のような拡張子を満たす場合に、Image Mangerが動作します。

 

Image Managerを一部ディレクトリのみで動作させる場合は「Add Match」からPathをAND条件を追加することで以下のように対象範囲を限定することができます。こちらの例では特定ディレクトリ(/images/*, /images-thumbs/*)配下かつ指定した拡張子が動作する設定となります。拡張子imviewerは今後のImage Managerの機能拡張でご利用いただけるものとなります。

 

続いてBehaviorsを設定します。まずCachingの設定となります。Image Managerを動作させる場合、適用するコンテンツのキャッシュのMax-ageは1日以上で設定する必要があるのでご注意下さい。

 

それでは、Image Mangerの設定を行います。Image Optimization Settingsについて確認します。

 

Scale for Mobile : User-Agent情報を元にモバイル端末の最大画像解像度に合うサイズのイメージを配信する機能となります。

Use Best File Type : User-Agent情報を元に最適な画像ファイルタイプ(WebP等)へ自動変換する機能となります。

Region : エンドユーザからアクセスが多い地域を選択します。Image Managerによって最適化されたファイルはこの地域からAkamaiのEdgeサーバへ配信されます。

 

 

Image Mangerでは通常のCPコードに加えて、Pristine ImageとDerivative Imageの2つのCPコードの設定が必要となります。

 

Pristine Images(変換前の画像)CP Code : Image Managerサーバとオリジン間のトラフィックに対応するCPコードとなります。

Derivative Images(変換後の画像)CP Code : エンドユーザに配信するトラッフィクに対応するCPコードとなります。

※Pristine Images CP CodeとDerivative Images CP Codeは異なる必要があります

 

 

Image Managerに使うPolicy Set(API KEY)の設定を行います。Standardを選択するとProperty名に基づいたPolicy Set Name (API Key)が作成されます。Customに選択するとPolicy Set Nameを決めることができます。Image ManagerのPolicy ManagerでPolicyを作成する際、こちらのPolicy Set Nameに紐付いて設定しますので、管理しやすい名称を付けておくことをお薦めします。

 

 

これでImage Managerのルール追加が完了しましたので、配信設定をStaging環境へ配信設定を展開します。続いてのImage Managerの細かい設定に関わるポリシー設定方法については別記事(Image Managerの設定方法について(Policy Manager編) )にてご紹介しております。

 

なお、LUNAの表示する言語をEnglishとしております。日本語の場合には表示されるメニュー名が翻訳されていることがあります。

1. はじめに

 

前回までの記事ではオリジンサーバが異常動作・ダウンした時にアカマイのエッジサーバがFailover動作を発動するまでのプロセスを解説しました.今回は,Failover動作が発動された時に返す臨時コンテンツ(Sorryコンテンツ)の配信設定について解説していきます.まずFailover動作でサポートする動作方式を説明し,Sorryコンテンツの作成方法を見たあと,アカマイのNetStorageを用いてSorryコンテンツを返す設定方法を具体的に見ていきたいと思います.

 

 

2. Failover時の代替コンテンツ提供の方法

 

アカマイではFailover時のSorryコンテンツを返す方法として,以下の3つの方法が利用可能になっています.

 

  1. エッジサーバ上に有効期限切れのキャッシュが残っていれば,それを返す(Serve Stale Content)
  2. 別のURLにリダイレクトする(外部サイト)
  3. 代替オリジンサーバからSorryコンテンツを返す

 

1.に関しては,クライアントがアクセスしたエッジサーバ上に有効期限切れのキャッシュデータが残っていれば,それをクライアントに返すという動作になります.残っていなければ,オリジンサーバからのエラーレスポンスに基づいて,クライアントに適切なエラーレスポンスを返します.例えば,オリジンサーバがダウンしてタイムアウトを起こしている場合は,504 Gateway Timeoutを返します.

 

2.では,別のURL(外部のサイト)にリダイレクトします.よって,ブラウザ上のアドレスバーにはリダイレクト先URLが表示されることになります.リダイレクトの設定例はFailover(1)の記事にありますので参考にしてください.

 

3.では,エッジサーバ上でSorryコンテンツのリクエストを生成,代替オリジンへ送出し,その結果をクライアントに返します.これをアカマイではリクリエーション(Re-Creation)と呼びます.このリクリエーションではブラウザのアドレスバーにオリジナルリクエストのURLを表示したまま,Sorryコンテンツを提示することが可能になります.

 

以上が,Failover時のSorryコンテンツの提供方法になります.今回の記事では,最もよく使用される3.の方法について詳しく見ていきます.Sorryコンテンツを配信するための代替オリジンサーバとしてNetStorageを用いることにします.

 

 

3. Sorryコンテンツの用意

 

Sorryコンテンツを作成する際には,ベースページ(HTML)から参照されるコンテンツ(組み込みコンテンツ)を通常の配信設定と識別するためにディレクトリを分けておく必要があります.詳細は後述しますが,Failover時にエッジサーバに届くリクエストに対して,通常コンテンツへのリクエストなのか,Failover時のSorryコンテンツ用のリクエストなのかを識別する必要があるためです.

 

ここでは,例として"/sorrycontent/"をSorryページ向けの組み込みコンテンツを配置するディレクトリとして使用します. 今回はNetStorageからSorryコンテンツを配信するため,以下のようなディレクトリ構成でSorryコンテンツを準備しました.

 

sorry.htmlのコード例は下記の通りになります.特に,ページ内の組み込みコンテンツ(png, css, jsファイル)は"/sorrycontent/..."というように絶対パスで記述する必要があります.

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="/sorrycontent/sorry.css">
    <script type="text/javascript"  src="/sorrycontent/sorry.js"></script>
  </head>
  <body>
    <h1>Sorry Page on NetStorage</h1>
    <img src="/sorrycontent/sorry.png">
  </body>
</html>

以上で,NetStorageからSorryコンテンツを配信する準備が整いました.

 

 

4. Luna上での設定

 

それでは実際にLuna Control Centerでの配信設定を説明していきます.細かい動作に関しては後述しますので,ここでは設定項目だけを簡潔に示すことにします.例として"site.myexample.com"というサイト配信に対してオリジンサーバがダウンした場合に上記で準備したSorryコンテンツをNetStorageから配信する場面を考えます.Luna上での配信設定のメイン画面の上部から見ていきます.

 

A. 配信ホスト名(プロパティホスト名)

上図の通り,配信ホスト名("site.myexample.com")に加えて,Failover用配信ホスト名("failoverns.myexample.com")を登録します.Failover用配信ホスト名はFailover発生時にアカマイエッジサーバ上のみで使用する名前になるため,DNSへのレコード登録や新たな証明書の取得は不要です.

 

B. Defaultルール

Defaultルールに関しては,通常の配信設定と同様になります.図中の設定項目およびその値は参考としてみてください. ここではキャッシュ設定をNo-Storeとしていますが,No-Store設定を用いずにキャッシュを許可する場は"Always revalidate with origin"を選択する必要があります(下図).

 

 

C. Site Failoverルール

ここではSite Failover配信設定の親ルールになります.このルールの下にFailoverに関するすべての設定を入れていきます.

 

C-1. Origin Health Detectionビヘイビア

Origin Health Detection(OHD)の設定をします.マッチ条件なしで設定しているので,すべてのリクエストに対して適用されます.OHDに関しては前回の記事を参照してください.

 

 

D. Failover Trigerルール

 

Failoverの条件とその時の動作を規定します.各項目について見ていきましょう.

 

D-1. マッチ条件

オリジンサーバからのレスポンスコードが500, 503, 504のいずれかであった場合,または,オリジンタイムアウトが発生した場合にFailoverが動作するように設定します.

 

D-2. Site Failoverビヘイビア

この設定により,Failover時にSorryコンテンツにアクセスするためのリクエスト("failoverns.myexample.com/sorry.html")を再生成します.この部分が先ほど説明したリクリエーションの設定になります.

 

 

E. Sorry Contentルール

Failover時にリクリエーションされたリクエストに対して,NetstorageからSorryコンテンツを配信する設定を行います.

 

E-1. マッチ条件

ホスト名が"failoverns.myexample.com"である,または,パスが"/sorrycontent/*"であるリクエストを条件にします.

 

E-2. Origin Serverビヘイビア

前節で準備したNetstorageをオリジンサーバとして使用します.

 

E-3. Site Failoverビヘイビア

代替オリジンサーバからエラーレスポンスが返ってきた場合にSiteFailoverの無限ループを回避するために設定します.

 

E-4. Origin Base Pathビヘイビア

Netstorage上のディレクトリ構成に合わせるために"/failoverpage/"をBase Pathとして設定します.

 

E-5. Caching ビヘイビア

Netstorageからコンテンツを配信するためキャッシュ時間を10分に設定します.

 

E-6. Cache HTTP Error Responsesビヘイビア

Netstorageからのレスポンスがエラー(4xx, 5xx)の場合にネガティブキャッシュする設定をします.

 

E-7. Cache Key Query Parameterビヘイビア

Netstorageを使用するのでキャッシュキーにクエリパラメータを含めない設定にします.

 

 

F. Sorry Base Pageルール

Sorryコンテンツのベースページ(HTML)に関して設定を行います.

 

F-1. マッチ条件

Sorryコンテンツのベースページ("/sorry.html")をマッチ条件にします.

 

F-2. Set Reponse Codeビヘイビア

Sorryコンテンツをステータスコード503で返すように設定します.

 

F-3. Downstream Cacheablityビヘイビア

Sorryコンテンツをクライアント側にキャッシュさせないように設定します.

 

 

以上がLuna上での配信設定になります.

 

 

5. Failover時の動作プロセス

 

続いて,オリジンサーバがダウンしている時の動作を追っていきましょう. まずは,クライアントであるブラウザがアクセスするところから始めます.

1. ブラウザで"http://site.myexample.com/jp/"にアクセスします.

 

2. アカマイエッジサーバがブラウザからのリクエストを受信し,(B) Default Ruleに基づいてオリジンサーバへリクエストを転送します.しかし,オリジンサーバがダウンしているため,タイムアウトが発生します(5xxのレスポンスが返る場合も同様です).

 

3. (D)Failover Trigerルールにおいて,(D-1)マッチ条件と(D-2)Site Failoverビヘイビアにより,リクエスト"failoverns.myexample.com/sorry.html"がリクリエーションされます.このリクリエーションは新しいリクエストがエッジサーバにに届くのと全く同様に扱われます.すなわち,通常のリクエストと同様に配信設定のDefaultルールから処理動作が評価・適用されていきます.

 

4. (E)Sorry Contentルールの(E-1)マッチ条件と(E-2)Origin Serverビヘイビア,(E-4)Origin Base Pathビヘイビアによって,NetStorageへ"failoverpage/sorry.html"リクエストを送出します.

 

5. NetStorageからsorry.htmlがステータスコード200で返ります.

 

6. (F)Sorry Base Pageルールの(F-1)マッチ条件と(F-2)Set Reponse Codeビヘイビアによって,sorry.htmlのコンテンツがステータスコード503でブラウザに返ります.さらに,(F-3)Downstream Cacheablityビヘイビアにより,ブラウザ上(および,ダウンストリームにあるプロキシサーバ上)にはSorry.htmlをキャッシュさせないようにCache-Controlヘッダが付与されます.

 

これで,ブラウザに対して,Sorryコンテンツのベースページ(HTML)が返されることになります.

 

7. 続いて,このSorryコンテンツ(sorry.html)の中には組み込みコンテンツが含まれているので,ブラウザは引き続きこれらのコンテンツをエッジサーバに対してリクエストします.

 

ただし,ブラウザ上では,"http://site.myexample.com/jp/"のコンテンツとしてSorry.htmlの内容が返っていることになりますので,続くリクエストもこのURLを起点にして生成されます.よって,ブラウザはエッジサーバに対して,

のリクエストを送信します.

 

8. エッジサーバ上において,これらのリクエストは(E)Sorry Contentルールのマッチ条件(Path is one of "/sorrycontent/*")に該当するため,このルール内のビヘイビアが適用され,ベースパスに"/faiover/"を加えた後,オリジンとしてNetstorageにリクエストを転送します.

 

この動作,すなわち,Sorryコンテンツに関連するリクエストをNetStorageオリジンに向けるために,"2. Sorryコンテンツの準備"で説明した通常コンテンツとfailoverコンテンツ分離のためのディレクトリ構成が必要になります.もし,この分離ができない場合,Sorryページの組み込みコンテンツのリクエストがあった場合に,これらをダウンしている通常のオリジンサーバに対してリクエストを転送することになり,結果としてSorryページ内の組み込みコンテンツがロードできないことになってしまいます.

 

9. オリジンサーバからはそれぞれのコンテンツがステータスコード200で返され,エッジサーバがそれをブラウザへ転送します.これらのコンテンツは(F)Sorry Base Pageルールにはマッチしないため,ベースページの時とはブラウザへのレスポンス動作が若干異なります.そして最終的に,ブラウザに組み込みコンテンツが読み込まれ,Sorryページ全体が表示されます.

 

以上が,ブラウザからリクエストが送信されてから,FailoverによってSorryコンテンツが表示されるまでのプロセスになります.

 

 

6. むすび

 

今回は,Failover時における代替コンテンツ提供方式,Sorryコンテンツの準備方法,および,NetStorageを用いたSorryコンテンツの配信設定について説明しました.次回はFailover設定のまとめとして,Netstorageを用いないFailoverの設定方法およびFailover設定のテスト方法について解説する予定です.

 

注意: LUNAの表示する言語をEnglishとしております。日本語の場合には表示されるメニュー名が翻訳されていることがあります。

本記事では、アカマイ経由でLet's EncryptのDomain Validation (DV)証明書を発行する場合の証明書発行プロセスについて、ご説明させていただきます。

 

まず、証明書発行プロセスの全体像は下図の通りとなります。

 

それぞれのプロセスについて、順にご説明させていただきます。

 

1) SSL Activation Request Formをお客様にて記入していただく

証明書発行を申請する前に、どのような証明書を申請するのかという情報をSSL Activation Request Formに記入していただきます。事前に記入しておいていただくことで、証明書の申請に必要な情報を整理しておくことができます。参考までに、2017年3月版のPDFファイルを添付させていただきます。なお、内容は変更となることがあるため、最新の情報については弊社担当者までご確認いただくことをおすすめいたします。

 

2) CPSにて登録を追加する

Certificate Provisioning System(CPS)での証明書管理 - 証明書申請とSymantec社への確認編にある「証明書申請時の入力項目について」をご確認いただき、1)で記入した情報を元に、CPSから登録を追加します。

DV証明書の場合、CPSに登録していただく組織情報は認証に利用されませんが、システムの都合上、すべて適切に登録していただきますようお願いいたします。

登録を追加すると、sf-no-reply(あっとまーく)akamai.comから「Certificate Notification for COMMON NAME: New order started」という件名のメールが届きます。

※パートナー様には2017年4月現在メールは届きません。2017年Q2を目処にこのメールが届くようになる予定です。

 

3) ドメイン検証情報を取得する

CPSからドメイン検証情報を取得する際は、以下の手順で行います。

a) 「ドメイン検証ステータス」に移動する

 

b) 「検証の説明を表示」に移動する

※ Subject Alternate Names (SAN)に登録がある場合、登録している数だけ情報を取得しておいてください。

 

c) 検証に必要なリダイレクト情報を取得する

 

赤枠で囲われている部分が、検証に必要なリダイレクト情報となります。

上の図より、

 http://{Common Name}/.well-known/acme-challenge/{トークン情報}

より

 http://dcv.akamai.com/.well-known/acme-challenge/{トークン情報}

へリダイレクトする必要があるということが読み取れます。

※ Subject Alternate Names (SAN)に登録がある場合、登録している数だけ情報を取得しておいてください。

 

4) サーバにリダイレクトを設定する

3)で取得したリダイレクトを設定します。リダイレクトは302 Temporaryでご設定ください。

※ Subject Alternate Names (SAN)に登録がある場合、登録している数だけリダイレクトを設定していただく必要があります。

 

5) Let's Encryptより証明書が発行される

リダイレクト設定を実施後、数時間で証明書が発行されます。

 

6) 証明書がアカマイネットワークに展開される

証明書が発行されると、アカマイネットワークに展開されます。

展開は、混雑状況等にもよりますが、概ね1時間30分から2時間程度で完了します。完了した際、CPS上のステータスが「Active」になるのと同時に、sf-no-reply(あっとまーく)akamai.comから「Certificate Notification for COMMON NAME: Successfully deployed!」という件名のメールが届きます。

※パートナー様には2017年4月現在メールは届きません。2017年Q2を目処にこのメールが届くようになる予定です。

これまでキャッシュ消去・無効化について(CCU編)キャッシュ消去・無効化について(ECCU編)をご紹介しました。今回は約5秒という僅かな時間でキャッシュを更新したい場合に便利なFast Purgeについてご紹介致します。

 

Luna公開タブからFast Purgeをクリックします。

 

続いて、Fast Purgeしたい対象URLとネットワーク、消去方法を選択し、送信すれば完了となります。

 

消去方法ではInvalidateとDeleteをお選びいただけます。それぞれに特徴がありますので、状況に応じて適切な方法を選択します。

 

Invalidate:エッジサーバ内の対象コンテンツを無効として認識させます。クライアントからアクセスがあった場合にエッジサーバはオリジンへ最新コンテンツの有無を確認(If-Modified-Sinceリクエスト)します。コンテンツが更新されていない場合(HTTPステータスコード304が応答された場合)、エッジサーバ内にキャッシュされているコンテンツが配信されます。オリジンサーバから最新のコンテンツが応答された場合は、最新のコンテンツがクライアントへ応答されます。

 

Delete:エッジサーバ内の対象コンテンツを完全に取り除きます。「Invalidate」を選択するよりお客様のサーバ負荷が高くなる場合がありますので通常時は無効化を推奨します。

 

Submitに成功後、約5秒でキャッシュの更新が完了します。

 

このようにキャッシュファイルを非常に短時間かつ簡単に更新できる点がFast Purgeの特徴となりますので、ぜひご活用下さい。

以前、キャッシュ消去・無効化について(CCU編)についてご紹介しましたが、今回はディレクトリ単位で更新する場合に活用できる拡張コンテンツコントロールユーティリティ(Enhanced CCU)についてご紹介致します。それでは具体的な流れを見ていきます。

 

コンテントコントロールユーティリティ(Enhanced CCU)のページへ進む

「公開」タブを選び、「コンテントコントロールユーティリティ」をクリックします。

 

「ディレクトリとファイル拡張子による更新」を選択します。

 

対象ファイルを指定する

更新を行うデジタルプロパティを選択します。「要求の名前(オプション)」を指定しておくと、更新開始後に「提出された要求の表示」から、リクエストの状況を確認できます。

 

続いて、ディレクトリを選択します。「/」を指定すると対象デジタルプロパティの全てのコンテンツが、「/store/images」と指定すると「/store/images」配下が更新対象となります。拡張子を限定する場合はドットを付けずにスペース区切りで指定します。例えばディレクトリを「/」と指定し、拡張子を「jpg」と指定すれば、対象のデジタルプロパティに対して拡張子がjpgのファイルを一括更新することも実現できます。そのあとの項目にてEメールを指定すると更新が完了した際にメールが通知されます。「次に」をクリックすると確認画面が表示されます。

 

更新メタデータを提出する

確認画面で、対象のデジタルプロパティ、ディレクトリが選択されていることを確認します。事前に「要求の名前」を記載した場合は、要求名で確認することができます。

 

「提出」をクリックすると、要求IDを確認できます。約30〜40分で更新が完了します。

 

更新内容のステータスを確認する

前述の通り、「提出された要求の表示」からIDおよび要求名で更新状況を確認できます。

 

ECCUはCCUとは異なり、更新方法は消去には対応しておらず無効化のみとなりますが、ECCUではディレクトリ単位で更新が可能という点が最大の特徴となります。なお、消去および無効化についてはキャッシュ消去・無効化について(CCU編)に記載しております。

Akamai の Edge Server でリダイレクトを設定を行う事で、オリジンで行っていたリダイレクト処理を Akamai Edge Server 側にオフロードする事ができます。

 

リダイレクトの条件はいろいろ指定できますが、ここでは HTTPで来たリクエストをHTTPS にリダイレクトしてみます。

 

1) 「Add Rule」で、空のルールを作成します。ここでは「Redirect to HTTPS from HTTP」と名前を付けます。

 

2) IF文とBehavior で以下のように指定します。

 

実際に https で、アクセスして debugツールで確認してみると、http/1.1 (HTTP)が、以下のように 301で h2(HTTPS)  にリダイレクトされている事がわかります。


尚、ここでは301 を使用しましたが、リダイレクトコードは、他にも302, 303, 307 が選択できます。

 

上記の例では、プロトコルを見てリダイレクトをする。という少し特種な例を取り上げましたが、以下のように一般的なサイトのディレクトリ構成の変更時に見られるような、特定パスへのアクセスを、新しいコンテンツのある場所にリダイレクトする設定ももちろん可能です。


例えば以下の設定では、/olddir/* (ワイルドカード指定) に来たアクセスを、別ディレクトリ /newdir/  ルートにリダイレクトします。

 

リダイレクトの条件に指定できる、IF文に指定できる条件は、購入されているオプションによって異なります。
例えば、"Content-Targeting" と呼ばれる、アカマイの IPデータベースを元にした国判定のオプションを追加されている場合は、以下のようにIF文の所で国判定の指定が可能になります。

尚、国判定にる国毎のリダイレクト処理を使って、アメリカのIPから来たリクエストを英語のページに飛ばす場合、例えば「アメリカに居る日本人が、日本語のページを見たい」というユーザーも、英語のページに飛ばしてしまう事になります。

 

そのため、国判定によるリダイレクト処理は、どちらかと言うと特定の地域のユーザーからのアクセスを、「リクエストされたコンテンツは、ご使用の地域から見る事はできません」のようなページに飛ばす、アクセス禁止処理に使用されるケースが多いようです。

本記事では、アカマイ経由ではなくお客様ご自身で任意の認証局の証明書を発行する場合の証明書発行プロセスについて、ご説明させていただきます。

 

まず、証明書発行プロセスの全体像は下図の通りとなります。

 

 

それぞれのプロセスについて、順にご説明させていただきます。

 

1) SSL Activation Request Formをお客様にて記入していただく

証明書発行を申請する前に、どのような証明書を申請するのかという情報をSSL Activation Request Formに記入していただきます。事前に記入しておいていただくことで、証明書の申請に必要な情報を整理しておくことができます。参考までに、2017年3月版のPDFファイルを添付させていただきます。

 

2) CPSにて登録を追加する

Certificate Provisioning System(CPS)での証明書管理 - 証明書申請とSymantec社への確認編をご確認いただき、1)で記入した情報を元に、CPSから登録を追加します。

システムの都合上、必ず一通りご入力いただきますようお願いいたします。

登録を追加すると、sf-no-reply(あっとまーく)akamai.comから「Certificate Notification for COMMON NAME: New order started」という件名のメールが届きます。

※パートナー様には2017年4月現在メールは届きません。2017年Q2を目処にこのメールが届くようになる予定です。

 

 

3) CPSよりCertificate Signing Request (CSR) を取得する

CPSからCertificate Signing Request (CSR) を取得する際は、以下の手順で行います。

a) 設定 > SSL証明書管理より、CPSに進む

 

b) 「登録のアクティビティ」に移動する

c) 「CSRを表示」に移動する

d) CPSからCertificate Signing Request (CSR) をコピーして、テキストファイルとして保存する

 

4) お客様にて任意の認証局より証明書を発行する

お客様にて任意の認証局より証明書を発行していただきます。

※ Private CAにて発行された証明書も対応しておりますが、自己署名証明書(証明書のCommon NameとIssuerが同一の証明書)はアカマイネットワークに展開することができません。ご注意ください。

 

5) 適切な信頼チェーンを準備する

発行されたサーバ証明書からチェーンした中間証明書、(必要であれば)クロスルート証明書をご準備ください。

チェーンが正しくない場合、アカマイネットワークへの展開時に失敗し、証明書を再度取得する必要があります。

 

6) 証明書と信頼チェーンをアカマイネットワークに展開する

証明書と信頼チェーンを展開する際は、以下の手順で行います。

a) 設定 > SSL証明書管理より、CPSに進む

 

b) 「登録のアクティビティ」に移動する

 

c) 「サードパーティ証明書アップロード」に移動する

 

d) 「署名証明書」、「信頼チェーン」をそれぞれペーストし、「アップロード」ボタンを押下する

信頼チェーンは中間証明書→クロスルート証明書の順に、以下のように続けてペーストします。

-----BEGIN CERTIFICATE-----

( 中略 )

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

( 中略 )

-----END CERTIFICATE-----

 

Certificate Signing Request (CSR) 情報と発行された証明書の情報に不一致が認められた場合、設定 > SSL証明書管理 > 登録アクティビティ > サードパーティ証明書警告のレビュ より「承認」または「拒否」する必要があります。

※「拒否」した場合、新しいCertificate Signing Request (CSR)が発行され、証明書の再取得が必要となります。

 

展開は、混雑状況等にもよりますが、概ね1時間30分から2時間程度で完了します。完了した際、CPS上のステータスが「Active」になるのと同時に、sf-no-reply(あっとまーく)akamai.comから「Certificate Notification for COMMON NAME: Successfully deployed!」という件名のメールが届きます。

※パートナー様には2017年4月現在メールは届きません。2017年Q2を目処にこのメールが届くようになる予定です。

本記事では、アカマイ経由でSymantec社のOV/EV証明書を発行をする場合の証明書発行プロセスについて、ご説明させていただきます。

 

まず、証明書発行プロセスの全体像は下図の通りとなります。

 

 

それぞれのプロセスについて、順にご説明させていただきます。

 

1) SSL Activation Request Formをお客様にて記入していただく

証明書発行を申請する前に、どのような証明書を申請するのかという情報をSSL Activation Request Formに記入していただきます。事前に記入しておいていただくことで、証明書の申請に必要な情報を整理しておくことができます。参考までに、2017年3月版のPDFファイルを添付させていただきます。

 

2) CPSにて登録を追加する

Certificate Provisioning System(CPS)での証明書管理 - 証明書申請とSymantec社への確認編をご確認いただき、1)で記入した情報を元に、CPSから登録を追加します。

このとき、OV証明書ならびにEV証明書をご利用の場合、証明書内の"組織 (会社)"と会社内の"会社の正式名称"を一致させていただく必要がございます。

登録を追加すると、sf-no-reply(あっとまーく)akamai.comから「Certificate Notification for COMMON NAME: New order started」という件名のメールが届きます。

※パートナー様には2017年4月現在メールは届きません。2017年Q2を目処にこのメールが届くようになる予定です。

 

3) Symantec社にて認証プロセスを進める

Certificate Provisioning System(CPS)での証明書管理 - Symantec社による認証編をご参照ください。

 

4) Symantec社より証明書が発行される

Symantec社における認証が完了すると、証明書が発行されます。

この時点で、Certificate Signing Request (CSR) 情報と発行された証明書の情報に不一致が認められると、sf-no-reply(あっとまーく)akamai.comから「Certificate Notification for COMMON NAME: Warning messages for your certificate」という件名のメールが届きます。問題なく次のステップに進んでいる場合は、このメールは届きません。

※パートナー様には2017年4月現在メールは届きません。2017年Q2を目処にこのメールが届くようになる予定です。

Certificate Signing Request (CSR) 情報と発行された証明書の情報に不一致が認められた場合、設定 > SSL証明書管理 > 登録アクティビティ > 証明書警告のレビュ より「承認」または「拒否」する必要があります。

※「拒否」した場合、新しいリクエストとして、Symantec社に申請されます。

 

5) 証明書がアカマイネットワークに展開される

証明書が発行されると、アカマイネットワークに展開されます。

展開は、混雑状況等にもよりますが、概ね1時間30分から2時間程度で完了します。完了した際、CPS上のステータスが「Active」になるのと同時に、sf-no-reply(あっとまーく)akamai.comから「Certificate Notification for COMMON NAME: Successfully deployed!」という件名のメールが届きます。

※パートナー様には2017年4月現在メールは届きません。2017年Q2を目処にこのメールが届くようになる予定です。

アカマイ経由でOrganization Validation (OV) 証明書ならびにExtended Validation (EV) 証明書を発行する際は、2017年4月現在、Symantec社の証明書となります。

そのOV証明書ならびにEV証明書を発行する際にSymantec社にて行われる認証プロセスについてご説明させていただきます。

なお、Symantec社のポリシー変更等により、本記事の情報が古くなっている可能性がありますので、あらかじめご了承ください。

 

本記事のカバー範囲はこちらの通りです。

 

 

OV証明書の認証プロセス

Symantec社がOV証明書の認証プロセスを進める際、以下の認証が必要となります。

  • 組織名の妥当性
    • 東京商工リサーチ、帝国データバンクなどの情報を元に、証明書のOrganization欄に入る組織名の妥当性を認証しています。
  • 電話認証の対象となる方の妥当性
    • 電話認証の対象となる方は、上記組織に所属する正社員である必要があります。
    • 電話認証の際は、東京商工リサーチ等から得られる組織の代表電話より対象となる方へ繋いでいただく必要があります。
  • 電話認証による申請内容の承認
    • アカマイ経由で申請している証明書の内容を電話認証にて承認する必要があります。
    • もしご不在で電話認証を完了できなかった場合、チャット、E-Mail、電話などでSymantec社に連絡し、再実施を依頼する必要があります。
    • 電話での認証が難しい場合、メールによる認証にて代用することが可能です。

その他、認証に関するFAQは、こちら (英語版)をご覧ください。

 

EV証明書の認証プロセス

EV証明書の認証プロセスは、上記OV証明書の認証プロセスに加え、以下の認証が行われます。

  • 企業登録の認証
    • 発行から3ヶ月以内の謄本のコピーをSymantec社指定のURLから送付する必要があります。
  • 英文商号の認証
    • 原則、金融庁が運営するEDINETにて確認が行われます。
    • EDINETにて英文商号を確認できない場合、定款にて確認されるため、以下の条件にあった定款のコピーをSymantec社指定のURLから送付する必要があります。
      • 原本証明作成日(3ヶ月以内)が記載されていること
      • 定款原本に相違ない旨の証明文言が記載されていること
      • 組織名(登記上の正式な組織・会社名)が記載されていること
      • 代表者名(印鑑証明書記載の代表者名)が記載されていること
      • 印鑑証明書の登録印(代表者印)の押印があること
      • 押印した代表者印の印鑑証明書(発行から3ヶ月以内の原本)が合わせて提出 されていること

その他、EV証明書の認証に関するFAQは、こちら (英語版)をご覧ください。

今回はFailover機能において欠かせない要素であるOrigin Health Detectionについて解説します.

 

1. はじめに

前回の記事では,オリジンサーバが障害時にアカマイエッジサーバがどのようにFailoverの動作を行うかを見てきました.しかし,デフォルトの機能では,エッジサーバはクライアントからのリクエストを受信する度に毎回ダウンしているオリジンサーバに問い合わせをするため,レスポンスまでの遅延時間が大きく,ユーザー体験を低下させてしまう問題がありました.この問題は,数回のトライアルを行ってもオリジンがダウンしていると判断したら一定期間はオリジンへリクエストを出さないようにすることで回避できそうです.

 

そして,アカマイプラットフォームでこの機能を実現するのが今回の主題であるOrigin Health Detection(以下,OHD)になります.はじめにOHDの動作原理を説明し,実際の配信設定で具体的な値を設定した場合にどのように動作するのかを見ていきたいと思います.

 

2. OHDの動作原理

それでは,今回もフローチャートを用いてOHDの動作を追ってみましょう. OHDはFailover動作の中で機能しますので,前回説明したFailoverが発生した場合にその処理の一部として追加される形になります.図中の緑の部分がOHDに関わる部分です.OHD以外の部分に関しては前回の記事を参照してください.

 

OHDでは,基本的にオリジンサーバのIPアドレスごとにタイムアウト発生回数カウンタ(以下,Bad-IPカウンタと呼ぶことにします)を用意して健康状態を識別します.

 

  1. [Increment Bad-IP Retry Count] アクセス失敗が発生した場合,そのIPのBad-IPカウンタ値を+1します.
  2. [Bad-IP Retry Count] 
    • Bad-IPカウンタの値が設定された閾値(Bad-IP閾値)を超えた場合は, "Marking as Bad-IP"に進みます. このBad-IP閾値は後述するOHDビヘイビアの"Retry Count"によって設定可能です.例えば,"Retry Count=3"と設定した場合,Bad-IP Retry Countが4回(通常の接続1回 + Retry Count設定値 3回)になった時に"Marking as Bad-IP"の動作が発生します.
    • Bad-IP閾値を超えない場合は,"Reconnect Count Over?"へ進みます.
  3. [Marking as Bad-IP] オリジンサーバIPを"Bad-IP"として一定期間マーキングします.マーキングされたIPは"Name Resolusion"で解決されたIPリストから除外されます.このBad-IPとしてマーキングする期間も後述のOHDビヘイビアの"Retry Interval"で設定可能です.この期間がすぎると,Bad-IPマーキングが解除され利用可能なオリジンサーバIPとして扱われます.

 

このBad-IPの扱いは,一台のエッジサーバ上でグローバルに管理されるため,そのエッジーサーバに届くリクエスト全体に適用されます.よって,続く"Available IP?"において他に利用可能なオリジンサーバIPがない場合は,即時的にFailoverになります.一方,他に利用可能なオリジンサーバIPがある場合は,"Pick up an IP, Request to Origin"において,Bad-IP以外のオリジンサーバにリクエストを送信することになります.

 

3. 配信設定とFailover動作

続いて,Luna Control CenterでのOHDの配信設定を見ていきましょう.下図がOHDのビヘイビアになります.

ご覧の通り,3種類のパラメータが設定できるようになります.それぞれのパラメータの意味は下記の通りです.

  • Retry Count: OHDのBad-IP閾値
  • Retry Interval: OHDで"Bad-IP"としてマーキングする期間
  • Maximum Reconnects: Failover判断までのオリジンサーバへの再接続数の上限値(前回説明)

 

具体的にオリジンサーバのIPのAレコードが1つ("10.20.30.40")のみの場合にOHDを下記のように設定したと仮定しましょう.

  • Retry Count = 2
  • Retry Interval = 60秒
  • Maximum Reconnects = 2

 

この設定下でオリジンサーバがダウンしている時に,単体のエッジサーバがブラウザからのリクエストをどう処理するかを見ていきましょう.

 

[Request 1]

はじめにクライアント(Webブラウザ)から最初のリクエストが届きます(オリジンサーバに問い合わせが必要なリクエストとする).エッジサーバはオリジンサーバへリクエストを出し,応答を待ちますが,オリジンサーバがダウンしているためタイムアウトします(origin timeout).エッジサーバは応答をOHDビヘイビアで設定した値に従って,3回(初回の1回+OHD Maximum Reconnects 2回)の接続を試みます.3回目の接続がタイムアウトした時点でFailover動作を発動します.そして,最終的にレスポンスがクライアントへ返されます(Response1).

 

一方,オリジンサーバIP(10.20.30.40)への接続が失敗する度にBad-IPカウンタ(図中では"Bad-IP Retry")値を+1していきます.3回目の接続タイムアウトでBad-IP閾値であるOHDビヘイビア内"Retry Count"設定値(=2)を超えるため,この時点からオリジンサーバIPの10.20.30.40はBad-IP期間に入ります.Bad-IPにマーキングされている期間はOHDビヘイビア内の"Retry Interval"値である60秒間続きます.60秒後にはBad-IPマーキングが解除されるとともに,Bad-IPカウンタもゼロクリアされます.

 

[Request 2-4]

唯一のオリジンサーバIP(10.20.30.40)がBad-IPになっており,利用可能なオリジンIPが存在しないため(No Available Origin IP),即時的にFailover動作が適用されます.

 

[Request 5]

Bad-IP期間が終わり,オリジンサーバIPが再び利用可能になります.よってRequest1の場合と同様の動作になります.

 

 

ここまでは,オリジンサーバIPがひとつだけ(単一オリジン)の場合を見てきました.それでは,オリジンサーバIPが複数ある(複数オリジン)場合はどうなるでしょうか.先ほどのケースと照らし合わせて考えてみると,オリジンサーバのうちダウンしているIPのみがBad-IPにマーキングされ,その期間は他のオリジンサーバのみが利用されるようになります.

 

ここまでの話をまとめると,OHDの効果として次の2点を挙げることができます.

  1. 単一オリジンの場合,アクセスユーザーへ即時にFailoverのコンテンツが提供でき,ユーザー体験低下を回避できる.
  2. 複数オリジンの場合,ダウンしているオリジンサーバを除外して,正常動作しているオリジンサーバのみを利用し,ユーザー体験を損なわずにサービスを提供できる.

 

上記の通りオリジンサーバ異常時のユーザー体験の損失を回避する機能であるFailoverを考えるうえで,OHDは欠かせない要素といえます.

 

4. むすび

今回は,Failover機能を強化する機能としてOHDについて説明しました.オリジンサーバが障害等でダウンしてしまったという異常時であっても,アカマイのFailoverとOHDの機能を用いることでウェブサービスを続行し,ユーザー体験の低下を回避することで,ビジネスインパクトを最小限に抑えることが可能になります.

 

ここまでの連載では,Failoverの動作原理に着目し,どうのような場合にFailover動作が発動するのかについて解説をしてきました.次回からは,Failoverが発生した後に配信する代替コンテンツの設定方法ついて具体的に解説していきます.

 

注意: LUNAの表示する言語をEnglishとしております。日本語の場合には表示されるメニュー名が翻訳されていることがあります。

キャッシュコンテンツを消去・無効化する方法は複数の方法をご提供しておりますが、今回はLUNA上にあるContent Control Utilityの「URLによる更新」(CCU)についてご紹介します。流れとしては以下の通りとなります。

 

  1. コンテントコントロールユーテリティのページへ進む

  2. 対象ファイルを指定する

  3. 対象ネットワーク(ステージング環境・プロダクション環境)を選択する

  4. 更新方法(消去・無効化)を選択する

  5. 通知方法を決定する

 

続いて具体的な作業内容を見ていきます。

1. コンテントコントロールユーティリティのページへ進む

「公開」タブを選び、「コンテントコントロールユーティリティ」をクリックします。

 

「URLによる更新」が選択されていることを確認します。

 

2. 対象ファイルを指定する

消去・無効化の方法は3種類から選択いただけますので、それぞれについてご紹介します。

方法 1. フォームに入力したURLで指定

フォームに1行ずつURLを入力します。

 

方法2. ファイルで指定したURLで指定

対象となるURLが記載されたテキストファイルをアップロードします。

 

方法3. CPコードで指定

対象のCPコードにチェックします。


CP Code あるいはトップレベルのディレクトリの配下にある全オブジェクトを削除・無効化する場合、 削除・無効化後オリジンサーバに高負荷がかかる場合があります。

 

3. 対象ネットワーク(ステージング環境・プロダクション環境)を選択する

ステージング環境もしくはプロダクション環境のどちらの環境を更新するか選択します。

 

4. 更新方法(消去・無効化)を選択する

更新方法は消去および無効化の二種類があります。それぞれに特徴がありますので、状況に応じて適切な方法を選択します。

 

消去:エッジサーバ内の対象コンテンツを完全に取り除きます。「無効化」を選択するよりお客様のサーバ負荷が高くなる場合がありますので通常時は無効化を推奨します。

無効化:エッジサーバ内の対象コンテンツを無効として認識させます。クライアントからアクセスがあった場合にエッジサーバはオリジンへ最新コンテンツの有無を確認(If-Modified-Sinceリクエスト)します。コンテンツが更新されていない場合(HTTPステータスコード304が応答された場合)、エッジサーバ内にキャッシュされているコンテンツが配信されます。オリジンサーバから最新のコンテンツが応答された場合は、最新のコンテンツがクライアントへ応答されます。

 

 

 

5. 通知方法を決定する

更新完了後にEメールの送信が必要であればEメールアドレスを入力して、更新開始をクリックします。

 

更新開始をクリックしたあとの更新要求の確認画面にて、最大完了時間が表示されます。更新したいコンテンツ量によって変化しますが、通常10分前後で完了します。

 

今回ご紹介した方法「URLによる更新」(CCU)の場合、ワイルドカードを用いて、ディレクトリ単位(/js/*等)や、拡張子単位 (*.jpg等)としてお選びいただくことはできません。これらの方法については拡張コンテンツコントロールユーティリティ(ECCU)で実現可能となります。

これから数回に渡って,オリジンサーバから5xxのレスポンスステータスコード(以後,レスポンスコード)が返る場合や,オリジンサーバからのレスポンスがない場合に適用されるFailoverについて説明したいと思います.

 

アカマイでは,オリジンサーバがダウンした場合でも,利用可能なキャッシュデータを利用してクライアントにレスポンスを返すことや,あらかじめ用意してある別のオリジンサーバに問い合わせるなど,オリジンサーバの異常時の処理をFailoverという機能で提供しています.例えば,オリジンサーバがダウンしてクライアントにレスポンスが返せない状態に陥った場合であっても,アカマイからユーザーフレンドリーな代替コンテンツ(カスタムエラーページ,別ホストへのリダイレクト等)を配信可能になり,ユーザー体験の低下によるビジネスインパクトを最小限に抑える事ことができます.

 

今回の記事では,アカマイのひとつのエッジサーバがオリジンサーバから正常ではないレスポンスを受けた場合にどのようにFailoverと判断するのかを説明し,その後,Failover時の動作について説明します.

 

 

1. Failoverの適用

Failoverは主にエッジサーバが送信したリクエストに対して,

  • オリジンサーバが5xxレスポンスコードを返したとき
  • オリジンサーバからのレスポンスがないとき(オリジンタイムアウト)

の2つの場合に適用されます.

 

オリジンが5xxのレスポンスコードを返す場合は,エッジサーバは即座にオリジンサーバのエラーとしてFailoverの判断をします.一方で,オリジンからのレスポンスがない場合(オリジンタイムアウト)は,何回かアクセスを試みてタイムアウトした結果によってFailoverの判断をします.このプロセスをフローチャートを使って見ていきましょう.

 

 

  1. [Client Request] まずエッジサーバの動作は,クライアントからのリクエストを受信するところから始まります.
  2. [In Cache?] リクエストのオブジェクトがキャッシュ(TTLが切れてない状態)されていればそれをクライアントに返して処理は終わります. もしキャッシュにない場合はオリジンサーバーに問い合わせることになります.
  3. [Name Resolution(DNS Cache)] そのために,エッジサーバはオリジンサーバのIPアドレスの名前解決を行います.名前解決が既にキャッシュされていれば,それらの結果を用いることになります.その結果,オリジンサーバのIPアドレスを一つ,もしくは,複数取得し,リスト化します.
  4. [Available IP?] 続いて,オリジンサーバのIPアドレスリストから利用可能なもの(Available IP: 後述するBad-IPマーキングされていないIP,初期状態ではすべてのIPがAvailable)を一つピックアップし,そのIPに対してリクエストを送信します.ここで,利用可能なIPが見当たらない場合,Failover(オリジンタイムアウト)と判断します.
  5. [Origin Response/Response to Client] 上記で送信したリクエストに対してオリジンサーバからレスポンスがあった場合,その結果を基にクライアントへレスポンスを返し,一連の動作は終了します(正常な場合).オリジンサーバからレスポンスがない場合(タイムアウト)は後述の動作になります.
  6. [Increment Reconnect Count/Reconnect Count Over?] もしエッジサーバのリクエストに対してオリジンサーバからレスポンスが一定期間なかった場合,再接続カウンタ(Reconnect Count)を+1した後,再接続数が上限値チェックします.上限値を超えている場合は,Failoverと判断されます.上限値を超えていない場合は再度,利用可能なオリジンサーバのIPに対して同様のリクエストが送信されます.

 

6.で用いられる再接続数の上限値はデフォルトで4回(通常の接続 1回 + Max Reconnect Count 3回)に設定されています.この上限値は次回説明するOrigin Health Detectionビヘイビアによって変更可能になっています.

 

やや複雑でしたが,以上がオリジンタイムアウトによるFailover適用のプロセスになります.

 

2. Failover時の動作

オリジンサーバから5xxのレスポンスが返ってきた場合,もしくは,オリジンタイムアウトが発生した場合,エッジサーバはFailoverの動作をします.Failover動作は下記のフローチャートに示す通り,以下の順で評価されクライアントにレスポンスが返されます.

 

  1. [No-Store or Must Validation?] もし,オブジェクトがNo-Storeもしくは"Must Revalidate"の場合,[Failover Config]へ進む."Must Revalidate"はCachingビヘイビア内で"Force Revalidation of Stale Object"が"Always revalidate with origin"が選択された場合に相当します.
  2. [Stale Cache?] もし,TTL有効期限切れのキャッシュが残っていれば,そのオブジェクトデータをクライアントに返す(Serve Stale Cache).
  3. [Failover Config?] もし,Site Failover設定(Site Failoverビヘイビア)があれば,その動作を行う(Failover Action).
  4. (Default) それ以外の場合,オリジンエラーの結果に応じて5xxレスポンスをクライアントに返す(オリジンタイムアウト場合は504 Gateway Timeoutを返す)

 

 

こららの動作を見るとわかる通り,no-storeに設定されたオブジェクトはSite Failover設定がない場合,デフォルトの5xxエラーをクライアントに返すことになり,ユーザー体験を著しく損なう結果になります.逆に,Site Failoverを設定することにより,ユーザーフレンドリーな代替コンテンツをクライアントに提供可能になります.そのため,Site Failover設定を強くお勧めいたします.

 

 

3. Site Failover設定

Site Failoverビヘイビアを用いることでFailover時の動作を規定することができます. 今回はSiteFailover設定の例として,一番シンプルなリダイレクト処理を行う設定を見ていきましょう. ここで注意すべき点は,Failover先を同じオリジンサーバに向けないようにすることです.オリジンサーバが異常なときに,代わりのリクエストをオリジンサーバにするのは意味がありません.ここでは,別のオリジンサーバ上で動作しているwww.akamai.comにリダイレクトするようにしましょう.

 

 

この設定によって,キャッシュにないオブジェクトへのリクエストに対してオリジンサーバが503, 504のレスポンスを返す,もしくはオリジンタイムアウトが発生した場合に,www.akamai.comへ302リダイレクトされるようになります.

 

 

4. オリジンタイムアウトによるレスポンス遅延

これまで見てきたFailoverの処理プロセスは,一つのリクエストに対するものでした.実際の場面を想定すると,ユーザーが同時に同一オリジンへの複数のリクエストを出すことになります.この場合,複数のリクエストに対して,どのようにFailoverの処理が実施されることになるのでしょうか.

 

実は,エッジサーバに到着する全てのリクエスト毎に毎回Failover判断のプロセスが実施されることになります.つまり,オリジンサーバがダウンしてしまい,オリジンタイムアウトが発生し,さらにFailover判断までのタイムアウト処理が全体で30秒かかるとすると,エッジサーバに到着する全てのリクエストに対して30秒経過しないとFailoverの動作が適用されないことになります.よって,たとえSite FailoverビヘイビアによってFailover動作が定義してあったとしても,毎回30秒間はユーザーのブラウザになんのレスポンスも返されない状態になります.

 

これでは,SiteFailoverの効果が半減してしまします.そもそも,オリジンサーバがタイムアウトしている場合,毎回Failoverの判断をせずに,一度オリジンタイムアウトになったオリジンサーバのIPを覚えておくことはできないのでしょうか.そうすることで,一定期間は問い合わせにいかずに,即時にFailover動作を発動させることで上記のレスポンス遅延の問題が解消できるはずです.アカマイではこの機能をOrigin Health Detection(OHD)という機能で提供しています.OHDに関しては,次回の記事で詳しく説明していく予定です.

 

5. むすび

今回は,エッジサーバからのリクエストに対してオリジンサーバが5xxレスポンスを返す場合や,そもそも応答しない場合の異常時に発動するFailover動作を説明しました.特に,オリジンサーバからのレスポンスがない場合に,エッジサーバはどのようにオリジンタイムアウトと判定するのかのプロセスについて解説しました.次回は,オリジンサーバがタイムアウトを発生させた場合に,一定期間オリジンサーバに問い合わせることなく即時的にFailover動作を発動させるOrigin Health Detectionについて説明します.

 

注意: LUNAの表示する言語をEnglishとしております。日本語の場合には表示されるメニュー名が翻訳されていることがあります。