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

2017年11月、新しいCertificate Provisioning System(CPS)がリリースされました。

これに伴い、以下のような変更が発生しています。

1. Luna Control Center上のメニュー

これまでCertificate Provisioning System(CPS)とCertificate Provisioning System(CPS)(Beta)という2つのメニューがありましたが、それぞれ以下のように変更されています。

  • Certificate Provisioning System(CPS) → Certificate Provisioning System(CPS)(Legacy)
  • Certificate Provisioning System(CPS)(Beta) → Certificate Provisioning System(CPS)

※ Certificate Provisioning System(CPS)を選択した場合、新しいUIに遷移しますのでご注意ください。

2. 旧Certificate Provisioning System(CPS)のEnd of Life(EOL)

新しいCertificate Provisioning System(CPS)のリリースに伴い、旧Certificate Provisioning System(CPS)がEOLを迎えます。時期は確定していませんが、2018年第一四半期を予定しています。

 

新しいCertificate Provisioning System(CPS)のリリースに伴い、このコミュニティ上の今後のCPSに関する記事は新しいCertificate Provisioning System(CPS)に合わせた内容となりますので、ご了承ください。

既存の記事の内容についても順次、新しいCertificate Provisioning System(CPS)に合わせてリニューアルしていく予定です。

Google/Symantec SubCA 移行の背景

2017年初頭、Google ChromeチームはTLS サーバ証明書発行の不手際についてSymantec社の調査を開始しました。これまでの間、Google Symantec両社は、GeoTrustRapidSSLThawteブランドを含むSymantec発行の証明書について、業界の信用を取り戻すべく努めています。Akamaiはこれまで同様、証明書のパートナーであるSymantecと緊密に連絡を取り合い、Akamaiをご利用のお客様のニーズを代弁するべく、提案へのフィードバックを行っています。

 

GoogleSymantecによると、Symantec が同社の既存PKIインフラストラクチャから発行した証明書は、20184月および201810月の2段階に分け、Google Chromeブラウザから段階的に無効化されます。これらの後は、Google Chrome(およびその他追随するブラウザ)はこれらの証明書が示すサイト向けの「セキュアパッドロック(鍵マーク)」の表示をいたしません。さらに、「安全でないサイト」の警告をアドレスバーに表示するか、エラーページを表示する可能性もございます。Google Chromeの後続バージョンにてSymantecの既存証明書を継続して信頼させるためには、(遅くとも201712月中には利用可能予定の)同社の新しいPKIインフラストラクチャ上で証明書を更新する必要があります。

 

Akamaiはお客様の円滑な証明書更新のため最善を尽くします。対象となるお客様証明書のほとんどは、Chromeによる措置が行われる前に自動で更新されます。その場合お客様に行っていただくアクションはございませんが、Akamaiが管理するお客様の証明書およびお客様が調達されているサードパーティ証明書の中には、お早めに更新いただく必要があるものがございます。これらについては、弊社が証明書更新のタイミングををChromeの無効化開始日より数ヶ月前に前倒しいたします。 

 

影響を受ける証明書

今後のGoogleSymantecの無効化スケジュールは、Symantecが発行した全ての証明書に影響します。Akamaiのお客様の場合、以下の証明書が含まれます:

  • Akamaiの管理下にある全てのSymantec OV SingleSANWildcardWildcard SAN 証明書。
  • Akamaiの管理下にある全てのGeoTrust OV SingleSANWildcard 証明書。
  • Akamaiの管理下にある全てのSymantec EV Single SAN 証明書。
  • 一部のお客様調達のサードパーティ証明書

 

Akamaiの管理下にある、Comodo およびLet’s Encrypt が発行した証明書は、今回の変更による影響はございません。

 

無効化のスケジュール

Chrome 6620183Beta4月に安定版)では、201661日より前にSymantecが発行した証明書は信頼しません。

  • Akamai経由で発行された現在有効なSymantecおよびGeoTrustブランドのOV証明書は、この無効化による影響はございません。これらのOV証明書は全て201661日より後に発行されています。
  • Akamai経由で発行された現在有効なSymantecブランドのEV証明書は、この無効化による影響はございません。これらのEV証明書は全て201661日より後に発行されています。

 

Chrome 7020189Beta10月に安定版)では、2017121日より前にSymantecが発行した証明書および同社旧来のPKIインフラストラクチャから発行された証明書を信頼しません。

  • Akamai経由で発行された全てのSymantecおよびGeoTrustブランドのOV証明書は、この無効化の対象となります。
  • Akamai経由で発行された全てのSymantecブランドのEV証明書は、この無効化の対象となります。

 

