IBM WebSphere Edge Serverによるアプリケーションのオフロード

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

James Giles, Research Staff Member, IBM Research
Dinesh Verma, Research Staff Member, IBM Research
Steve Ims (steveims@us.ibm.com), Software Engineer, FIT Team, IBM China Development Lab　
Ron Doyle (rdoyle@us.ibm.com), Software Engineer, FIT Team, IBM China Development Lab　
Subbarao Meduri (mkv@us.ibm.com), Software Engineer, FIT Team, IBM China Development Lab　

2002年 5月 01日

IBM WebSphere Edge Server 2.0には、アプリケーション・オフロード(積み出し)というすばらしい機能が装備されています。アプリケーション・オフロード機能を利用すると、サーブレットやJSPコンポーネントを含むWebベース・アプリケーションの全部または一部を、プロキシー・キャッシュに配置し、キャッシュで実行できるようになります。アプリケーションをキャッシュで実行すれば、応答時間も速くなりますし、スケーラビリティ（大規模化容易性）が得られ、集中管理も可能になります。本稿では、いろいろなアプリケーション・クラスについて、アプリケーション・オフロードの利用方法を解説します。

WebSphere Edge Server 2.0では、サーブレットやJSPコンポーネントを含むアプリケーションの全部または一部をプロキシー・キャッシュに配置し、それをキャッシュで実行できるようになりました。キャッシュは、ここでは、Edge Serverと呼ばれますが、IBM WebSphere Application Serverを実行している、おおもとのアプリケーション・サーバーと連携する形で動作します。アプリケーションは、リバース・プロキシーとして機能するキャッシュで実行させることもできれば、コンテンツ・ディストリビューション・ネットワークの代理(surrogate)サーバーとして機能するキャッシュで実行させることもできます。リバース・プロキシーの場合、Edge Serverと元のアプリケーション・サーバーは、通常、高速ローカル・エリア・ネットワークで接続されますので、それに起因するネットワーク待ち時間は無視できる程度です。コンテンツ・ディストリビューションの場合、Edge Serverと元のアプリケーション・サーバーは、ワイド・エリア・ネットワークで接続されますので、ネットワーク待ち時間は大きなものになる可能性があります。

実行をキャッシング(caching)・プロキシーに移すことで、スケーラビリティは増し、アプリケーションの応答時間も改善されます。分散されたアプリケーションを1箇所で管理できますので、1箇所で配置を定義することで、オフロードされるアプリケーションをすべてのキャッシュに配置することができます。アプリケーション・オフロードによって、性能の規模拡張が容易となり、集中管理が行えることになります。

本稿では、アプリケーション・オフロードによって得られる機能の活用方法を紹介します。Edge ServerにオフロードさせやすいWebアプリケーションの書き方や、既存のWebアプリケーションをオフロードする技法を解説します。

この記事では説明のため、アプリケーションを以下の4つのカテゴリーに分類しています。

• ディレクトリー検索アプリケーション
• リソース予約アプリケーション
• エレクトロニック・コマース (電子商取引) アプリケーション
• ネットワーク・アプリケーション・サービス

ネット上のすべてのアプリケーションをカバーするわけではありませんが、上記のカテゴリーは、アプリケーション・オフロードがどのように機能するかを示す良い例です。

ディレクトリー検索アプリケーション

IBM SecureWay DirectoryなどのLDAPディレクトリー・サーバーに登録されているデータにアクセスするWebベース・アプリケーション。ほとんどの企業が保持している人的資源のディレクトリーが、その例です。

リソース予約アプリケーション

リソースを予約したりスケジュール管理するために使用されます。この種のアプリケーションは、企業内で会議室のスケジュールを管理したり、個人が予定表 (たとえば、Web上で患者が受診の予約を行うためのシステム) を管理したりするために使用されます。

エレクトロニック・コマース (電子商取引) アプリケーション

Webベースの買い物サービス用として開発されるもの。

ネットワーク・アプリケーション・サービス

あるページを指定の言語に翻訳するとか、広く普及したデバイス向けにコンテンツをトランスコードするといったサービスを、プロキシー・サーバーに提供するもの。

アプリケーション・オフロードの基礎

Webアプリケーションを構成するサーブレットやJSPコンポーネントは、2つのカテゴリーに分けることができます。1つ目は、もっぱらユーザーから入力したもらったパラメーターにしたがって、提示するページの構造を決定するタイプのプログラムです。2つ目は、アプリケーション内に保存されているデータ・ソースを使って、その機能を実行するタイプのプログラムです。

1つ目のカテゴリーには、時刻、システム・リソースの使用状況、またはその他の統計情報提示プログラム、ユーザーが指定した数量をある単位から別の単位に変換する (たとえばメートルをフィートに変換する) といったプログラムが含まれます。といっても、そのようなアプリケーションの守備範囲は、かなり限定されています。このカテゴリーには、また、ある種のデータ変換を行うプロキシーとして機能するアプリケーションも含まれます。このようなプログラムは、ユーザーから指定された入力と、プロキシーによってリモート・サーバーから入手される若干の元データにしたがって処理を行います。この種のアプリケーションとしては、たとえば、ページをある言語から別の言語に翻訳するとか、HTMLをWMLに変換するなど、データをあるフォーマットから別のフォーマットにトランスコードするといったプログラム等が含まれます。このようなアプリケーションの場合、しかるべき応答を生成するために必要な情報は、ユーザー入力とクライアントから提供される元の応答とによって容易に入手されます。Edge Serverでアプリケーション・オフロードがサポートされていれば、そのようなアプリケーションは (サーブレットやJSPコンポーネントとして記述される場合)、簡単にEdge Serverにオフロードして実行することができます。

