[製品紹介]
オープン化とミッションクリティカルを目指す
WebSphere Appliaction Server V5
樽澤広亨(たるさわ ひろゆき)
日本アイ・ビー・エム システムズ・エンジニアリング
2003/2/21
| WebSphere Application Server V5.0は、その根本思想として一層のオープン化への対応、オートノミック・コンピューティング実現を柱としている。本稿ではこの2本柱を中心にWAS V5の概要を説明する。 |
WebSphere Application Server V5.0（以下WAS V5）は、IBMのオープン化推進の成果が反映された製品だ。WAS V5のプログラミング・インターフェイスは、J2EE 1.3に対応し、SOAP、WSDL、UDDI、WSIFといったWebサービスの標準仕様の実装を提供している。加えてオープン・ソースのJ2EEフレームワークであるJakarta StrutsのJarファイルを同梱した。カスタム・メイドのJ2EEコンポーネントから、一歩進んだWebサービス、そしてStrutsアプリケーションまで、WAS V5は幅広い業界標準コンポーネントの稼働環境を提供している。
開発環境の観点で見れば、WAS V5は、IBMがeclipse.orgに寄贈したWebSphere Studio Workbench を基に開発されている。サポートOSも幅広くWindows 2000、Windows NT、AIX、Solaris、Linux/Intel、Linux/390（HP-UXとPower PC版Linuxについては開発意向表明）をサポートしている。
オープン化対応と並ぶWAS V5の意欲的な取り組みとしてオートノミック・コンピューティングへの第一歩を踏み出したことが挙げられる。オートノミック・コンピューティングとは、従来多くの人手を介して行われてきたシステム管理を、システム自身が自律的に履行するための技術で、自己構成／自己修復／自己最適化／自己防御の4つの要素から成り立っている。WAS V5では、自己最適化の実現のためにWorkload Management機能を改良し、さらに自己修復・自己最適化の基盤を支えるパフォーマンス・アドバイザ機能をTechnology Preview（正式サポートがない評価版相当の機能）として同梱している。完全なオートノミック・コンピューティングの実現はいまだ先の話ではあるが、WAS V5におけるWorkload Management改良とパフォーマンス・アドバイザの提供は、オートノミック・コンピューティング実現への取り組みのメッセージといえよう。
WAS V5の提供形態としては、用途別に「WebSphere Application Server Express」（以下WAS Express）、「WebSphere Application Server」（以下WAS Base）、「WebSphere Application Server Network Deployment」（以下WAS ND）、「WebSphere Application Server Enterprise」（以下WAS Enterprise）の4つのパッケージが提供されている。それぞれ、WAS Expressは軽量Webコンテナ、WAS BaseはJ2EE 1.3準拠のシングル・サーバ、WAS NDはJ2EE 1.3準拠の分散配置可能な複数サーバ、WAS EnterpriseはWAS ND機能＋拡張APIサポート、といった特徴を備えている。システム要件に合わせて柔軟に選択できるラインアップとなっている。
| 1.WAS V5のアーキテクチャ |
次にW V5トポロジ、Workload Management、パフォーマンス、システム管理の観点よりWAS V5のアーキテクチャを概説する。
| 信頼性とハイ・パフォーマンスを両立する WebSphereトポロジ |
WAS V5では従来のWASアーキテクチャを大幅に見直しており、WASの根幹を成すプロセス・モデルが一新されている（図1）。
 |
