目次


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

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

Comments

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 氏に感謝いたします。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

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