GoogleおよびSymantec は、2017121日以降にSymantecおよびGeoTrustが発行した証明書は、Chromeが予定している全ての後続バージョンにおいて信頼されると述べています。

 

新しいトラストチェーン

GoogleおよびSymantec は、2017121日以降に発行した証明書は、新しいPKIプラットフォーム上で発行されると述べています。新しい証明書には、現在取得されるものとは異なるトラストチェーン(中間証明書およびルート証明書)が発行されます。新しいトラストチェーンは既存ブラウザからの認証が続行するため、この変更にお気づきになるエンドユーザは少ないと思われます。これはクロスルート証明書の提供により実現されます。例えば、現在Akamai経由で発行されるSymantec OV SAN 証明書は以下の構成を取っております:

 

エンドエンティティ証明書
“G4
中間証明書による署名:
C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
“G5
ルート証明書”による署名:
C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5

 

TLS クライアントがAkamai エッジサーバに接続する時、Akamaiはクライアントにサーバ証明書と中間証明書を送ります。デバイスやウェブブラウザ上のクライアントが信頼するルートストアにはすでにルート証明書があるという前提のため、接続中のクライアントにルート証明書を送る必要はなく、送られるべきでもありません。 これによりクライアントは、エンドエンティティ証明書からローカルの信頼されたルート証明書までのトラストチェーンを構築することができます。

 

2017121日以降にAkamai経由で発行され、Symantecの新しいPKIインフラが発行したOV SAN証明書は、以下の構成となります:

 

エンドエンティティ証明書
新しいSymantec 中間証明書による署名:
(名称は未定)
新しいSymantec ルート証明書による署名:
(名称は未定)
既存の“G5ルート証明書による署名:
C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5

 

Akamaiは、接続してきたクライアントに対して新しいSymantec ルートのサーバ証明書、中間証明書およびクロスルート証明書を送ります。このトラストチェーンにより、新しいSymantecルート証明書を自身のトラストストアに追加済みのクライアントは、自身が信頼するルートストア内の新しいルートで完結するトラストチェーンを構築することができます。さらに、新しいルート証明書の追加がまだされてない、もしくは追加予定のないクライアントも、サーバ証明書から既存の信頼された”G5"ルートまでのトラストチェーンを構築することができます。

 

CPSで旧来の「Cross-signed 1k root」オプションが有効化された証明書では、以下の新しいトラストチェーンが表示されます:

 

エンドエンティティ証明書
新しいSymantec 中間証明書による署名:
名称は未定)
新しいSymantec ルート証明書による署名:
(名称は未定)
既存の“G5ルート証明書”による署名:
C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
既存の“1k root証明書”による署名:
C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

 

お客様にはできるだけ早くこのCross-signed 1k root の設定を変更されるようお奨めします。TLSクライアントがDefaultのトラストチェーンをサポートするようアップグレード済みの為、ほとんどのお客様には、Cross-signed 1k rootの必要はありません。CPS内で、証明書の「Default」トラストチェーンを選択することで今すぐ設定可能です。

 

GoogleおよびSymantecは、GeoTrust Symantecの両社がAkamaiOVEV証明書向けに新しいトラストチェーンを用意すると述べています。DigiCert は、SymantecPKI事業買収を発表しましたが、これらの新しいトラストチェーンのルート証明書は、Symantecブランドで新しく作成する可能性もあり、既存のDigiCertのルート証明書である可能性もあります。これらのトラストチェーンはまだ生成されておらず、業界ではSymantecからのアップデートを待っている状態です。トラストチェーンが取得可能になりましたら、このアナウンス内容を更新し、弊社Community ページ、「SSL/TLS certificate chains for Akamai-managed certificates」にて発表します。


お客様にとっていただくべきアクション

  • 201661日より前に発行された証明書をお持ちの場合は、20184月までに更新いただく必要があります。該当するお客様には弊社より直接ご連絡し、20181月に対象となる証明書の早期更新を始めます。
  • 201710月より前に発行された現在有効のAkamai経由で発行されたOV証明書は全て、自動的に期限の60日前から更新いたします。つまり、201710月以前に発行された証明書は、全て201810月の無効化前に有効期限を迎えます。既存の証明書は新しい証明書に更新されるまでブラウザでの信頼が続行されます。通常通り、Symantecからの認証のためのEメールおよび電話にご返答いただく以外は、お客様に必要なアクションはございません。
  • その他の、201710月から12月の間にAkamai経由で発行されたOV証明書と全てのEV証明書は201810月までに更新される必要があります。対象となるお客様には20181月より順次Akamaiからご連絡いたします。201810月の無効化前に証明書が更新できるよう、通常の更新日より前に証明書更新を行う予定です。
  • 予定されたSymantec発行の証明書無効化は、GeoTrust,RapidSSLThawteを含む全てのSymantecブランドに適用されます。Akamai Secure CDN上にこれらのブランドのサードパーティ証明書をお持ちのお客様も、この変更による影響を受ける可能性があります。対象のサードパーティ証明書は、2017121日以降に、弊社CPSからCSRを生成しダウンロードいただき、そのCSRSymantecに送付し新しい証明書を取得することにより、証明書の更新が可能です。
  • お客様はいつでも、(Akamai経由で発行しているか、サードパーティかにかかわらず)これらの証明書の早期更新を実施することが可能ですが、証明書がSymantecの新PKIインフラにより発行される2017121日まで、お待ちにいただくことを推奨します。早期更新を実施する場合はCPSにてお持ちの証明書の“Edit and Submit” 操作を行ってください。

 

