次の項では、WebLogic Serverクラスタの各種のアーキテクチャについて説明します。
この項では、このドキュメントで使用する用語を定義します。
Webアプリケーションは、複数の「層」に分けられます。「層」は、アプリケーションで提供される論理的なサービスに対応します。すべてのWebアプリケーションが似通っているわけではないので、アプリケーションによっては、次で説明する層のすべてを利用しない場合があります。また、層はアプリケーションのサービスの論理的な区分を示すものであり、必ずしもハードウェアまたはソフトウェアのコンポーネント間の物理的な区分を示すものではありません。1つのWebLogic Serverインスタンスを実行している1台のマシンが、次で説明するすべての層を提供する場合もあります。
Web層
Web層では、Webアプリケーションのクライアントに対して静的なコンテンツ(単純なHTMLページなど)が提供されます。Web層は、通常、外部クライアントがWebアプリケーションにアクセスする最初のポイントになります。単純なWebアプリケーションでは、Apache、Netscape Enterprise ServerまたはMicrosoft Internet Information Serverを実行している1つまたは複数のマシンで構成されるWeb層が存在する場合もあります。
プレゼンテーション層
プレゼンテーション層では、Webアプリケーションのクライアントに対して動的なコンテンツ(サーブレットやJavaServer Pages (JSP)など)が提供されます。Webアプリケーションのプレゼンテーション層は、サーブレットやJSPのホストになるWebLogic Serverインスタンスのクラスタで構成されます。クラスタでアプリケーションの静的なHTMLページも提供される場合は、クラスタにはWeb層とプレゼンテーション層の両方が含まれます。
オブジェクト層
オブジェクト層では、Webアプリケーションのクライアントに対してJavaオブジェクト(Enterprise JavaBeansやRMIクラスなど)や、それらに関連付けられたビジネス・ロジックが提供されます。EJBのホストになるWebLogic Serverクラスタは、オブジェクト層を提供します。
非武装地帯(DMZ)とは、外部の、信頼性のないソースから使用できるハードウェアおよびサービスの論理的な集合のことです。ほとんどのWebアプリケーションでは、WebサーバーのバンクはDMZにあります。DMZでは、ブラウザ・ベースのクライアントからの静的なHTMLコンテンツへのアクセスが許可されています。
DMZには、ハードウェアおよびソフトウェアに対する外部からの攻撃に備えてセキュリティが用意されている場合もあります。ただし、DMZは信頼性のないソースから使用できるので、その安全性は内部システムよりは劣ります。たとえば、内部システムは、外部からのアクセスをすべて拒否するファイアウォールによって保護できます。DMZは、アクセス先の個々のマシン、アプリケーション、またはポート番号を隠すファイアウォールによって保護できますが、信頼性のないクライアントからそれらのサービスにアクセスすることは可能です。
ロード・バランサという用語は、このドキュメントでは、クライアントの接続リクエストを1つまたは複数の別々のIPアドレスに分散させる技術を指します。たとえば、単純なWebアプリケーションでは、DNSラウンドロビン・アルゴリズムがロード・バランサとして使用される場合があります。大規模なアプリケーションでは、通常、Alteon WebSystemsなどから発売されているハードウェア・ベースのロード・バランシング・ソリューションが使用されます。このようなソリューションには、ファイアウォールのようなセキュリティ機能も用意されています。
ロード・バランサには、クライアント接続をクラスタ内の特定のサーバーに関連付ける機能があります。この機能は、クライアント・セッション情報のインメモリー・レプリケーションを使用する場合に必要です。一部のロード・バランシング製品では、インメモリー・レプリケーションで使用されるプライマリ・サーバーおよびセカンダリ・サーバーを追跡するWebLogic ServerCookieを上書きしないように、Cookieの永続性メカニズムを構成する必要があります。詳細は、「外部ロード・バランサによるHTTPセッションのロード・バランシング」を参照してください。
プロキシ・プラグインとは、WebLogic Serverクラスタによって提供される、クラスタ化されたサーブレットにアクセスするApache、Netscape Enterprise Server、またはMicrosoft Internet Information ServerなどのHTTPサーバーに対するWebLogic Serverの拡張機能のことです。プロキシ・プラグインには、WebLogic Serverクラスタ内のサーブレットおよびJSPへのアクセスに対するロード・バランシング・ロジックが含まれます。また、クライアントのセッション状態のホストになっている主要なWebLogic Serverに障害が発生した場合の、セッション状態のレプリカへのアクセスに対するロジックも含まれます。
推奨基本アーキテクチャは、Webアプリケーションのすべての層が同じWebLogic Serverクラスタにデプロイされる組合せ層アーキテクチャです。このアーキテクチャを次の図9-1に示します。
推奨基本アーキテクチャの利点は、次のとおりです。
管理の容易さ
1つのクラスタが、静的HTTPページ、サーブレットおよびEJBのホストになるため、WebLogic Server管理コンソールを使用して、Webアプリケーション全体を構成したり、オブジェクトをデプロイまたはアンデプロイしたりできます。クラスタ化されたサーブレットの利益を得るために、Webサーバーのバンクを別々に保持する(およびWebLogic Serverプロキシ・プラグインを構成する)必要はありません。
柔軟性の高いロード・バランシング
WebLogic Serverクラスタの前で直接ロード・バランシング・ハードウェアを使用することで、HTMLコンテンツとサーブレット・コンテンツ両方へのアクセスに対して高度なロード・バランシング・ポリシーを使用できます。たとえば、現在のサーバーの負荷を検出し、クライアントのリクエストを適切に送信するよう、ロード・バランサを構成できます。
堅牢なセキュリティ
ロード・バランシング・ハードウェアの前にファイアウォールを配置することで、Webアプリケーションに対して、最小限のファイアウォール・ポリシーを使用する非武装地帯(DMZ)を設定できます。
最適なパフォーマンス
組合せ層アーキテクチャでは、プレゼンテーション層のほとんどまたはすべてのサーブレットあるいはJSPが通常オブジェクト層のオブジェクト(EJBまたはJDBCオブジェクトなど)にアクセスするアプリケーションに対して、最適なパフォーマンスを提供します。
注意: インメモリー・セッション・レプリケーションでサード・パーティ製のロード・バランサを使用する場合は、プライマリ・セッション状態のホストとなるWebLogic Serverインスタンス(接続先サーバー)へのクライアント接続を、ロード・バランサが保持するようにしなければなりません。ロード・バランサの詳細は、「外部ロード・バランサによるHTTPセッションのロード・バランシング」を参照してください。 |
推奨基本アーキテクチャなどの組合せ層アーキテクチャは多くのWebアプリケーションのニーズに適していますが、クラスタのロード・バランシングおよびフェイルオーバー機能を活用できる度合いは多少限定されます。ロード・バランシングおよびフェイルオーバーは、Webアプリケーションの各層間のインタフェースでのみ導入できます。そのため、すべての層を単一のクラスタにデプロイするときは、クライアントとクラスタの間でのロード・バランシングしか行うことができません。
ロード・バランシングとフェイルオーバーの大部分は、クライアントとクラスタ自身の間で発生するので、組合せ層アーキテクチャでも、ほとんどのWebアプリケーションのニーズを満たすことができます。
しかし、組合せ層クラスタには、クラスタ化されたEJBへのメソッド呼出しに対してロード・バランシングを実行する機会がありません。クラスタ化されたオブジェクトは、クラスタ内のすべてのWebLogic Serverインスタンスにデプロイされるので、各オブジェクト・インスタンスは各サーバーでローカルに使用できます。WebLogic Serverでは、常にローカルのオブジェクト・インスタンスを選択することにより、クラスタ化されたEJBに対するメソッド呼出しが最適化されます。リクエストをリモート・オブジェクトに分散させないので、ネットワークのオーバーヘッドが増加しません。
この連結方式は、ほとんどの場合で、異なるサーバーへの各メソッド・リクエストに対してロード・バランシングを行うよりも効率的です。ただし、各サーバーの負荷が不均衡な場合は、ローカルでメソッドを処理するよりも、リモート・オブジェクトにメソッド呼出しを送信する方が結果的に効率的になる場合もあります。
クラスタ化されたEJBへのメソッド呼出しに対してロード・バランシングを行うには、次の項で説明するように、Webアプリケーションのプレゼンテーション層とオブジェクト層を物理的に異なるクラスタ上に分割する必要があります。
組合せ層アーキテクチャと複数層アーキテクチャのどちらかに決定する際には、プレゼンテーション層によるオブジェクト層の呼出しの頻度を考慮してください。プレゼンテーション・オブジェクトが通常オブジェクト層を呼び出す場合、組合せ層アーキテクチャは、複数層アーキテクチャよりも高いパフォーマンスを示す可能性があります。
この項では、推奨複数層アーキテクチャについて説明します。このアーキテクチャでは、アプリケーションの各層が複数の異なったクラスタにデプロイされます。
推奨複数層アーキテクチャでは、2つの異なるWebLogic Serverクラスタを使用します。1つは静的なHTTPコンテンツを提供するクラスタであり、もう1つはクラスタ化されたEJBを提供するクラスタです。複数層クラスタは、次のようなWebアプリケーションで推奨されます。
クラスタ化されたEJBへのメソッド呼出しに対するロード・バランシングが必要です。
HTTPコンテンツを提供するサーバーとクラスタ化されたオブジェクトを提供するサーバーの間により柔軟性の高いロード・バランシングが必要です。
より高い可用性(シングル・ポイント障害がより少ないこと)が必要です。
注意: 複数層アーキテクチャを検討する場合は、プレゼンテーション層からオブジェクト層への呼出しの頻度を考慮してください。プレゼンテーション・オブジェクトが通常オブジェクト層を呼び出す場合、組合せ層アーキテクチャは、複数層アーキテクチャよりも高いパフォーマンスを示す可能性があります。 |
図9-2は、推奨複数層アーキテクチャを示します。
推奨複数層アーキテクチャでは、アプリケーションの各層が2つの異なった物理レイヤー(ハードウェアとソフトウェア)上に配置されます。
Web/プレゼンテーション・レイヤーは、静的なHTTPページ、サーブレット、およびJSPの専用ホストになっているWebLogic Serverインスタンスのクラスタで構成されます。このサーブレット・クラスタは、クラスタ化されたオブジェクトのホストにはなりません。そのかわりに、プレゼンテーション層クラスタ内のサーブレットは、オブジェクト・レイヤーにある異なるWebLogic Serverクラスタ内のクラスタ化されたオブジェクトのクライアントとして機能します。
オブジェクト・レイヤーは、Webアプリケーションで必要なクラスタ化されたオブジェクト(EJBオブジェクトおよびRMIオブジェクト)専用のホストになるWebLogic Serverインスタンスのクラスタで構成されます。専用クラスタにオブジェクト層のホストを配置することで、クラスタ化されたオブジェクトへのアクセスに対するデフォルトの連結の最適化(「連結されたオブジェクトの最適化」を参照)が失われます。ただし、次の項で説明するように、特定のクラスタ化されたオブジェクトへの各メソッド呼出しに対するロード・バランシングは可能になります。
複数層アーキテクチャには、これらの利点があります。
EJBメソッドのロード・バランシング
サーブレットとEJBのホストを異なるクラスタに配置することで、サーブレットのEJBへのメソッド呼出しで、複数のサーバーにわたるロード・バランシングが可能になります。このプロセスについては、「複数層アーキテクチャでのクラスタ化オブジェクトのロード・バランシング」で詳しく説明しています。
改良されたサーバー・ロード・バランシング
プレゼンテーション層とオブジェクト層を別々のクラスタに分割することで、Webアプリケーションの負荷分散に関するオプションが増加します。たとえば、アプリケーションがEJBコンテンツよりも頻繁にHTTPおよびサーブレット・コンテンツにアクセスする場合は、プレゼンテーション層のクラスタで数多くのWebLogic Serverインスタンスを使用し、EJBのホストになるサーバーを少数にしてアクセスを集中させることができます。
より高い可用性
追加のWebLogic Serverインスタンスを利用することで、複数層アーキテクチャの障害ポイントはベース・クラスタ・アーキテクチャよりも少なくなります。たとえば、EJBのホストになっているWebLogic Serverに障害が発生しても、WebアプリケーションのHTTPやサーブレットのホストとなる機能には影響しません。
改良されたセキュリティ・オプション
プレゼンテーション層とオブジェクト層を別々のクラスタに分割することで、DMZにサーブレット/JSPクラスタだけを配置するファイアウォール・ポリシーを使用できます。信頼性のないクライアントからの直接アクセスを拒否することで、クラスタ化されたオブジェクトのホストになっているサーバーの保護を強化できます。詳細は、「クラスタ・アーキテクチャのセキュリティ・オプション」を参照してください。
「連結されたオブジェクトの最適化」で説明されているように、クラスタ化されたオブジェクトに対するWebLogic Serverの連結の最適化は、クラスタ化されたオブジェクト(EJBまたはRMIクラス)のホストが、オブジェクトを呼び出すレプリカ対応スタブと同じサーバー・インスタンスに配置されることに基づいています。
オブジェクト層を分離することの最終的な効果としては、クライアント(HTTPクライアント、Javaクライアントまたはサーブレット)が、クラスタ化されたオブジェクトのホストになるサーバーと同じサーバーにあるレプリカ対応スタブを取得できなくなります。このため、WebLogic Serverでは、連結の最適化を使用できず(「連結されたオブジェクトの最適化」を参照)、クラスタ化されたオブジェクトに対するサーブレット呼出しはレプリカ対応スタブにあるロジックに従って自動的にロード・バランシングされます。図9-3は、複数層アーキテクチャ内のクラスタ化されたEJBインスタンスにアクセスするクライアントを示します。
クライアント接続の経路をトレースすると、異なるハードウェアとソフトウェアにオブジェクト層を分離させる意味が理解できます。
HTTPクライアントは、Web/サーブレット・クラスタ内に複数あるWebLogic Serverインスタンスのいずれか1つに接続し、ロード・バランサを経由して最初のサーバーに到達します。
クライアントはWebLogic Serverクラスタにホストが配置されたサーブレットにアクセスします。
サーブレットはWebアプリケーションで必要になるクラスタ化されたオブジェクトのクライアントとして機能します。前述の例では、サーブレットはステートレス・セッションEJBにアクセスします。
サーブレットは、クラスタ化されたオブジェクトのホストになる、WebLogic ServerクラスタにあるEJBをルックアップします。サーブレットは、Beanのレプリカ対応スタブを取得します。スタブには、Beanのホストになるすべてのサーバーのアドレスと、Beanのレプリカへのアクセスに対するロード・バランシング・ロジックが示されています。
注意: EJBデプロイメント記述子の要素を使用して、EJBレプリカ対応スタブおよびEJBホーム・ロード・アルゴリズムを指定します。詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスに関する項を参照してください。 |
次にEJBにアクセスしたとき(たとえば、別のクライアントに対するレスポンスとして)、サーブレットは、Beanのスタブに示されているロード・バランシング・ロジックを使用してレプリカを見つけます。上記の例では、複数のメソッド呼出しがロード・バランシングのラウンドロビン・アルゴリズムを使用して送信されます。
この例では、同じWebLogic ServerクラスタがサーブレットとEJBの両方のホストになっている場合(「推奨基本アーキテクチャ」を参照)、WebLogic ServerではEJBのリクエストに対するロード・バランシングは実行されません。その代わり、サーブレットは常に、ローカル・サーバーがホストになっているEJBレプリカでメソッドを呼び出します。ローカルのEJBインスタンスを使用した方が、別のサーバーにあるEJBに対してリモート・メソッド呼出しを行うよりも効率的です。しかし、複数層アーキテクチャでは、EJBメソッド呼出しのロード・バランシングを必要とするアプリケーションに対してリモートEJBアクセスが可能です。
複数層アーキテクチャでは、次の項で説明するように、構成の調整が必要になる場合があります。
複数層アーキテクチャではクラスタ化されたオブジェクトへの呼出しに対するロード・バランシングが提供されるため、システムでは通常、組合せ層より多いIPソケットが使用されます。特に、ソケットの最大使用時には、サーブレットおよびJSPをホストするクラスタ内の各WebLogic Serverインスタンスは、次を最大限に使用する可能性があります。
プライマリ・サーバーとセカンダリ・サーバーの間でHTTPセッション状態をレプリケートするためのソケット
EJBクラスタ内の各WebLogic Serverに1つずつある、リモート・オブジェクトにアクセスするためのソケット
たとえば、図9-2では、サーブレット/JSPクラスタ内の各サーバーは最大で5つのソケットをオープンする可能性があります。この最大数は、プライマリおよびセカンダリの各セッション状態が均等にサーブレット・クラスタ全体に分散していて、サーブレット・クラスタ内の各サーバーがオブジェクト・クラスタ内の各サーバーのリモート・オブジェクトに同時にアクセスするという、最悪のケースを表しています。ほとんどの場合、実際に使用されるソケット数はこの最大数より小さくなります。
複数層アーキテクチャでpure-Javaソケット実装を使用する場合は、ソケットの最大使用に対応できるだけのソケット・リーダー・スレッドを構成していることを確認してください。詳細は、「Javaソケット実装用にリーダー・スレッドを構成する」を参照してください。
複数層アーキテクチャではハードウェア・ロード・バランサを使用するため、インメモリー・セッション状態レプリケーションを使用する場合は、クライアントの接続先サーバーに対するセッション維持型の接続を保持するように、ロード・バランサを構成しなければなりません。手順については、「EJBとRMIのロード・バランシング方式を構成する」を参照してください。
この項では、複数層クラスタ・アーキテクチャでの制限の概要を示します。
推奨複数層アーキテクチャでは、連結方式を使用してオブジェクト呼出しを最適化できないので、Webアプリケーションでは、クラスタ化されたオブジェクトに対するすべてのメソッド呼出しでネットワークのオーバーヘッドが発生します。ただし、このオーバーヘッドは、Webアプリケーションで「複数層アーキテクチャの利点」で説明した利点のいずれかが必要な場合には許容できる場合もあります。
たとえば、WebクライアントがサーブレットおよびJSPを頻繁に使用するものの、クラスタ化されたオブジェクトへのアクセスは比較的少ない場合、複数層アーキテクチャではサーブレットおよびオブジェクトの負荷を適切に集中させることができます。各サーバーの処理能力を最大限に利用しながら、10個のWebLogic Serverインスタンスを含むサーブレット・クラスタと3個のWebLogic Serverインスタンスを含むオブジェクト・クラスタを構成できます。
複数層アーキテクチャのサーブレット・クラスタとオブジェクト・クラスタの間にファイアウォールを配置する場合は、オブジェクト・クラスタ内のすべてのサーバーをIPアドレスではなく、外部に公開されているDNS名にバインドさせる必要があります。サーバーをIPアドレスにバインドさせると、アドレス変換に関する問題が発生し、サーブレット・クラスタが各サーバー・インスタンスにアクセスできなくなる場合があります。
WebLogic Serverインスタンスの内部DNS名と外部DNS名が同じでない場合、サーバー・インスタンスのExternalDNSName
属性を使用して、サーバーの外部DNS名を定義します。ファイアウォールの外で、ExternalDNSName
はサーバーの外部IPアドレスに変換されます。
クライアントがt3およびデフォルト・チャネルを使用してWebLogic Serverにアクセスする場合を除き、ファイアウォールがネットワーク・アドレス変換を実行する構成では、ExternalDNSName
を使用する必要があります。たとえば、ファイアウォールがネットワーク・アドレス変換を実行し、クライアントがプロキシ・プラグインを介してHTTPでWebLogic Serverにアクセスする構成では、ExternalDNSName
が必須です。
既存のWebサーバーと連携して動作するよう、WebLogic Serverクラスタを構成することができます。そのようなアーキテクチャではWebサーバーのバンクはWebアプリケーションの静的なHTTPコンテンツを提供し、WebLogicプロキシ・プラグインまたはHttpClusterServlet
を使用してクラスタにサーブレット・リクエストおよびJSPリクエストを送信します。
次の項では、2種類の代替プロキシ・アーキテクチャについて説明します。
図9-4に示す2層プロキシ・アーキテクチャは、推奨基本アーキテクチャとほぼ同じです。異なる点は、静的なHTTPサーバーのホストがWebサーバーのバンクに配置されることのみです。
2層プロキシ・アーキテクチャには、ハードウェアとソフトウェアの物理レイヤーが2つあります。
プロキシ・アーキテクチャでは、アプリケーションのWeb層を提供するタスクに特化したハードウェアとソフトウェアのレイヤーが利用されます。この物理的なWebレイヤーは、次のアプリケーションの組合せのいずれか1つのホストである、1つまたは複数の同じように構成されたマシンで構成されます。
WebLogic ServerとHttpClusterServlet
ApacheとWebLogic Server Apache Server (プロキシ)プラグイン
Netscape Enterprise ServerとWebLogic Server NSAPI (プロキシ)プラグイン
Microsoft Internet Information ServerとWebLogic Server Microsoft-IIS (プロキシ)プラグイン
選択するWebサーバー・ソフトウェアに関係なく、Webサーバーの物理層では静的なWebページのみが提供されるようにする必要があります。動的なコンテンツ(サーブレットやJSP)は、プロキシ・プラグインまたはHttpClusterServlet
を経由して、プレゼンテーション層のサーブレットやJSPのホストになるWebLogic Serverクラスタにプロキシされます。
推奨2層プロキシ・アーキテクチャでは、プレゼンテーション層およびオブジェクト層のホストはWebLogic Serverインスタンスのクラスタに配置されます。このクラスタは、単一のマシンまたは複数の異なるマシンにデプロイできます。
サーブレット/オブジェクト・レイヤーは、組合せ層クラスタ(「推奨基本アーキテクチャ」を参照)とは、アプリケーションのクライアントに静的なHTTPコンテンツを提供しないという点で異なります。
また、Webサーバーのバンクを、プレゼンテーション層およびオブジェクト層のホストになる1対のWebLogic Serverクラスタに対するフロント・エンドとして使用することもできます。このアーキテクチャを次の図9-5に示します。
このアーキテクチャには、「推奨複数層アーキテクチャ」と同じ利点(および同じ制限)があります。異なる点は、Web層がWebLogicプロキシ・プラグインを利用するWebサーバーの異なるバンクに配置されることのみです。
スタンドアロンWebサーバーとプロキシ・プラグインを使用すると、次の利点があります。
既存のハードウェアの利用
静的なHTTPコンテンツをクライアントに提供するWebアプリケーション・アーキテクチャがすでに存在する場合は、1つまたは複数のWebLogic Serverクラスタを持つ既存のWebサーバーを簡単に統合して、動的なHTTPおよびクラスタ化されたオブジェクトを提供できます。
一般的なファイアウォール・ポリシー
WebアプリケーションのフロントエンドでWebサーバー・プロキシを使用することで、一般的なファイアウォール・ポリシーを使用してDMZを定義できます。通常は、アーキテクチャの残りのWebLogic Serverクラスタへの直接接続を禁止している間は、DMZ内に引続きWebサーバーを配置することができます。上記の図には、このDMZポリシーが示されています。
スタンドアロンWebサーバーとプロキシ・プラグインを使用すると、Webアプリケーションが次のような制限を受けます。
追加の管理
プロキシ・アーキテクチャ内のWebサーバーは、サード・パーティ・ユーティリティを使用して構成する必要があり、WebLogic Server管理ドメインには表示されません。また、クラスタ化されたサーブレットへのアクセスおよびフェイルオーバーの恩恵を受けるためには、WebサーバーにWebLogicプロキシ・プラグインをインストールおよび構成する必要があります。
限定的なロード・バランシング・オプション
プロキシ・プラグインまたはHttpClusterServlet
を使用して、クラスタ化されたサーブレットにアクセスする場合は、ロード・バランシング・アルゴリズムが単純なラウンドロビン方式に制限されます。
WebLogic Serverクラスタでロード・バランサを直接使用すると、サーブレット・リクエストのプロキシに関する利点がもたらされます。まず、ロード・バランサを持つWebLogic Serverを使用することにより、クライアントの設定における追加管理が不要になります。HTTPサーバーのレイヤーを別に設定し保持する必要もなく、1つまたは複数のプロキシ・プラグインをインストールおよび構成する必要もありません。また、Webプロキシ・レイヤーの削除により、クラスタへのアクセスに必要なネットワーク接続数も削減されます。
ロード・バランシング・ハードウェアを使用することで、システムの能力に適合したロード・バランシング・アルゴリズムをより柔軟に定義できるようになります。使用するロード・バランシング・ハードウェアでサポートされている、任意のロード・バランシング方式(ロード・ベースのポリシーなど)を使用できます。プロキシ・プラグインまたはHttpClusterServlet
を使用する場合、クラスタ化されたサーブレットへのリクエストについては、単純なラウンドロビン・アルゴリズムに制限されます。
ただし、インメモリー・セッション状態レプリケーションを使用している場合、サード・パーティ製のロード・バランサを使用するには、さらに構成を行う必要があります。この場合は、クライアントがプライマリ・セッション状態情報にアクセスできるようにするため、クライアントと接続先のサーバー間でセッション維持型の接続を保持するように、ロード・バランサを構成しなければなりません。プロキシは自動的にセッション維持型の接続を保持するため、プロキシ・プラグインを使用する場合は特別な構成は不要です。
推奨構成にあるハードウェアとソフトウェアの物理レイヤーの間の境界には、Webアプリケーションの非武装地帯(DMZ)を定義できるポイントがあります。ただし、すべての境界で物理的なファイアウォールがサポートされているわけではありません。特定の境界で典型的なファイアウォール・ポリシーのサブセットがサポートされているだけです。
次の項では、DMZを定義して、様々なレベルのアプリケーション・セキュリティを作成する方法について説明します。
基本ファイアウォール構成では、信頼性のないクライアントとWebサーバー・レイヤーの間に1つのファイアウォールを使用します。このファイアウォール構成は、推奨基本アーキテクチャまたは推奨複数層アーキテクチャのクラスタ・アーキテクチャで使用できます。
図9-6の構成では、1つのファイアウォールで任意のポリシー(アプリケーション・レベルの制限、NAT、IPマスカレード)の組合せを使用して、3つのHTTPサーバーへのアクセスをフィルタ処理しています。ファイアウォールの最も重要な役割は、システム内のその他のサーバーへのアクセスを拒否することです。つまり、信頼性のないクライアントからは、サーブレット・レイヤー、オブジェクト・レイヤー、およびデータベースにはアクセスできないようにする必要があります。
物理的なファイアウォールは、DMZ内のWebサーバーの前後どちらにも配置できます。Webサーバーの前にファイアウォールを配置すると、Webサーバーへのアクセスを許可し、その他のすべてのシステムへのアクセスを拒否するだけで済むので、ファイアウォール・ポリシーを簡素化できます。
プロキシ・レイヤーとクラスタの間にファイアウォールを配置する場合は、次の構成ガイドラインに従ってください。
プロキシ・プラグインがクラスタ内の各サーバーにアドレス変換エラーなしで接続できるようにするため、IPアドレスではなく外部に公開されたDNS名を使用して、クラスタ化されたサーバー・インスタンスにバインドします。IPアドレスを使用すると、「ファイアウォールについての考慮事項」で説明するようにアドレス変換エラーが発生する可能性があります。
クラスタ化されたサーバー・インスタンスの内部DNS名と外部DNS名が同じでない場合、サーバー・インスタンスのExternalDNSName
属性を使用して、その外部DNS名を定義します。ファイアウォールの外で、ExternalDNSName
はサーバー・インスタンスの外部IPアドレスに変換されます。
注意: クラスタ化サーバーが、1組のカスタム・チャネルのHTTPSトラフィックおよびHTTPトラフィックを分離する場合は、『Oracle WebLogic Serverサーバー環境の構成』のチャネル、プロキシ・サーバー、およびファイアウォールに関する項を参照してください。 |
Webサーバー・レイヤーへのアクセス以外のすべてのアクセスを拒否することによって、基本ファイアウォール構成では、3つのWebサーバーのみが含まれる小規模なDMZが作成されます。ただし、DMZをどんなに慎重に定義しても、悪意のあるクライアントがプレゼンテーション層とオブジェクト層のホストになっているサーバーにアクセスする可能性があることは考慮に入れておいてください。
たとえば、ハッカーがWebサーバーのホストになっているマシンの1つにアクセスしたと仮定します。アクセスのレベルによっては、動的なコンテンツを求めてWebサーバーがアクセスする、プロキシされたサーバーに関する情報を、ハッカーが入手できる場合もあります。
DMZをより慎重に定義する場合には、追加のファイアウォールを配置できます(「共有データベースに対するセキュリティの追加」を参照)。
推奨クラスタ・アーキテクチャでロード・バランシング・ハードウェアを使用する場合は、基本ファイアウォールとの関連を考慮してハードウェアのデプロイ方法を決定する必要があります。数多くのハードウェア・ソリューションでは、ロード・バランシング・サービスに加えてセキュリティ機能も提供されていますが、ほとんどのサイトではWebアプリケーションの防御の最前線としてファイアウォールが使用されています。通常、ファイアウォールでは、Webトラフィックを制限するための、最もよくテストされた一般的なセキュリティ・ソリューションが提供されます。ファイアウォールは、次の図9-7に示すようにロード・バランシング・ハードウェアの前で使用する必要があります。
前述の設定では、Web層を含むDMZ内にロード・バランサが配置されています。この構成でファイアウォールを使用すると、ファイアウォールはロード・バランサへのアクセスを制限するのみで済むため、セキュリティ・ポリシーの管理を簡素化できます。また、この設定では、次の説明のように、Webアプリケーションにアクセスする内部クライアントをサポートするサイトの管理を簡素化することもできます。
Webアプリケーションへの直接アクセスを必要とする内部クライアント(独自のJavaアプリケーションを実行するリモート・マシンなど)をサポートする場合は、プレゼンテーション層への制限されたアクセスを許可できるよう、基本ファイアウォール構成を拡張できます。アプリケーションへのアクセスを拡張する方法は、リモート・クライアントを信頼性のある接続として扱うか、または信頼性のない接続として扱うかによって変わります。
仮想プライベート・ネットワーク(VPN)を使用して、リモート・クライアントをサポートする場合は、クライアントを信頼性のある接続として扱うことができ、クライアントはファイアウォールの向こう側のプレゼンテーション層に直接接続できます。この構成は、次の図9-8のようになります。
VPNを使用しない場合は、Webアプリケーションへのすべての接続(独自のクライアント・アプリケーションを使用するリモート・サイトからの接続も含む)は、信頼できない接続として扱う必要があります。この場合は、図9-9に示すように、プレゼンテーション層をホストするWebLogic Serverインスタンスへのアプリケーション・レベルの接続を許可するようにファイアウォール・ポリシーを変更できます。
Webアプリケーションの内部データと外部から入手できるデータの両方をサポートする1つのデータベースを使用する場合は、データベースにアクセスするオブジェクト・レイヤーの間に強固な境界を配置することを検討する必要があります。この場合、ファイアウォールを追加することによって、「プロキシ・アーキテクチャの基本ファイアウォール」で説明されているDMZ境界を簡単に強化できます。
図9-10の構成では、Webアプリケーションと内部(信頼性のある)クライアントによって共有されているデータベース・サーバーの前に追加のファイアウォールが配置されています。この構成では、最初のファイアウォールが万一破られて、ハッカーが最終的にオブジェクト層のホストになっているサーバーにアクセスした場合のための追加のセキュリティが提供されています。本番環境では、この状況が決して起こらないようにする必要があります。サイトでは、ハッカーがオブジェクト・レイヤーにあるマシンにアクセスするよりもずっと前に、悪意のある侵入を検出し、止める機能が必要になります。
上記の構成では、オブジェクト層とデータベースの間の境界は追加のファイアウォールによって強固になっています。ファイアウォールは、オブジェクト層のホストになっているWebLogic ServerからのJDBC接続以外のすべての接続を拒否する厳密なアプリケーション・レベルのポリシーを保持します。