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

1. はじめに

 

前回の記事では最も典型的なFailover設定であるNetStorageを用いたSorryコンテンツの配信設定について説明しました.これまでいろいろなFailover動作を紹介してきましたので,今回はそれら動作のおさらいとその比較をしてどのような場面でどの設定にすべきかを見ていきたいと思います.また,後半では,前回の記事ではカバーできなかった代替オリジンサーバからSorryコンテンツを配信する設定方法について説明いたします.

 

 

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

 

前回の記事の再掲になりますが,アカマイではFailover時のSorryコンテンツの提供の方法として以下の3つの方式を提供しています.

 

  1. エッジサーバ上に有効期限切れのキャッシュが残っていれば,それを返す(Serve Stale Content)
  2. 別のURLにリダイレクトする(外部サイト)
  3. 代替オリジンサーバからSorryコンテンツを返す
    1. 同一配信設定内でFailoverを設定する(Use alternate hostname in this property) [後述]
    2. Failover用の配信設定を用いる(Use alternate hostname on provider network) [後述]

 

これらの動作の違いについて,もう少し詳しく見てみましょう.それぞれのリクエストの流れは下図の通りになります.

上の図で,オリジンサーバがダウンしてFailoverが動作した後のリクエストの違いについて見ていきましょう.

 

「1.エッジサーバ上に有効期限切れのキャッシュが残っていれば,それを返す(Serve Stale Content)」に関しては,Sorryコンテンツは提供されませんので,説明はこれだけに留めておきます.

 

「2. 別のURLにリダイレクトする(外部サイト)」(以下,リダイレクト)では,Failover時に一度ブラウザにリダイレクトのレスポンスが返り,その後ブラウザが代替ウェブサイトにコンテンツを取得しにいきます.よって,リダイレクト後の代替ウェブサイトはアカマイ化されている必要はありません.また,ブラウザ上では明示的に別のサイトとして扱われるため,アドレスバーにも代替ウェブサイトのURLが表示されることになります(SorryコンテンツのURLがアクセスユーザから見える形になります).当然ですが,代替ウェブサイトはそのドメインがDNSに登録され,一般公開されている必要があります.

 

「3. 代替オリジンサーバからSorryコンテンツを返す」(以下リクリエーション)は,Failover時にアカマイエッジサーバがSorryコンテンツのリクエストをリクリエーション(再生成)し,取得されたSorryコンテンツをブラウザに返します.よって,Failover時においてもブラウザのアドレスバーには通常アクセスと同様のURLが表示されることになります(SorryコンテンツのURLはアクセスユーザからは見えません).また,リダイレクトの場合とは異なり,ブラウザからは一度のリクエスト(元のリクエスト)でSorryコンテンツが返されるため,Sorryコンテンツが表示されるまでの時間が短縮されます.つまり,リクリエーションの場合,リダイレクトに比べて,よりシームレスにSorryコンテンツの配信を行うことが可能になります.

 

このようにリダイレクトとリクリエーションではユーザー体験に影響するため,要件に応じて適宜選択する必要があります.

 

 

3. 代替オリジンサーバを用いたSorryコンテンツ配信の概要

 

前節で説明した「3. 代替オリジンサーバからSorryコンテンツを返す」方式の実装についてさらに詳しく見ていきましょう.この実装方法には下記の2種類があります.

 

  1. 同一配信設定内でFailoverを設定する(Use alternate hostname in this property)
  2. Failover用の配信設定を用いる(Use alternate hostname on provider network)

 

どちらの設定でも代替オリジンサーバとしてNetStorage,もしくは,ユーザーが用意した代替オリジンサーバを用いることができます.前回の記事では,NetStorageを代替オリジンサーバとして「A. 同一配信設定内でFailoverを設定する」方法について解説しました.ただし,上記の2種類の実装方法に関して説明をしてませんでしたので,ここで比較をしてみたいと思います.

 

下図に示した通り,「A. 同一配信設定内でFailoverを設定する」方法では,各配信設定(Property)ごとにFailoverとSorryコンテンツの配信設定を設定するのに対して,「B. Failover用の配信設定を用いる」ではFailover時のSorryコンテンツ配信設定(図中ではProperty X (for Failover))を一つ作成し,それを複数の配信設定で共有することでFailover設定をするという違いがあります.よって,配信設定ごとに,Sorryコンテンツが異なる場合には「同一配信設定内でFailoverを設定する」必要があります. また,配信設定で特にFailover設定を共有化できる場合には「Failover用の配信設定を用いる」ことで設定作業の効率化を図ることができます.

 

 