ただし、ほとんどのアプリケーションは、2つ目のカテゴリーに属し、データベースやディレクトリーやローカル・ファイル・システムなどの情報を使用してユーザーへの応答を生成します。Edge Serverはデータ・キャッシングをまったくサポートしていないので、アプリケーション・オフロードは、1番目のカテゴリーのアプリケーションにしか適用できないと考える方もいるかもしれません。しかしながら、既存のデータベースやディレクトリーやWebサーバー製品を利用している、2番目のカテゴリーのアプリケーションでも、多くはオフロードが可能です。

アプリケーション・オフロードは、アプリケーションの開発や配置に際し、いろいろな状況で利用することができます。本稿では、オフロード可能なコンポーネントに分割する必要のある既存のアプリケーションについてのヒントを紹介するとともに、新規開発のプログラムをオフロードしやすくするために有効なヒントも紹介したいと思います。また、アプリケーションの中でオフロードが可能な部分の割合をできるだけ大きくするための一般的な技法についても紹介したいと思います。

既存のアプリケーションのオフロード

既存のアプリケーションをオフロードしようという場合、以下の技法のいくつかまたは全部を試してみるとよいでしょう。

• データの複製:多くのデータベース・システム (たとえば、IBM DB2 Universal Databaseなど) は、データベースのコピーを作成し、いろいろなサイトでアクセスできるようにするテクノロジーを提供しています。データベースを複製することで、Edge Serverから近いところにデータを配置できるようになります。データを処理するサーブレットやJSPコンポーネントも、Edge Serverにオフロードできますので、性能やスケーラビリティを高めることができます。同様の複製テクノロジーが、LDAPベースのディレクトリーでも利用できます。
• データのパーティショニング:場合によっては、各Edge Serverが処理の対象とするデータを分担し、ある範囲のデータを扱うリクエストは、すべて、対応するEdge Serverでのみ処理するように、アプリケーションを設計することができます。この種の仮想的なデータ・パーティショニングによって、多数存在するデータベースのコピーの間で調整を行わなくても、それぞれのEdge Serverがそれぞれ種類の異なるデータを処理できるようになります。会議室のスケジュール管理アプリケーションの場合、各Edge Serverが、別々のブロックの会議室の予約を処理することができます。
• リクエストの転送:多くの場合、データのパーティショニングは、ほとんどのWebサーバーがサポートしているリクエストの転送(redirection)機能で支援することができます。多くの場合、リクエストで処理の対象とされるデータ・パーティションがどれであるかは、ユーザーから送られてくるURL文字列に指定されたパラメーターで判別できます。URLの転送ルールにしたがって、各リクエストをしかるべきEdge Serverに振り分けることができますので、担当のサーバーがそのリクエストを処理できることになります。

アプリケーション・オフロード対応の新規アプリケーションの開発

新規アプリケーションを開発する場合、以下の点に注意すれば、その大半はオフロードすることができます。

• サーブレットやJSPコンポーネントにJ2EEプログラミング・モデルを採用する。主に読み出しを行う処理と主に書き込みを行う処理とを別々のサーブレットまたはJSPコンポーネントとして定義する。それによって、読み出し処理がEdge Serverにオフロードできるようになる。
• データベースやディレクトリー・サーバーへのアクセスを、標準的なアクセス・ライブラリーを使って読み出しおよび書き込みのアクセスを行うクラスにカプセル化する。それによって、データのキャッシングが透過的に実現できる。
• ワイド・エリア・ネットワーク経由でデータベースやディレクトリー・サーバーにアクセスすることが予想される場合、遅いリンクを経由してデータにアクセスする確率を小さくするために、アプリケーション・レベルでキャッシング機能を実現する。独自のキャッシング機構を実現しているサーブレットは、オフロードすることができ、全体的な性能やスケーラビリティを高めることができます。
• サーブレットおよびJSPコンポーネントを構造を設計する際には、次の点を考慮すること。すなわち、オフロードされたサーブレットが、高い確率でオフロードされている他のサーブレットを呼び出すことができ、オフロードされていないサーブレットからオフロードされているサーブレットへの呼び出し (およびその逆の呼び出し) の回数ができるだけ少なくなるようすること。
• 特定のパーティションのデータを処理するEdge Serverへの転送が簡単に実現できるように、URL中のユーザー引数の渡し方を定義する。たとえば、パーティションの識別子が照会文字列中の第1パラメーターに指定されるようにする。

上に戻る

アプリケーション・クラスごとのアプリケーション・オフロード

以下では、Webアプリケーションのいろいろなクラスごとにアプリケーション・オフロードを有効にする方法、既存のアプリケーションでアプリケーション・オフロードを機能させる方法、およびアプリケーション・オフロードを活用する新規アプリケーションの開発方法について解説していきます。

検索 / ディレクトリー・アプリケーション

検索 / ディレクトリー・アプリケーションには、IBM SecureWay Directoryなどのディレクトリー・サーバーに格納されている情報を利用するWebベースのプログラムや、ディレクトリー・サーバーにWebベースでアクセスできるようにする共通プログラムなどがあります。ここでは、ディレクトリー・サーバーが、一般によく知られているLDAPアクセス・プロトコルを使ってアクセスされるものとします。

