[プロダクトレビュー]

信頼性とスケーラビリティを高めるアーキテクチャ
WebShpere Application Server 3.5

樽澤広亨(たるさわ ひろゆき)
日本アイ・ビー・エム システムズ・エンジニアリング
2001/3/23

IBMのWebSphere Application Serverは、高パフォーマンス、スケーラビリティ、高可用性の実現のために工夫されたアーキテクチャが採用されている。本稿では、アーキテクチャとJ2EE対応状況、開発環境をポイントとして、日本アイ・ビー・エム システムズ・エンジニアリングの樽澤広亭氏に紹介していただく。（編集局）

---

1.WebSphere Application Serverのアーキテクチャ

　WebSphere Application Server（以下WAS）は、J2EE／EJB／XMLといった最新の技術を使ったECサイトの立ち上げから、レガシー・システムと連携するアプリケーション・ハブまで、幅広いeビジネス・ソリューションの提供を可能とするJavaベースのアプリケーションサーバ製品です。本稿では、WASについて、アーキテクチャ、プログラミング・インターフェイス、開発環境の観点からご紹介します。

複数のロードバランス機能を搭載

　どの時間帯にどの程度のアクセスが見込めるか？ グローバルネットワークを相手にするECサイトではこの基本的な予測が困難です。そこで常に良好なレスポンスを保ち、多量のアクセスにも耐えうる、決してダウンしない情報システムが求められます。WASは、3つのワークロード・バランス／HA（ハイ・アベーラビリティ）機能で、この難問を解決します。

　 図1を参照してください。WebサーバへのHTTPリクエストは別売りのWebSphere Edge Serverのネットワーク・ディスパッチャー（ND）機能で、WebサーバからWAS（サーブレット）へのリクエストはWASリモートOSE機能で、EJBヘのRMI/IIOPリクエストはWAS WLM機能で、各クラスタに振り分けられます。アクセス数が増えても、良好なレスポンスを維持できます。また各クラスタやND機能自体の障害を検知しバックアップする機能（HA）もありますので、障害に強いシステムを実現できます。なお各機能ともにHttpSessionオブジェクトに対応しますので、セッションはしっかりと維持されます。

図1 3種のワークロード・バランスによって将来の大きな負荷にも耐えうるWebアプリケーションを実現できる

　NDとほかのワークロード・バランス／HA機能の違いは、次の3点です。

（1）IPレベルでのワークロード・バランス

　リモートOSEはWebサーバとWAS間のソケット通信（OSEプロトコル）の、WLMはEJBクライアントとEJB間のRMI/IIOPプロトコルのワークロード・バランスをサポートします。それに対して、NDのワークロード・バランスはIPレイヤで行われるため、HTTPをはじめとして、FTP、SSL、NNTP、POP3などIP上のほとんどのプロトコルに対応します（IIOPは未対応）。NDを使用すれば、例えばIPプロトコルで通信可能な任意のサーバ・クラスタに対するワークロード・バランスとHAが可能なのです。

（2）セッション数、レスポンス時間の重みづけによるワークロード・バランス

　リモートOSEやWLMはラウンド・ロビンやランダムにワークロード・バランスしますが、NDの場合はラウンド・ロビン、ランダムに加えて各サーバに割り振られているセッション数、サーバからのレスポンスなどによる重みづけも加味した割り振りを行います。NDでは、クラスタを構成する各サーバのワークロードを把握して、よりバランスの良いワークロード・バランスができるのです。

（3）NDが自身のHA機能を内蔵

　ND自身の障害対策としてハートビートの交換によるHA機能が提供されています。NDを本番、バックアップの2台構成にした場合、ハートビートを交換して互いの状況を確認し合います。本番機の障害時には瞬時にバックアップ機に切り替わるので、継続的なワークロード・バランスが可能です。

異なるプロセスで稼動させるメリット

　WASはWebサーバとは異なるプロセスで稼働し、Webサーバ・プラグイン・モジュールを通してソケット通信します。つまり、Apacheのような使い慣れた業界標準のWebサーバとWASを組み合わせることができます。もちろんWASに同梱されるIBM HTTP Serverを利用することも可能です。また、万が一ユーザー・アプリケーションのバグのためにWASが障害に陥っても、プロセスの異なるWebサーバはダウンすることなく稼働します。障害が発生してもエンド・ユーザーを当惑させることのない信頼性の高いシステムを構築することができます。

