はじめに
キャッシュできるコンテンツは、CDN上にキャッシュを配置する事でオリジンへのアクセスが減り、CDN事業社のネットワークを使用する事でユーザーに近い位置からキャッシュを配信できるので、結果としてユーザーに短時間でコンテンツを提供できる事が知られています。
一方でキャッシュできない(するのに手間がかかる) ようなリクエストに関してもCDNのネットワークを介す事で高速化できるという話があります。この記事では実際にAkamai社のCDNを使用してキャッシュしないコンテンツのリクエストがどの程度高速化できるかを実験してみました。
実験1 (オリジン@東京-クライアント@大阪)
測定条件
オリジン： nginx (AWS東京リージョンEC2)
クライアント: f1-micro（vCPU x 1、メモリ 0.6 GB）(GCP大阪）
CDN : Akamai
- HTTPS Standard TLS
- キャッシュ無し(no-store)
- SureRoute(Akamaiのルート最適化機能) ON
- GETで以下のJSONデータを取得。シェル内でループで回して100回連続で取得。
{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 } - シェルを動かしている間 vmstat 1 で CPU使用率を確認したが idle 95-98%くらいでCPUネックでシェルの動作に影響は与えてないように見える。
構成図は以下のような感じです。CDNは Akamaiを使用しました。
図にも書いている通り、SureRoute という機能を有効にしています。SureRouteは、標準のインターネットのルート(BGPルート）とは違うパスをAkamaiが定期的に測定して、もし別のルートが速い場合は、そちらのルートを使用する機能です。また、「Persistent Connection」は、Edger ServerとOrigin間のTCPコネクションをある程度貼りっぱなしにして、同じドメインへのリクエストに対して再利用してあげる機能です。
測定結果は・・・
殆ど変わりませんでした。
実験2 (オリジン@東京-クライアント@イギリス)
測定条件
クライアントのインスタンスが、GCPのイギリスに移動しただけで他は同じです。
構成概要は以下の通りです。
結果は以下の通りでした。
かなり速くなっています。
1回1回のリクエストでは、数十msec？程度しか速くなってないのですが、流石に100リクエストを繰り返すと明確な差になるようです。
オリジン側のTCPセッションを観察
Akamai Edge Server と Origin の間のHTTPセッションは、HTTPの「Keep Alive」を使用して維持され、別のクライアントから来たセッションにそのまま使い回されます。
これにより、TCPやTLSハンドシェイクにかかる時間を節約しています。
今回は HTTPS の接続でテストしたで、netstat で 443 のポートを使うセッションの数がどのように推移するのかオリジン側で観察してみました。
横軸にテスト経過時間、縦軸にHTTPSセッション数をプロットしたのが以下の図です。
オレンジ色がイギリスのGCPインスタンスからオリジンに直接アクセスした時のセッション数ですが、最大でオリジンのセッション数が80程度まで増加しています。100回リクエストを繰り返していてそれぞれのリクエストはすぐに終了しますが、リクエストが終わった後も TIME_WAITの残骸が暫く残るのでこのような形になっています。
一方でCDN経由のアクセスの場合は、オリジン側のHTTPS セッション数があまり伸びず、既存のコネクションを上手く使い回している事が見て取れます。
考察
AkamaiのSureRoute と Persistent Connection を使用した場合、Latencyが大きく、かつリクエスト数が多い場合は、キャッシュを使用しない場合でもクライアントから見てかなりの時間節約になる事があるようです。
時間があれば、SourRoute を OFF にしてみたり、どの要素が Latency の短縮に効果を及ぼしているのか観察してみたいです。。。
また、オリジン側から見た場合、セッション数がかなり節約されており、オリジンの負荷軽減という意味でも CDNの導入は約に立ちそうです。