FAQ(よくある質問)

この変更による、コストや契約への影響はありますか?

現在ご契約の料金は変わりません。また、追加の契約処理も必要ございません。

 

Akamaiはなぜ、証明書発行におけるSymantecとの提携を続けるのですか?

Symantec(今後はDigiCert)はSSL/TLS証明書発行における世界最大手であり、弊社の顧客ベースのニーズに最適であることに変わりがないためです。20164月に発表しましたように、Symantecは、引き続きOV およびEV 証明書発行におけるAkamaiの戦略的パートナーです。

 

SymantecからのOVEV証明書を希望しない場合はどうなりますか?

Let’s EncryptDV SAN証明書を、Akamaiより提供しております。また、お客様がご希望のSSL証明書の種類・認証局を選ぶことができる、サードパーティ証明書もご用意しております。

 

SymantecPKI事業の、DigiCertへの売却は、利用中の証明書にどう影響しますか?

DigiCertの親会社である Thoma Bravoの発表では、Symantec PKI 事業の取得予定は2017 年第4四半期(Symantecの会計年度では2018年第3四半期)とのことです。現行の計画では、この買収は上記の移行プロセスには影響しない予定です。売却後も、Akamai経由で発行されたOVEV証明書をお持ちのお客様は現在と同じ様に弊社Luna ポータルのCPSをご利用いただけます。GoogleおよびSymantec は、2017121日以降に新しいSymantec PKIインフラストラクチャが発行した証明書は、その有効期限日まで引き続き信頼されると述べています。

 

当社のアプリケーションはトラストチェーンの変更に影響を受けやすいのですが、どうしたらよいですか?

Certificate Provisioning System (CPS)の中で、お使いの証明書上でChange Management (“Test on Staging”) ONになっているかをご確認ください。この機能により、お客様は、本番環境に展開する前にStagingにて新しい証明書を検査し試験することができます。Akamaiでは、クライアントアプリケーション内で証明書をピン留めすることはお奨めしません。

 

現在の証明書が更新前に、新しいトラストチェーンを確認できますか?

新しいトラストチェーンが利用可能になり次第、Community ページのSSL/TLS certificate chains for Akamai-managed certificatesAkamai経由で発行された証明書のSSL/TLS 証明書チェーン)にて、中間証明書およびルートを含めた情報を公開する予定です。

 

当社のアプリケーションに、もし、“C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority” ルートで提供された例のような、Cross-signed 1k rootの設定必要な場合はどうしたらよいですか?

お客様はできるだけ早くこのCross-signed 1k rootの設定を変更されるようお奨めします。CPS内で、証明書の「Default」トラストチェーンを選択するだけで設定変更可能です。AkamaiではSymantec OV 証明書をご利用のお客様に、クロス署名された1kルート証明書によるトラストチェーンの提供を続けます。詳細は前述事項をご参照ください。

 

201712月より前に新しいSymantec 証明書を取得できますか?

お客様にはいつでも証明書の更新をいただくことが可能ですが、弊社としては、証明書がSymantecの新PKIインフラにより発行される2017121日までお待ちになることを推奨します。早期更新を実施する場合は、CPSでお持ちの証明書の“Edit and Submit” 操作を行なってください。

 

Akamaiは、なぜ、201712月以降の早期更新を強いらずに、ほとんどの証明書の期限が来て交換されるまで待っているのですか? 

お客様のSymantec 証明書の全てを早期更新することもできますが、弊社はSecure CDN上で数万もの証明書を管理しています。証明書更新日が1年の中で分散されていたほうが、Akamaiのお客様を含めよりよい状態となります。

 

証明書の更新リクエストが201712月以降にSymantecに送信された後、再度OVEVの認証プロセスをに対応する必要がありますか?

証明書の更新時期に正確な確認手順は、業界標準のCA/Browser Forum ガイドラインと、SymantecGoogle両者の決定に即してSymantec が実施されます。 

 

