あなたのアカマイ大丈夫？
Tweet
こんにちわ、宇津井です。今回は私が陥ってしまったCDNの落とし穴について書いていきます。
アカマイと言えば言わずと知れた世界をリードするCDN事業者です。 最近はSaaSプロバイダを目指しているようで、先日行われたAkamai Conference 2015では特にセキュリティプロバイダを意識した内容になっていましたので、CDN事業者と言われる事は嫌うかもしれません。
今回はAkamai Conference 2015とは全く関係なく、且つ最新のアカマイソリューションにも全く触れません。単純にCDNとしてアカマイを1年以上運用していて、普段LUNA Control Center(Akamaiの管理コンソールをLUNAと呼びます)なんかほとんど見ないよーという方に見ていただけて共感していただけると嬉しい感じです。当社ではCDNとしてアカマイを採用しているのでアカマイでの例となりますが、他のCDN事業者でも同様の事が言えるかもしれませんので、そのような方にもこの記事が届くと幸いです。
あなたのアカマイ大丈夫？
さて、本題です。アカマイ自体は非常に安定していて、サービスが止まってしまうというような事は滅多に起きません、大丈夫だと思います。 今回問題提起しているのは、数年前にコンフィグを投入してから見直しを実施していなかったプロパティがある場合、何か問題が発生している可能性があるから定期的な見直しが必要だよというお話です。
そんな事は百も承知で、モニタリングばっちりな方々には何の価値もない記事かもしれませんが、ご容赦ください。 当社ではアカマイのプロパティ数が40を超えていて、細部まで目を行き届かせていなかった事でオフロード率(キャッシュヒット率)の低下が起きていましたので、状況の把握方法と、その対策について書いてみます。
オフロード率
他社のオフロード率ってどれ位なんだろう？という疑問を持つ事多いですよね。当社は多くのサービスでアカマイを利用しているので、CGMだったらこれくらい、その中でも静的コンテンツならあれくらいといった感覚値は持っていたものの、実際に細かくモニタリングしてみるとその目標値みたいなものに届いていたり届いていなかったり、バラバラでした。届いていなくても、対策をする事で目標値を大幅に超えていくケースもありました。
以下に諸々の対策を実施する前のオフロード率をいくつか晒します。サービスの特徴、キャッシュ対象、その他諸々の条件化でオフロード率は変わってきますのであくまでも参考数値として捕えてください。
個人的にはCGMなら90%、静的コンテンツは99%のオフロード率というのが今回見直す迄の私の基準でした。
契約全体のオフロード状況確認方法
アカマイでオフロード率を確認するには「Offload」モニターを利用するのが一番手っ取り早いです。 全てのCPコードを対象にして6月初旬のオフロード率を表示といった指定が出来ます。
LUNAでは件数が多い場合にやや見づらいので、私はcsvダウンロードしたものを閲覧しています。
それでは当社で提供しているサービスのオフロード率を一部抜粋した内容をご覧ください。（対象期間:2015/6/1〜2015/6/6）
如何でしょうか、99.9%という高いオフロード率を達成しているサービスもあれば、明らかにオフロード率が低いサイトが存在していました。 90%に満たないサイトは軒並み対策を実施しました。
なお、LUNAではEmail Reportという機能があって、これを設定するとdairy,weekly,monthly等で定期的にレポートを送信してくれる機能が有ります。今回の驚きをきっかけに設定しました。
新しい画像フォーマットへの対応不足
さて、対策を検討していきます。39.5%という恐ろしいくらい低いオフロード率を叩き出しているCoordisnapのユーザアップロード画像部分から見ていきましょう。
「Offload」モニターの項目に「TOP URLS」という項目があります。その名の通りですが、指定した期間中にリクエストが発生した上位50件がLUNA上で確認可能です。こちらが2015年6月初旬のスクリーンショットですが非常にマズいです！拡張子「.webp」のリクエストを一切キャッシュしておらずオリジンへ毎回リクエストを転送していて、まるでプロキシ状態です。
どうしてこうなったかというと、アカマイでのキャッシュ設定で拡張子毎にキャッシュ時間等を制御していた為です。 こちらがキャッシュ制御の画面ですが、指定した拡張子にマッチした場合にのみ30日間のキャッシュを持つという設定ですが、比較的新しい画像フォーマットの拡張子を記載していませんでした。。
新しい拡張子を採用する場合はhttpサーバー等でmime/typeとかの意識はすると思いますが、Akamaiのキャッシュ対象に加えるという事を忘れないようにしないといけません。 拡張子「.webp」とついでに「.pjpeg」をキャッシュ対象に加えたところオフロード率は95%程度迄急上昇しました。 今後他の画像フォーマットを利用する際はアカマイのキャッシュ対象に入れる事を忘れないようにしないとです。
こちらがオリジンサーバーの帯域幅のグラフです。アカマイでのキャッシュが始まったため転送量が大幅に下がりました。
Coordisnapではスマートフォンアプリで利用している画像フォーマットをWebPに切り替えた時期がありました。それがいつなのかは明言しませんが、その時期からWebPについてはアカマイが全くキャッシュしていなかったという事になりますね。 言い訳すると、オリジン側でもCDNが入っていたり(多段CDN)して、スマホアプリのダウンロードサイズ軽減、表示速度向上等で意図した効果が得られていたため、このような事態が発生していることに気付くのが遅れました。
定期的なモニタリング、大事です。（モニタリングの前に気付けよという突っ込みがありそうですが・・・）
Tiered DistributionとCache Prefreshing
気を取り直して壁紙.comの例を見ていきましょう。今回は「Offload」モニターの「TOP URLS」をダウンロードしてみます。 ダウンロードしたcsvファイルをExcelで閲覧してみると、一見問題ないように見えますが、頻繁にアクセスされるファイルでさえ満遍なくオリジンへリクエストを送っている事が解ります。
このような状況で簡単に考えられるのは以下のような事象かなと思います。
- アクセス元の立地が相当にばらけていて、エッジキャッシュが効きにくくなっている
- 1つ1つのファイルに対するリクエスト数が少なく、且つアクセスパターンが多く、キャッシュ効率が悪い。若しくはキャッシュが押し出される。
- キャッシュ有効期間が短くて頻繁にキャッシュが失われる
これらに対応するため今回は以下の施策を行いました。
- キャッシュ期間を7日->30日に延長
- Tiered Distributionの導入でキャッシュ効率を効率化
Tiered Distributionはキャッシュサーバーの構成を多段化してオリジンへのリクエスト数を減少させるソリューションです。Akamai Japanブログのキャッシュ効率の上げ方 その2というエントリーからイメージ画像を引用させていただきます。
TTL切れの際にオリジンへリクエストが飛んでしまいユーザからの応答に時間がかかる事を回避する為に、DSD(Dynamic Site Deliveryの略)には「Cache Prefreshing」という機能があります。併せて設定しましょう。
結果として、Tiered Distributionの導入後はオフロード率が80%まで上昇しました。
オリジンへのリクエスト状況は「Responses」モニター、或はDSDの場合は「Traffic」モニターが利用可能です。 以下は「Responses」モニターの例ですが、Tiered Distribution導入後はEdgeのトラフィックは変わらないが、Midgressでキャッシュが生成されるようになったため、Originへのトラフィックが減少した事が見て取れます。
オリジンサーバーはAWS環境のためCloudWatchを確認したところCPU使用率、転送量もきちんと低下しています。
何らかの理由でオリジンのレスポンス速度が遅い場合には、キャッシュ効率を上げる事がコンテンツダウンロードの体感時間を大幅に下げる事に大きく影響します。
今回のケースでは効果は確実に現れているものの、オフロード率は80%程度です。90%目指して更に頑張りたい所ですが、キャッシュTTLの延長も合わせて実施している為、こちらの効果を見る為にも7月中旬まで様子を伺うことにします。
アクセス状況を可視化
アカマイが提供しているモニター類で大凡の対策はできるのですが、アクセスパターンを細かく見てみたい場合は「URLs」モニターから全アクセスリストをcsvでダウンロードして、Tableau等のBIツール、若しくはGoogle Spreadsheet,Excel等の表計算ソフトで解析が可能です。
こちらの図はURLの第一階層でオフロード率の違いを見たかったので、アクセス状況をtableauで解析してみたイメージ図です。
更に第二階層へドリルダウンしてみたりして、様々な角度からオフロード率が低下している理由を推測していくのに役立ちます。
但し注意点として、「URLs」モニターに集計結果が反映されるには2日間程度要するようです。
今日行った結果をリアルタイムで確認するにはアクセスログの確認が必要になります。ところが、アカマイのアクセスログを解析かけるのはかなり面倒な手順（gpg公開鍵をアカマイに登録して、暗号化されたアクセスログをアカマイから自前で用意したftpサーバーにアップロードするといった手順を踏みます）が必要です。画像等のアクセスログは膨大ですので集計かけるのにはそれなりの基盤が必要でしょう。なので当社では生ログの解析はほとんど行いません。
改善結果
細かいチューニングを施した結果どうなったか、現在の状況を記載しておきましょう。 以下は「Offload」モニターからcsv出力してTableauに読み込ませたものです。
全体的に良くなっていますが、まだまだ改善の余地はありそうですね。
まとめ
Akamaiには多様なソリューションが存在して、契約次第で利用出来る機能が有ったり無かったりしますので、当社の事例がそのまま参考にならないケースも多々有るかと思います。
ですが、1度アカマイ化して充分なパフォーマンスを発揮していたとしても今一度稼働状況を振返ってみては如何でしょうか。
定期的なモニタリング、大事です。
