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

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としております。日本語の場合には表示されるメニュー名が翻訳されていることがあります。

LunaのOrigin ServerにあるCache Key HostnameはIncoming Host Header(着信ホストヘッダー)とOrigin Hostname(オリジンホスト名)をご選択いだだけます。

 

Cache KeyはAkamaiデバッグヘッダを含めてHTTPリクエストした場合のAkamaiサーバから応答されるレスポンスヘッダにあるX-Cache-KeyやX-True-Cache-Keyにて確認できます(参考:  Akamai設定の検証やデバッグ方法(Firefox編))。Cache Key HostnameがOrigin Hostnameの場合は、Cache Keyの中からOrigin Hostnameを知ることができます。Cache Keyに含まれるOrigin Hostnameを第三者に知られないために、Origin ServerのCache Key HostnameはIncoming Host Headerで設定いただくことをお勧めしております。

 

 

なお、1つのProperty Hostnameで複数オリジンから異なるコンテンツを提供し、Cache Keyが重複し得る場合や、複数のProperty Hostnameで同一オリジンから同じコンテンツを提供し、キャッシュ効率を最大限高めたい場合等、お客様の設定によってはOrigin Hostnameをご選択いただいたほうが良い場合もございます。

 

また既にAkamai化されている配信設定にて本設定を変更する場合、オフロード率の一時的な低下やLog Delivery ServiceのログにあるARLがOrigin HostnameからIncoming Hostnameへ変わりますのでご注意下さい。

 

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

Akamai導入後、下記のような画面が表示されるようになり驚かれたご経験は御座いませんでしょうか?

 

実はこちらはAkamaiのPlatformにて生成・出力しているエラー画面となります。

エラーが発生した"リクエストURL""Reference #" という一見ランダムな英数字が表示されています。

 

『このエラー画面が出たらお手上げ…エラー詳細についてはAkamaiに調査依頼をしなければ…。』

 

…と、Technical Supportチケットを起票しようとしている貴方!

Akamaiでは Translate Error String というツールを公開しており、Luna Control Centerにアクセス出来るユーザーであれば "Reference #" をキーにエラー内容を調べることが可能です。

 

Translate Error Stringの使い方

1) ツールへのアクセス

Translator Error StringRESOLVE メニューからアクセスできます。
RESOLVE > Diagnostic Tools > Service Debugging Tools > Translate Error String を選択します。

 

以下、Translate Error Stringページが開きます。

 

2) ツールの使い方

2-1) エラー画面から Reference # を取得します。

 

2-2) Error stringに 2-1)で取得したReference #を指定し、【Submit】ボタンをクリック、エラー情報を取得します。

 

2-3) ResultのSummary | Error Logs タブからエラー内容を解析します。

Summary

Client IPやReason for Failureなどエラー調査の足掛かりとなる情報が確認できます。

 

Error Logs

詳細なログを確認することができます。個々のログフィールドについてはAkamaiにお問い合わせ頂かないと詳細が不明なものもありますが、"error" フィールド等エラー原因調査に直接的に役立つフィールドもあります。

 

2-4) Download Results から Summary | Error Logs タブで取得した内容をテキスト形式でダウンロード可能です。

Summary | Error Logs タブからエラー詳細を確認しても、やはりエラーの原因が分からないケースもあると思います。その際は、【Download Result】ボタンから Translate Error String ツールでの調査結果をテキスト形式でダウンロード、Technical Supportチケットに添付の上調査依頼をすると障害調査がスムーズに進むかもしれません。(Timestamp、Ghost IP、Client IP、ARL等、調査に必要な最低限の情報が含まれています。)

 

 

なお、今回の例 403 Access Denied (Forbidden) の原因になりそうな設定内容がないか確認してみます。すると、下記のようなクライントの地理情報を条件にアクセスコントールを掛けるルールが設定されていました。上記 (2-3) で取得した Error Log の error フィールドと同様のメッセージ "ERR_ACCESS_DENIED|ptk_default-deny-reason" が設定されていることから、403 Access Denied (Forbidden) の原因は日本国外からのアクセスが原因だと想定することが出来ます。

さらに、Diagnostic Tool (Locate IP) にて該当のClient IPを調べてみると、US > MA > CAMBRIDGE のIPだと言うことが分かります。

 

RESOLVE > Network and Service Debugging Tools > Locate IP

 

 

