Akamai Diversity
Home > 第2回 コンテンツキャッシュを最大限活用する - アカマイ ベスト・プラクティス (Web Perfromance編)

第2回 コンテンツキャッシュを最大限活用する - アカマイ ベスト・プラクティス (Web Perfromance編)

第1回は Akamai Intelligent Platform の仕組みについてご紹介しました。
第2回では、Akamaiでキャッシュを行う際のベストプラクティス・考慮点についてお話します。

    1. キャッシュするコンテンツ・しないコンテンツを見極める
    2. キャッシュTTLの最大化・キャッシュ対象の最大化
    3. オリジンサーバーの設定をAkamaiの挙動に合わせて見直す
    4. こんなときには
    • さらにオフロード率を上げたい(オリジンの負荷を減らしたい)場合
    • サイズの大きいファイルを配信する場合
    • コンテンツを更新する場合 
1.キャッシュするコンテンツ・しないコンテンツを見極める

キャッシュ可能なコンテンツの分類
よく「動的に生成するコンテンツはキャッシュできない」と考える方がいますが、これは正しくありません。
キャッシュすべきかすべきでないかは、複数のユーザーがそのコンテンツを取得するかどうかで判断します。
動的コンテンツでも複数のユーザーが取得するのであれば、キャッシュを検討すべきです。

一方でパーソナライズされたコンテンツについては、通常CDNではキャッシュさせません。 

bestpractice_web_perfromance02_01.png

パーソナライズを行う場合のベスト・プラクティス
htmlにパーソナライズされた情報(ユーザー名、ポイント残高、ショッピングカート情報等)を入れてしまうと、前述の通りキャッシュできなくなります。
しかし以下のような方法でパーソナライズを実現できれば、キャッシュを活用できます。

方法1. クライアント側で、JavaScriptを使って生成する
・Cookieの値を元に、表示を変更 (Cookieにユーザー名があれば"こんにちは、Taroさん"など)
・Ajaxで非同期にコンテンツを取得し、表示を変更

方法2. パーソナライズされた情報を表示する箇所をひとまとめにする
・ESIやiframeなどを利用して、パーソナライズされた箇所以外はキャッシュできるようにする

Webサイトでパーソナライズが必要な場合は、上記のような実装ができないかご検討ください。

2.キャッシュTTLの最大化・キャッシュ対象の最大化

キャッシュTTLは、キャッシュの有効期限を指定します。
Akamai Edgeサーバーは、コンテンツをオリジンから取得した際のタイムスタンプと、クライアントからHTTPリクエストを受けた際のタイムスタンプを比較します。この差がTTLを超えていれば、コンテンツが更新されていないかオリジンに確認します。

TTLを長く設定できれば、その分オリジンの負荷が減り、オリジンのレスポンスを待たずに配信できるためパフォーマンスも良くなります。

Akamaiではコンテンツ毎に、キャッシュの制御方法を非常に細かく設定可能です。その例をご紹介します。 

キャッシュキーの有効活用
キャッシュキーとは、Akamai EdgeサーバーがHTTPリクエストを受けた際、キャッシュを特定するために用いるインデックスです。
デフォルト設定では、URL全体(https://www.akamai.com/us/en/solutions/products/web-performance/等)になっています。

キャッシュキーを変更することで、同一URLで異なるコンテンツを出し分けたり、複数のQuery String付きリクエストをグループ化するなどしてキャッシュヒット率を上げることが可能になります。

活用例1. 特定のQuery Stringパラメータをキャッシュキーに追加する
→ 商品検索ページをキャッシュし、DBへの負荷を下げる

活用例2. User-Agent等の特定のヘッダをキャッシュキーに追加する
→ モバイルとPCでキャッシュを分ける

活用例3. 特定のCookieの値をキャッシュキーに追加する
→ ログインユーザーとゲスト(未ログイン)でキャッシュを分ける 


Akamaiで可能なキャッシュコントロールの例
Akamaiでは、どのような条件で・どのような制御を行うか、GUIやAPIで簡単に設定を行うことができます。 

bestpractice_web_perfromance02_02_v2.png

以下はアカマイで可能なキャッシュコントロールの例です。

  • ファイル拡張子単位でCache TTLを設定
  • ディレクトリ毎に異なるTTLを設定
  • /CGI/ ディレクトリ以下のコンテンツは、no-store とする
  • ログインcookieが付いている場合は、Bypass-cache※する
  • HTTP POSTリクエストに対するレスポンスをキャッシュする
  • 毎日6amと4pmに、HTMLファイルのキャッシュを無効(期限切れ)にする
  • ExpireヘッダやCache-Controlヘッダを付与して、ブラウザ側でキャッシュされるようにする
  • 特定の条件に合致した場合に、リクエストをリダイレクトする
  • 特定の条件に合致した場合に、ヘッダを付与したり、書き換えて配信する

※Bypass-cache: 一時的にオリジンのコンテンツを配信するが、既にキャッシュされているコンテンツはキャッシュしたままにする


3.オリジンサーバーの設定をAkamaiの挙動に合わせて見直す

オリジンサーバーが以下のように設定されているか、確認してみてください。

  • IMS(If-Modified-Since)リクエストに従うようにする
  • サーバ―の時刻を常に合わせておく
  • Last-Modifiedを付与する(コンテンツが静的か動的かに関わらず)
  • キャッシュ対象のコンテンツには content length を付与する
詳細については、「第5回 Akamaiの仕組みに合わせて、オリジンや運用を最適化する」で解説します。


4.こんなときは

さらにオフロード率を上げたい/オリジンの負荷を減らしたい場合
Akamai Edge サーバーを階層化して利用することで、オフロード率を上げることができます。

bestpractice_web_perfromance02_03.png

また静的コンテンツであれば、Akamaiのクラウドストレージ(NetStorage)から配信することもできます。
NetStorageはAkamai配信用に最適化されているため、オリジンやアクセス回線の負荷を気にすることなく、配信を行うことができます。

この他にもホットコンテンツ向け/コールド(ロングテール)コンテンツ向けなど、トラフィックの特性によって様々な最適化を行うことができます。オフロード率をさらに上げたい場合には、Akamai担当営業までご相談ください。


サイズの大きいファイルの配信する場合
サイズが100MB以上のコンテンツでは、Akamai配信設定でLarge File Optimization(大容量ファイルの最適化)を有効にすることを推奨しています。 
 
bestpractice_web_perfromance02_04.png

特に1.8GBを超える場合は、Large File Optimizationが必須となり、かつNetStorageの利用を強く推奨します。

コンテンツを更新する場合
コンテンツを更新する際は、同一ファイル名を使用せず、別名で更新することを推奨しています。

例1)
更新前: http://www.example.com/image/001_1.jpg
更新後: http://www.example.com/image/001_2.jpg

例2)
更新前: http://www.example.com/style.css?v=1
更新後: http://www.example.com/style.css?v=2

このような更新が可能であれば、キャッシュキーが変更になるため、新しいURLにHTTPリクエストが来た時点で新しいコンテンツを返します。(html等に含まれるURLも併せて変更し、その更新を待つ必要はありますが)
コンテンツのTTLが長く設定されていたとしても、TTLが切れるまで待たずに、新しいコンテンツを配信できます。



第2回はどのようにすればAkamaiのキャッシュ機能を効率的に活用できるか、についてご紹介しました。
第3回では、キャッシュ対象外のコンテンツも含めて、Akamaiでどのような高速化ができるかをご紹介いたします。

Leave a comment