現在GeoTrust を利用中です。このGeoTrust 証明書はどうなりますか?

Akamaiを通じて発行された(Symantec ブランドの1つである)GeoTrust証明書をお持ちのお客様は、引き続きGeotrustにて証明書が更新されます。201712月より前に発行されたGeoTrust証明書がChromeブラウザに認証される為には201810月までに更新を完了する必要がございます。

 

現在利用しているGeoTrust 証明書をSymantecSSL証明書に変えることはできますか?

新しい認証局(CA)への移行については、お客様の担当アカウントチームにお問い合わせください。

 

Let’s EncryptDV SAN証明書は、この変更による影響はありますか?

これらの変更によるLet’s Encrypt 証明書への影響はございません。

 

当社では今でもアカマイ管理下のComodoEV証明書を利用しています。この変更による影響はありますか?

Akamaiが管理するComodo EV の証明書はこれらの変更には影響されません。以前お知らせの通り、既存のComodo 証明書は現在の証明書の期限がくる前にSymantec 証明書へと移行されます。2017121日より前にこの移行が行われた場合、そのSymantec EV証明書は201810月までに再度更新する必要があります。

 

サードパーティ証明書を利用していますが、この変更に影響されますか?

Akamai Secure CDN上に「GeoTrustRapidSSLSymantecThawte」のサードパーティ証明書をお持ちのお客様は、この変更による影響を受ける可能性があります。これらのサードパーティ証明書は、2017121日以降に交換可能です。弊社Certificate Provisioning System (CPS)からCSRを作成してダウンロードいただき、そのCSRSymantecに送って新しい証明書を取得いただくことができます。

 

Akamaiが共有する証明書のトラストチェーンは、変わりますか?

a248.e.akamai.net *.akamaihd.net*.akamaihd-staging.net *.akamaized.net *.akamaized-staging.net」のホスト名に使用される、“a248” 共有証明書のトラストチェーンは、GoogleSymantec両社からの指示に合わせて変更されます。新しいトラストチェーンが利用可能になり次第、Community ページの「SSL/TLS certificate chains for the Akamai shared certificate Akamai共有証明書のSSL/TLS証明書チェーン)」にて新しい証明書の情報を公開する予定です。

 

当社のオリジンサーバにはSymantec発行の証明書があります。Akamaiがこの証明書の信頼をやめるのはいつですか?

Akamaiは、Akamai Secure CDNからオリジンサーバへの接続に関し、これらの証明書の有効期限が切れるまで、Symantec証明書の信頼を続けます。

 

 

本件の英文Akamai Community Postについてはこちらをご覧下さい。

 

この移行についてご不明な点がございましたら、お客様担当のアカウントチーム、または弊社テクニカルサポートまでご連絡ください。

現在、Akamaiの配信設定を作成/変更するときには主にProperty Managerから実施いただいておりますが、Property Managerがリリースされる前の配信設定エディタ、Configuration Managerは2018年3月迄にEOL(End of Life)となる予定です。(Config Manager final EOL delayed until Q1 2018)

 

※Configuration ManagerのEOLに関する情報はこちら(Configuration Manager Retirement)をご参照下さい。

 

そのため、Configuration Managerで作成された配信設定を参照すると以下のような警告画面が表示されます。本記事ではConfiguration ManagerからProperty ManagerへUpgradeする方法についてご紹介致します。

 

Property Managerへ移行する場合は、警告が表示されている箇所にある「Click here」をクリックします。

 

「Click here」をクリックするとProperty Groupsの画面へ遷移しますので、対象となる配信設定のActionにある「Upgrade」ボタンをクリックします。

 

次に対象となるバージョンとUpgrade typeを選択し、「Upgrade Property」をクリックしてProperty Managerでの配信設定を作成します。

 

Choose a version to upgradeUpgrade元となる対象バージョンを選択します。

Choose an upgrade type:2つのタイプから選択します。

Upgrade in-place同一プロパティ内で版数を上げて新規バージョンを作成する方法です。Congiruration Managerの設定情報をUI上で参照できなくなります。

Upgrade to new property:既存のConfiguration Managerを残し、新しいPropertyをバージョン1として作成する方法です。Property Managerの新しい配信設定をActivateする際、Configuration Managerの設定のProperty Hostname(Digital Property)が自動で取り除かれます。

 

 

Property Managerへ移行した配信設定は、必ずStaging環境にてリグレッションテストを実施し、結果に問題がないことを確認してからProduction環境へ展開下さい。

 

また、お客様のConfiguration Mangerの設定によっては本Upgrade方法を実施いただけない場合もございます。その際はアカウントチームへご連絡下さい。

 

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

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の特徴となりますので、ぜひご活用下さい。