クラウドでの Web コンテンツの配信を高速化する

Akamai プラットフォームを使用して速度と信頼性に対処する

ブラウザー・ベースの SaaS (Software as a Service) アプリケーションを使用することで、企業は素早く簡単に世界中のユーザーと接続することができます。その一方で、これらのアプリケーションをいつでも確実に、そしてハイパフォーマンスで提供できるかどうかが重要成功要因になります。IBM Cloud でマルチテナント型アプリケーションを構築するためのベスト・プラクティスを主題とするこの連載の 3 回目では、Web アプリケーションのパフォーマンスに目を向けます。信頼性の高い Web コンテンツ配信を実現するためのソリューションとして、この記事では SaaS フレームワークと Akamai グローバル・エッジ配信プラットフォームとの統合について説明します。

Christina Lau, Distinguished Engineer, IBM

Christina LauChristina Lau は、クラウドやモバイル・コンピューティングなどの新しい技術に豊富な経験を持つ、WebSphere の Distinguished Engineer です。彼女は現在、BPM、接続性、および ILOG ポートフォリオでのオンライン・クラウド・サービスの提供をサポートする高度な技術の開発に取り組んでいます。


developerWorks 貢献著者レベル

Valentina Birsan (popescu@ca.ibm.com), Senior Developer, IBM

Valentina Birsan's photoValentina Birsan は WebSphere のシニア開発者で、現在はクラウド・プロジェクトに取り組んでいます。以前は、Rational Application Developer で技術リーダーを務めていました。Eclipse TPTP オープンソース・プロジェクトには初期メンバーとして加わった他、 TPTP Architecture Group の議長、Cosmos Service Modeling Eclipse オープンソース・プロジェクトの主任アーキテクトを務めた経験もあります。また、彼女は SML オープン標準のメンバーです。



2011年 4月 04日

Web アプリケーションにおけるパフォーマンス問題の根本原因は、以下の 2 つのカテゴリーに分類することができます。

  • アプリケーション自体のパフォーマンス不足。この問題は通常、アプリケーション開発者がパフォーマンスを調整してコードを訂正することによって対処することができます。
  • インターネットの問題によるアプリケーションのパフォーマンス不足。インターネットのインフラストラクチャーは予測不可能であるため、この事態を 1 つの企業が単独で制御することはできません。

パフォーマンス不足の原因が内部にあるか、外部にあるかに関わらず、応答時間の遅さはユーザーに影響を及ぼし、そのことが原因でアプリケーションの普及率も、満足度も低下しかねません。

図 1. インターネットはさまざまなネットワークが複雑にマルチパス化されたネットワークです
さまざまなネットワークが複雑にマルチパス化されたネットワークの図

図 1 は、インターネットは 1 つのネットワークではなく、ピアリング・ポイントによって接続された 12,000 を超えるネットワークで構成されていることを表しています。データ・センターからユーザーへのパスが、複数のネットワークと複数のピアリング・ポイントを通ることもあります。そのため、パスでは輻輳が発生しがちで、さらに事故や自然災害、あるいは事業紛争によって伝送に遅れが出る場合もあります。

インターネット・ピアリング

ピアリングとは、管理上分離されたインターネット・ネットワークを自主的に相互接続し、各ネットワークの顧客の間でトラフィックを交換し合えるようにすることです。純粋な定義によると、ピアリングには決済がなく、「送信側がすべてを負担」します。これは、トラフィックを交換する両者は、相手側に支払う代わりに、それぞれの顧客から収益を得ることを意味します。

パフォーマンス不足の Web アプリケーションに対処する 1 つの方法は、サーバー数、帯域幅、さらに場合によってはデータ・センターの数を増やして処理容量を拡大し、それぞれの負荷を減らすことです。けれども、この方法ではコスト効率が悪いだけでなく、インターネットの予測不可能なパフォーマンスには適切に対処しきれません。しかも、インフラストラクチャーを増設するということは、トラフィックの少ない時間帯には過剰な設備ということになり、トラフィックが極めて高くなった場合には相変わらずボトルネックに突き当たる可能性があることを意味します。

この記事で説明するベスト・プラクティスでは、世界 70 ヶ国の 1000 を超えるネットワークに配備された 70,000 台を超えるサーバーからなる大規模なネットワーク、Akamai EdgePlatform を利用します。この EdgePlatform を使ってインターネットをリアルタイムで監視し、トラフィック、輻輳、問題の起こりやすい箇所に関する情報を収集して、距離の長いルートを排除し、問題の起こりやすい箇所を回避することによって、高速かつ信頼性の高い Web コンテンツ配信を確実にします。

ベスト・プラクティス: Akamai Web Application Accelerator による動的 Web コンテンツの配信