そうしたアプリケーションは、企業内の人的資源ディレクトリーやWebベースの電子メールユーザーのアドレス・ブックとして利用されることもあれば、ディレクトリー・サーバー内に登録されたユーザーのプロファイルやプリファレンスを表示するために利用されることもあります。たとえば、企業の人的資源ディレクトリー・システムは、企業内の他のユーザーを検索するために利用できるかもしれません。アドレス・ブック・サービスは、システム内のメンバーの名前やアドレスを検索するために利用できるでしょう。ディレクトリー・アプリケーションの一般的な用途は、システム内のエントリー（登録項目）を検索することにあり、ディレクトリーの更新は、比較的少ない頻度で行われます。

通常のアプリケーションでは、クライアントがアクセスするのは、サーブレットやJSPコンポーネントとのインターフェースとなるWebアプリケーション・サーバーであり、サーブレットまたはJSPコンポーネントは、ディレクトリーの照会を受け取り、それをLDAPリクエストに変換します。変換されたLDAPリクエストは、LDAPディレクトリー・サーバーに転送されます。サーブレットやJSPコンポーネントは、ディレクトリー・サーバーからの応答をブラウザーが理解可能なHTML (または他の構文) の書式にします。筋書きは、図1 のとおりで、クライアントがアプリケーション・サーバー経由でディレクトリー・サーブレットを起動し、LDAPディレクトリーをアクセスするという図式です。

他のディレクトリー・ベースのWebアプリケーションの場合、ディレクトリー・サーブレット (LDAPサーバーとのインターフェースをとるサーブレット) が間接的にしか呼び出されないこともあります。たとえば、ユーザーが呼び出すのは、ユーザー・サーブレットが応答を行うURLで、そのユーザー・サーブレットがLDAPとのインターフェースをとるディレクトリー・サーブレットを起動するといった場合です。このような場合、ディレクトリー・サーブレットは、通常、ディレクトリー検索の結果を、ユーザーと相対しているサーブレットが理解可能な構造またはフォーマットに変換することになるでしょう。フォーマットは、プログラム設計次第で、HTMLのこともあれば、別のアプリケーション固有の内部フォーマットの場合もあります。このような構造を示したのが図2 です。ユーザー・サーブレットは、サーブレット同士がお互いのサービスを呼び出せるようにアプリケーション・サーバーが用意している何らかのメカニズムを使って、ディレクトリー・サーブレットにアクセスします。

ディレクトリー・アプリケーションは、たいていは読み取り専用ですので、ディレクトリー・サーブレット (LDAPとのインターフェースとなるサーブレット) は、オフロードすることができます。ユーザー・サーブレットが主として読み出しを行うアプリケーションで、かつユーザー・サーブレットのオフロードを妨げる問題が他にない環境では、ユーザー・サーブレットとディレクトリー・サーブレットは、ともにEdge Serverにオフロードすることができます。

既存の検索 / ディレクトリー・アプリケーション
既存の検索 / ディレクトリー・アプリケーションの場合、アプリケーションに変更を加えることなく、アプリケーション・オフロードを有効にするには、Edge Serverにディレクトリー・サーブレットを (ユーザー・サーブレットが使われているならそれも) オフロードし、オフロードされたディレクトリー・サーブレットに元のLDAPサーバーをアクセスさせるようにします。ディレクトリー・サーバーのアクセスに要する待ち時間が、アプリケーション・サーバーで必要とされる全体の処理時間の中のわずかな割合でしかない場合には、アプリケーションのスケーラビリティを向上させ、ユーザーが体感するアプリケーションの応答時間も短縮できます。Edge Serverがリバース・プロキシーとして配置されているところでは、これが功を奏する場合があります。

しかし、Edge Serverが遠く離れたところにある場合、これが逆効果となる場合もあります。ディレクトリー・サーブレットからディレクトリー・サーバーまでのネットワーク待ち時間が比較的大きく、しかもディレクトリーのアクセスがクライアントによって体感される応答時間の大きな部分を占めるような地理的に分散した環境においては、単純なオフロードが、ユーザー性能を劣化させる場合もあります。単純なオフロードが有効かどうかは、ディレクトリー・サーブレットの中で何を行っているのかに依ります。

ディレクトリー・サーブレットがディレクトリー・エントリーのキャッシングをサポートしているのであれば、Edge Serverをオフロードすることで、性能に逆効果をもたらすことはないかもしれません。利用パターンがキャッシングになじみやすい (すなわち、いくつかのエントリーが他のエントリーよりもアクセス頻度が多い) 場合には、ディレクトリー・サーブレットをオフロードすることで、スケーラビリティや性能にかなりの向上を見込むことができます。ディレクトリー・ライブラリーがキャッシングをサポートしている場合 (すなわち、ディレクトリーのキャッシングをサポートするJNDIのバージョンをEdge Serverで利用している場合) にも、同じことが言えます。

一方、ディレクトリー・サーブレットがキャッシングをまったく何もサポートしていない場合、データをEdge Serverから近いところに配置する必要があるかもしれません。たとえば、ディレクトリー・サーバーへの待ち時間が大きい地理的に分散した環境でのアプリケーションがそうです。

