Content Based Routing

重要: Content Based Routing (CBR) コンポーネントは、以下の例外はありますが、すべてのサポートされるプラットフォームで使用可能です。

Application Server の Load Balancer コンポーネントは、Application Server の Caching Proxy コンポーネントと共に機能して、さまざまなコンテンツのホストとして機能する複数のバックエンド・サーバーに要求を分散できるようにします。 (これらの Edge Components の概要については、WebSphere Application Server Edge Components の紹介を参照してください。)

Load Balancer の Content Based Routing (CBR) コンポーネントを Caching Proxy と共にインストールすると、URL または管理者が決定したその他の特性に基づいて HTTP 要求を分散させることができ、同一のコンテンツをすべてのバックエンド・サーバーに保管する必要がなくなります。

CBR は、Web サーバーで複数の異なる機能の実行または複数の異なるタイプのサービスの提供が必要な場合にとくに適しています。 例えば、オンライン小売業の Web サイトでは、カタログの表示と受注の両方を行う必要があります。カタログの大部分は静的ですが、受注では Common Gateway Interface (CGI) スクリプトなどの対話式アプリケーションを実行して品目番号や顧客情報を受け入れる必要があります。 別々の 2 セットのマシンに異なる機能を実行させ、CBR を使用して異なるタイプのトラフィックを別々のマシンに経路指定する方法により効率が改善される場合がよくあります。 また、購買要求をより強力な Web サーバーに経路指定して、Web サイトの偶発的な訪問者よりも、購買意欲のある顧客に対するサービスを優先するように、CBR を使用することもできます。

CBR は、ユーザーが作成したルールを基にして要求を経路指定します。 最も一般的なタイプは コンテンツ・ルール で、このルールは URL のパス名に基づいて要求を送ります。 例えば、ABC Corporation という会社の場合、URL http://www.abc.com/catalog_index.html への要求をあるサーバーのクラスターに送り、http://www.abc.com/orders.html への要求を別のクラスターに送るように、ルールを作成することができます。 また、要求を送信したクライアントの IP アドレスまたはその他の特性に基づいて要求を経路指定するルールもあります。詳しい説明については、「WebSphere Application Server Load Balancer 管理ガイド」の CBR の構成に関する章および Load Balancer と CBR の拡張機能に関する章を参照してください。 ルールの構文定義については、「WebSphere Application Server Load Balancer 管理ガイド」の CBR のルール・タイプに関する付録を参照してください。

図 12 に示すものは単純な構成の 1 つです。この構成では、Load Balancer の CBR コンポーネントと Caching Proxy が共に 4 の番号が付いたマシンにインストールされ、異なるコンテンツを保管する 3 つのコンテンツ・ホスト (678) に要求を送付します。 1 の番号の付いたマシンの 1 つを使用しているエンド・ユーザーがファイル X を要求すると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通ってその企業の内部ネットワークに入ります。 プロキシー は要求をインターセプトして、同じマシン上の CBR コンポーネントに渡します。CBR は要求の URL を解析して、コンテンツ・ホスト 6 にファイル X が保管されていることを判別します。プロキシー はファイル X に対する新規の要求を生成して、キャッシング機能が使用可能になっている場合は、ホスト 6 がファイルを返したときに、そのファイルがキャッシュに適格であるかどうかを判断します。ファイルがキャッシュ可能である場合、プロキシー はそのファイルのコピーをキャッシュ (5) に格納してから、エンド・ユーザーに引き渡します。 他のファイルの経路指定もこれと同様に行われます。ファイル Y に関する要求はコンテンツ・ホスト 7 に送られ、ファイル Z に関する要求はコンテンツ・ホスト 8 に送られます。

図 12. CBR による HTTP 要求の経路指定
この図は CBR による HTTP 要求の経路指定を描いたものです

図 13 に、オンライン小売業に適していると考えられるより複雑な構成を示します。Load Balancer の CBR コンポーネントと プロキシー は、共に 4 の番号が付いたマシンにインストールされ、要求を 2 つの Load Balancer マシンに送付します。 6 の番号が付いた Load Balancer マシンは、主として小売業者のカタログの静的コンテンツを保管するコンテンツ・ホスト (8) のクラスターのロード・バランスを取り、7 の番号が付いた Load Balancer は、注文を処理する Web サーバー (9) のクラスターのロード・バランスを取ります。

1 の番号の付いたマシンの 1 つを使用しているエンド・ユーザーが小売業者のカタログの URL にアクセスすると、 その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通ってその企業の内部ネットワークに入ります。 プロキシー は要求をインターセプトして、同じマシン上の CBR コンポーネントに渡します。CBR コンポーネントは URL を解析して、6 の番号が付いた Load Balancer マシンがその URL を処理すると判断します。 プロキシー は新規のアクセス要求を作成して Load Balancer に送信します。Load Balancer は (ユーザーが定義した基準に基づいて) 8 の番号が付いたコンテンツ・ホストのうち、現在どのホストがその要求へのサービス提供に最も適しているかを判断します。 このコンテンツ・ホストは Load Balancer をバイパスして、カタログ・コンテンツを プロキシー に直接引き渡します。 前の例の場合と同様、プロキシー は、コンテンツがキャッシュ可能であるかどうかを判断し、必要に応じてそのコンテンツをキャッシュ (5) に格納します。

通常はカタログのハイパーリンクを経由して小売業者の注文 URL にアクセスすることによって、エンド・ユーザーは発注します。 この要求がたどる経路は、マシン 4 の CBR コンポーネントによって 7 の番号が付いた Load Balancer マシンに送られる点を除けば、カタログ・アクセスの要求の場合と同じです。Load Balancer は 9 の番号が付いた Web サーバーのうち最も適したものに要求を転送し、その Web サーバーは プロキシー に直接応答します。 通常、注文情報は動的に生成されるため、プロキシー が注文情報をキャッシュに入れることはほとんどありません。

図 13. CBR により経路指定された HTTP 要求のロード・バランシング
この図は CBR により経路指定された HTTP 要求のロード・バランシングを描いたものです

Load Balancer の CBR 機能は、cookie アフィニティー をサポートしています。 これは、エンド・ユーザーの最初の要求にサービスを提供するサーバーの識別が、サーバーの応答に含まれる特殊なデータ・パケット (cookie) に記録されるということです。 定義した期間内にエンド・ユーザーが同じ URL に再びアクセスすると、要求に cookie が含まれている場合 CBR は標準ルールを適用する代わりに要求を元のサーバーに経路指定します。 一般に、サーバーが再び取得する必要のないエンド・ユーザー情報 (クレジット・カード番号など) がサーバーに保管されている場合、cookie により応答時間が改善されます。