また,Failover設定についての設定必要項目に関してもいくつかの違いがあります.これについては下記の表にまとめました.

 

A. 同一配信設定内でFailoverを設定する

(Use alternate hostname in this property)

B. Failover用の配信設定を用いる

(Use alternate hostname on provider network)

Failover用配信ホスト名のDNS登録不要

必要

(組み込みコンテンツなしのベースページだけであれば不要)

(SSL配信の場合) Failover用配信ホスト名のSSL証明書設定不要

必要

(組み込みコンテンツなしのベースページだけであれば不要)

Sorryコンテンツの配信設定配信設定ごとに個別設定一括で設定(複数の配信設定で共有)
Sorryコンテンツ内の組み込みコンテンツの指定方法

Failover用パスを決めて,絶対パスで指定

 

e.g.

<img  src="/sorrycontent/sorry.jpg">

Failover用配信ホスト名(Digital Property)で指定

 

e.g.

 <img src="//failover.myexample.com/

sorrycontent/sorry.jpg">

 

 

4. 代替オリジンサーバを用いたSorryコンテンツ配信設定

 (A. 同一配信設定内でFailoverを設定する + ユーザー代替オリジンサーバ)

 

この場合は,前回記事の「A. 同一配信設定内でFailoverを設定する + NetStorageオリジン」の設定方法において,オリジンサーバ設定でNetStorageを指定している部分をユーザーが用意した代替オリジンサーバに変更することで実現可能です.以下では,例として代替オリジンサーバとして"origin-failover-qt246ygk.myexample.com"を使用してSorryコンテンツを配信する設定例について見ていきます.ほどんど前回の設定に同じであるため,差分のみを説明します.

 

4.1 Sorryコンテンツの用意

基本的には前回の記事と同様です.前回の記事ではNetstorage上に配置したSorryコンテンツを今回用いるオリジンサーバ上に配置するのみです.ベースページ(sorry.html)のソースも変更はありません.

 

4.2 Luna上での設定

E. Sorry Contentルール

E-2. Origin Serverビヘイビア

代替オリジンサーバとして"origin-failover-qt246ygk.myexample.com"を指定します.それ以外の項目は代替オリジンサーバの環境に合わせて適宜変更する必要があります.例えば,SSL配信でSorryコンテンツを配信する場合はオリジンサーバ向けのSSL設定(Origin SSL Certificate Verification設定)をする必要があります.

 

上記以外の設定に関しては,前回の記事にある配信設定と同様になります.以上が,ユーザー代替オリジンサーバを用いて同一配信設定内でFailover設定を行う場合の実装方法になります.

 

 

5. 代替オリジンサーバを用いたSorryコンテンツ配信設定

    (B. Failover用の配信設定を用いる + ユーザー代替オリジンサーバ)

 

この場合は,上表で示している通り,Sorryコンテンツ内の組み込みコンテンツをFailover用配信ホスト名(Digital Property)で指定する必要があるため,Sorryコンテンツのベースページ(sorry.html)の内容を変更する必要があります.ここではFailover用配信ホスト名として"failover.myexample.com"を用いることにします.

 

5.1 Sorryコンテンツの用意

sorry.htmlは下記の通り"failover.myexample.com"で指定する必要があります.

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

 

また,Sorryコンテンツのは前節の設定と同様に代替オリジンサーバに配置する必要があります(下図は再掲).

 

5.2 Luna上での設定 - サイト配信設定 (Failoverを起動する側)

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

Failover用の配信設定は別に作成するため,こちらにはサイト配信用のプロパティホスト名"site.myexample.com"のみ設定します.

 

B. Defaultルール

 

これまでと同様にサイト配信のための基本設定を行います.

 

C. Site Failoverルール

これまでと同様にOHDの設定を行います.

 

D. Faiover Triggerルール

Failoverの条件とその時の動作を規定します.

 

D-2. Site Failoverビヘイビア

Actionの項目で"Use alternate hostname on provider network"を選択します.また,Alternate Hostname on Provider Networkの項目では.Failover用の配信ホスト名である"failover.myexample.com"を指定します.これによって,Failover発生時にアカマイエッジサーバ上の"failover.myexample.com"の配信設定が参照されることになります.

 

 

以上がサイト配信設定になります.これまでのFailover設定にはあったSorryコンテンツ配信のためのルール("Sorry Cotentn", "Sorry Base Page"ルール)は後述のFailover用の配信設定内で設定されることになります.

 

 

5.3 Luna上での設定 - Failover用の配信設定 (Sorryコンテンツを配信する側)