このような場合にディレクトリー・サーブレットのオフロードを可能にする便利な方法の1つとして、LDAPの複製機能を利用して、オフロードされるサーブレットから近いところにディレクトリー・データを配置するという方法があります。LDAPディレクトリー・サーバーの複製を、Edge Serverに配置するか、あるいはディレクトリー・サーブレットとのネットワーク接続が良好なサイトに配置します。ユーザー・サーブレットとディレクトリー・サーブレットには、エッジ化可能 (edgeable)というマークが付けられます。アプリケーション中の他のサーブレットには、必要に応じてエッジ化可能 とかエッジ化不可能 (non-edgeable) というマークが付けられます (詳細については、参考文献に掲げたApplication Offload Programming Guideを参照してください)。

新しい検索 / ディレクトリー・アプリケーションの設計
新規にアプリケーションを開発するのであれば、以下のような手段を講じることで、作成するサーブレットやJSPコンポーネントのほとんどをオフロード可能なものにすることができます。

• 読み取り専用の機能のほとんどが、変更処理や書き込み処理を行う機能とは別のサーブレットで実現されるようにアプリケーションの構造を設計してみる。読み取り専用のサーブレットは簡単にオフロードすることができますが、書き込みサーブレットをオフロードしようとすると、データの整合性や同期化の問題が生じます。
• Edge Serverに空きスペースがあるなら、Edge ServerにLDAPディレクトリーの複製を用意する。あるいは、そのエッジ・サイトに近いサイトにLDAPディレクトリーの複製を用意する。LDAPの複製作業はEdge Server外で手作業で行う必要がありますが、複製の機能は、商品化されているほとんどのLDAPディレクトリー・サーバーでサポートされています。
• ディレクトリー・サーバーの複製コピーが手許で利用できるかどうかが不確か場合には、LDAPのキャッシングをサポートするJNDIライブラリーかLDAP Cライブラリーを使用する。たとえば、LDAPクライアントのIBM z/OS実装版は、LDAPのアクセスに関して照会のキャッシングをサポートしています。
• LDAPの複製やキャッシングがインフラストラクチャーとしてサポートされていないようであれば、アプリケーション・ソフトウェアの中でLDAPの照会についてある程度のキャッシングを実現することを検討する。ディレクトリー・サーバーをアクセスするための独自のクラスを定義し、そうしたクラスの中で照会に関するある程度のキャッシングを実現すれば、ディレクトリー・サーブレット (並びにキャッシング・クラス) をEdge Serverにオフロードすることは容易となります。

予約 / スケジュール管理アプリケーション

予約 / スケジュール管理アプリケーションには、通常、リソースを閲覧するためのコンポーネントと、指定したリソースを予約したり、登録済みの予約を変更するためのコンポーネントが使用されます。

たとえば、会議室予約システムでは、ユーザーは以下のようなことを行うことができます。

• 登録済みの予約の確認と検索
• 指定した時間に利用可能な部屋の確認と検索
• 部屋の予約
• 予約の取り消しと変更
• ユーザー・プリファレンス (利用者選好) の設定

最初の2つの機能は、閲覧コンポーネントに属し、ほとんどの場合、アプリケーション・データへの読み取り専用アクセスで済みます。次の2つの機能は、変更コンポーネントに属し、アプリケーション・データへの書き込みアクセスを必要とします。最後の機能は、変更コンポーネントであり、その設定情報は、閲覧コンポーネントから、そしておそらく変更コンポーネントからも必要とされそうです。この構造を示したのが、図3 です。

この種のアプリケーションの場合、ユーザーは、条件に合致するリソースを見つけ出そうとして、通常、閲覧コンポーネントにリクエストを何個も出します。適当なリソースが見つかった場合、普通、リソースの予約を更新するためには、変更コンポーネントとちょっとしたやり取りを行います。

アプリケーション・オフロードの観点から、この種のアプリケーションを自然な形で分割するとすれば、閲覧コンポーネントをEdge Serverに置き、変更コンポーネントは元のサーバーに残すという形になります。このようにすることで、頻繁に使用されるほうの閲覧コンポーネントは分散配置され、サーバーの負荷が軽減され、クライアントが最もよく使用する機能に対するユーザー応答時間を改善できることになります。

既存の予約 / スケジュール管理アプリケーション
予約 / スケジュール管理アプリケーションをEdge Serverで有効に機能させるための手段は、アプリケーションの特性に依存する面もありますが、この種のアプリケーション一般について言えば、目標は、閲覧コンポーネント用としてEdge Serverを活用し、変更コンポーネントには元のサーバーを利用することになるでしょう。閲覧コンポーネントをオフロードすることで、元のサーバーは、リソース予約の受け付けというもっと重要な作業に専念できるようになり、同時に、それよりも頻繁に起こる閲覧については、応答時間が短縮されることになります。

多分、アプリケーション・オフロードのことを意識してアプリケーションが設計されていれば、話は最も簡単なのでしょうが、すべてのアプリケーションがそうなっているわけではありません。そうしたアプリケーションは、通常、閲覧コンポーネント用のサーブレットと変更機能用のサーブレットを使用することになり、これらのサーブレットは、すべて、図4 に示されるように、データ・ストアに直接アクセスするか、中間のEJBコンポーネントを介してデータ・ストアにアクセスします。

閲覧コンポーネント・サーブレットをEdge Serverにオフロードしつつも、それらのサーブレットが元のサーバーにある元のデータ・ストアにアクセスするようにすることもできますが、そのようにした場合、閲覧コンポーネントは、クライアントからの個々のリクエストに応えるために、データ・ストアに何度も照会を行うことになるでしょうから、性能を損なう公算が強いでしょう。実際に必要なのは、データ・ストア上の関係するデータのコピーをEdge Serverに置くことで、Edge Serverが、元のサーバーに問い合わせを行うことなく、ほとんどの閲覧リクエストに応えることができるようにすることです。