　WASは、最低3つのプロセスで構成されます（Windows版、UNIX版）（図2）。サーブレット、JSP、EJBといったユーザー・アプリケーションが稼働するManaged Server、WASを構成管理するAdmin Server、そしてNannyの3つのプロセスです。NannyはAdmin Serverを監視するプロセスで、Admin Serverが障害に陥った場合、正常な状態に復旧します。さらに、Admin Serverは、Managed Serverのプロセス障害を修正します。つまりWASは二重にプロセス監視の仕組みを用意して、障害に強い構造を備えているのです。ちなみにAdmin Serverの管理する構成情報は、EJBによるトランザクション処理で管理DBに格納されています。構成管理の安全性も保障されているというわけです。

図2 Admin serverプロセスがユーザー・アプリケーションが稼動するManagedプロセスを監視し、障害が発生した場合は復旧を行う。一方Admin Server自身は、Nannyプロセスによって監視されている。この二重の監視機構に加え、Admin Serverの管理する構成情報は管理DBに格納されるため、構成情報自身の安全性も保障される

セキュリティはOSEリモート機能で確保

　WebサーバとWASは別プロセスで稼働するので、それぞれを異なるノード（ホスト）に導入することができます。このとき、ノード間のソケット通信を実現するのが OSEリモート機能です。OSEリモート機能はワークロード・バランス機能も提供します。

　WAS OSEリモート機能は、堅牢なセキュリティを実現します。もしネットワークに、DMZ（非武装地帯：2つのファイアウォールに挟まれたネットワーク・セグメント）を設けているならば、Webサーバ・ノードをDMZに、WASノードをイントラネットに配置します（図3）。両ノード間はOSEリモート機能で通信が行われ、WASは2つのファイアウォールでブロックされることになります。その結果DMZ上のWebサーバとOSEリモート機能で認証されたメッセージだけがイントラネットのWASに転送されるため、セキュリティを脅かす攻撃からの保護が実現できるのです。つまり大切なビジネス・ロジックやデータは安全なイントラネットで保護されるのです。WAS OSEリモート機能だからこそできる安心設計といえるでしょう。

図3 WebサーバのノードをDMZに、WASのノードをイントラネットに置くことによってセキュリティを保つことができる

対話型の構成管理が可能

　WASの構成管理作業は簡単でかつ細かな制御が可能です。対話型で構成管理作業を行うには管理クライアント（画面1）を使います。管理クライアントはWASのほぼすべての管理が可能なGUIです。管理クライアントはEJBクライアントとして実装されており、EJBサーバであるAdminServerプロセスにトランザクション中で働きかけて安全に構成管理作業を実施します。

画面1　細かな構成管理作業も対話型のインターフェイスで行うことができる

　他方XMLConfigまたはwscpという機能も構成管理作業のために提供されています。XMLConfigとは、管理作業の内容をXMLで記述しておいて、その記述内容をWAS提供のシェル（Windows版ではバッチ）で読み込んで処理する機能です。wscpはtclに似たスクリプト言語でコマンド・ラインから管理作業を行います。双方ともに対話型でもバッチ・スタイルでも管理作業を行うことが可能です。

　管理クライアント、XMLConfigとwscpは適用場面が異なります。GUIを提供する管理クライアントは、不特定の作業を直感的に実施することができます。さまざまな構成を試す開発期間には管理クライアントを利用することが多くなると思います。それに対して、構成管理作業プロシージャをあらかじめ用意しておき、コマンドでバッチ的に処理可能なXMLConfigやwscpは、カット・オーバー後の運用管理の自動化を可能にします。つまりシステム運用時の定型処理にはXMLConfigやwscpを用いることになります。

主要なプラットフォームに対応

　WASは多くの主要なOSに対応します。現在WAS 3.5は、AIX、OS/400といったIBMのプラットフォームに加えて、Solaris、HP-UX、Linux、Windows NT、Windows 2000に対応しています。また、Oracle、SybaseそしてDB2 UDBといった業界標準のDB製品に対応しています。さらにWebサーバとしては、Apache、Internet Information Server、Netscape Enterprise Server、iPlanet Web Server、IBM HTTP Server（IBMがApacheを拡張したもの）、ほかと一緒に使用することができます。