| 図1 WAS V5 NDのトポロジー。刷新されたアーキテクチャによって、複数ノードで構成された分散コンピューティング環境も実現できるようになった |
WAS ND以上のパッケージを導入すると複数ノード（ノード = 物理的ハードウェア）から構成される分散コンピューティング環境を構築することができる。このような分散環境を管理する論理的な単位がセルである。いい換えると、セルとはWAS V3やV4におけるドメインに相当するものと考えてよい。セルの主要な構成要素としてデプロイメント・マネージャ、ノード・エージェント、アプリケーション・サーバがあり、UNIX／Windows環境においてはそれぞれ１つのプロセスとして稼働する。これらのプロセスはそれぞれシステム管理の階層を構成している。つまり、管理者によるすべてのシステム管理作業はデプロイメント・マネージャに対して行われ、デプロイメント・マネージャは管理下のノード・エージェントに実作業を委託する。ノード・エージェントは必要に応じてアプリケーション・サーバと協業して管理作業を遂行するのだ。また、システム構成情報のマスタはデプロイメント・マネージャが管理しているが、同時に各ノード・エージェントも同等の構成情報を保持している。マスター情報が更新されると、その変更情報はノード・エージェントにブロードキャストされ、マスター構成情報と同期されるようになっている。
この新しいプロセス・モデルが導き出す特徴の1つが、アプリケーション・サーバのハイ・アベイラビリティである。例として、デプロイメント・マネージャ、ノード・エージェントに障害が発生した場合を考えてみよう。何らかの影響でこれらのプロセスがダウンした場合、新たなJ2EEモジュールの導入といったシステム管理作業を履行することはできない。しかしながら、このモデルでは各階層間が疎結合しているので、この障害が、アプリケーション・サーバ内のビジネス・トランザクション処理に影響を与えることはない。障害回復後、デプロイメント・マネージャ、ノード・エージェントを起動すれば、再び管理作業を開始することができるのだ。一方、アプリケーション・サーバに障害が発生しプロセスがダウンした場合、自動的にノード・エージェントがそのアプリケーション・サーバを再起動する。ノード・エージェントは、ノード内の全アプリケーション・サーバ・プロセスを常時監視しているのだ。
| 可用性を高めるためのWorkload Management |
従来のWASのWorkload Management（以下WLM）は、ワークロード・バランス、ハイ・アベイラビリティの実現という2つの役割を担ってきた。WAS V5でも引き続きそれらの役割を実現するため3つのレベルのWLMを提供している（図2）。WAS V5におけるWLMの特徴は、Weighted Routingのサポート、プライマリ／バックアップ・サーバ（クラスタ）のサポート、WebSphere Edge Serverの同梱（WAS ND以上）、そしてMemory to memoryのセッション・パーシスタンス機能のサポートだ。
 |
|
図2 可用性を高めるためのワークロード・バランス機能 |
WAS V4までのHTTPサーバ・プラグインWLM（以下WebコンテナWLM）とEJBリクエストWLM（EJB WLM）は、ラウンドロビンないしはランダムといった単純なルーティング・ポリシーに基づいてリクエストをディスパッチしていた。確かに、同等の処理能力を持つクラスタ・サーバ間のワークロードを平準化するには、このような単純なルーティング・ポリシーでも問題はない。しかしクラスタ・サーバ間に処理能力のばらつきがある場合、必ずしも最適なワークロード・バランスを図ることはできない。このような処理能力の異なるメンバーによって構成されるクラスタに最適なルーティングを提供するのが、新たなルーティング・ポリシー「Weighted Routing」である。Weighted Routingは、あらかじめ定義しておいたクラスタ・メンバーごとの重みの比率に基づいて、リクエストをディスパッチしてくれるポリシーで、処理能力の高いクラスタに大きな重みを、逆に処理能力の低いクラスタには小さく設定することで、最適なワークロード・バランシングを実現する。Weighted Routingは、オートノミック・コンピューティングを構成する重要な要素の1つ、自己最適化実現への第一歩といるだろう。
Weighted Routingがワークロード・バランスの最適化を進める機能であるのに対し、ハイ・アベイラビリティ機能をより強化するのがWebコンテナWLMとEJB WLMに対するプライマリ／バックアップ・サーバ（クラスタ）・サポートだ。この機能によって、通常ビジネス・トランザクションを処理するアプリケーション・サーバ群をプライマリ・サーバ（クラスタ）として定義すると同時に、障害発生時のみビジネス・トランザクションを処理するアプリケーション・サーバ群をバックアップ・サーバ（クラスタ）として定義することができる。こうしておけば、仮にプライマリ・サーバ（クラスタ）として定義された全クラスタ・メンバーが障害で応答できなくなった場合でも、引き続きバックアップ・サーバ（クラスタ）がビジネス・トランザクションの処理を受け付けることができるので、ユーザーには障害を意識させないで済む。クラスタとプライマリ／バックアップ・サーバ（クラスタ）を組み合わせることで、いわば2重のバックアップ処理体制を用意することができるのだ。
Webサーバへのワークロード・バランシングはWebSphere Edge ServerのNetwork Dispatcherで実現してきたが、WAS V5ではWAS ND以上のパッケージにEdge Serverが同梱される（ただしライセンス形態が複雑なので事前に日本アイ・ビー・エムに確認のこと）。また、クラスタにおけるHttpSessionオブジェクトの受け渡しに、従来のDBを経由する方法に加えて、JVM間（クラスタ・メンバーのアプリケーション・サーバ間）のプロセス間通信による方法 ― memory to memory ― が追加された。要件に応じて柔軟にセッション・パーシスタンスの方法を選択できるようになったといえる。
| 強化されたパフォーマンス最適化機能 |
WAS V5のパフォーマンス機能は大き2つに大別できる。1つはパフォーマンス最適化、つまりパフォーマンスを向上させるための技術／機能、そしてパフォーマンス・モニタリング機能だ。
パフォーマンス最適化機能としては、WAS V4から引き続いてダイナミック・キャッシングを継承、強化している（図3）。WASの外側（Edge）、プレゼンテーション・ロジック、ビジネス・ロジックの3階層に加え、コマンド・パターンの処理を対象に、一度生成したダイナミック・コンテンツを再利用することでパフォーマンスを向上させるのがダイナミック・キャッシングである。既存のコンテンツを即座に返答するためレスポンスが向上するうえに、システムに無駄な負荷をかけないので処理能力の最適化にも役立つソリューションだ。
 |