Failover時にSorryコンテンツを配信するための配信設定になります.これを通常のサイト配信設定とは別に作成します.Luna上での配信設定のメイン画面の上部から見ていきましょう.

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

上記の通り,Failover用のプロパティホスト名である"failover.myexample.com"を設定します.Sorryページの組み込みコンテンツはこの配信ホスト名でエッジサーバにアクセスすることになるため,サイト公開前にこの配信ホスト名をDNS登録(CNAME)する必要があります.また,同様の理由でSSL配信の場合にはSSL証明書の取得が必要になります.

 

Y. Defaultルール

 

DefaultルールではSorryコンテンツを配信するためのオリジンサーバの設定や各種キャッシュ,パス設定を行います.この配信設定はFailover時にしかアクセスが来ることがないため,これまでの設定であったような通常のサイト用コンテンツとFailover用コンテンツとを分離するためのマッチ条件などが不要になっています.

 

Z. Sorry Base Pageルール

こちらはSorryコンテンツのベースページ(sorry.html)をレスポンスコード503かつクライアント側でのキャッシュを許可しないための設定になります.この部分に関しては,これまでの設定と同様になります.

 

以上が,ユーザー代替オリジンサーバを用いてFailover用の配信設定によってSorryコンテンツを配信する場合の実装方法になります.

 

 

6. むすび

 

今回はFailoverに関しての一連の記事のまとめとして,Failover時のアカマイの動作の方式について比較し,利用用途に応じてどのようにFailoverの機能を使うべきかについて解説しました.また,後半では前回カバーできなかった代替オリジンサーバを用いたSorryコンテンツ配信設定について解説しました.異常系であるFailover動作は,ウェブサイトが正常に動作している間は全く隠れて見えない機能です.しかし,システム障害が発生した時であっても,サービスを継続するための最低限のコンテンツを配信することでビジネスインパクトを最小限に抑えることを可能にする価値のある機能です.これを機にFailoverの導入や設定の見直しの検討をされてみてはどうでしょうか.

 

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

Pragmaヘッダに特定の値を含めてAkamaiサーバへリクエストを行うと様々なデバッグ情報が取得できます。(参考:Akamai設定の検証やデバッグ方法(デバッグヘッダ編))。これらのデバッグ情報を第三者に知られないために、今回はテンプレートルールからデバッグヘッダの表示を限定する方法についてご紹介します。

 

対象の配信設定に対してProperty Managerから設定変更を行います。「Edit New Version」から新しいバージョンを作成し、「Add Rule」をクリックします。

 

左の検索窓に「debug」と入力すると、Remove Debug Infoというルールが表示されますので、Insert Ruleをクリックします。

 

新しくRemove Debug Infoルールが追加されました。こちらのルールはリクエストのPragmaヘッダに特定のキーワードがあればPragmaヘッダを削除してリクエストする動作となります。

 

 

Criteriaの2つ目に書いてある「X-Akamai-Debug」の部分を、別のカスタム値に変更します。今回の例では「ASecureValue12345」と入力しました。

 

設定変更したバージョンをSaveして、AkamaiのStaging環境ネットワークに展開します。展開完了後、ブラウザのデベロッパーツール等でリクエストおよびレスポンスヘッダを確認します。Pragmaヘッダにデバッグ用のパラメータを入れても、Akamaiのデバッグヘッダが応答されないことが分かります。ブラウザ上で特定のヘッダを送信する方法はこちらの記事で紹介しております。(Akamai設定の検証やデバッグ方法(Chrome編)Akamai設定の検証やデバッグ方法(Firefox編))

 

続いて、リクエストヘッダに先ほど設定したカスタムヘッダ(ASecureValue12345: true)を追加してリクエストをします。今度はデバッグヘッダが応答されて、デバッグ情報を取得することができます。

 

Staging環境にて全てのテストを完了し、問題ないことを確認できればProduction環境に設定を展開します。設定が反映されましたら、Akamaiデバッグヘッダの表示が制限されるようになります。

 

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

これらの記事(Akamai設定の検証やデバッグ方法(Chrome編)Akamai設定の検証やデバッグ方法(Firefox編))にてご紹介している通り、Pragmaヘッダに以下パラメータを付与してリクエストを行うと、Akamaiのサーバからデバッグヘッダが応答されます。今回はその中でもデバッグに有用なヘッダについてご紹介します。

 

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

 

X-Cache:Akamaiサーバのキャッシュに関連する動作と、その動作がどのAkamaiサーバによって応答されたかを示します。

