システム構成は,次の流れで設計します。
図3-2 システム構成を設計する流れ(J2EEアプリケーション実行基盤の場合)
各システム上で動作するアプリケーションで使用するコンポーネントの構成を明確にして,アプリケーションのどのコンポーネントをアクセスポイントにするかを決定します。
アクセスポイントとは,クライアントからリモートでアクセスされる場合に,アプリケーションのリクエスト受信窓口として動作するコンポーネントです。アクセスポイントになるコンポーネントの種類によって,実現できるシステム構成が決まります。
また,アプリケーションがデータベースなどのリソースに接続するかどうかを決めます。接続するリソースに対応して,使用するリソースアダプタが決まります。
なお,ここで検討したアクセスポイントになるコンポーネントの種類によって,それ以降のシステム構成の設計で検討が必要な項目が異なります。アクセスポイントになるコンポーネントの種類ごとに検討が必要な項目を,次の表に示します。
表3-1 アクセスポイントになるコンポーネントの種類ごとに検討が必要な項目
設計項目 | アクセスポイントになるコンポーネントの種類 | 参照先 | |||
---|---|---|---|---|---|
Webフロントシステム | バックシステム | ||||
サーブレット /JSP | Session Bean /Entity Bean | CTMを使用する場合のStateless Session Bean | Message- driven Bean | ||
クライアントとサーバの構成 | ◎ | ◎ | ◎ | - | 3.4 |
サーバ間での連携方法 | - | △ | △ | - | 3.5 |
トランザクションの種類 | ◎ | ◎ | ◎ | ◎ | 3.6 |
ロードバランスクラスタによる負荷分散方式 | △ | △ | △ | - | 3.7 |
サーバ間での非同期通信 | - | - | - | ◎ | 3.8 |
運用管理プロセスの配置 | ◎ | ◎ | ◎ | ◎ | 3.9 |
セッション情報を引き継ぐための構成 | △ | △ | - | - | 3.10 |
クラスタソフトウェアを使用した系切り替えを実現するための構成 | △ | △ | △ | △ | 3.11 |
ファイアウォールの配置 | △ | △ | △ | △ | 3.12 |
DMZへのリバースプロキシの配置 | △※ | - | - | - | 3.13 |
性能解析トレースファイルを出力するプロセスの配置 | ◎ | ◎ | ◎ | ◎ | 3.14 |
アプリケーションサーバ以外の製品との連携 | △ | △ | △ | △ | 3.15 |
任意のプロセスの運用管理 | △ | △ | △ | △ | 3.16 |
注※ インターネットに接続するシステムでWebサーバとしてインプロセスHTTPサーバを使用する場合は必ず検討してください。
アクセスポイントになるコンポーネントに応じて,クライアントとサーバの対応を明確にします。システムに配置したアプリケーションサーバは,その役割に応じて,クライアントとして機能したり,サーバとして機能したりします。
クライアントとサーバの構成の考え方を次の図に示します。
図3-3 クライアントとサーバの構成の考え方
この構成の場合,APサーバ1はWebクライアントに対するサーバに当たり,アクセスポイントはサーブレット/JSPになります。また,APサーバ1はAPサーバ2に対してのクライアントになります。APサーバ2はAPサーバ1に対するサーバに当たり,アクセスポイントはEnterprise Beanになります。
サーバが複数ある場合に,サーバ間で連携するかどうか,連携する場合はどのように連携するかを検討します。サーバ間連携とは,クライアントから見て垂直に並んだ複数のサーバから,ほかのサーバ上にあるアクセスポイントのコンポーネントを呼び出して処理を実行する連携方法です。
サーバ間連携の考え方を次の図に示します。
図3-4 サーバ間連携の考え方
この構成の場合,APサーバ1とAPサーバ2は,APサーバ3のクライアントになり,それぞれのサーブレット,JSPまたはMessage-driven Beanから,APサーバ3のSession Beanを呼び出します。
サーバ間連携と同時に,必要に応じて,アプリケーションを分割するなど,アプリケーションの形態も見直します。また,複数のシステム間で連携する場合も,それぞれのシステムに含まれるサーバ間の連携方法を検討する必要があります。
データベースなどのリソースを使用するシステムの場合に,トランザクション管理の対象になるリソースの数に応じて,使用するトランザクションの種類を検討します。
システムの可用性を高めるために,ロードバランスクラスタ構成によって負荷を分散するかどうか検討します。負荷を分散する場合は,アクセスポイントになるコンポーネントの種類に応じてどの方式で実現するかを検討します。
Message-driven Beanを使用してアプリケーションサーバ間での非同期通信をする場合に,利用する製品に応じたシステムの構成を検討します。なお,Message-driven Beanによる負荷分散についても,あわせて検討します。
運用管理プロセス(Management Server)を利用する場合に,管理対象にする範囲によって,Management Serverをどのサーバマシンに配置するかを検討します。
Webフロントシステムで動作するJ2EEアプリケーションまたはJ2EEサーバに障害が発生した場合に,セッション情報をほかのJ2EEサーバに引き継ぐための構成について検討します。
一つのアプリケーションサーバに障害が発生した場合およびシステムを保守する場合を考慮して,クラスタソフトウェアによって系切り替えを実行して,システムの運用を続行させるための構成を検討します。このとき,実行系と待機系がそれぞれ相互に切り替え対象になる構成(相互スタンバイ構成)も検討できます。また,トランザクションサービスを使用している場合は,障害発生時にリソースを解放するためのリカバリサーバを利用するための構成も検討します。
なお,この構成は,Solarisの場合には使用できません。
アプリケーションサーバおよびリソースのセキュリティを確保するための,ファイアウォールの配置について検討します。ファイアウォールは,アクセスポイントになるコンポーネントの前に配置して,アクセスポイントに対する不正なアクセスを防止します。ファイアウォールを配置するポイントは,アクセスポイントによって決まります。なお,「3.12 ファイアウォールを使用する構成を検討する」では,基本的なファイアウォールの配置についてだけを示します。侵入検知システムも含めたセキュリティ構成の詳細については,「10.10.2 ファイアウォールと侵入検知システムを配置する」を参照してください。
インターネットと接続するシステムの場合などには,アプリケーションサーバおよびリソースのセキュリティを確保するために,DMZへのリバースプロキシの配置を検討します。
性能解析に使用するプロセスであるPRFデーモン(パフォーマンストレーサ)の配置について検討します。
システムの集中監視,構成管理,自動運転などをしたい場合には,必要に応じてJP1などのアプリケーションサーバ以外の製品との連携を検討します。
ユーザが定義する任意のプロセスをユーザサーバとしてManagement Serverによる運用管理の対象にしたい場合には,ユーザサーバの配置について検討します。
(14)までで検討した以外の構成について検討します。また,必要に応じて,07-00より前のアプリケーションサーバで構築しているシステムとの互換性を持つシステム構成も検討します。