CDN のデバッグ方法 ツールとレスポンス測定

CDNを利用中の場合、動作の確認や正しくキャッシュしているのか等の調査のために、HTTPヘッダーを確認する機会が多いと思います。今回は、CDN中の人（弊社エンジニア）も使っているGUIツールやコマンドラインの利用方法についていくつかピックアップしてみました。

CDNをデバッグ（調査）するためのツールとは？

CDNをデバッグするためには、HTTPの通信内容を調査する必要があります。このようなツールはGUIとCLIで様々ありますがGUIで確認するツールはCLI（コマンド）と比べ導入・操作の敷居が低いことが特徴です。Chromeなどの主要ブラウザだけでもある程度のデバッグが可能ですので、非エンジニアの方もすぐに調査できることがGUIツールの大きなメリットといえます。いっぽう、ある程度コマンドが利用できる方や大量のURLに対して調査したい場合はCLIの方が優れています。

まず始めに敷居が低いGUIツールについてご紹介します。どちらもChromeブラウザーだけあれば利用できるため大変お手軽です。

CHROME (デベロッパーツール)

Chromeブラウザには標準でデベロッパーツールという開発者モードがあり、これを利用して様々な調査が可能です。デベロッパーツールはChromeを起動した状態で、Windowsの場合 F12 MACの場合 Command + Option + I を押すことでツールが起動します。

Networkパネル

デベロッパーツールの上部にあるNetworkパネルは、各コンテンツへのリクエストヘッダーやCDNまたはサーバーからのレスポンスヘッダが確認でき、さらにレンダリング・読み込み順序が確認できるためページ表示が遅くなっている原因を特定するのに非常に有益です。

Chrome Advanced REST client

ChromeデベロッパーツールはGETリクエストを投げて結果を確認することに特化しており、どちらかというとフロント向けのデバッグツールというイメージが強いですが、高機能なChromeアプリ Advanced REST clientというのもお勧めです。

Advanced REST client は非常に優秀なツールでMethod（GET・POST等）やHTTPヘッダーを個別指定して任意の宛先にリクエストする事ができます。そのため、ユーザーエージェントを指定したリクエストをCDNに投げ、ユーザーエージェント別にキャッシュされているかを確認したり、Methodと認証ヘッダーを指定し素早くキャッシュ削除（パージリクエスト）などもおこなえます。もちろん、レスポンスヘッダーやレスポンスされたBodyも確認出来るためChromeブラウザとAdvanced REST clientがあれば大体のデバッグや調査ができてしまうといっても過言ではありません。

便利な機能。履歴とプリセット

Advanced REST client は一度リクエストした履歴は左側のHistoryという場所に保存されているため、以前リクエストした内容をもう一度送信したい場合はHistoryから簡単に指定することができます。また、リクエストのプリセットを作成し保存した内容をGoogleDrive経由で別のマシンと同期する事もできるため、たとえば、「キャッシュ削除用」「TOPページ」「キャッシュさせないページ」など、サイト毎にデバッグ用プリセットを用意しておくと、いざというときに確認時間が大幅に短縮でき大変便利です。

さて、GUIは非エンジニアの方でも比較的とっつきやすいデバッグツールだとおもいますが、やはり大量のURLや結果を確認したい場合はCLI（コマンド）がベストです。そこでcURL とopenssl s_client という代表的な2つのコマンドを使っていくつかデバッグする例をご紹介します。

cURLコマンド

cURLコマンドはLinuxやMACに標準で搭載されているスタンダードなコマンドラインツールです。まずは以下のコマンドとオプションを覚えましょう。

curl -svo /dev/null リクエスト先IPまたはドメイン名

オプションの意味

-s サイレントモードを有効にします。進行状況やエラーメッセージは表示されません。
-v リクエストとレスポンスを出力します。
-o /dev/null 出力が破棄され、なにも表示されません。

この curl -svo /dev/null  は不要なものを取り除き必要な情報のみ出力させることができるオプションセットです。

デバッグ時は必ずGETで！

