レベル: 中級 Kyle Brown (brownkyl@us.ibm.com), Distinguished Engineer, IBM
Keys Botzum, Senior Technical Staff Member , IBM India Software Lab Services and Solutions
Bill Hines, Senior Certified Consulting IT Specialist , IBM
2005年 09月 21日 IBM® WebSphere® Extended Deployment は、そのオートノミック・コンピューティングおよび数々のかつてない運用機能によって、革命的な製品になっています。さらに優れているのは、WebSphere XD とインテリジェントな新ルーティング・エンジンであるオンデマンド・ルーターが、ネットワーク設計者に、これまでは手に入れることができなかった驚くべきトポロジー・オプションを新たに提供していることです。この記事では、WebSphere XD が高可用性環境に関する目下の期待をいかに上回る機能を提供しているかについて説明します。
IBM WebSphere 開発者向け技術ジャーナル より。
はじめに
WebSphere XDはモニタリング、可用性、システム可視化、パーティショニング機能などにおいて、無類の価値を持つ製品ですが、WebSphere XD が真に革命的なのは、ネットワーク管理者がトポロジーを設計する上で、驚くべき一連の新オプションを提供していることです。そして、そのトポロジーは、常にニーズを満たす必要がある様々な顧客の目標を達成する必要があります。例えば、以下のような顧客が含まれます。
- 使用アプリケーションが常時最大限の性能で稼動し、堅実かつ確実に履行されるサービス・レベル・アグリーメント (SLA) が整備されていることを求める、アプリケーション開発者およびビジネス・ユーザー。
- 絶対に必要な場合にのみハードウェアを購入し、会社が投じるドル (あるいは円、ユーロ、元) が最高の価値を得られるよう万全を期したい企業の会計担当者。
- 与えられたトポロジーおよびアプリケーションを首尾よく管理する必要があるネットワーク管理者。
トポロジー設計者がこれらの目的を達成する上で、WebSphere XD がどのように役立つのかを理解するには、最初に WebSphere Application Server Network Deployment (以後Network Deployment と表記します) のトポロジーにおけるいくつかの機能をレビューする必要があります。そうすることによって、WebSphere XD の新機能がどのように導入され、なぜこれらが目的達成にこれほど役立つのかを理解することができます。
Reviewing Network Deployment topologies
まず、ほとんどの WebSphere 開発者およびトポロジー設計者にとって馴染み深いと思われる、Network Deployment の機能を活用した高可用性トポロジーから検討を始めます。
図 1. Network Deployment トポロジー
図 1 では、最初に要求が、Edge Components のLoad Balancerまたはその他の IP スプレイヤーのいずれかの IP スプレイヤーに送信されているのがわかります。その次に、要求は Web サーバーのレイヤーに送られ、そこでは WebSphere プラグインがそれぞれの要求を評価して、アプリケーション・サーバー・レイヤーに送るべきかを判断します。
このトポロジーは、WebSphere Application Server V3.5 Advanced Edition が発表されて以来かなり一貫性を保ってきており、その後の WebSphere のスケーラビリティーおよび高可用性に関する評価の基礎を形作ってきました。ただし、プラグインの機能には、理解しておく必要があるいくつかの制限があり、それを理解することによって、なぜ WebSphere XD が異なる形で処理を行なうのかを理解することができます。
-
プラグインが、要求をどのようにアプリケーション・サーバーに送るかを判断するために使う情報は静的です。すなわち、要求 URL およびそれらの URL をサービスできるアプリケーション・サーバー・セット間のマッピングは、(WebSphere Application Server V5.x 以降において plugin-cfg.xml と呼ばれる) XML ファイルによって提供されます。その XML ファイルは、デプロイメント・マネージャーによって生成され、管理者が手動で Web サーバー・マシンにコピーしなければなりません。URL が変更されたり、または新たなサーバーが追加された場合には、プラグイン・ファイルは再生成され、置換されなければなりません。(WebSphere Application Server V6 においては、plugin-cfg.xml ファイルを Web サーバーにプッシュすることができますが、この方法にはいくつかの考慮点があり、この方法が不適切になる場合が頻繁に起こります。)
-
アプリケーション・サーバー・マシンから、Web サーバー・プラグインに情報を通知する通信パスは存在しません。そのため、プラグインは、サーバーがどれほどビジーであるのかがわかりません。多くの場合、サーバーが要求に応じなくなったときに初めて、プラグインはサーバーが過負荷状態になったことを知ります。
-
Web サーバー・プラグインは、必然性から、小さくてポータブルな一片のコードになっています。プラグインは、Network Deployment が対応しているすべての Web サーバーに準拠しなければならず、また、DMZ (非武装地帯、安全ではないゾーン) 内で稼動することから、これらの要件を満たすために、機能を最小限にしておく必要があります。
ご覧のように、現在の配置にはいくつかの因果関係があります。プラグイン・ファイルが再生成されて置換されなければならないため、トポロジーの配置は手動操作によって変更されます。また、アプリケーション・サーバーの状態について、プラグインが収集できる情報量は制限されます。これらの因果関係は、明らかな問題であるかという観点からすれば、確かに相対的な重要性は低いことを認めざるを得ません。しかし、インテリジェントなロード・バランサーとしてどのような強力な機能が必要かという観点で、より発展的な考え方をする方が良いでしょう。これが、WebSphere XD の、そしてオンデマンド・ルーターに具体化されている重要な革新の 1 つです。
オンデマンド・ルーターの紹介
オンデマンド・ルーター (ODR) は、WebSphere XD トポロジーの中核を成すインテリジェントな Java™ ベースのルーティン・エンジンです。ODR には、Network Deploymentの Web サーバー・プラグインと、Edge ComponentsのLoad Balancerのようなネットワーク先端ルーターの両方が持つ多くの機能が具体化されています。さらに、ODR は、これらの機能を大きく凌ぐ形で、WebSphere XD のオンデマンド機能に対応しています。
ODR は以下の機能を持っています。
-
プロキシーを務めるべき要求に対して listen します (現在は HTTP のみですが、今後 RMI-IIOP や JFAP (WebSphere に組み込みメッセージング) など、その他のプロトコルへの拡張が予定されています。)。
-
要求の宛先となっている WebSphere (またはその他の) アプリケーション・サーバーの構成に応じて、要求を分類します。
-
要求に優先順位を付け、どのアプリケーション・サーバーに要求が送られるべきかを判断するために、保有しているアプリケーション・サーバーの状態に関する情報を利用します。
-
要求を待ち行列に並べ、それぞれの要求に割り当てられたウェイトに従って、アプリケーション・サーバーに送出します。
-
XDシステムのその他の機能と通信して、その活動を調整したり、動的配置などの機能を促進します。
ODR を含めた、XDトポロジーは、図 2 のようになります。
図 2. WebSphere XD トポロジー
このトポロジーには、標準の Network Deployment トポロジーに対し、以下のようないくつかの有利な点があります。
-
このトポロジーにおいては、ODR が使用するルーティング情報は動的です。アプリケーションがデプロイ (またはアンデプロイ) されるか、またはアプリケーション・サーバーがトポロジーに追加 (または削除) される際に、ODR ルーティング・テーブルは自動的に更新されます。このとき、デプロイメント・マネージャーと ODR 間の通信は直接行なわれるため、plugin-xml.cfg ファイルが必要なくなります。
-
ODR 自身も独立したアクティブなアプリケーション・サーバー・インスタンスなので、アプリケーション・サーバーからの追加情報を利用して、要求の加重に関して動的な判断を下すことができます。
しかし、これらの利点はほんの序の口にすぎません。ルーティングを動的なものに変え、アプリケーション・サーバー (およびデプロイメント・マネージャー) と ODR の間に通信パスを作成したことにより、次のセクションで示されるようなその他の数々の心躍る可能性への道が開かれたのです。
図 2 を眺めて、なぜ ODR サーバーの前にプロキシー・サーバーが配置されているのかを、不思議に思うかもしれません。DMZ 内のセキュリティーの保全性を維持するのが、その理由です。ここでは、DMZ に関する以下の 3 つの基本原則を適用しています。
-
外から入ってくるインバウンド・ネットワーク・トラフィックは、DMZ で断ち切らなければなりません。Load Balancerなどのネットワーク透過ロード・バランサーでは、単独でその要件を満たすことができません (図 1 では DMZ に Web サーバーを配置したことを思い起こしてください。)。
-
DMZ からイントラネットに向けて開かれているトラフィック・タイプとポート数は、制限しなければなりません。
-
DMZ 内で稼動しているコンポーネントは、強化されている必要があり、機能を最低限に抑えて複雑さを抑制するという原則に従わなければなりません。
ODR は、基本的には特殊機能が付加された Java アプリケーション・サーバーです。結果として、複雑 (かつ有用) なコードが大量に含まれています。残念ながら、これほど複雑で、多くのポートが開かれている ODR は、DMZ には不向きです。さらに、最大の効果を得るため、ODR はアプリケーション・サーバーと通信できなければならず、セル管理インフラストラクチャーに参加しなければなりません。その結果、大量の通信が伴うことになります。もし、ODR が DMZ 内にあったとすれば、内部ファイアウォールにおびただしい数の穴が開くことになります。WebSphere Application Server インフラストラクチャーを強化するステップの詳細については、「WebSphere Application Server V5 拡張セキュリティーおよびシステムの強化」を参照してください。
これらの理由から、DMZ にはより単純なコンポーネントを配置して、ネットワーク接続を遮断する必要があります。図 2 ではプロキシー・サーバーを選びましたが、インバウンド SSL を遮断する SSL アクセラレーター、(Tivoli® Access Manager WebSEAL のような) 認証プロキシー・サーバーなどの他のコンポーネントでも構いませんし、あるいは、plugin-cfg.xml ファイルを使って ODR「アプリケーション・サーバー」に要求を転送するような、ごく単純な Web サーバーであっても構いません。
このトポロジーにとって 1 つ残念ともいえることは、各ユーザー要求が飛び越えなければならない新たなレイヤーが加わったことです。すなわち、各要求は、アプリケーション・サーバーに到達する前に、これからは 2 つのコンポーネント (プロキシーおよび ODR) を通過しなければならず、確実に待ち時間が増えることになります。ただし、高需要要件を伴う環境の多くでは、ODR がロード・バランシングを改善し、これに加えてその他の数多くの有用な機能を提供してくれるという点で、これは価値ある代償となります。次のセクションでは、これらの機能のいくつかを取り上げます。
サービス・ポリシーとルーティング・ルールの紹介
WebSphere XD の基本機能であり、多くの拡張機能の根底にあるのがサービス・ポリシーの概念です。サービス・ポリシーとは、パフォーマンス目標および優先順位を定義している、名前を付けられたエンティティーで、一連のトランザクション・クラスに関連付けられます。その目標は、ルーティング・ルールの作成を通じて、トランザクション・クラスを (一連の URL にマップされる) 作業クラスに紐付けることによって、アプリケーション URL に適用します。
これは、多少複雑に感じられるかもしれません。基本的に、これによって、どの URL がどのパフォーマンス目標を保持し、どのような状況下に置かれるべきかを確定するための、柔軟な配置の作成が可能になります。
WebSphere XD の ODR がどのように作動するかを理解する上で、これらの概念は鍵となります。一度管理者が、あるアプリケーションの URL を分類して、それをサービス・ポリシーに紐付けると、ODR は受信した要求の URL を調べ、それらのパフォーマンス特性と、対応するサービス・ポリシーに定義された目標とを比較します。ODR は、以下に示したようないくつかのメカニズムを通じて、これを達成することができます。
-
ODR は、様々なサービス・ポリシーの相対的な優先順位に関する情報を利用して、内部待ち行列において、要求をどれだけ長く待たせるかを決定することができます。リソースに制約があるときには、優先度の高い要求が、優先度の低い要求よりも先にサービスを受けることになります。
-
ODR は、応答時間の目標や、各クラスター・メンバーにおけるリソース (CPU およびメモリー) の使用状況に関する情報を、ダイナミック・ワークロード管理を実施するために利用できます。
-
ODR は、システムのその他の部分と連携して、ダイナミック・クラスターの中で動的配置を実現することができます。動的配置とは、クラスターの中にアプリケーション・サーバーのコピーがいくつあるのが適切なのかを、XD オートノミック・マネージャーが判断する機能です。例えば、あるアプリケーションはパフォーマンス目標を大きく上回って機能していますが、その一方で、やや高い、または同等の優先度が付けられた別のアプリケーションは、そのアプリケーションのクラスター・コピーを実行しているマシンに過重な負荷がかかっているために、低い性能しか発揮できていない場合があるとします。その場合、オートノミック・マネージャーは、各アプリケーションを実行しているアプリケーション・サーバーの数を調整することを決定し、前者の数を減らす一方で後者の数を増やして、負担がかかっていたアプリケーションの性能を改善することができます。
これらの機能のいくつか (作業の分類や待ち行列作成など) は完全に ODR の機能であり、多くの異なるタイプのワークロードともうまく機能します。その他の機能 (動的配置など) は、より専門化されており、XD システムのその他の部分と呼応して機能します。いずれの機能も、XD の基本的な設計上の根幹である ODR を利用する必要があり、ODR にはさらに多くの機能が備わっています。
キャッシングおよびその他の拡張機能
XD のキャッシングに目を向ける前に、まずは再度、典型的な WebSphere Application Server Network Deployment V6 アーキテクチャーにおける層ごとのキャッシュ機会を概観します。図 3 は、この典型的なトポロジーにおける各層、または「ゾーン」にキャッシュ領域がある主要コンポーネントを示しています。ゾーンについては、同じ属性を共有し、同様の機能を持つサーバーの論理的な集合であるものとみなします。(もちろん、Network Deployment アプリケーション・サーバー・キャッシュは、この図で示されているものよりもずっと洗練されています。例えば、クラスター内において、キャッシュは複数のアプリケーション・サーバーに配布することができます。)
図 3. キャッシング・オプション
Network Deployment 環境において使用可能なキャッシングは以下のような構成になります。
-
エッジ・デバイス (プロキシー・サーバーなど) および Web サーバー・プラグインにおけるサーブレット/JSP ページの ESI エッジ・キャッシング。
-
エッジおよび Web サーバーにおける、HTML、グラフィックス・ファイル、JavaScript などの、静的アプリケーション成果物のキャッシング (WebSphere Application Server のWeb コンテナーによって提供された静的ページのWebサーバー・プラグインでのキャッシングを含みます)。
-
WebSphere Application Serverの Web コンテナーにおける、サーブレット/JSPのフラグメント・キャッシング。
-
Web サービス SOAP 要求および応答のキャッシング。
-
オブジェクトをキャッシュして参照によって戻す、アプリケーション・サーバーにおけるAPI ベースのキャッシング、すなわちObject/DistributedMap キャッシュと、コマンド・パターンの実行結果をキャッシュして、そのコピーを戻すコマンド・キャッシュ。
WebSphere XD V6 の ODR は、WebSphere Application Server Network Deployment V6.02 のプロキシー・サーバーから派生したもので、同時にキャッシング機能も継承しています。それではまず初めに、この新たなプロキシー・サーバーが導入しているいくつかの新しい機能を見てみることにします。
Network Deployment V6.02 プロキシー・サーバー (ひいては ODR) には、RFC 2616 (13 章) の規則に準じて応答をキャッシュすることによって、静的および (ときには) 動的コンテンツをキャッシュする機能があり、それは HTTP 1.1 キャッシング・ヘッダーの存在 (および適用度) に依存します。WebSphere Application Server V6 は、デフォルトで、静的コンテンツのコンテンツ・キャッシングに際して、適切な HTTP 1.1 ヘッダーを自動設定します。静的コンテンツを含むそれぞれの応答に対し、WebSphere Application Server は適切な Cache-Control および Expires ヘッダーを設定します。そして現在の日時から WAR ファイルの静的コンテンツが最後に修正された日付を減算し、その結果に、最終変更係数 (デフォルトで 0.1 に設定されています) と呼ばれる係数を乗じた値をコンテンツの有効期限として算出します。その特定の URL が次に要求される際に、キャッシュされた応答値を戻しても良いのか、あるいは、もっと新しい応答を得るためにアプリケーション・サーバーに戻すべきなのかを判断するために、コンテンツ・キャッシュはこの計算値を用います。
アプリケーション・サーバー上で最近変更がなかったコンテンツは、時間をかけて変更されるという仮定ができるので、たいていの場合、これは適切な仮定になります。ただし、WAR ファイルが新たに再構築されてサーバーにデプロイされるという、ある特定のケースにおいては、これは問題となり得ます。WAR ファイル内にある全ての静的コンテンツの最終変更日には、WAR ファイルが再構築された日付が反映されるからです。キャッシュは、アプリケーションがデプロイもしくは再デプロイされた直後の方が、デプロイされてからしばらく経った場合よりも、頻繁にリフレッシュされます。この問題を修正するためには、ある特定の URL パターンを新たな (そして、おそらくより大きな) 最終変更係数と突き合わせることができる静的キャッシュ・ルールを、いつでも作成することができます。また、静的キャッシュ・ルールを使って、ある特定の URL パターンに一致する静的コンテンツのキャッシングを無効化することもできます。例えば、そのコンテンツが機密あるいは私用のものである場合です。
プロキシー・キャッシング機能は、WebSphere Application Server V6 のオブジェクト・キャッシュ・インフラストラクチャー上に構築されています。これによって提供されるものの 1 つが、ODR インスタンス間で情報を共有するための分散キャッシュ機能です。デフォルトでは、各プロキシー・サーバー (または ODR) には、独立したオブジェクト・キャッシュ・インスタンスが設定されています。これらのインスタンスを接続するためには、まず初めにオブジェクト・キャッシュ用の複製ドメインを作成し、各 ODR のオブジェクト・キャッシュ・インスタンスが新しいドメインを参照するように設定しなければなりません。これにより各ODRのキャッシュ・インスタンスは複製ドメイン内で複製されます。こうすることによって、キャッシュ内で情報が更新されるたびに、この変更が、複製ドメインのその他のメンバーにも確実に波及することになります。
WebSphere Application Server V6 プロキシー・キャッシュ・サーバーにもまた、Edge Side Includes (ESI) に対応したいくつかの機能があります。特筆すべきは、アセンブル済みページのページ・キャッシュを可能にする機能と、(様々な ESI インクルード・コンテンツを含む) ページを構成するコンポーネントがどのようにキャッシュできるかを判断するための ESI ルール処理機能です。このテーマについては、のちほど改めて取り上げます。ESI キャッシングを活用すると、対象となるネットワークのトポロジーの配置にも影響が及ぶことになります。
最後に、Network Deployment V6 は、アプリケーション・サーバー内に情報をキャッシュする機能が必要なアプリケーションを対象に、強力で有用な API ベースの Object/DistributedMap キャッシュを追加しています。この機能は、かつては WebSphere Application Server V5 の Enterprise 版においてのみ使用可能でしたが、V6 版ではすべてのV6エディションに含まれています。
これらのキャッシュ技術はすべて、WebSphere XD V6 にて使用可能で、さらには ObjectGrid や WebSphere パーティション・フレームワーク技術など、この他にも多くの追加オプションが備えられています。
WebSphere XD ObjectGrid
ObjectGrid は、拡張可能なトランザクション・オブジェクト・キャッシング・フレームワークであり、アプリケーションのスケーラビリティーと性能を向上する、素早く簡単なデータ共有を実現します。これは Java 2 Platform, Standard Edition (J2SE) 1.4.2 以降および J2EE 1.4 アプリケーションと共に使用し、アプリケーション API または XML ベースの機能のいずれかを用いることによって、キャッシュされたオブジェクトのグリッド内にあるオブジェクトを、検索、保管、削除、更新、無効化します。これは、Java Map インターフェース上に構築されているという点で、上述の Network Deployment V6 における DistributedMap キャッシュに似ていますが、従来の技術よりも強力で、DistributedMap インターフェースには装備されていない、構成可能なキャッシュ入れ替えストラテジーやプリロードなどの洗練された機能が追加されています。API ベースのキャッシュであるため、ObjectGrid を使用するには、キャッシュ API を使用することを具体的に指定して、プログラムへの変更を加える必要がありますが、プログラムが既に Java Map ベースの API を使用しているような場合には、変更は最低限で済みます。
WebSphere パーティション・フレームワーク
ObjectGrid が、トランザクション的な方法で、キーと値を対でキャッシュする機能を提供する一方で、WebSphere パーティション・フレームワーク (WPF) は、オブジェクトの特性に応じたコンテキスト・ベースのルーティングを提供します。WPF はアプリケーションおよびデータのパーティションを可能にすることによって、データベースを改良すると同時にメモリー内キャッシングやワークロード管理を改良し、共有されているデータ・ソースの競合を劇的に減らします。
WPF は、単一のヒープのサイズに制限されないように、複数の JVM にわたって論理的にキャッシュを分割できるようにします。キャッシュは高い可用性を持ち得るため、情報が失われた際にはすぐに回復されます。キャッシュはまた、固有の「グループ化」概念を持つことも可能で、それにより最適な形でキャッシュにエントリーを編成し、関連するもの同士を結び付けておくことができます。
ObjectGrid の整合性と保全性を維持するために、パーティション機能を使って、大きなObjectGrid を多数のパーティション化された ObjectGrid に展開することができます。パーティション機能のコンテキスト・ベース・ルーティングにより、ObjectGrid キーに従って要求が導かれます。例えば、単一の JVM ヒープに納まりきらない大量のオブジェクトを取り扱う際には、ObjectGrid が必要になります。そして異なるサーバーにデータをロードするパーティション機能を用いれば、パーティション機能のコンテキスト・ベース・ルーティングが、各要求に対応する正しい ObjectGrid を検出します。
ネットワーク設計者にとっての波及効果
ご覧のように、ODR の諸機能は、トポロジー設計者に無数のオプションを提供します。事実、あまりにも多くの新しい選択肢があるため、ルーティングの問題を細かく切り分けて、ODR がトポロジー設計にどのような影響を及ぼすかを考察するのが、おそらく最良ではないかと思われます。次に、先に紹介した、ゾーンという一般概念を取り上げ、トラステッド・ゾーンをさらにもっと細かく分割することを検討します。ある特定の WebSphere XD ネットワークのトラステッド・ゾーンは、4 つのタイプのサブゾーンを含むことができます。以下がその 4 つです。
-
レガシー WebSphere ND ゾーン: Network Deployment アプリケーションがデプロイされています。このゾーン内で稼動するアプリケーションについては、アプリケーション・サーバーまたはアプリケーション・デプロイメント処理に対する変更は一切必要ありません。
-
ダイナミック・オペレーション・ゾーン: WebSphere XD がアプリケーション・サーバーにデプロイされています。XDのインストールにより、WebSphere XD の新機能のほとんど (ヘルス・モニタリングおよび動的配置など) がその機能を発揮できるようになります。
-
Non-WebSphere ゾーン: このゾーンには、おそらく最も刺激的と思われる新機能が採用されています。ODR は、図2に示されているようなHTTP サーバーのみならず、他の J2EE サーバーや .NET サーバーさえも含む他のタイプのアプリケーション・サーバーに対しても、同様にインテリジェントなルーティングを行なうことができます。
-
要求指示ゾーン: このゾーンは、要求が最終目的地に誘導される前に、前処理される際に必要となる ODR および任意のセキュリティー・プロキシーを含みます。
図 4. ゾーン・タイプ
トラステッド・ゾーンをこれらの異なるサブゾーンに分割することによる波及効果、利点、および検討事項を考察してみます。
要求ルーティング・ゾーン
少しの間だけ、トポロジーに ODR を追加することの価値を認めていると仮定してみます。このゾーンについて最初に下す決定は、ODR がいくつ必要かという判断になります。いかなる実働システムにおいても、Single point of failureが存在しないように、最低でも 2 つの ODR を設定することを推奨します。それ以上については、ネットワークが経験する負荷量の予想によって、必要な ODR の数は決まります。経験上、現在アプリケーション・サーバーにルーティングされている HTTP サーバーの数から始めるのが適当です。現在、ODR の性能は、WebSphere Application Server V6の Web サーバー・プラグインのルーティング性能の数パーセント内の差にあるので、ここから始めるのは良い方法です。ただし、そうした場合には、最適な数を判断するために、ODR の数を変えながら性能テストの実行を検討する必要が生じてきます。
第 2 の重要な決定は、ODR においてどのようなキャッシュ・オプションを使用できるようにするかを決めることです。例えば、そもそも ODR にキャッシュするつもりがあるのかを決定しなければなりません。ほとんどの顧客の場合、特に、静的コンテンツがアプリケーション・サーバー上の、WAR ファイルの中から提供される場合には、静的コンテンツのキャッシングができるようにするべきです。このとき、前述にて検討した ODR のキャッシング機能は、上流にキャッシュせずにファイル・サービス・サーブレットを単独で使用した場合よりも、高い性能を提供します。
次に、キャッシュを複製するか否かを決定する必要があります。もしコンテンツが、更新される頻度が低く、サイズが非常に大きい少数のページによって構成されているならば、非常に大きなページをキャッシュ間で転送するのに時間を浪費することになるため、キャッシュを複製する意義はないかもしれません。ただし、コンテンツが、非常に頻繁にアクセスされる、サイズが非常に小さい多数のページで構成される場合には、キャッシュの複製は、素早いキャッシュへの取り込みを実現して、キャッシュから静的コンテンツを提供することで全体的な応答時間を改善するより良い方法となります。
レガシー WebSphere ゾーン
ネットワーク設計にこのゾーンを導入する際の重要な検討事項の 1 つは、WebSphere XD の様々な機能の利点をすべて一度に導入することなく検討できる余地があることです。既存の Network Deployment ネットワークの前に ODR を配置することにより、望むのであれば、アプリケーション・サーバーを段階的な方法で WebSphere XD に移行することができるようになります。最初に、アプリケーション・サーバーを最新版の Network Deployment に移行したあと、次に、Network Deployment の静的クラスタリング構成を保持しながら、アプリケーション・サーバーを WebSphere XD に移行することができ、そして最後に、このゾーンからサーバーを移行すると完全な XD の機能へと遷移できます。ただし、静的クラスター構成のバックレベル・サーバー上であっても、既存の Network Deployment クラスターの前面に ODR を置くことによって、Non-WebSphere Application Server URI と全く同様に、サービス・ポリシーおよびルーティング・ルールを通じて要求は分類され、待ち行列を使用して処理されます。
ダイナミック・オペレーション・ゾーン
このゾーンにあるサーバーは、WebSphere XD が提供するすべての利点を活用することができます。ここでの重要な検討事項は、すべてのアプリケーション・サーバーが WebSphere XDの前提であるNetwork Deployment (V6.02) レベルにあり、かつ WebSphere XD もインストールしていなければならないことです。このことはライセンスにも影響をもたらします。WebSphere XD はアプリケーション・サーバーごとにライセンス・コストがかかるため、ここにアプリケーションを移行する前に、このゾーンにおける XD のライセンス数が適切であることを確認しなければなりません。このゾーンでは WebSphere XD V6 アプリケーション・サーバーのみが稼動できるという前提により、このゾーンにアプリケーションを移行する前に、これらを Network Deployment V6.02 に移行しておくのが最良の処置となります。ただし、これらの手順を踏むことによって、十分なメリットがもたらされます。このゾーンにノード・グループ (動的配置が作動する共有されたノードのプール) を定義できるだけではなく、このゾーン内でヘルス・ポリシーおよびエディション管理を得ることもできます。
Non-WebSphere ゾーン
おそらくは、ODR が提供する (Network Deploymentと比較した場合) 最も抜本的なWebSphere XD機能は、WebSphere Application Serverではない宛先にも経路指定ができることです。これらの他の宛先は、HTTP サーバー (図 2 で示したように) のような簡単なものでも構いませんが、他の J2EE アプリケーション・サーバー (Apache Geronimo サーバーなど) や、たとえ Microsoft® .NET® が稼動しているアプリケーション・サーバーであっても、同様に簡単に対応できます。これらの宛先は、WebSphere が管理していない HTTP 宛先のセットですが、ODR による経路指定が可能で、汎用サーバー・クラスターを定義することによって定義されます。
事実、ODR は、WebSphere をホストとするアプリケーションと同じように、非 WebSphere 宛先であっても、サービス・ポリシーを使い、要求の分類および待ち行列機能を適用可能にします。しかし、これがすべてではありません。XD Remote Agent として知られるソフトウェアを、それぞれのNon-WebSphere マシンにインストールすれば、そのサーバーが使用可能な CPU とメモリーのリソースに基づいて、加重ルーティングを行うことも可能です。このレベルのフィードバックを追加することによって、ODR は、市場で入手可能な他のルーターが、トラフィックをルーティングする際に実現できる機能を超える能力を最も扱いやすい場所で発揮することができます。
最後の検討事項は、この新しいトポロジーのどこに、HTTP サーバーを配置するかということです。ESI を使っていて、ページ・アセンブリーが Akamai サーバーのようなエッジ・サーバーで行なわれているならば、図 2 のように、HTTP サーバーをNon-WebSphere ゾーンに置くことができます。しかし、ESI を使う必要があって、ページ・アセンブリーにエッジ・サーバーを使っていない場合は、ODR の前に HTTP サーバーを置き、WebSphere のWeb サーバー・プラグインのページ・アセンブリー機能を使用する必要がある場合があります。この場合、トポロジーは図 1 のような概観になるかもしれませんが、アプリケーション・サーバーに直接ルーティングする代わりに、プラグインは ODR のみに経路指定をして、そしてそのあと ODR がアプリケーション・サーバーに経路指定します。これは図 5 に示されています。
図 5. プラグイン・ルーティングを伴う XD トポロジー
トポロジーがエッジにおけるページ・アセンブリーを考慮に入れない場合、ページ・アセンブリーはアプリケーション・サーバーによって行なわれ (<jesi>タグまたはcachespec.xml ESI 使用可能化オプションを使っている場合)、ESI タグを使う意味がなくなるかもしれません。しかし、図 5 に示されたトポロジー・バリエーションを選択した理由はこれだけではありません。Web サーバーにサード・パーティー・セキュリティー・プラグインを使用して、WebSphere プラグインが要求を処理する前にそのプラグインを実行させるといった他の検討事項の場合でも、結果的にこのトポロジーを選択することになるかもしれません。この場合、ODR にWebサーバーからの静的コンテンツをキャッシュする機能は失われますが、依然として、この配置において、アプリケーション・サーバーが提供する静的コンテンツをキャッシュすることはできます。
まとめ
この記事では、WebSphere XD の新機能がネットワーク・トポロジーに及ぼし得る波及効果について、その探索の旅へと旅立ちました。この旅を終わらせるには、(ObjectGrid および WebSphere パーティション・フレームワークのためのアプリケーション設計など) さらに多くの課題を検討する必要があります。しかし、それは別の記事に譲るしかありません。
参考文献
著者について
 | | |
ビル・ハインズは、IBM Software Services for WebSphere の上級認定コンサルティング IT スペシャリストです。彼の専門には、エンタープライズ J2EE WebSphere アプリケーションのインストレーション、コンフィグレーション、チューニング、dynacache、セキュリティー、トラブルシューティング、設計・アーキテクチャーが含まれます。 |
記事の評価
| 
