NSUG README 第36号 Feature Article

NSUG README 第36号 (C) 日本サン・ユーザ・グループ(2000年6月発行)



「iPlanet Netscape Application Server 4.0」

iPlanet E-Commerce Solutions Japan  工藤 達雄

iPlanet E-Commerce Solutions、A Sun-Netscape Allianceが提供するiPlanet Netscape Application Server(NAS)は、特に電子商取引やポータル・サイトにおいて数多くの 実績を有するWebアプリケーション・サーバである。現在リリースされているNAS 4.0では、 従来からの特長であるパフォーマンス、拡張性、信頼性などの基盤機能を向上し、加えて 新たに分散トランザクション機能とJava 2 Platform、Enterprise Edition(J2EE)指向 のアプリケーション開発モデルを備えている。 NAS 4.0はSolaris 2.6/7、Windows NT 4.0、およびHP-UX 11.0で動作する。

構成

NASの運用時の構成は

    - Webブラウザ
    - Webサーバ
    - NAS
    - データベース
の4層からなり、これに加えてNASの設定情報およびユーザ情報などを格納するためのディレクトリ・サーバが存在する(図1)。処理の中心となるWebサーバおよびNASを複数台配置することにより、負荷分散およびフェイルオーバに対応する。

図1:NASのシステム構成

NAS内部のプロセスについて図2に示す。Webブラウザからのリクエストは、まずWebサーバ内に組み込まれたWeb Connector Pluginによって処理される。なお、Web Connector PluginはNSAPI(iPlanet Web Server)/ISAPI(Microsoft Internet Information Server)/ASAPI(Apache)によって実装されている。 Web Connector PluginはリクエストをNAS内のkxsプロセスに転送する。kxsはそれがJavaのアプリケーション・ロジックに対するリクエストであればkjsプロセスに、C++であればkcsプロセスに実行を依頼する。 kjsおよびkcsはそれぞれ当該ロジックを実行し、必要であればデータベースなどに接続を行う。処理された内容はHTMLなどに整形され、kxsへ送られる。kxsはさらにWeb Connector Pluginへ処理結果を転送し、最終的にWebブラウザへの応答となる。

図2:NASの内部プロセス

これらのプロセスはマルチ・スレッドで動作する。また、実行エンジンであるkjs/kcsは同一NASインスタンス内に複数配置することも可能である。

パフォーマンス
基本的にNASはマルチ・スレッド/プロセス/マシンで動作し、また一般のCGIのようにリクエストごとのプロセス起動は発生しないため、処理のオーバーヘッドが小さく高速なレスポンスを行うことができる。
これに加え、NASでは以下の機能が強化されている。

データベース接続のキャッシング
データベースを利用する場合に問題となるのが、接続の確立/切断に要する時間である。NASではkjsがデータベース接続をプールすることでこのオーバーヘッドを回避している。

リザルト・キャッシング
NASでは特定の入力パラメータとそれに対する処理結果をキャッシングすることが可能である。キャッシュはkxs内に生成され、同一内容のリクエストであればkjs/kcsによるアプリケーション実行をせずに応答する。キャッシングの対象とする入力パラメータの条件は、アプリケーション・コンポーネントごとに設定することができる。

データ・ストリーミング
ヒット件数の多いような検索処理など、あるリクエストに対して出力結果が長大なものになる場合、処理が完全に終了してから応答を開始する方式では、ブラウザ側に結果が出力されるまでに相当の待ち時間が発生する可能性がある。 NASではこれに対して処理結果のストリーミングを行うことができる。例えばデータベースに問い合わせを行ったとき、問い合わせ結果を順次クライアントに出力することでユーザの感じる待ち時間を短縮することが可能である。

スケーラビリティ
拡張性には垂直方向、および水平方向の2つの側面がある。まず垂直方向の拡張性については、NASではアプリケーションの実行エンジンであるkjs/kcsを追加することで実現される。これにより、例えばCPUを追加した場合のパフォーマンスが向上する。 また、NASの水平方向の拡張性は主に以下の2点によってもたらされる。

アプリケーション・パーティショニング
アプリケーションは複数のコンポーネント、典型的にはServlet、JSP、EJB、およびその他のユーティリティ・クラスにより構成される。NASではこれらをマシンごとに分散して配置することが可能である。加えて、あるコンポーネントをアプリケーション間で共有することもできる。
例えば処理時間の長いトランザクションを行うコンポーネントと、一方比較的短い別のコンポーネントが存在するとしよう。これらを同一マシン上に配置した場合、前者のトランザクションが完了するまで後者の処理がキューイングされるということがあり得る。サーバをそれぞれ分割しトランザクションを並列させることで、全体の処理性能は向上すると考えられる。
またバックエンドが複数の異なるデータ・ソースより構成される場合、そのデータ・ソースごとに接続するNASを分割することは管理性の向上に結び付く。
同一のコンポーネントを複数のNASにそれぞれ配置することも可能であり、これによってそのコンポーネントに対して負荷分散機能を適用することができる。また予期しないクラッシュなどによりサーバが停止する場合にも、システム全体としてはサービスをそのまま稼働させることができる。
これらの設定はNASを再起動させることなく変更することが可能であるので、管理者はリクエストの増大に応じて柔軟にコンポーネントの配置を調整することができる。

