一石二鳥なCDNのキャッシュをもっと活用しよう

CDNのキャッシュの動作

あるWebアプリケーションに対してCDNを適用すると、そのWebサーバとユーザーの間には常にCDNのプラットフォームが介在するようになります(これはキャッシュを使用する/しないに関わらず、必ずこのようになります)。CDNのプラットフォームは一種のリバースプロキシの集合であると考えて差し支え無く、ユーザーからのTCPコネクションやTLSセッションも一旦CDNのサーバ上で終端されます。(※2)

時折、「キャッシュを使うにはCDNにコンテンツを1つ1つアップロードしないといけませんか？」とご質問を頂くことがあるのですが、そのような手間は必要はありません。キャッシュの設定(具体的な設定のイメージは後述します)を行った際、当然最初の時点ではCDN上にキャッシュはありませんが、ユーザーがコンテンツを取得するのに伴って、自動的にキャッシュが生成されていきます。

あるコンテンツに対するユーザーからの最初のリクエストが来ると、CDNサーバは元のWebサーバからコンテンツを取ってきてクライアントに返します。ちなみに、「元のWebサーバ」のことはオリジナルのコンテンツが置いてあるサーバ、といった意味合いで「オリジン」とか「オリジンサーバ」と呼びます。その時のリクエスト・レスポンスが実際に通ったCDNサーバが最初にそのコンテンツのキャッシュを持ち、そこで生成されたキャッシュは一定の範囲内にある他のCDNサーバにも共有されます。このような過程を通じて、ユーザーがいる場所の近くにあるCDNサーバ群は、それまでリクエストされたコンテンツのキャッシュを獲得していきます。

すでに有効なキャッシュを保持しているCDNサーバに対してユーザーからリクエストがあると、CDNサーバはオリジンへリクエストを出すこと無く、自身のキャッシュから応答を返します。(※3)

このような動作を知れば、CDNのキャッシュには2つの大きな利点があることに気づくと思います。

• ユーザーの近くにあるCDNサーバがレスポンスを返すため、パフォーマンスが良い(速い)
  
• キャッシュで応答したリクエストはオリジンへ送られないため、オリジンの負荷が減る

そしてこれら利点はグローバルに利用されているWebアプリやアクセスの多いWebアプリになるほど、劇的なものになります。

キャッシュ動作の基本的な条件設定

ここまでで、CDNのキャッシュの大まかな動作と利点についてはご理解頂けたかと思います。ここからはCDNのキャッシュの使い方についてもう少し具体的に見て行きます。

CDNやキャッシュの話をしていると、「ウチのWebサイトは動的な処理もあるから、キャッシュは使えないですよね？」とご質問を頂くことがあるのですが、これは半分正解であり、半分誤りです。CDNのキャッシュはそのサイトの全てのコンテンツに対して、一緒くたに「適用する/しない」ではなく、キャッシュの対象とするコンテンツを様々な条件で指定できるようになっています。そしてWebサイト等で、あるページを構成するコンテンツが全て動的に生成されるということは、実際にはほとんどありません。

例えばユーザー名を表示している部分等、そのユーザー固有の情報を動的に出している部分についてはキャッシュ対象外としつつ、それ以外の画像やCSS, JSファイル等はキャッシュ対象とすることで、ページ全体としてのパフォーマンスは向上させることができます。例えばAkamaiの場合、下図のようにしてキャッシュの動作を定義する仕組みになっています。

この画面の例では、「ファイル拡張子がjpg, jpeg, png, webp, gifになっているコンテンツを1日キャッシュする」というルールを定義しています。Criteriaには条件を、Behaviorsには条件に一致した場合の動作を入れるようになっています。Criteria(条件)には「ファイル拡張子がjpg, jpeg, png, webp, gifのいずれかであること」が指定されており、Behaviors(動作)にはキャッシュするという動作とともに、キャッシュの有効期間(ここではMaxage)が1日で指定されています。

