ダイナミック・コンテンツを高速化したい――。こんなニーズに答える製品やサービスが登場してきた。1つは,米アカマイ・テクノロジと米オラクルが共同で提案したESI(エッジ・サイド・インクルード)。Webページに動的に変化するコンポーネントを組み込むためのマークアップ言語だ。一方,米国のベンチャ企業が独自開発したツールは,変化分だけを送信してクライアント側でダイナミック・コンテンツを生成させる。どちらも,キャッシュを活用した新手法である。

河井 保博=kawai@nikkeibp.co.jp

図1 ESIはキャッシュ・サーバー向けの技術
キャッシュ上で動的にWebページを生成できる。Webサイトに設置されるリバース・プロキシ・キャッシュと,ネットワーク上に設置されたキャッシュのどちらでも利用可能。
 動的に内容が変化するWebコンテンツ,いわゆるダイナミック・コンテンツを高速に提供するための手段が現実味を帯びてきた。新しい技術とそれを実装した製品,あるいはサービスが登場してきたからだ。

 例えば「エッジ・サイド・インクルード」(ESI)という技術がその1つ。コンテンツ・デリバリ・サービスを提供する米アカマイ・テクノロジと米オラクルが共同で提案した技術で,ほかにも米IBMや米BEAシステムズなど大手ベンダーが仕様策定に参画している。アカマイとオラクルに関して言えば,それぞれのサービス/製品はすでにESIを実装済みでさえある(図1[拡大表示])。

 もう1つ,米ファイングラウンド・ネットワークスが提供するツール「Condenser」も,ダイナミック・コンテンツを高速化することに主眼を置いている。近く,日本でも代理店を通じて販売されそうである。

キャッシュ上でのページ生成を実現

 ここで言うダイナミック・コンテンツとは,ユーザー1人ひとりに対してカスタマイズ(パーソナライズ)されたWebページや,株価情報など頻繁に更新されるデータを含んだコンテンツである。どれも,データベースなどを参照して動的にWebページを作成・表示する。最近は,こうしたダイナミック・コンテンツを提供するWebサイトも珍しくない。「実際,ダイナミック・コンテンツの高速化を求める声は増えてきている」(日本オラクルの製品本部システム製品マーケティング部9iマーケティンググループ担当マネジャーである西脇 資哲氏)。

 ところが,ダイナミック・コンテンツは,高速化が難しい。動的にデータを取得してWebページを構成するというアプリケーション処理が介在するため,たいていはオリジンのサーバーにアクセスしなければならない。コンテンツは,ユーザーによって変わったり,時間とともに刻々と変化したりするため,キャッシュやコンテンツ・デリバリ・サービス(CDS)はあまり効果を望めない。そのうえ,すべてのアクセスが集中するから,オリジン・サーバーの負荷も高まりがちである。さらに,キャッシュを利用できたとしても,多くの場合は,コンテンツの一部が変更されただけでも,エンドユーザーはWebページ全体を再取得しなければならなくなる。結局,キャッシュの恩恵にあずかれる場面は限られる。

 こうした背景で登場してきた技術がESIである。ESIは,キャッシュ上でWebページを動的に組み立てる機能を実現する。アカマイは,同社のCDS「EdgeSuite」に,「ESIの母体となったASI(アカマイ・サイド・インクルード)を実装済みで,国内でもすでにサービスとして提供可能な状況」(アカマイ・テクノロジーズ・ジャパンのテクノロジーサービス 相澤 俊幸氏)にある。オラクルも,Oracle9i ApplicationServer」(Oracle9i AS)にESIを実装。日本では2001年10月から出荷される。