動的負荷分散機能
NASの負荷分散機構はNASマシン・レベルとWeb Connector Pluginレベルの2通りの方式がある。
NASマシン・レベルの負荷分散機構はロード・モニタとロード・バランサから構成され、前者はある時間ごとのサーバ情報の測定を、後者はその統計情報に基づくリクエストの振り分けを行う。リクエストのルーティング・テーブルは負荷状況に応じて動的に変更され、高負荷時にもシステムの性能を最大限に発揮することができる。
ロード・モニタによって収集される情報は大きく分けて2種類ある。1つはサーバ自身の負荷であり、これにはCPU loadやI/O、メモリ・ページングなどが含まれる。他方アプリケーションに関する情報として、リザルト・キャッシュの有無や待ち行列に入っているリクエストの個数などがある。これらのパラメータのうちどれに重点を置くかは運用中にチューニングすることができる(図3)。

図3:NAS Administratorによる負荷分散機能の設定

これらの情報はNASの間でインターバルをおいて互いに交換され、各NASマシンは自分の負荷状態が他と比較して大きいか小さいかを決定する。もし負荷が大きいと判断した場合、そのNASマシンはWeb Connector Pluginから受け取ったリクエストをさらに別のNASマシンへとディスパッチする。
一方Web Connector Pluginレベルの負荷分散機構は、NASマシンの負荷状況によらずWeb Connector PluginとNASとの間の応答時間の長短によって行われる。NASが起動した直後はWeb Connector Pluginはラウンド・ロビンによって各NASへリクエストを振り分けるが、次第に最も応答時間の短いNASへリクエストを多く転送するようになる。
このWeb Connector Pluginレベルでの負荷分散機構は、NASマシン・レベルのようなきめ細かな設定は行うことができないが、半面NAS間での負荷情報のやりとりが発生しないので通信量は小さいものとなる。なおどちらの負荷分散機構でも、それを用いるかどうかはアプリケーション・レベルではなくそれを構成するコンポーネント・レベルで選択することが可能である。

可用性/信頼性

インターネット/イントラネットを問わず、多くのアプリケーションは24時間、365日の稼働が求められている。これを実現するために、NASでは前述の動的負荷分散機能に加え、フェイルオーバ機能を備えている。アプリケーションを複数のサーバに配置することにより、あるサーバがダウンしたとしても他のサーバが処理を継続することができる。またアプリケーションの追加や変更はNASをシャットダウンすることなく行うことが可能である。

分散ステート/セッション管理
例えばオンライン・ショッピングのようなアプリケーションでは、「買い物かご」に購入する商品を格納しそれをページ間で持ち回るケースが想定されるだろう。この買い物の途中でその情報がサーバのダウンによって失われるようなことがあっては、利用者はそれまでの作業を一からやり直す羽目になる。
アプリケーションの状態(ステート)とユーザのセッション情報の管理は、Webベースのアプリケーションでは非常に重要である。NASはこれらのステートおよびセッション情報をサーバ間、具体的には各NASマシンに存在するkxsの間で複製・同期を行い信頼性の向上を図っている。
まずすべてのセッション情報は、NASクラスタ内のある1台(Sync Primary)によって集中して管理される。これに対しNASクラスタ内の任意のサーバ(Sync Backup)はSync Primaryのセッション情報の複製を保持し、セッション情報に変更があったときにはSync Primaryからその差分を受け取って同期を行う。なおセッション情報はin-memoryで管理されるので、データベースやファイルに保存する場合に比較して非常に高速な処理がなされる。
Sync Primaryが何らかの原因でダウンすると、Sync Backupのうちの1台が自動的に新たな Sync Primaryとして機能する。すなわちセッション情報はすべて引き継がれ、利用者にはサーバがダウンした影響を生じることなくサービスを提供し続けることができる。
NASクラスタ内には必ず1台のSync Primaryが存在するが、残りすべてのNASがSync Backup となるわけではない。PrimaryとBackupの他に、BackupのバックアップとなるSync Alternate、そしてセッション情報の同期に参加しないSync Localを組み合わせることで、同期処理によって発生する通信量の増大を抑えつつ、信頼性の高い構成が実現できる。