curlを使用してCDNをデバッグする場合、curl -Iというオプションは利用しないほうがいいです。I オプションはHEADリクエストを送信するのですが、CDNはGETとHEADリクエストの処理について必ずしも同一のレスポンスを返却するわけではありません。そのため、デバッグする際はしっかりGETリクエストを送る必要があります。

メソッドの指定

HTTPにはGET/POSTに代表されるメソッドがいくつかありますが、cURLも -X オプションでメソッドを指定することができます。任意のURLにパージ（キャッシュ削除）リクエストを送信する場合、GETではなくPOSTやPURGEメソッドを利用することが多いため-Xオプションを利用してメソッドを変更する必要があります。※何も指定しない場合はGETメソッドになります。

curl -svo /dev/null -X POSTリクエスト先IPまたはドメイン名

リクエストヘッダーの指定 -Hオプション

cURLも任意のHTTPヘッダ－を追加してリクエスト出来る-Hオプションというものがあります。-H　に続けて追加したいヘッダー情報を指定する事によって先ほどのGUIツールと同じようなことが可能です。

ホストヘッダー設定例

CDNは基本ホストヘッダーを元にオリジンへのリクエストを決定します。しかし、CDNを経由しないオリジンサーバーのレスポンスヘッダーを見たい時、オリジンサーバーをIPアドレスで指定すると、ホストヘッダーにIPアドレスが入ってしまい、正しい値がとれない場合があります。その場合、以下の様にホストヘッダーを指定してリクエストする必要があります。

curl -svo /dev/null -H 'Host: www.redbox.ne.jp' 'http://オリジンサーバーIP/path/to/file'

ユーザーエージェント設定例

特定のUser-Agent文字列を送ることも可能です。

curl -svo /dev/null -H 'User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X)' 'http://ドメイン名'

圧縮オプション –compressed

-H ‘Accept-Encoding: gzip, deflat’  と指定しても問題無いのですが、curlには–compressed というオプションを指定すると、‘Accept-Encoding: gzip’ リクエストを送信することが出来ます。

SSL/TSLバージョン指定

ここ数年、SSLのセキュリティについて色々な脆弱性が公開されました。弊社でもtls1.0の廃止予定日を公開したばかりですが、脆弱性があるネゴシエーションが無効になっているかどうか簡単ですが確認できるオプションもあります。

curl --sslv3 -svo /dev/null -H 'Host: www.redbox.ne.jp' 'https://ドメイン名'

※通信が出来ない場合は、About to connect()と出力されます。

その他cURLには様々なオプションがありますので興味がある方はマニュアルを確認下さい。

openSSL s_client

次にご紹介するツールは、HTTP通信のデバッグというよりもＳＳＬ通信の内容を確認するためのツールです。まずはこちらのコマンドを覚えましょう。

openssl s_client -connect ホスト名:443 < /dev/null 2>&1

※openssl s_client を実行すると、標準入力を受け付けた状態となりCtrl+Cを入力しない限り終わらないため、実行後にすぐに処理を終了できるよう < /dev/null  を追加しておく。

cURLのように特定プロトコルで通信させる方法

openssl s_client -connect ホスト名:443 -tls1_1 < /dev/null 2>&1

証明書を一式表示させる -showcerts

-showcerts  オプションを利用すると、SSL証明書一式が表示されるため設定したSSL証明書に間違いが無いかどうか確認することができます。

openssl s_client -connect ホスト名:443 -showcerts < /dev/null 2>&1

SNI証明書を利用している場合の注意点

一つのIPアドレスで複数のSSL証明書を扱えるSNIという技術があります。CDN事業者が無料で提供しているSSLなどはほぼSNI証明書なのですが、SSLハンドシェイク時にコモンネームを指定しないと正しいSSL証明書が返却されず、CNという部分に違う名前が出力されることがあります。 その場合 -servername  コモンネーム というオプションを利用して明示的に指定しましょう。

openssl s_client -connect ホスト名:443 -servername コモンネーム（ドメイン名） < /dev/null 2>&1

詳細情報出力 -debug