Luna Control Centerからご利用頂ける各種Diagnostic Tools。

是非、皆様の日々のAkamai配信業務にご活用下さい!

NetStorageアカウントの初期パスワードを変更したい場合はLunaポータルから設定が必要となります。そこで今回はNetStorageにおけるアップロードアカウントのパスワードを変更する手順についてご紹介します。

 

まずLunaの「設定」タブからNetStorageにある設定をクリックします。

 

次に対象のNetStorageGroupをクリックします。

 

ページ下側にアップロードアカウントの設定箇所がありますので、パスワードを変更したいアップロードアカウントの歯車アイコンから編集をクリックします。

 

パスワードの変更をクリックします。またユーザーのEメールアドレスを変更したい場合はこちらの画面から変更が可能となります。

 

 

現在のパスワードと新しく設定したいパスワードを入力します。古いパスワードもそのまま有効にしておく場合はChoose Behavior for existing passwordの項目にて、「keep both the existing password and the new password active」を、新しいパスワードのみを有効にする場合は「Discard the existing password as soon as the new password is active」を選択します。パスワードの変更をクリックして完了となります。設定展開完了後にはEメールアドレスに通知メールが届きます。

Akamai Community はその名の通り、コミュニティサイトですので、皆様に質問を投稿していただき、Akamai もしくは他のご利用ユーザー様から回答を得るというかたちで、ご利用いただくことが可能です。

 

質問の投稿方法

1. Akamai Community ジャパンユーザーグループページより、右上 アクション から 質問 をクリック。

  

 

2. 質問のタイトルと内容を記載し、任意のタグ付けを行い投稿。カメラボタンから、画面キャプチャなども追加可能。

 

以前、セキュア配信に向けた手順についてをご紹介しましたが、配信設定をセキュア化してもオリジンサーバ証明書の有効期限等で証明書を更新することがあると思います。新しい証明書によっては証明書更新後に配信ができなくなってしまう可能性もあるため、今回は証明書を更新する場合の手順と注意すべき事項についてご紹介します。

 

1. 現行配信設定の確認

現行配信設定のオリジンサーバ設定内容から現行証明書がどの種別に属するかを確認します。種類としては以下の4つに分かれます。Origin ServerのBehaviorにある「Origin SSL Certificate Verification」を参照することでどの種類に該当するかを確認できます。

  • Akamai Certificate Store対応の証明書を使用
    Akamai Certificate StoreがEnableである。
  • Third Party Certificate Store対応の証明書を使用
    Third Party Certificate StoreがEnableである。
  • Akamai/Third Party Certificate Store以外の認証局から発行された証明書を使用
    Trustが “Custom Certificate Authorities Set”である。
  • Self-Signed証明書を使用
    Trustが “Specific Certificates (pinning)”である。

 

なお、お客様の設定によっては複数に該当する設定がされている場合があります。その場合は既存証明書がどの設定と本来合致しているか確認する必要があります。

 

2. 新証明書の確認

先の手順で証明書の種類を特定したように新証明書がどの条件に合致するかを確認します。

  • Akamai Certificate Store対応の証明書
    Akamai Certificate StoreのView CA Setから対象となる認証局を確認できます。新証明書がリストにあるルート証明書とチェーンが繋がる場合は、Akamai Certificate Store対応の証明書となります。

    こちらがリストの一部となります。※最新のリストについては必ずLUNAよりご確認ください。
  • Third Party Certificate Store対応の証明書

Third Party Certificate StoreのView CA Setから 対象となる認証局を確認できます。新証明書がリストにあるルート証明書とチェーンが繋がる場合は、Third Party Certificate Store対応の証明書となります。

こちらがリストの一部となります。※最新のリストについては必ずLUNAよりご確認ください。

  • Akamai/Third Party Certificate Store以外の認証局から発行された証明書
    Akamai Certificate StoreおよびThird Party Certificate Store対応していない認証局から発行された証明書は、"Custom Certificate Authority Set" で指定する必要がある証明書となります。
  • Self-Signed証明書の証明書

    上述に該当しない証明書は、"Specific Certificates (Pinning)"で証明書をピン留め設定で固定する必要がある証明書となります。

    なお、諸事情により期限切れの証明書をご利用になる場合にもこちらの設定となります。

 

3. 配信設定の変更と新証明書の適用