例)TCP_MEM_HIT from a23-15-12-111.deploy.akamaitechnologies.com (AkamaiGHost/9.0.0.2-20192836) (-)

※from以降にあるハイフンで区切られている数字は、ドットに置き換えた場合のIPアドレスと一致します。(a23-15-12-111.deploy.akamaitechnologies.comの場合、IPアドレスは23.15.12.111となります。)

 

キャッシュに関連する動作としては以下にご紹介します。

TCP_HIT : Akamaiサーバのキャッシュ(ディスク)からコンテンツが配信された意味となります。
TCP_MEM_HIT : Akamaiサーバのキャッシュ(メモリ)からコンテンツが配信された意味となります。
TCP_MISS : Akamaiサーバにキャッシュが存在せず、オリジンサーバから取得されたコンテンツが配信された意味となります。
TCP_REFRESH_HIT : Akamaiサーバにキャッシュは存在しているが有効期限が切れているため、オリジンサーバへIf-Modified-Sinceリクエストを行い、HTTPステータスコード304「Not Modified」の応答を受け取った後にキャッシュからコンテンツが配信された意味となります。
TCP_REFRESH_MISS : Akamaiサーバにキャッシュは存在しているが有効期限が切れているため、オリジンサーバへIf-Modified-Sinceリクエストを行い、オリジンサーバから取得された新しいコンテンツが配信された意味となります。
TCP_REFRESH_FAIL_HIT : Akamaiサーバにキャッシュは存在しているが有効期限が切れているためオリジンサーバへIf-Modified-Sinceリクエストを行ったものの、何らかの理由でオリジンからコンテンツを取得できず、結果キャッシュからコンテンツが配信された意味となります。
TCP_IMS_HIT : クライアントからIF-Modified-Sinceリクエストを受け取り、AkamaiサーバからHTTPステータスコード304「Not Modified」が応答された意味となります。
TCP_NEGATIVE_HIT : オリジンからHTTPステータスコード404「Not Found」や504「Gateway Timeout」のように正常なコンテンツを配信できなかったケースがキャッシュされており、そのキャッシュが配信された意味となります。このようなキャッシュ時間は「Cache HTTP Error Response」のBehaviorで設定可能です。

なお、X-Cache-RemoteヘッダはTiered DistributionのようなAkamaiサーバを複数経由した場合の経由先サーバに関する同等の情報を示します。

 

X-Cache-KeyCache Key(キャッシュ識別子)に加えて、TTLやCPコード等を含みます。

例)/L/12345/123/1d/origin-www.example.com/index.html

 

こちらの例ではキャッシュの設定が1日で設定されているということ意味になります。1dの箇所が000であればキャッシュしない設定という意味になります。なお、この値はキャッシュの設定やオリジンのレスポンスヘッダによっては実際のキャッシュの有効期限と異なる動作となる場合があります。またTTL(1d)の前にある数字がCPコードになります。上の例では123が割り当てられたCPコードとなります。


X-True-Cache-Key:Cache Keyを示します。