-debug オプションを利用すると通信の内容まで詳細に出力させることができます。まるっとSSLの情報を取得したいときはdebugオプションを利用することをお勧めします。

openssl s_client -connect ホスト名:443 -debug < /dev/null 2>&1

CDNのデバッグ（レスポンス測定）

先ほどの例では、様々なリクエストを送りデバッグ出来るツールについてご紹介しました。これはCDNの設定が意図した動作になっているかどうかを確認するためのものです。もう一つ忘れてはいけない確認項目はレスポンスの測定です。やはりCDNを導入したからにはレスポンスに問題が無いかどうかも確認しておくべき事項です。

cURLでレスポンスタイムの確認方法

cURLも以下のオプションによりレスポンスタイムの計測が可能です。

curl -kL 'ホスト名' -o /dev/null -w "%{time_total}" 2> /dev/null

単一ロケーションからの測定は無意味

CDNはアクセス元の近くにあるエッジサーバーからコンテンツを配信するというのが本来の基本動作です。そのため、単一のアクセス元からリクエストを送信した場合、常に同じエッジサーバーに着信します。国内配信のみであれば特に問題ないのですが、グローバルへの配信をおこなっている場合は、複数ロケーションからリクエストを送信し測定する必要がでてきます。

全世界の拠点からチェック

よくAWSなどで複数リージョンにEC2を契約し、そこからCDNのレスポンス測定をするのは有効ですか？と質問されることがあります。確かに複数リージョンからのリクエストとなるため適切ですが、もっと手軽に確認できる方法としては、dotcom-toolsという外部サービスを利用することです。このサービスは世界各地にあるサーバーから指定したURLへリクエストを送信しレスポンスタイムを計測してくれます。若干、リージョンによってはあやふやな部分もありますが大まかに問題ないかどうか結果を知ることができます。

回線種別の違いを考慮する

先ほどのようにEC2を各リージョンに立ててレスポンス測定をおこなうことは、厳密に言うと回線種別の違いがあるため実際アクセスするユーザーのレスポンスとは結果が異なる場合があります。インターネット回線は、大きく分けてアクセスするユーザーが利用するコンシューマー向け回線と、EC2などのサーバーが利用するデータセンター向け回線という種別があり、それぞれネットワークMAPでいう位置関係が異なります。そのため、ざっくりですがデータセンターからの通信の方がコンシューマー回線より経由する経路が少ない分、早い結果が得られることがあります。

1つの特定のラストマイルネットワーク上のユーザーに対してのみ、CDNのパフォーマンスが悪くなることは珍しいことではありません。これは、ネットワークが混雑していたりルーティング情報が不適切でアクセス元がアメリカだったにもかかわらずヨーロッパにルーティングされたり、ISPのDNSリゾルバがCDNのDNSネームサーバーに到達できないことがあります。これらの問題を発見することは、それぞれの国のコンシューマー回線から定期的にアクセスして接続してみないことには分かりません。

世界中のコンシューマー回線からテスト

実は世界中のコンシューマー回線からDNS、HTTP、Tracerouteの応答をすばやく収集できるTurboBytes Pulseというサービスがあります。TurboBytes Pulseの「エージェント」のほとんどは、消費者向けISPネットワークに接続されており、米国、カナダ、ヨーロッパ、ブラジル、オーストラリア、インド、タイ、台湾、ベトナムの多くの国が含まれています。

まとめ

今回はCDNの動作確認を行う上で作業を便利にしてくれるツール（GUI/CLI）の利用方法と代表的な利用例についてご紹介しました。それぞれ環境にあった最適なツールで素早いチェックが出来るようにしておくことは悪いことではありません。また、CDNのレスポンスタイム計測方法について、WEBサイトにアクセスするユーザーはオフィスやデータセンターから通信するわけではなく、あくまで家庭内や外出先でラストマイルネットワーク（コンシューマー回線）に接続していることを意識しておくべきです。弊社でレスポンスを計測させて頂く場合などは、回線種別が異なることからあくまで目安の値ということをご案内しています。