新証明書に切替後も配信できるように、必要に応じて配信設定を変更します。

  • 配信設定の変更が不要の場合
    • 新証明書と旧証明書ともAkamai Certificate Store対応の証明書を使用
    • 新証明書と旧証明書ともThird Party Certificate Store対応の証明書を使用
    • 新証明書と旧証明書ともAkamai/Third Party Certificate Store以外の認証局で同一の証明書チェーンを使用
  • 配信設定の追加作業が必要な場合
    • Akamai/Third Party Certificate Store対応する証明書を新たに使用
      Akamai-managed Certificate Authority Setsで新証明書側のStoreをEnableにします。

    • Akamai/Third Party Certificate Storeのリストにない認証局が発行した証明書を新たに使用
      Add Certificateからルート証明書や中間証明書の情報を登録します。

    • Self-Signed証明書を新たに使用
      Add Certificateから新証明書の情報を登録します。

 

新証明書と旧証明書でTrustが異なる場合は"Satisfies any of the trust options below"を選ぶことでTrustオプションを跨いだ設定が可能です。

 

新証明書のCommon NameもしくはSubject Alternative Nameが変更する場合は"Match CN/SAN To"にもご注意下さい。別ブロク記事、「Origin SSL Certificate Verification」の設定について、でも「Origin SSL Certificate Verification」の設定をご紹介しております。

 

4.配信設定の旧証明書用設定の無効化

新証明書に更新したあと、必要に応じて旧証明書用の設定を削除して下さい。

 

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

今回はシステムの安定運用に欠かすことのできないFastDNSのトラフィックモニタ・ログ機能を紹介します.

 

 

トラフィックモニタ・ログ機能の概要

 

DNSはあらゆるWebサービスにアクセスする場合に最初に参照されるポイントであるため,システムの安定性を担保するために,ステータスのモニタリングやログ管理を通常の運用プロセスに組み込むことが求められます.例えば,どのDNSレコードへのアクセスがどこからどの程度あるのか,不正や疑わしいクエリのリクエストがないか,また,問題があった場合にログ解析が迅速に実行できるのか等の要件が常に求められます.これらの観点から,FastDNSではトラフィックモニタ機能およびログ機能を提供しており,次のような特徴を持っています.

 

  • Zoneへのアクセス全体を俯瞰するためのトラフィックモニタ機能
    • 直近3ヶ月間のトラフィックデータを保持 
    • Zone毎のアクセス数の時間推移(グラフ表示)
    • 登録していないレコードへの問い合わせ(NXDOMAIN)の時間推移(グラフ表示)
    • 指定期間内のアクセス数,NXDOMAIN回答数,アクセス全体に占めるNXDOMAIN回答率の集計値
    • 定期的なレポートメールの自動送付
    • CSV形式によるエクスポート機能

 

  • 詳細なアクセス・クエリ結果を見るためのログ機能(FastDNSのLog Delivery Service )
    • DNSクエリ毎のログ記録
      • アクセス日時,アクセス元IPアドレス,クエリ内容,返した結果の内容のログ記録
    • メールによるログデータ送付機能
    • FTPサーバへのログ配置機能
    • NetStorageとの連携

 

これにより,例えば,普段は定期的にEmailでトラフィックモニタレポート受け取りつつ,何か問題があった場合にはLog Delivery Service(以下,LDS)で指定したFTPサーバにアクセスして,発生時前後のログレコードを調べて原因特定を行う,といった運用ができるようになります.また,NXDOMAINの処理結果数の時間推移(トレンド)を調べることで,アタック攻撃やwebサイトシステム内のエラーなどの異常検知を見つけやすくなります.

 

以下では,それぞれの機能の設定方法,および,使い方を解説していきます. なお,本記事ではLUNAの表示する言語をEnglishとしております.日本語の場合には表示されるメニュー名が翻訳されていることがあります.

 

 

トラフィックモニタ機能

 

トラフィックモニタは,前述した通り,Zoneへのアクセス全体を俯瞰する機能を提供します. ここでは,前回までに設定したZoneである"myexample.com"についてアクセス数の時間推移を確認するとともに, 週間のレポート(html形式)をメールで送付する設定を説明します.

 

まず,Luna Control Centerにアクセスし,メニュー上部の"Monitor > FastDNS Traffic"からZoneリストページを開きます.

 