X-Check-Cacheable:Akamaiでキャッシュ対象のコンテンツか否かをYESかNOで示します。(参考 : キャッシュ対象コンテンツの確認について

X-Akamai-Request-ID:リクエストIDはAkamaiの各サーバが払い出すユニークなIDとなります。Akamaiのサポートチームへトラブル等の原因調査を依頼するとき、こちらのリクエストIDとAkamaiサーバのIPアドレスをお伝え下さい。

これまでImage Managerの設定(Image Managerの設定方法について(配信設定編) 、Image Managerの設定方法について(Policy Manager編))についてご紹介しました。今回はImage Manager設定後に必要となる動作確認方法についてご紹介します。まず動作確認を行う上で非常に便利なChromeブラウザの拡張機能Piezをご紹介します。

 

Piezは以下のページから取得できます。

 

インストール後にはPiezアイコンが表示されていることを確認します。

 

PiezアイコンをクリックしてImage Manager(Advanced)を選択します。これで事前準備が完了です。

 

それではデベロッパーツールを表示します。デフォルト設定ではWindowsの場合はF12キーを、Macの場合はCommand+Option+Iキーを押すとデベロッパーツールが表示されます。デベロッパーツールが表示されましたらPiezセクションを選択します。

 

実際にImage Managerを利用しているサイトへアクセスするとブラウザが取得した画像情報が表示されます。

 

Piezは複数項目から構成されるため、各項目について確認していきます。一番上の項目では読み込みを行った該当ページに含まれる画像に対して、全体でどれぐらい容量を削減できたか確認できます。以下の例では16個の最適化された画像が配信され、画像最適化前と比較すると91%(3.96MiB)も容量が削減されたことが分かります。

 

Optimized Offline Detailsの項目ではImage Managerにて最適化画像が配信された画像情報を確認できます。それぞれの意味については以下にご紹介します。

Transformed Image Type:画像変換後のファイル形式

※配信設定側のBehavior「Image Optimization Settings」の「Use Best File Type」をOnにした場合各ブラウザ毎の最適な画像フォーマットが配信されます(参考:Image Managerの設定方法について(配信設定編)

Original Width:画像変換前の横幅[ピクセル]

Pixel Density:ピクセル密度

File Chosen:適用されたImage Managerのファイル名

※ファイル名は、例「.auto.2.960.chrome」のように左から「ポリシー名(.autoの場合はデフォルトポリシー).ポリシーのバージョン.適用された画像の横幅(ピクセル単位).対応ブラウザ」で構成されます

Encoding Quality:画像変換後の画像品質レベル

※Image ManagerのPolicy Managerで設定するDerivative Image Qualityで設定する箇所に該当します(参考:Image Managerの設定方法について(Policy Manager編)

Original Size:画像変換前のファイルサイズ[Bytes]

Transformed Size:画像変換後のファイルサイズ[Bytes]

%Bytes Change:画像変換前後におけるファイルサイズの変化割合[%]

 

なお、URLの部分をクリックすると実際の画像を確認できます。「Click The Image To Toggle」をクリックすると矢印の箇所にある通り、変換前と変換後の画像比較をできますので、画像品質が劣化していないかを確認できます。

 

Optimized Realtime Detailsではファイルサイズの変化量を確認できます。こちらの項目は表示されない場合もあります。

 

最後に表示されている項目、Non Image Manager ImagesがImage Managerの対象とならない画像情報が表示されます。配信設定側でImage Managerの対象としていないパスや拡張子はこちらの項目に表示されます。

 

このようにPiezを利用することで、Image Managerがどのように動作しているかを詳しく確認できるようになります。ぜひImage Managerをご利用頂く場合はPiezを使って動作確認を試してみて下さい。

本ブログでは、Net Storageのアップロードアカウントの作成手順について説明させていただきます。

 

まず、以下の手順によりアップロードアカウントを作成することが可能です。

  1. ストレージグループ設定画面に移動する
  2. ストレージグループ詳細画面に移動する
  3. アップロードアカウントを作成する
  4. Eメールによる検証を行う
  5. アクティベートが完了する

 

では、それぞれの手順を詳しく見ていきたいと思います。

1. ストレージグループ設定画面に移動する

Luna Control Centerの「設定」内にある「NetStorage > 設定」に移動します。

 

2. ストレージグループ詳細画面に移動する

アップロードアカウント追加対象のストレージグループ名をクリックし、ストレージグループ詳細画面に移動します。

※ストレージグループは、アカマイもしくはパートナ様にて事前に作成されている必要があります。

 

3. アップロードアカウントを作成する

ページ下部の「アップロードアカウントの追加」ボタンを押下し、アップロードアカウントの追加画面に移動します。

 

次に、必要な情報を入力し、保存ボタンを押下します。

  • SFTP/SCPを利用する場合は、あらかじめ鍵を作成いただき、その公開鍵をopenssh形式で登録してください。
  • FTPでの利用、またはLog Delivery ServiceでログをNetStorageに保存するためのアカウントを作成する場合は、「パスワード」を選択します。

※セキュリティの観点から、アカマイは、SFTP/SCPでの利用をお薦めいたします。

※アップロードアカウントの作成には、90分から数時間要します。

 

4. Eメールによる検証を行う

ストレージグループ詳細画面に移動すると、作成したアカウントのステータスは「非アクティブ」、前回変更伝搬ステータスは「Eメール検証待ち」になっています。

 

新しいアカウントが作成された旨のメールがアカマイから送信されますので、リンクを押下してアカウントをアクティベートします。

 

5. アクティベートが完了する

Eメール検証を行うと、下図のようにステータスは「アクティブ」となりますが、前回変更伝搬ステータスが「Not Yet Propagated」になっています。この段階ではまだアカウントはご利用いただけない状態です。

 

メール検証の後、90分から数時間が経過すると、アクティベートが完了し、以下のようなメールが送信されます。この時、前回変更伝搬ステータスも「Propagated」となり、利用できる状態となります。

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を目処にこのメールが届くようになる予定です。