このようにして、指定した条件に応じてキャッシュの適用有無やその有効期間を設定できるようになっています。もう1つ例を見てみましょう。

今度は条件が2つ設定されています。ファイル拡張子の条件と、パスの条件がANDで結ばれており、両方に一致した場合のみ下のキャッシュ動作を適用するというものです。パスの条件にはワイルドカード(*)が含まれており、/my_path/配下にある全てのコンテンツを指定する条件になっています。このようにして、複数の条件を組み合わせた上で動作を定義することができます。

今回使用した条件はファイル拡張子とパスという典型的なものでしたが、この他にも、指定したクエリパラメータやリクエストヘッダの値、クライアントの地域、デバイス種別等々、様々な条件が指定できるようになっています。(※4) また、このようなルールは複数作成し、ネストしたりすることも可能なので、少し慣れればかなり柔軟なルール設定ができるようになります。

動的なコンテンツのキャッシュ設定

ここまで見てきた内容で、静的なコンテンツのキャッシュは様々な条件とともに設定することができます。では、動的なコンテンツはどうでしょうか？(※5) この点については考えるために、「キャッシュキー」について簡単にご説明します。

キャッシュキーとは、AkamaiのCDNサーバがユーザーからのリクエストを受けた際、どのキャッシュコンテンツを返すか？を判断するために使用するキャッシュの識別子と言えるものです。デフォルトでは、クエリパラメータを含むURL全体がキャッシュキーとして使用されます。この状態では、例えば同一URLで、Cookieに応じて異なるコンテンツを出し分けたいといった場合でも、キャッシュはCookieの値に関係無く決まってしまうので適切なコンテンツの出し分けができません。

こうした類のコンテンツはキャッシュ対象外としてシンプルに運用する、というのも1つの解なのですが、キャッシュキーを変更すればキャッシュ対象として検討することも可能になります。この例では、コンテンツの出し分け判断に使うCookieをキャッシュキー含めることで、適切なキャッシュを出し分けることができるようになります。

キャッシュキーにはCookieだけでなく、その他のリクエストヘッダ等も含めることができます。以下はAcceptヘッダの有無をキャッシュキーに含める設定の例です。

AkamaiのCDNと今後

いかがだったでしょうか。この記事ではCDNのキャッシュの概要や具体的な設定例、それと少し応用的なキャッシュの使い方をご説明させて頂きました。もしも皆様のWebアプリケーションがパフォーマンスや可用性、突発的な負荷等で課題を抱えていらっしゃるなら、是非CDN、そしてキャッシュの活用を検討してみて下さい。

特にAkamaiは、

• 135カ国に36万台以上のサーバーを配置した超分散型のプラットフォームを持っているため、多くのユーザーに対してより近い場所からキャッシュが配信できる
• 高度かつ柔軟な設定ができるため、複雑なキャッシュ要件にも対応しやすい

という点で大きなアドバンテージを持っています。

また現在では、CDNとして動いているAkamaiのサーバ上でお客様のJavaScriptコードを実行したり、Key-Valueデータストアを保持したりすることが可能なエッジコンピューティングにも注力しています。こうしたソリューションを活用すると、皆様のWebアプリ個々のロジックに即した更に高度なキャッシュ保持、出し分けの仕組みを構築することができます。

ご興味がある方は是非弊社へご連絡下さい！それではまた。

※1 AkamaiのCDNを念頭に記載しているため、他社様のCDN製品では異なる場合があります。

※2 このため、HTTPS配信を行う場合はWebサーバ上にあるサーバ証明書に加え、CDNサーバ上にも専用の証明書を作成/展開する必要があります。

※3 有効なキャッシュを持っている場合でも、敢えてオリジンへコンテンツの更新有無を確認しに行くよう設定することもあります。

※4 Akamaiの中でも、ご利用頂く製品によって使用できる条件は異なっています。

※5 ここで言う「動的なコンテンツ」は、同じURLであっても、リクエストに付随する他の情報(ヘッダ等)によって返されるコンテンツが異なる場合を指しています。