前述のように、閲覧コンポーネントが照会のキャッシングをサポートするなら、閲覧コンポーネントをオフロードするだけで、充分良好な性能が得られるかもしれません。他方、閲覧コンポーネントがキャッシングをサポートしておらず、その点を変更することもできない場合には、複製機能を備えたデータ・ストアを採用し、データ・ストアの複製を各Edge Serverまたはその近くに配置するとよいでしょう。アプリケーションの閲覧コンポーネントには、エッジ化可能のマークを付け、変更コンポーネントにはエッジ化不可能のマークを付けるとよいでしょう。Edge Serverのデータ・ストアおよび複製は、手作業でセットアップしなければならないでしょうが、複製データ・ストアを配備してしまえば、Edge Serverで提供されるアプリケーション・オフロード機能を使って、アプリケーションのエッジ化可能コンポーネントおよびエッジ化不可能コンポーネントを分散配置することができます。この配置状況を示したのが図5 です。

閲覧コンポーネントにはエッジ化可能のマークが付けられていますので、閲覧リクエストは、すべて、Edge Serverで処理されることになり、Edge Serverがローカルな複製データ・ストアに照会を行い、リクエストへの応答を作成することになります。変更コンポーネントにはエッジ化不可能のマークが付けられていますので、変更リクエストは、Edge Serverから元のサーバーに転送されることになり、元のサーバーが元のデータ・ストアに対して変更を行うことになります。変更内容は、データ・ストアの複製機能を用いて、元のデータ・ストアから各エッジのデータ・ストアに伝播されます。複製の頻度は、元のデータ・ストアに対する変更の頻度にしたがって、選択することができます。

閲覧に使われるEdge Serverの配置位置にしたがって、データを部分集合に分けているようなアプリケーションの場合、Edge Serverには、そうしたデータの部分集合だけを複製しておけばよいことになります。たとえば、会議室スケジュール管理アプリケーションの場合、ユーザーが自分の事業所の会議室しかスケジュールできないようになっていて、それぞれの事業所にEdge Serverが置かれているときには、会議室のデータを事業所ごとに分割し、各事業所がそれぞれのデータの面倒をみるようにすることもできるでしょう。

データ・ストアを複製するという解決策は、変更があってから複製が実行されるまでは閲覧データに不一致があるわけですから、頻繁に更新がなされたり、データの一貫性に格段の厳密さが求められるようなアプリケーションでは、充分有効だとは言えないことになります。

予約 / スケジュール管理アプリケーションの新規設計
新規開発の予約 / スケジュール管理アプリケーションでアプリケーション・オフロードを利用する場合、閲覧コンポーネントをEdge Serverに置き、変更コンポーネントを元のサイトに置く (場合によっては、元のデータ・ストアに対する更新内容とともにEdge Serverに置く) というのが自然な選択です。閲覧コンポーネント用のデータをEdge Serverに置く方法としては、アプリケーション・データの性質に依って、少なくとも複製と照会のキャッシングの2通りの方法があります。

アプリケーション・データのサイズが比較的小さい場合、あるいはリクエストにあまり局所性がない場合には、複製が最適でしょうし、アプリケーション・データのサイズが比較的大きい場合、あるいはリクエストに局所性がある場合には、照会のキャッシングが最適でしょう。

ここでは、Edge Serverの閲覧コンポーネントにまずリクエストをローカルで処理させてみて、それがうまくいかない場合に元のデータ・ストアに照会を行うという方法で実現することのできる照会のキャッシングに話を絞ることにします。元のデータ・ストアに対する紹介およびデータ・ストアからの応答は、Edge Serverのキャッシュに保存されます。クライアントから新しいリクエストがくると、そのつど、そのクライアントへの応答として使用できるようなデータがキャッシュにないか、キャッシュをチェックします。そういうものがなければ、元のストアに対して照会がなされ、それに対する回答は、キャッシュに入れられるとともに、クライアントに返答されます。

たとえば、前回のクライアントからのリクエストが、以下のように、元のデータベースに対して照会を行うようEdge Serverに求めるものだったとします。

      SELECT Person, Time, Room, Day FROM reservations WHERE Day="Tuesday";

このとき、照会に対する回答が、以下のような表だったとします。

その後のクライアントからのリクエストが、以下のように、火曜日のRoom1の予定の照会を行うものだったとすると、Edge Serverは、ローカルにキャッシュされた照会と回答を参照するだけで、A. Personが午後2:00から、J. Smithが午後3:30からその部屋を使用することを返答できることになります。

      SELECT Time, Room FROM reservations WHERE Day="Tuesday" and Room="Room1";

通常、データにどの程度の一貫性をもたせる必要があるかによって、照会キャッシュの各エントリーには有効期限が設けられるでしょう。また、照会キャッシュを元のサーバーにも記録しておき、元のサーバーに変更を行うと、照会キャッシュのエントリーを無効にするようにすることも考えられます。そして、無効にしたことを各Edge Serverに通知することもできるでしょうし、Edge Serverが、照会キャッシュのエントリーを使用する前に、元のサイトに対して簡単なリクエストを発行し、エントリーが無効になっていないかどうか確認するようにすることもできるでしょう。

局所性のあるデータの場合、あるいは同じようなリクエストが頻繁に起こる場合には、複製よりも照会のキャッシュのほうが、各Edge Serverにコピーすべきデータが少なくて済みますので、ずっと有効です。