インターネットでの輻輳および脆弱性といった問題の解決を支援するために Akamai が開発した Akamai EdgePlatform は、さまざまな状況で Web サイト、コンテンツ、アプリケーションを配信する際のインターネットの欠点を軽減できるように設計された製品を提供しています。そうした製品の中でも、この記事で使用する Akamai Web Application Accelerator は、動的な Web コンテンツ配信の高速化を目的に設計されており、その目的を実現するための手段は、以下のとおりです。

  • インターネット・トラフィックの輻輳の回避: 送信元サーバーと Akamai エッジ・サーバーとを直接結ぶルートは、インターネットのトラフィックに起因する輻輳が発生する可能性があります。この問題は、SureRoute for Performance を使用して最適な代替ルートを識別することによって克服することができます。
  • TCP 構成の最適化: Akamai は、TCP 接続ウィンドウの最適化機能、TCP タイムアウトの調整機能、そして永続的接続の有効利用によって、Akamai エッジ・サーバーと送信元サーバーとの間のスループットを最大限にします。
  • コンテンツのキャッシング: 画像や動画、そして zip ファイルなど、ほとんどの静的コンテンツはキャッシュ可能です。これらのオブジェクトをエンド・ユーザーの近くにあるエッジ・サーバーのキャッシュに入れることにより、Akamai は送信元サーバーから静的コンテンツを取得するために必要なラウンドトリップの回数を削減することができます。
  • コンテンツのプリフェッチ: Akamai は、HTML ページに埋め込まれたすべてのコンテンツを最小限の応答時間でエンド・ユーザーに配信できるように、インテリジェントなプリフェッチ機能を提供しています。ページに埋め込まれたコンテンツをエンド・ユーザーのブラウザーからリクエストする時点で、そのコンテンツは近くのエッジ・サーバーのメモリー内で、配信されるのを既に待機している状態になっています。これは、Akamai は実際のブラウザー・リクエストにわずかに先立って、そのコンテンツをリクエストするためです。
  • コンテンツ送信時間の短縮化: Akamai はコンテンツをクライアントに送信する前に、エッジ・サーバーで gzip を使ってコンテンツを圧縮できるため、コンテンツの送信にかかる時間が短縮されます。10KB を超えるオブジェクトは、ラストマイル・アクセラレーションによるメリットを得られます。

Web Application Accelerator に対応した設計には、以下の 2 つの主要なタスクが必要です。

  1. エッジ・サーバーを認識するようにシステムを構成する
  2. SaaS アプリケーションに適用可能なキャッシング・ルールおよびポリシーを設計する

タスク 1: エッジ・サーバーを認識するように構成する

最初のタスクは、Akamai エッジ・サーバーを認識するようにシステムを構成することです。図 2 に、このアーキテクチャー全体を示します。

図 2. エッジ・サーバーを認識するようにシステムを構成する
エッジ・サーバーを認識するようにシステムを構成する

ユーザーがオブジェクトをリクエストすると、そのリクエストは最初に Akamai エッジ・サーバーに転送されます。エッジ・サーバーからコンテンツを提供できる場合には、キャッシュ内のコンテンツがユーザーに返されます。キャッシュ内に該当するコンテンツがない場合には、Akamai は送信元サーバー (つまり、データ・センター) にコンテンツをリクエストし、そのコンテンツを Akamai エッジ・サーバー・ネットワークにキャッシュしてからユーザーに返します。

このタスクを実行するには、Akamai が通信するサーバーの IP アドレスとホスト名、アプリケーションの URL、セキュア接続であるかどうか、ドメイン名などのシステム・トポロジーを理解しているサブジェクト・マター・エキスパートが、Akamai スペシャリストと協力することで、システムをセットアップすることができます。


タスク 2: キャッシング・ルールを設計する

2 番目のタスクには、SaaS アプリケーションに適用可能なキャッシング・ルールおよびポリシーの設計が関係してきます。このタスクを実行に移すには、Web サイトのコンテンツを理解していなければなりません。具体的には、ディレクトリー構造、コンテンツのタイプ、そしてコンテンツが生成される方法を理解する必要があります。このセクションでは、キャッシュングに関するトピックをいくつか取り上げます。

ファイル拡張子およびパスに基づくキャッシング・ルール

最も単純なキャッシング・ルールは、標準的なファイル拡張子に基づきます。デフォルトでは、以下の拡張子を持つファイルが自動的にキャッシュされます。

aif aiff au avi bin bmp cab carb cct cdf class css doc dcr dtd
exeflv gcf gff gif grv hdml hqx ico ini jpeg jpg js mov mp3 nc pct
pdfpng ppc pws swa swf txt vbs w32 wav wbmp wml wmlc wmls
wmlsc xsd zip