Zoneリストのページにおいて,今回の対象Zoneである"myexample.com"を見つけ"View Report"をクリックしてトラフィックモニタページに進みます. なお,管理するZoneが複数ある場合には検索機能がありますので,対象のZone名の一部を入力するとマッチしたZoneのみリストに表示されます.

 

トラフィックモニタは下図のようなページ構成になっています.

上から見ていくと,次の4種類のトラフィック情報が表示されています.

  1. モニタ対象のZone名とモニタ対象期間の情報
  2. 登録されているレコードへのリクエスト数の時間推移と期間中のピーク値
  3. 登録していないレコード(NXDOMAIN)へのリクエスト数の時間推移とそのピーク値
  4. 上記の統計値

 

トラフィックモニタページを開いたときに表示されるトラフィックのモニタ対象期間は1日(デフォルト)になっています. 例えば,このトラフィックモニタ結果を見てみると,

  • 登録されているレコードへのアクセス数は秒間3-4回の範囲で約2時間ごとの周期がある
  • NXDOMAINへのアクセスは0.4%程度のごく少数で,周期性は特に認められない

ということが大まかにわかるかと思います.

 

また,グラフの右側には今後推定される時間推移が表示されています.これはログ収集過程にある一部の時系列データから推定したもので,ひとつの参考値として用いることができます.

 

もし直近1日ではなくもっと長期の時間推移を確認したい場合や,さらに過去の日時の状況を確認したい場合には,右上部の"Show Last:"からモニタの対象期間を変更することができます.また,任意の期間に設定する場合や,後述するEメールのレポート機能を設定する場合には"More Option"で設定可能になります.ここでは週間レポートをメールで送付する設定を行いますので,"More Option"をクリックして設定ページに進みます(上図参照).

 

 

"More Option"の設定ページでは,以下の3つの機能に応じたにタブ構成になっています.

  • Edit this Report: このトラフィックモニタページで表示する期間の変更
  • Create Email Report: Eメールレポートの作成
  • Download this Report: 時系列データ(CSV形式)のダウンロード

今回はEメールレポートを設定するので,"Create Email Report"タブを開いて,図にあるように必要項目を記入していきます. 最下部にある"Date Range"の項目は,"Reccurence"の項目で繰返し送付の設定("Send Now"以外)を選択した場合は設定は不要です. 設定項目の入力が終わったらページ下部にある"Send Email Report"ボタンをクリックして,設定が完了します.

 

以上で,トラフィックモニタページで確認した内容がHTML形式で毎週配信されるように設定ができました.

 

なお,今回は毎週繰り返し送付する設定にしましたが,期間を指定したレポートを一度だけ受け取る指定も可能です.その場合は,

  • Reccurence: Send Now
  • Date Range: 取得したいモニタ対象期間

を指定します."Send Email Report"ボタンをクリックしたのち,まもなくレポートが指定したEmailアドレス宛に送付されます.

 

 

ログ機能(FastDNSのLog Delivery Service)

 

ログ配信の設定

 

ログ機能であるLog Delivery Service(LDS)では,アクセスがあったDNSクエリ毎にログを記録していきます. そのため,いつ,誰が(送信元IP),どのレコードを参照し,どんな結果を返したかなどを詳細に調べることができます. 前節で詳細したトラフィックモニタ機能では,最大3ヶ月の期間でしたが,LDSではFTPもしくはEmailによって配信するので, 運用次第でトラック可能な期限を自由に設定することができます.FTPサーバはユーザーが用意した一般的なFTPサーバの他に,アカマイが提供するロバストなストレージサービスであるNetStorageを使用することも可能です.なお,LDSをメールで受け取る場合に,メーラーや社内のメールサーバーの受け付けられるファイルサイズに注意いただく必要があります.

 

ここでは,具体的に,1日(24時間)毎にログデータをEmailで配信する設定を見ていきたいと思います.

 

はじめに,Luna Control Centerの上部メニューの"Configure > Log Delivery"からLDS設定ページに進みます.

 

次に,LDS設定ページ内の右の"View By"から"Zone"を選択します(デフォルトでは"CP Code"が選択されおり,ここを"Zone"に変更しないとFastDNSのZoneがリストされませんので注意が必要です).この中からログ配信を設定するZoneである"myexample.com"を見つけます.ここから,図にあるように該当するリスト行の右端にある"Action"上の歯車から"Begin Log Delivery > New"を選択します.設定のポップアップウィンドウが立ち上がります.

 