エレクトロニック・コマース (電子商取引) アプリケーション

エレクトロニック・コマースとかeコマースというのは、オンラインで、通常はインターネット上で、ビジネスを行うことを意味します。eコマースでは、通常、商品やサービスがオンラインで売買されます。カスタマーは、製品カタログを閲覧し、安心できるオンライン環境で製品を購入し、製品を宅配してもらうことを想定してWebサイトをアクセスします。IBM WebSphere Commerce Suiteなどのeコマース・ソリューションには、通常、企業が商売を行う上で必要とするもの一式が用意されます。

eコマース・アプリケーションは、次の2つのモデルに分類することができます。

• 企業間取引 (B2B)
• 企業・顧客間取引 (B2C)

企業・顧客間 (B2C) eコマースのストア・モデルは、一般からアクセス可能なWebサイトであり、そこには販売したい製品が提示されます。カスタマー (買物客) は、取引を行う上で必要な、カスタマー自身についての一般的な情報 (名前、住所、クレジット・カードなど) を提示することで、買物が可能になります。たいていのB2Cサイトは、ユーザー登録を行い、メンバーになることを求めます。

企業間取引 (B2B) eコマースのストア・モデルは、とくに組織体がインターネット上でビジネスを行うために構築されるeコマース・ストアのことを指します。2つのエンティティーは、お互いを知っており、ユーザーはすべて登録されています。B2Bアプリケーションは、業務を能率的なものにし、事業者間の購買手続きの効率を向上させることができます。

eコマースで使われる基本的な概念に、以下のようなものがあります。

• 製品カタログ:印刷されたカタログと同様、製品が論理的なグループに分類・整理され、売上高ができるだけ大きくなるように製品の表示方法が設計されます。カスタマーは、カタログを閲覧して製品を検索し、発注を行います。
• 買物かご:オンラインの注文バスケット。カスタマーは、eコマース・サイトを閲覧し、自分の買物かごに製品を入れていきます。買物客は、精算レジ (check-out) に行って、買物かごに入れた製品を購入します。
• ユーザー・プロファイル:ユーザーに関する情報。B2Cサイトでは、通常、ユーザーに登録を行ってもらうようにします。この情報は、ユーザーがサイトを訪問している間に収集される情報とともに、ユーザー・プロファイルを構成します。ユーザー・プロファイル情報を使って、サイト・コンテンツをユーザーに合わせたものにすることもできます。

これらの構成部品の他にも、ストアには、注文後の処理を行うための事務処理システムも組み込まれています。

eコマースの概念は、図6 に示されるように、閲覧コンポーネントと変更コンポーネントの2つのコンポーネントに分けて実現することができます。閲覧コンポーネントは、製品カタログの閲覧や検索、依頼済みの注文内容の確認といった作業を担当します。変更コンポーネントは、買物かごの更新とかユーザー・プロファイルの更新といった更新処理を担当します。

既存のeコマース・アプリケーション
eコマース・アプリケーションをEdge Serverで有効に機能させるための手段は、アプリケーションの特性に依存する面もありますが、この種のJ2EEアプリケーション一般について言えば、目標は、先に予約 / スケジュール管理アプリケーションについて説明したことと同様、閲覧コンポーネントにはEdge Serverを活用し、変更コンポーネントには元のサーバーを利用することになります。eコマース・アプリケーションの場合も、閲覧コンポーネントをオフロードすることで、元のサーバーは、注文の処理というもっと重要な作業に専念できるようになり、同時に、それよりも頻繁に起こる閲覧については、応答時間が短縮されることになります。

いま、J2EEのeコマース・アプリケーションが、閲覧コンポーネント用のサーブレットと変更機能用のサーブレットを使用し、これらのサーブレットが、すべて (図4 に示されるように)、データ・ストアに直接アクセスするか、中間のEJBコンポーネントを介してデータ・ストアにアクセスするものとします。閲覧コンポーネント・サーブレットをEdge Serverにオフロードしつつも、それらのサーブレットが元のサーバーにある元のデータ・ストアにアクセスするようにすることもできますが、そのようにした場合、閲覧コンポーネントは、クライアントからの個々のリクエストに応えるために、データ・ストアに何度も照会を行うことになるでしょうから、性能を損なう公算が強いでしょう。実際に必要なのは、データ・ストア上の関係するデータのコピーをEdge Serverに置くことで、エッジ・サーバーが、元のサーバーに問い合わせを行うことなく、ほとんどの閲覧リクエストに応えることができるようにすることです。

照会のキャッシングをサポートする閲覧コンポーネントは、オフロードするだけで、充分な性能を示すかもしれません。閲覧コンポーネントがキャッシングをサポートしておらず、その点を変更することもできない場合には、複製機能を備えたデータ・ストアを採用し、データ・ストアの複製を各Edge Serverまたはその近くに配置するとよいでしょう。

アプリケーションの閲覧コンポーネントには、エッジ化可能のマークを付け、変更コンポーネントにはエッジ化不可能のマークを付けるとよいでしょう。Edge Serverのデータ・ストアおよび複製は、手作業でセットアップしなければならないでしょうが、複製データ・ストアを配備してしまえば、Edge Serverのアプリケーション・オフロード機能を使って、図5 に示されるように、アプリケーションのエッジ化可能コンポーネントおよびエッジ化不可能コンポーネントを分散配置することができます。