このルールの前提となっているのは、上記の拡張子が付いたテキスト・ファイル、画像ファイル、スタイルシート、および音声ファイルは静的であるため、キャッシュ可能であること、そして静的ファイルをエッジ・サーバーにキャッシュしておけば、パフォーマンスが改善されることです。デフォルトのキャッシング期間は 1 日です。JavaScript が重要な役割を果たすリッチ・インターネット・アプリケーションでは尚更のこと、Akamai は数多くのオブジェクトをキャッシュに入れられるため、全体的なパフォーマンスが大幅に向上します。

上記のファイル拡張子のリストは、アプリケーションの要件に応じて拡張子を追加するのも、削除するのも簡単です。例えば、特定のファイル・パス (/doc/*.html など) にある HTML または XML ファイルは静的ファイルであると考えられるので、これらのファイルも同じくキャッシュすることができます。

リクエスト・パラメーターやその他のアプリケーション・メタデータに基づいて、動的コンテンツをキャッシュに入れるためのキャッシング・ルールを定義することもできます。一般に、リソースの URL だけを使用したのでは、キャッシングのキーとして十分ではありません。URL だけではなく、cookie を追加して補うことで、複合キャッシュ・キーにする必要があります。cookie は、特定のテナント、またはテナントのユーザーを識別するために使用することができます。そのため、エッジ・サーバーはユーザー/テナントに固有のコンテンツのコピーを保持し、キャッシュから正しいコピーを提供できるというわけです。これは高度な機能なので、慎重に設計してテストしなければなりません。

キャッシング・ルールをテストするためのツールと手法

定義したキャッシング・ルールが期待通りに機能することを確認するには、HTTP デバッグ・ツールを使用してください。例えば HTTP デバッグ・ツールの 1 つ、Fiddler を透過型プロキシーとして使用すれば、実行したすべてのリクエストを確認し、それぞれのレスポンスを検証して、キャッシングが適切に機能しているかどうかを調べることができます。

一般的な手法としては、キャッシュ可能なオブジェクトをリクエストした後、Fiddler の Session Inspector を使用してリクエストのヘッダーを検査します。Fiddler には、リクエスト内で Akamai 固有の Pragma ヘッダー (X-Check-Cacheable、X-Cache など) を使用できるようにするためのルールを追加する必要もあります。

キャッシュ可能なオブジェクトへの初めてのリクエスト

一例として、JavaScript の場合にはキャッシュするというキャッシング・ルールがあるとします。この場合に、例えば test.js というファイルをリクエストすると、このファイルに対する初めてのリクエストなので、Response Headers パネルには以下の属性が表示されるはずです。

X-Check-Cacheable: YES
X-Cache: TCP_MISS from a96-17-171-7 (AkamaiGHost/6.3.0-7086845)

.js 拡張子を持つ JavaScript ファイルが実際にキャッシュされることは、最初の属性によって検証されました。2 番目の属性は、オブジェクトはキャッシュ可能であるものの、test.js が Akamai キャッシュ内に見つからなかったため、このファイルはデータ・センターから配信されたことを示しています。

キャッシュ可能なオブジェクトへの 2 回目のリクエスト

続いて、同じ test.js ファイルをもう一度リクエストします。これは、このオブジェクトに対する 2 回目のリクエストなので、今度は Response Headers パネルに以下の属性が表示されることになります。

X-Cache: TCP_HIT from a96-17-171-7 (AkamaiGHost/6.3.0-7086845)

値 TCP_HIT は、Akamai エッジ・サーバーはキャッシュからファイルを返したことを意味します。したがって、エッジ・サーバーはデータ・センターに戻って同じファイルをフェッチする必要がなかったということです。

キャッシュ・ポイズニングとは何か

エッジ・サーバーのキャッシュ・ポイズニングとは、キャッシュの内容に関するデータは提供されるものの、キャッシュされているリソースが正しく表されていないという、意図せぬ状況のことです。次に送信されるリクエストに対しては、エッジ・サーバーがキャッシュしたリソースが返されるため、キャッシュに関するデータが確実にそのリソースの正しい内容を表すようにすることが極めて重要になります。

以下に、エッジ・サーバーのキャッシュが無効なデータで「汚染」される可能性のあるシナリオを説明します。

例えば、まだ認証されていないエンド・ユーザーが、保護されたリソースである foo.gif をリクエストするとします。この時点で、foo.gif はまだキャッシュ内にありません。そのため、Akamai エッジ・サーバーはリクエストをデータ・センターに送信します。

バックエンドのアプリケーション・サーバーの前には WebSeal サーバーが配置されています。保護されたリソースをリクエストしたユーザーがまだ認証されていない場合 (あるいは、そのユーザーの認証セッションが期限切れになっている場合)、最初のリクエストはバックエンド・サーバーまで到達しません。その場合、WebSeal サーバーはリクエストされたリソースの代わりに、HTTP レスポンス・コード 200 と共に HTML ログイン・ページを返します (ユーザーがログインできるようにするため)。

ログイン・ページを Akamai が受信すると、レスポンス・コードは 200 であるため、Akamai はリクエストが成功したと見なし、そのリクエストに対するレスポンスをキャッシュに保存します。これにより、Akamai のキャッシュは誤ったオブジェクトで汚染されてしまいました。次回、ユーザーが foo.gif をリクエストすると、レスポンスは Akamai のキャッシュからログイン・ページを返すことになります。

Akamai のキャッシュ・ポイズニングを防ぐためのベスト・プラクティス

キャッシュ・ポイズニングを防ぐためのベスト・プラクティスには、以下の 2 つがあります。

  • レスポンス・ヘッダーでサーバーを適切に識別すること。
  • アプリケーションが正しいステータス・コードを返すようにすること。

レスポンス・ヘッダーでサーバーを適切に識別してください。リダイレクトを行う WebSeal リバース・プロキシー・サーバーから直接提供されたコンテンツについてはキャッシュしないように構成を定義することで、上記のような状況になるのを防ぐことができます。

Akamai ソフトウェアは、レスポンス・ヘッダーの Server プロパティーを調べることで、サーバーのタイプを確認することができます。例えば、WebSeal リバース・プロキシー・サーバーから返されたレスポンスの場合、サーバー・ヘッダーの値は Server: WebSEAL/6.1.0.0 に設定されます。レスポンスがバックエンドのアプリケーション・サーバーのうち、例えば WebSphere sMash から送信された場合には、サーバー・ヘッダーの値は Server: IBM WebSphere sMash/1.1.1 となります。

アプリケーションが必ず正しいステータス・コードを返すようにしてください。アプリケーションが正しいステータス・コードを送信できないとしても害はないように思えますが、エッジ・サーバーを有効にするときに、大きな問題となってきます。リクエストの処理に成功し、期待されるデータがレスポンスとして返される場合に限り、HTTP 200 レスポンスが送信されるようにしてください。レスポンス・コードが 200 の場合、エッジ・サーバーはキャッシュ可能なコンテンツをすべて自動的にキャッシュします。

一般に、HTTP ステータス・コードを実装し、Web ソリューションとして具体的なアプリケーション固有のエラー・ページを作成することが有効なプラクティスとなります。

キャッシュをクリアする

場合によっては、Akamai エッジ・サーバー構成に指定された有効期限が切れる前に、エッジ・サーバーにキャッシュされたコンテンツを更新しなければならないことがあります。例えば、JavaScript のエラーにクイック・パッチを当てる必要がある場合や、既存の画像を更新しなければならない場合などです。あるいは、アプリケーションの新しいバージョンでアプリケーション全体を更新したほうがよい場合もあります。

Akamai では、このタスクを実行するために使用できる、柔軟な Content Control Utility を提供しています。Akamai Edge Control ポータルにアクセスし、パネルを使用して更新対象の URL を指定するだけで、コンテンツを更新することができます。コンテンツの更新が完了すると、Akamai が E メールで通知します。さらに、SOAP API を使用してコンテンツをプログラムによって更新することも可能です。


まとめ

この記事で説明したのは、私たちが IBM Cloud で動作するアプリケーションに Akamai を統合するなかで学んだ教訓です。Akamai のキャッシュを導入することによって、全体として 50 パーセントを超えるパフォーマンスの改善が認められました。

この記事ではキャッシュングによるパフォーマンスの改善に話題を絞りましたが、Akamai には他にも、SaaS アプリケーションのフェイルオーバーおよび負荷分散を可能にするために利用できる機能があります。クラウド・プロバイダーはロード・バランシングに特化されたハードウェアをサポートしないこともあるため、これは他には類を見ない機能です。フェイルオーバーと負荷分散の統合により、私たちの SaaS アプリケーションの全体的な可用性およびパフォーマンスは改善されました。この話題については、今後の記事で取り上げることにします。


謝辞

私たちのチームは、Akamai チームとの共同作業を楽しんでいます。Akamai チームは非常に知識が豊富であるばかりでなく、一緒に作業するのが楽しい方々です。この記事の作成を支援してくれた Akamai の Patrick Boucher 氏、そして IBM の Tom Mikalsen 氏、Bhadri Madapusi 氏に感謝いたします。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=651147
ArticleTitle=クラウドでの Web コンテンツの配信を高速化する
publish-date=04042011