| 図3 システムの各層においてキャッシュ機能でパフォーマンスを最適化 |
また、2フェイズ・コミット時のトランザクションのパフォーマンス・アップが図られている。従来トランザクション・ログは複数のアプリケーション・サーバで共有されていたのだが、V5ではアプリケーション・サーバ単位でトランザクション・ログを持つよう改良し、トランザクションの並行稼働性を向上させたのだ。大規模基幹システムを構築するうえで重要な機能改善といえる。
一方パフォーマンス・モニタリングとしては、Technology Preview（評価機能）としてではあるがパフォーマンス・アドバイザ機能が提供される。パフォーマンス・アドバイザとは、実行時のパフォーマンス計測データを分析し、チューニングを要するパラメータなどパフォーマンス・チューニングのアドバイスを通知するためのエンジンだ。オートノミック・コンピューティングの構成要素の1つである自己修復には、障害を発見／診断／防止することが求められる。パフォーマンスという観点から最適な環境をアドバイスするパフォーマンス・アドバイザは、自己最適化、自己修復という観点よりオートノミック・コンピューティングへの第一歩として期待できる機能といえよう。一部パフォーマンス・アドバイザ機能を含む形で、パフォーマンス・データを監視するための機能がTivoli Performance Viewerである。
ところで、大規模システムを構築する際、しばしばカスタム・メイドのパフォーマンス・モニタの開発を求められる場合がある。パフォーマンス・データのしきい値をトリガに何らかのトランザクションを起動したい、といった要件にはやはり作り込みのソリューションで対応せざるを得ない。そのような場合に役立つのがPerformance Monitoring Infrastructure（PMI）である。PMIはパフォーマンス・データを収集するクライアント・サーバ・アプリケーション開発のためのツール・キットで、パフォーマンス・データ収集のためのサーバAPI、パフォーマンス・データをサーバから取得するためのクライアントAPIを提供している。PMIを使えば、分散コンピューティング環境に対応するカスタム・メイドのパフォーマンス・モニタリング・ソリューションを自由に開発することができるのだ。
| システム管理機能 |
WAS V5は、管理コンソール、管理ツール（コマンド・インターフェイス、以下Wsadmin）、API、という3種類のシステム管理インターフェイスを提供している。WsadminはWAS V4のWSCP、XMLConfigを置き換えるもので、サービス・イン後の運用の自動化を支えるコマンド・ラインのインターフェイスである。一方、WAS V5ではシステム管理機能の実装にJMX 1.0が用いられており、同時にMbeanインターフェイスが公開されている（図4）。これらのMbeanを活用してカスタム・メイドのシステム管理アプリケーションを開発することも可能だ。
|
|
|
||||||
[関連記事]
- [製品紹介]BEA WebLogic Server 7.0
「Webサービスの統合／相互運用性を強化」
- [製品紹介]iPlanet Application Server 6.5
「Sun ONEの基盤を提供するAPサーバ」
- [製品紹介]Oracle9i Application Server
「キャッシュ技術によるパフォーマンスの実現」
- [製品紹介]日立製作所 Cosminexus Version 4
「業界標準の技術で構成」
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