ポップアップウィンドウは3つのパートに分かれています.最初のパートではログデータの開始日,データファイル名のプレフィックス,およびログ収集の時間周期等を設定します.下図のように必要項目を記入します.

"Aggregation"の項目では,分散的に記録されたログをどう集約して配信するかを設定します.FastDNSは,アカマイの他のプロダクト同様に分散サーバシステムとして構成されるため,それぞれのサーバにログが分散しています.それらをLDSサービスが収集し,指定した宛先(FTPサーバもしくはEmail)に配信することになります.この収集時にそれぞれのサーバから届くログデータをどう集約するかの方式として,アカマイのプラットフォームでは下記の2種類を規定しています.

  • Aggregate by arrival time: 各分散サーバ(FastDNSサーバ)から届いた順に集約する
  • Aggregate by hit time: DNSクエリのログレコード時間順に並べて(ソート)して集約する

前者はログが届いた順に集約されるため,ログの時間系列はソートされていない状態で配信される一方で,後者よりも即時的にログ配信することが可能です.

 

今回は前者の集約方式を24時間単位で行い,ログを配信する設定をすることにします.各項目を入力したら"Next"をクリックして次のステップに進みます.

 

続いて,ログデータの配信手段(Type),ログデータの配信サイズ(Approx. Message Size),およびデータ形式(Encoding)の設定になります.

ここではEmailで受信するので,そのEmailアドレスを記入します.ログデータの配信サイズはログデータが大きい場合に分割するサイズを指定します.gzip圧縮形式が適用されて配信されるため実質ログデータの1/6サイズになります.ここでは5MB(展開後のログファイルサイズは約30MB程度)に設定します.最後にファイル形式は,GZIP+UNENCODED,GZIP+BASE64, GPG(暗号化)に対応しています.ここではもっとも単純なGZIP+UNENCODEDを選択することにします.最後に”Next”をクリックして次のステップに進みます.

 

最後に,連絡先の電話番号およびEmailアドレスを記入します."Finish"をクリックしてLDSの設定が完了します.

 

ここで設定したログ配信設定は下図のようにLDS設定ページのリスト上で確認することができます.FastDNSの"myexample.com"のログ配信がEmail経由で機能している(Active)ことがわかります.

 

以上で,FastDNSのログ配信(LDS)を設定することができました.

 

 

ログデータの確認

 

続いて,上記で設定したログ配信設定によって届いたログファイルの中身を簡単に見ていきたいと思います. データ自体はCSV形式になっており,FastDNSログには下記の項目が一つのログレコードに含まれています.

 

  • 日時
  • リクエスト元IP
  • リクエスト元ポート番号
  • リクエスト名
  • クラス (IN) 
  • レコードタイプ
  • EDNS0 フラグ (Eもしくは空白) 
  • EDNS0 サイズ (もし利用可能でれば)
  • DNSSEC flag (Dもしくは空白)
  • TCPフラグ (Tもしくは空白)
  • DNS回答結果

 

下記が実際のLDSで届いたログになります(一部抜粋).

350560 - 1481599443 13/12/2016 03:24:03,110.4.181.242,38806,mail.myexample.com,IN,ANY,,,,,3600:0 10.20.30.43.myexample.com 3600:"v=spf1 +ip4:192.168.100.0/24 +ip4:10.0.0.0/24 ~all" 
350560 - 1481599444 13/12/2016 03:24:04,110.4.181.242,49263,file.myexample.com,IN,A,,,,,3600:util.myexample.com
350560 - 1481599244 13/12/2016 03:20:44,110.4.181.242,48188,www2.myexample.com,IN,A,,,,,3600:10.20.30.41
350560 - 1481599312 13/12/2016 03:21:52,110.4.181.242,39251,myexample.com,IN,SOA,,,,,3600:a12-65.akam.net hostmaster.akamai.com 2016111701 10800 3600 604800 86400
350560 - 1481599408 13/12/2016 03:23:28,110.4.181.242,39181,myexample.com,IN,NS,,,,,3600:a1-76.akam.net 3600:a9-67.akam.net 3600:a20-65.akam.net 3600:a12-65.akam.net 3600:a13-65.akam.net 3600:a4-65.akam.net

 