分散トランザクション管理
NASにはTPモニタであるEncinaが組み込まれている。これにより異種データソース間、あるいは複数kjs(Java VM)間にトランザクションがまたがる場合(heterogeneous transaction/distributed transaction)でも、X/Open XAプロトコルによる2相コミットを行うことができる。
この機能はEJBの宣言型トランザクションとして利用することが可能であり、開発者は特別なコードを書く必要はない。また前述した通りdistributed transactionに対応しているので、システムの構成にとらわれることなく、アプリケーションの柔軟な配置を行うことができる。

管理

NASには管理ツールとしてNAS Administrator(NASA)が付属しており、これまで述べた事項に関するほとんどの設定、および各NASマシンの状態の監視を行うことが可能となっている。加えてSNMPに対応しており、サードパーティの管理ツールを用いた管理を行うこともできる。
アプリケーション配布にあたっては、NAS Deployment Managerによる複数のNASマシンへの一括配置が可能である。また開発ツールであるiPlanet Netscape Application Builder 4.0にも同様の機能が含まれており、開発と配備をスムーズに連係させることができる。

アプリケーション開発モデル

J2EE
NASのアプリケーション開発モデルはJ2EEを指向しており、プレゼンテーション・ロジックのためのJava Servlet/JavaServer Pages(JSP)、ビジネス・ロジックのためのコンポーネント技術であるEnterprise JavaBeans(EJB)、そしてデータ・アクセスのためのAPIとしてJDBC、JTA(Java Transaction API)などを提供している。以下、各APIを利用する際のNASの優位点について述べる。

Servlet/JSP
NASではServlet/JSPの実行に関して、前述したリザルト・キャッシングや動的負荷分散機能、ステート/セッションのフェイルオーバなどのサポートを行っている。これらのNASを機能を活用するにあたって、開発者は独自のAPIを用いる必要はない。例えばセッション・フェイルオーバはServlet APIでセッション機能として定義されているHttpSessionに対して有効であるし、動的負荷分散機能は運用時に設定することができる。

EJB
EJBには大別して2種類あり、それぞれSession Bean(主にビジネス・ロジックを扱う)と Entity Bean(テーブルのある1行など、永続的なデータを表現する)と呼ばれる。EJB 1.0の仕様ではSession Beanのサポートのみが必須となっているが、NASではこれに加えてEntity Beanも利用することができる。
どちらの種類のEJBに対してもServletと同様に動的負荷分散が行われる。またEntity Beanについて、NASではデータの整合性をデータベースが担当することで同一のEntity Beanインスタンスを複数のkjs(Java VM)内に存在させることが可能となり、パフォーマンス・ボトルネックとなるのを避けることができる。
加えてEJBからデータベースにアクセスする際には分散トランザクションがサポートされる。

JDBC/JTA
データベース・アクセスに関してNASではJDBC APIが利用可能であるが、これはJDBCドライバではなく、実際には各ベンダが提供するネイティブのデータベース・ドライバを用いている。これによりパフォーマンスは前者に比べて向上している。またデータベース接続のキャッシングについても、開発者はそれを利用するためのコーディングを意識的に行う必要はない。
またEJBではDeployment Descriptorに記述することによって自動的にトランザクションの境界が設定されるが、JTAによってこれを明示的に行うことも可能である。

ロードマップ

次期バージョンであるiPlanet Application Server(iAS)6.0は、現行のNAS 4.0ともう一方のアプリケーション・サーバであるNetDynamics 5を統合した製品として、北米では今年5月に出荷されている(日本語版は2000年秋を予定)。iAS 6.0ではNAS 4.0をベースに、主に以下の点について機能強化を図っている。

- J2EE完全対応
- Java Messaging Service(JMS)のサポート
- スケーラビリティ、可用性、信頼性、パフォーマンスの更なる向上

おわりに

現在Webアプリケーション・サーバ市場にはさまざまな製品が存在するが、「既存システムとの統合機能」や「強力な開発ツールとの統合」など、それぞれ得意とする分野は各社各様である。Webアプリケーション・サーバの選定にあたっては、まずどのような機能を求めるのかを明確にすることが重要であろう。
NASの特長を一言で表すなら「大規模インターネット・サイト向け」であり、本稿で述べたように、NASはそれを実現するための機能のすべてを提供している。アクセス数の急激な増大にもダウンすることのない、かつ安定して運用することのできるアプリケーション基盤を求めるのであれば、NASは最適な、そして唯一のソリューションと言えるのではないだろうか。  



このページに関するご質問は www@nsug.or.jp までお願いいたします。