閲覧コンポーネントにはエッジ化可能のマークが付けられていますので、閲覧リクエストは、すべて、Edge Serverで処理され、エッジ・サーバーがローカルな複製データ・ストアに照会を行い、リクエストへの応答を作成します。変更コンポーネントにはエッジ化不可能のマークが付けられていますので、変更リクエストは、Edge Serverから元のサーバーに転送され、元のサーバーが元のデータ・ストアに対して変更を行います。変更内容は、データ・ストアの複製機能を用いて、元のデータ・ストアから各エッジのデータ・ストアに伝播されます。複製の頻度は、元のデータ・ストアに対する変更の頻度にしたがって、選択することができます。

データ・ストアを複製するという解決策は、変更があってから複製が実行されるまでは閲覧データに不一致があるわけですから、頻繁に更新がなされたり、データの一貫性に格段の厳密さが求められるようなアプリケーションでは、充分有効だとは言えないことになります。

新しいeコマース・アプリケーションの設計
前と同様、eコマース・アプリケーションを分割するなら、閲覧コンポーネントをEdge Serverに置き、変更コンポーネントを元のサイトに置く、あるいは場合によっては、元のデータ・ストアに対する更新内容とともにEdge Serverに置く、というのが自然です。閲覧コンポーネント用のデータをEdge Serverに置く方法としては、アプリケーション・データの性質に依って、少なくとも複製と照会のキャッシングの2通りの方法があります。

eコマース・アプリケーションの場合、製品提供が頻繁に変更されるわけではありませんので、多くの場合、複製が最適です。一方、大規模なeコマース・サイトで、製品の数が多い場合には、照会のキャッシングのほうが適している場合もあるでしょう。

ここでは、Edge Serverの閲覧コンポーネントにまずリクエストをローカルで処理させてみて、それがうまくいかない場合に元のデータ・ストアに照会を行うという方法で実現することのできる照会のキャッシングに話を絞ることにします。元のデータ・ストアに対する紹介およびデータ・ストアからの応答は、Edge Serverのキャッシュに保存されます。クライアントから新しいリクエストがくると、そのつど、そのクライアントへの応答として使用できるようなデータがキャッシュにないか、キャッシュをチェックします。そういうものがなければ、元のストアに対して照会がなされ、それに対する回答は、キャッシュに入れられるとともに、クライアントに返答されます。

たとえば、前回のクライアントからのリクエストが、Return all of the women's outerwear products (女性ものの上着全品を返せ) のように、元のデータベースに対して照会を行うようEdge Serverに求めるものだったとします。

その後のクライアントからのリクエストが、女性ものの上着で20ドル以下の製品を求めるものだったとすると、Edge Serverは、それまでにキャッシュされたデータを基に、指定された部分集合を返せることになります。

通常、データにどの程度の一貫性をもたせる必要があるかによって、照会キャッシュの各エントリーには有効期限が設けられるでしょう。また、照会キャッシュを元のサーバーにも記録しておき、元のサーバーに変更を行うと、照会キャッシュのエントリーを無効にするようにすることも考えられます。無効にしたことは、各Edge Serverに通知することもできるでしょうし、Edge Serverが、照会キャッシュのエントリーを使用する前に、元のサイトに対して簡単なリクエストを発行し、エントリーが無効になっていないかどうか確認するようにすることもできるでしょう。

局所性のあるデータの場合、あるいは同じようなリクエストが頻繁に起こる場合には、複製よりも照会のキャッシュのほうが、各Edge Serverにコピーすべきデータが少なくて済みますので、ずっと有効です。

アプリケーション・サービス

Edge Serverでのアプリケーション・サービスには、それまで元のサイトで実行されていたサービスを、Edge Serverで実行できるようにするということが含まれます。Edge Serverで実行できるようにされるのは、通常、応答そのものを生成するサービスではなく、リクエストに対する応答を変更するコンテンツ変更サービスです。trans* クラスのアプリケーション・サービス (transcoding, translation, transformation) は、有効な応答を入力として受け取り、それに何らかの変更を加え、ユーザーに対する応答を改造します。

以下では、Edge Serverでアプリケーション・サービスを総て実行できるようにする方法について紹介します。また、サービスを元のサイトで実行しながら、アプリケーション・サービスの構成をEdge Serverに移行する方法についても説明します。もともとEdge Serverのアプリケーション・オフロード・モデルは、元のアプリケーション・サーバーの代理としてEdge Serverで機能を実行するという考え方ですが、ここで紹介するアプリケーション・サービスの手法は、それとは少し異なります。

IBM WebSphere Transcoding Publisherは、trans* クラスのアプリケーション・サービスに当てはまります。この製品は、(クライアントのリクエストのパラメーターも含めた) 構成パラメーターにしたがって、応答をトランスコードすることで、クライアントへの応答ストリームに変更を加えます。たとえば、Webページをユーザーのハンドヘルド・デバイスに収まるようにトランスコードするといった処理です。その他、このカテゴリーに入るサービスには、XMLの変換や言語の翻訳があります。図7 は、配置例を示しています。

アプリケーション・サービスをEdge Serverで有効にする
ここでは、アプリケーション・サービスがHTTPリクエストに対して有効な応答を受け取り、ユーザーに送信する前に、その応答に変更を加えることを考えます。この場合、これらのアプリケーション・サービスをEdge Serverで実行できるようにするためのプログラミングは必要ありません。これらのアプリケーション・サービスは、元のサーバーで実行されるときと同じ動作をします。