これを見ることによって,どのDNSレコードがどのDNSリゾルバからアクセスされているかを詳細に調べることができます.また,LDSの配信設定で"Aggregate by arrival time"を選択したため,ログレコードの順序が日時順に並んでいないこともわかります.さらに,NXDOMAINクエリに対しても,リクエストされたレコードを調べることができます.これによって,何か問題が起こった場合にもログを詳細に見ることで原因追求に大きく役立てることができます.

 

むすび

 

今回は,FastDNSのトラフィックモニタ・ログ機能について紹介しました.DNSは,ほぼすべてのwebシステムの基本サービスとして機能するため,その安定運用のためには動作状況をモニタし,ログを管理することが強く求められます.こうした要求に応えるべく,FastDNSではアクセス全体の状況を俯瞰するための「トラフィックモニタ機能」,および,詳細なアクセス状況を見るための「ログ機能(LDS)」を提供します.これらの機能を使うことによりDNS運用をシンプルに保ち,ひいてはwebサービス全体をよりロバストにすることができるのではないでしょうか.

 

次回はFastDNSのセキュリティ機能について解説したいと思います.

アカマイエッジサーバとエンドユーザ様の間の通信で利用する暗号スイート(Cipher Suites)は、証明書ごとに設定していただくことが可能となっております。本記事では、暗号スイートの最適化必要性とその設定方法についてご案内させていただきます。

 

  • 暗号スイートの最適化必要性

暗号スイートの脆弱性が明らかとなり、その攻撃に備えて暗号スイートの最適化が必要となるシーンが増えてきています。2016年9月のSweet32脆弱性を利用したトリプルDES CBCモードに対する攻撃などは記憶に新しいかと思います。(参考記事)こういった脆弱性を対処しない状態で攻撃を受けると、ホームページの機能停止や情報の流出の危険を伴うため、暗号スイートの最適化が必要となります。

一方で、利用できる暗号スイートを最適化(変更)するということは、これまで接続できていたエンドユーザが接続できなくなってしまう可能性もあるため、最適化の判断は慎重に行う必要もあります。

アカマイから提供している暗号スイートのプロファイル(暗号プロファイル)は、こちらの記事を参考にしてください。脆弱性を含むトリプルDESを除外した暗号プロファイルは、ak-akamai-default-2016q3となります。

※記事の情報は、2016年12月現在のものです。

 

  • 暗号スイートの設定方法

暗号スイートの設定方法をご案内します。暗号スイートの設定は、Certificate Provisioning Systemから実施可能です。

1. SSL証明書管理に移動します。

 

 

2. "TLSメタデータの編集"に移動します。

 

 

3. 暗号スイートを設定します。

 a. アカマイで事前に設定しているプロファイルを利用する場合

  1) "暗号プロファイル"グループの"必要な暗号"と"優先する暗号"において、プルダウンより設定したいプロファイルを選択します。

  ※SSLハンドシェイクを行う際、まず最初に"優先する暗号"から利用するCipherの選択を試みますが、利用できるものがなかった場合に"必要な暗号"のCipherから選択を試みます。特に要件がない場合は、"必要な暗号"と"優先する暗号"は同一にしておくことが推奨されます。

  ※最新の暗号プロファイルは、こちらの記事にてご確認ください。

 

 

 

  2) 最下部の"Submit"ボタンを押下します。

  3) 設定の反映には、1〜1.5時間ほど要します。

 

 b. 任意の暗号スイートを設定する場合

  お客様ご自身では設定いただけません。

  弊社アカウントチームまでご相談ください。

HTTPSによるセキュア配信を行うためにはコンフィグのセキュア化が必要となります。今回はセキュア化で必要な作業をご説明致します。最初に流れについてご紹介します。

 

  1. Certificate Provisioning System(CPS)にて証明書のご用意

  2. セキュリティコンフィグのご準備( ~.edgekey.netと配信設定の作成)

    2-1. SecureオプションのチェックとProperty Hostname(~.edgekey.net)のご準備
    2-2. Behaviorの変更(「Origin SSL Certificate Verification」の設定等)
    2-3. Staging環境展開
  3. お客様試験

  4. Production環境展開

  5. CNAME先の変更(~.edgesuite.netから~.edgekey.net)

 

それでは具体的に作業内容を見ていきます。

 

1. Certificate Provisioning System(CPS)にて証明書のご用意