コンポーネント単位の更新を実現

 もう少し具体的に見てみよう。ESIは,HTML(ハイパーテキスト・マークアップ言語)などと同様のコンテンツ記述用マークアップ言語である。Webページにどのコンポーネントを組み込むか,そのURLなどを指定する。重要なのは,ESIがキャッシュ・サーバー上で稼働する点。ESIを使うと,コンポーネント単位にキャッシング・ルールを設定できるため,コンテンツ更新もコンポーネント単位に実現できる。

 あるダイナミックWebページの構成要素となるコンポーネントがすべてキャッシュされているとしよう。するとキャッシュ・サーバーは,記憶したデータを使ってWebページを動的に生成する。

 キャッシュの有効期限が切れている場合は,「もし元データが更新されていれば」という条件付きのHTTP GET要求を送る。コンテンツが更新されていなければ,やはりキャッシュのデータを利用できる。コンテンツが変更されている場合でも,ページ全体ではなくコンポーネントだけをバックエンドから取得すれば済む。さらに,Webアプリケーション・サーバーのWebページ生成にかかる負担を軽減できるため,Webシステム全体としてのパフォーマンス向上を期待できる。オラクルによると,「Webキャッシュを利用すると150倍,ESIを併用するとさらに85倍パフォーマンスが向上する」という。

 実際には,同じESIでもオラクルとアカマイのソリューションでは期待できる効果に異なるところがある。ネットワーク全体から見た場合のキャッシュの配置が違うからだ。

 アカマイの場合,コンテンツ・デリバリ・ネットワークを構成するキャッシュ上でESIを判読する。ダイナミック・コンテンツを構成するコンポーネントがキャッシュ上にあれば,何ホップものネットワークの経路を介してオリジンのサーバーにアクセスしなくても,最寄りのサイトからダイナミック・コンテンツを取得できる。

 一方,オラクルの場合は,ESIが稼働するのはOracle9i ASに搭載されているWebキャッシュ上である。このWebキャッシュは,いわゆるリバース・プロキシとして動作する。このため,サーバーの負荷は軽くなるものの,アカマイのサービスのようにネットワークの伝送遅延を減らす効果は望めない。代わりに,Oracle9i ASはデータベースのOracle9iと連携し,コンテンツをより新鮮に保てる。Oracle9i上のデータが更新されると,9i ASがこれを検知。自動的に,キャッシュされているコンテンツを廃棄する。

差分のみ転送する「Condenser」

図2 米ファイングラウンドのアプライアンスの動作概要
Webページのうち,動的かつ頻繁に変化する部分を自動的に検出し,更新分だけを送信する機能を持つ。変化しない部分は,ベース・ファイルとしてユーザー側のキャッシュに保存させておける。更新データだけを送信すれば済むため,サーバーの負荷を顕現できると同時に,コンテンツ送信にかかる時間を短縮させられる。
 一方,独自の技術を使ってダイナミック・コンテンツの高速化実現に取り組むベンダーもある。米ファイングラウンドである。同社は,「Condenser」というソフトウエア製品を開発した。リバース・プロキシと同様に,エンドユーザーから見てWebサーバーの手前に設置されるツールである。

 Condenserは,動的に生成されるWebページのうち,頻繁に更新される部分だけを切り出し,その差分だけを送信してブラウザ側で動的にWebページを生成できるようにする。サーバー側にCondenserを搭載したマシンを設置するだけで,Webサーバーや元のコンテンツの変更は不要。エンドユーザー側にも特別なソフトは必要ない。

 仕組みはこうだ。まず,ユーザーからWebサイトにアクセス要求があると,Webサーバーが応答を返す。この際,CondenserがWebコンテンツを受け取り,エンドユーザーに中継すると同時に,Condenser上に記憶する(図2[拡大表示])。これをベース・ファイルと呼ぶ。ここまでの動作は,リバース・プロキシ・キャッシュとあまり変わらない。違いはここからだ。Webサーバーに対して同じWebページへのアクセス要求があると,Condenserは前に記憶したベース・ファイルと新たに取得したWebページの内容を比較。コンテンツに違いがあれば,変化していない部分だけをベース・ファイルとして記憶し,変化分をデルタ・ファイルとして記憶する。このデルタ・ファイルが頻繁に変化する情報ということになる。

 デルタ・ファイルには,ベース・ファイルに差分を反映する命令も含まれていて,ブラウザ上でベース・ファイルを変換するイメージでWebページを動的に生成できる。ブラウザが近くのキャッシュ(ブラウザ・キャッシュまたはエンドユーザー側のキャッシュ・サーバー)からベース・ファイルを取得できれば,Webサイト(Condenser)からは容量の小さなデルタ・ファイルだけを取得すれば済み,Webページのダウンロード時間を短縮できる。ファイン・グラウンドによれば,帯域使用率を最大で40分の1に抑えられる。