WASのアプリケーション・インターフェイス ■J2EE 1.2対応のプログラミング・インターフェイス 　WASは、J2EE 1.2をサポートし、ここで定めるサーバ・サイドのJava APIの使用を推奨します。すなわち、サーブレット、JSP、EJB、JTA、JNDI、JDBC、JMSといった主要APIを使ってポータビリティのあるサーバ・アプリケーションの開発が可能です。それに加えて、XA対応のJMS、EJBのアソシエーション、EJBアクセスBeanといった先進的な機能も提供します。DBテーブル設計に応じた関連性をCMPのEntity Beanに追加するのがアソシエーション機能、EJBクライアントをラップするJavaBean（アクセスBean）を自動開発するのがアクセスBean機能です。両者はVisualAge for Javaエンタープライズ版（VAJ EE）の機能で、ウィザードに答えるだけでJavaの実装を作ってくれる便利なものです。 　なおIBMは J2EE 1.2に含まれるAPIの80%の策定作業にかかわってきましたが、今後もJ2EEへの貢献を継続します。 ■高いパフォーマンスを約束するアプリケーション実行環境 　WASはJDBC 2.0コネクション・プールのような標準APIの実装でパフォーマンスを改善しています。さらにWAS独自の機能として、PreparedStatementキャッシュとJNDIキャッシュを提供しています。これらはWASの内部実装として提供されるのでプログラムのポータビリティを損なうものではありません。 　PrepareStatementはコンパイル済みのSQLステートメントを格納するオブジェクトで、Statementオブジェクトに比べてコンパイルがない分高速な処理が可能です。WASのPreparedStatementキャッシュは、PreparedStatementオブジェクトをキャッシュ、再利用することでさらにDBアクセスを高速化しようというものです。意識してPreparedStatementをコーディングできないCMP Entity Beanも自動的にPreparedStatementキャッシュを使用してDBに高速アクセス可能です。 　EJBHomeやDataSourceはJNDI経由でネーミング・サービスから取得しますが、この処理はパフォーマンスのボトルネックとなりがちです。JNDIキャッシュとは、ネーミング・サービスの検索結果をWASにキャッシュすることで、名前解決のレスポンスを改善する機能です。 ■2フェーズ・コミット可能なトランザクション・マネージャ 　WASはJTSに準拠したトランザクション・マネージャの機能を実装しています。トランザクション機能は、JTAを介してサーブレットやJavaBean、EJBのSession Beanから利用することができます。また、コンテナ管理トランザクションのSession Bean／Entity Beanから暗黙的にトランザクション機能を利用することもできます。 　WASのトランザクション・マネージャはXAインターフェイスを通じた分散トランザクション機能を実現できます。つまり、リソース・マネージャのドライバがXAインターフェイスを実装していればWASのトランザクション・マネージャを利用して２フェーズ・コミットが可能というわけです。WAS 3.5では、DB2 UDB、Sybaseを対象に２フェーズ・コミットすることができます。さらにWAS 3.5.3では、MQ Series、Oracle、そしてSQL Serverに対するXAサポートが開始されました（SQL Server、OracleについてはMERANT DataDirect SequeLink経由でXAインターフェイスが提供されますが、現在のところ日本語環境での2フェーズ・コミットは検証しておりません）。 ■統合されたバックエンド・システムとの連携 　アプリケーションサーバにはバックエンドのレガシー・システムとの連携も求められます。バックエンド連携はIBM CCF（コモン・コネクタ・フレームワーク）準拠のコネクタにお任せください。コネクタとはCICS、IMS、Encina、MQSeries、SAP R/3などのミドルウェアのJavaインターフェイスで、各ミドルウェアのクライアント機能を意識することなく、連携処理を実装できます。コネクタは、VAJなどが提供します。 　IBM CCFは、J2EE standard for enterprise connectivity（JCX API）のIBMの実装になる予定です。

2.WebSphereの開発環境と周辺ソリューション

Index 1. WebSpere Application Serverのアーキテクチャ ■複数のロードバランス機能を搭載 ■異なるプロセスで稼動させるメリット ■セキュリティはOSEリモート機能で確保 ■対話型の構成管理が可能 ■主要なプラットフォームに対応 コラム：WASのアプリケーション・インターフェイス 　 2. WebSphereの開発環境と周辺ソリューション ■ファミリー製品が提供するソリューション ■将来動向

Application Server Center アプリケーション・サーバ情報へのリンク集 (2001/12/3更新)    　各社アプリケーション・サーバ製品紹介 BEA WebLogic Borland AppServer IONA iPortal IBM WebSphere Oracle Oracle9iAS Macromedia JRun (旧Allaire） hp bluestone 日立製作所 Cosminexus iPlanet Application Server

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）