アプリケーション・サービスをEdge Serverで有効するための手順は2つです。

• Edge Serverでサービス呼び出しを有効にする
• 分散配置されるサービス構成を有効にする

Edge Serverでサービス全体を実行できるようにする場合には、Edge Serverにサービス呼び出しを新規に作成する必要があります。そのためには、Edge Serverのキャッシング・プロキシーへのプラグインを作成します (詳細については、参考文献のプラグインに関するものを参照してください)。このプラグインが必要に応じてサービスを呼び出すことになります。サービスは、Edge Serverと同じマシンに収容してもかまいませんし、プラグインから呼び出せるなら別のサーバーであってもかまいません (図8参照)。

アプリケーション・サービスを分散させて配置する構成にすることで、サービスは、元のサーバーで実行できるとともに、各Edge Serverごとに、それぞれのサービス構成を設定することもできます。このようにするのは、個々のEdge Serverごとにロケールや地理的な情報を適用する必要があったりするためです。分散配置の構成を実現するために、Edge Serverのプラグインは、クライアントのリクエストにアプリケーションごとのクッキーを付加します。そして、クッキーは、元のサーバーに転送されます (図9 参照)。これらのクッキーを使って、各ユーザー・リクエストに対するアプリケーション・サービスの構成がカスタマイズされます。

たとえば、ある企業のWebサイトが英国でホストされ、フランスとスペインに支部サイトがあるものとします。この企業は、元サーバーを1基設置し、そのサーバーでトランスコード機能や翻訳機能を同社のイントラネットに提供しています。フランスとスペインにある支部サイトは、これらの国のリモートの従業員に対して、キャッシングとファイアウォールの機能を設けています。トランスコードや翻訳の構成をEdge Serverに分散して配置できるようにすることで、いろいろな支部へのトラフィックそれぞれに対して、適当な言語に適切に翻訳が行われるようになります。各支部で使用されるデバイスの種類がまちまちである場合、Edge Serverでのトランスコードの構成によって、支部ごとのデバイスに対応したトランスコードを行うことができます。

上に戻る

まとめ

IBM WebSphere Edge Server 2.0のアプリケーション・オフロード機能を利用すれば、みなさんのWebアプリケーションのスケーラビリティは向上し、応答時間も速くなり、集中管理も簡単に行えるようになります。本稿で紹介した一般的なガイドラインが、この便利な機能を活かしきるための一助になれば幸いです。

参考文献

• 本製品の詳細については、IBM WebSphere Edge Server を参照してください。
  
  
• データベースの複製については、IBM DB2 DataPropagatorのサイトを参照してください。
  
  
• IBM SecureWay Directory Server には、トライアル版があります。
  

著者について

		James Gilesは、IBM T.J. Watson Research CenterのEdge Networkingグループ所属の研究スタッフ・メンバーです。氏の現在の研究対象は、コンテンツ・ディストリビューション・ネットワークとネットワーク・セキュリティーに関してです。2000年にイリノイ大学Urbana-Champaign校で電子工学のPh.D. を取得し、Evansville大学で電子工学および数学の理学士号を取得しています。 Webページ も覗いてみてください。

		Dinesh C. Vermaは、1987年インドKanpurにあるIndian Institute of Technologyでコンピューター・サイエンスの工学士号 (B. Tech. Degree) を取得し、カリフォルニア大学バークレー校で1992年コンピューター・サイエンスのPh.D. を取得しています。その後は、IBM Watson Research CenterおよびPhilips Research Laboratoriesに勤務しています。氏は、現在、IBM Watson Research Centerで研究マネージャーを務めており、Edge Networkingの分野の研究を主管しています。現在の研究対象は、コンテンツ・ディストリビューション・ネットワーク、ポリシィ・ベース・ネットワーキング (policy-based networking) 、およびネットワーク化システムの性能管理などです。Webページ も覗いてみてください。

		Steve Imsは、IBMのシニア・ソフトウェア・エンジニアです。WebSphere Advanced Technologyグループのメンバーであり、インテリジェント・ネットワーク・インフラストラクチャ、モバイル・コンピューティング、レガシー・インテグレーションなど、J2EEフレームワークを中心にした次世代サービスの考察に日々の時間を費やしています。とくに、ソフトウェア・ツールとの統合を通して、これらのサービスのユーザビリティを育てることに興味をもっています。夜は、永久運動の子供たちとの触れ合いを欠かさないように努めています。

		Ron Doyleは、IBMのWebSphere Advanced Technologyグループのシニア・ソフトウェア・エンジニアで、デューク大学のPh.D. 取得者候補です。コンテンツのディストリビューションと管理、インターネット・サービス配信、およびリソース・プロビジョニングなどに興味があります。氏は、デューク大学でコンピューター・サイエンスのM.S. を、西バージニア大学でコンピューター・サイエンスのM.S. とB.S. を取得しています。Data GeneralのUnixコミュニケーションズ・グループに勤務した後、1993年にIBMに入社しました。

		Subbarao Meduriは、IBMのWebSphere Edge Serverグループのアドバイザリ・ソフトウェア・エンジニアです。インドKanpurにあるIndian Institute of Technologyで電子工学のM.S. を取得しています。現在、ネットワーク・エッジ (edge-of-the-network) のサービスの向上、J2EEフレームワークを中心とした次世代エッジ・サービスの開発などに興味をもっています。WebSphere Edge Serverチームに加わる以前には、IBMで分散ファイルシステムについて長い間研究開発を行っていました。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る