AkamaiではSSL/TLS通信がClientからAkamaiサーバ、Akamaiサーバからお客様オリジンサーバでそれぞれで終端するため、オリジンサーバとAkamaiサーバでそれぞれ別のサーバ証明書のご準備が必要となります。ここではAkamaiサーバ側で実装する証明書の準備をします。Akamaiサーバで実装する証明書はCertificate Provisioning System(CPS)にて設定できます。Certificate Provisioning Systemについてはこちらの記事(Certificate Provisioning System(CPS)での証明書管理 - 証明書申請とSymantec社への確認編)で詳しく記載しております。

 

Akamaiサーバ側に実装する証明書の準備が完了後、配信設定の変更作業を行います。セキュア化する前の対象となる配信設定から「Edit New Version」で新しい配信設定を作成します。

 

2. セキュリティコンフィグのご準備( ~.edgekey.netと配信設定の作成)

2-1. SecureオプションのチェックとProperty Hostname(~.edgekey.net)のご準備

配信設定の「Property Version Information」にある「Secure Options」にチェックを入れます。

「Property Hostnames」にある「Add」をクリックして、Property Hostnameを追加設定します。

「Add Hostname(s)」に対象となるHostnameを入力して「Next」をクリックします。同じHostnameでセキュア化する場合は既存のHostnameと同じ設定となります。

続いてIP Versionに関して「IPv4 only」か「IPv4 + IPv6(dual stack)」を選択し、「Next」をクリックします。

1のCertificate Provisioning System(CPS)で作成した証明書を選択して「Next」をクリックします。(作成したHostnameに対して証明書のCommon NameもしくはSubject Alternative Nameが合う証明書のみ表示されます)

EdgeHostname(〜.edgekey.net)が自動作成・表示されますので、問題がなければ「Submit」をクリックします。ペンのアイコンをクリックすると、編集できます。

「Success」画面が表示されましたら「Close」をクリックします。

「Property Hostnames」に新しく作成したホスト名が追加されており、証明書も関連付けられていることを確認できます。

続いてEdgeHostname(〜.edgesuite.net)を削除します。もともと設定されているEdgeHostname(〜.edgesuite.net)側のHostnameのチェックボックスにチェックして、"Delete Selected"をクリックして削除します。

 

これでProperty Hostnameの設定が完了しました。続いてオリジンサーバ側の設定を行います。

 

2-2. Behaviorの変更(「Origin SSL Certificate Verification」の設定等)

セキュア化に伴い、既存のBehaviorの設定変更を行います。オリジンサーバの証明書をご用意できましたら、オリジンサーバのBehaviorにある「Origin SSL Certificate Verification」の設定します。設定方法については別の記事(「Origin SSL Certificate Verification」の設定について)でご紹介しております。

またSiteShieldを有効にされている場合は、SiteShield MAPの変更が必要となるため、事前にMAPを作成する必要があります。「〜.akamaiedge.net」となっているものが対象のMAPとなります。

 

2-3. Staging環境展開

セキュア化に伴う配信設定の変更が完了したら、Staging環境でコンフィグ展開を実施します。これに伴い、2−1で用意した新たなEdgeHostname(〜.edgekey.net)が作成されます。

 

展開が完了したら、セキュア化対応しているStaging用(〜.edgekey-staging.net)のIPアドレスが取得できるか確認してみます。Staging環境のIPアドレスの取得および動作手順については別記事(Staging環境での動作検証手順について)にて詳しくご紹介しております。

 

3. お客様試験

Staging環境で検証をします。検証方法についてはこちらの記事、Akamai設定の検証やデバッグ方法(Firefox編)でご紹介をしております。

 

特に試験では、期待通りの証明書が払い出されること(Common NameもしくはSubject Alternative Name等)やオリジンサーバからSSL/TLS通信でコンテンツを取得できていることを必ずご確認下さい。

 

4. Production環境展開

3の試験で問題がなければ、Production環境でも配信設定を展開します。

 

5. CNAME先の変更(~.edgesuite.netから~.edgekey.net)

CNAME先をEdgeHostname(〜.edgekey.net)へ変更することで、セキュア化の配信準備が完了となります。何か問題があった場合に備えて、変更後のDNSのTTLは短めで作業を実施することを推奨致します。またキャッシュ設定によっては切替直後にオフロード率が低下することもあります。

 

 

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