ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. ソフトウェア
  3. WebOTX
  4. アプリケーションサーバ
  5. 特長/機能
  6. バージョン別機能強化ポイント
  7. V6.3
ここから本文です。

WebOTX Application Server - V6.3機能強化ポイント

「バージョン別機能強化ポイント」へ戻る

2005年11月30日にWebOTX V6.3の出荷を開始いたしましたが、2006年3月末にV6.31として機能拡張を行っています。それに伴い主なものについて記述を追加しました。

WebOTX V6.3で強化した内容について

サービス実行性能の大幅な向上 Ver6.31で拡張

メインフレーム連携機能強化による既存資産活用

信頼性・可用性向上によるサービスレベルの向上 Ver6.31で拡張

サービス実行基盤の運用管理強化


WebOTX V6.2情報についてもご参照ください。バージョン6での機能強化内容が把握できるようになっています。

WebOTX V6.3で強化した内容について

2005年4月に出荷したバージョン6.2では、高信頼モデルの『要』である実行基盤を見直し「ビジネスを止めない」を実現するサービス基盤としての強化を中心に行いました。今回のバージョン6.3では、さらなる信頼性・可用性の向上はもちろんのこと、課題であった運用管理部分の強化を行っています。

また、Webアプリケーションが動くWebコンテナや、SOA実現のベースとなる技術として注目されているWebサービス部分の性能向上も行っています。

さらに2006年3月に公開した、バージョン6.31では、大規模向けプラットフォームの拡大に加え、サービス起動時間の性能を大幅に改善しています。

WebOTX V6.3の強化ポイント

青字の部分がVer6.31で強化したところ

そのほかにもバージョン6.3では数多くの強化を行っています。ここでは追加された主な機能や特長を簡単にご紹介いたします。

サービス実行性能の大幅な向上

バージョン6.3を開発するにあたり、WebOTXの各モジュール、および通信の基盤となる部分について基本性能の向上対策を行ってきました。その中でも特に、Webアプリケーションが動くWebコンテナや、課題の多かったEJBコンポーネントの配備処理部分、およびWebサービスアプリケーションの処理部分、およびサービス起動時間の短縮については大きな成果を出すことができました。

APサーバ起動時間の性能向上(Ver6.31で強化)

APサーバに求められる機能が、ますます高機能、多機能化される一方、多くのサービスを統合してきた結果、WebOTXの起動時間が長くなり運用や開発作業面で課題となっていました。

バージョン6.31ではそれらの課題に対して、WebOTXの各サービスや基盤部分の細部に渡り性能改善を図りました。V6.3とV6.31とでWebOTXの起動時間を比較した結果では、30%~37%(*1)の性能向上を実現しています。

下図はV6.3とV6.31 の起動時間について各エディション別に比較したものです。WebOTXの起動時間は、WebOTX管理サービス(*2) 、WebOTXの本体である AP実行基盤部分、ユーザアプリケーションのロード時間に大別して表現しています。

V6.3とV6.31 の起動時間比較

  • (*1)WebOTX管理サービスとは、Windowsの場合サービスマネージャ、Unixの場合起動スクリプトに該当
  • (*2)ユーザAPのロード時間は、ユーザAPにより変動するため、デフォルトインストールの性能比較

Webサービスメッセージ処理部分の性能向上

Webサービスを使用する際に避けて通れないのがXMLデータの解析です。XMLデータ解析速度がWebサービスを利用したシステム全体の稼動性能に大きく影響を及ぼすのは言うまでもありません。

Webサービスエンジンの性能比較

バージョン6.3のWebサービスエンジン部分では、このようなXMLデータの読み書き、および解析処理を行う部分の構成を根本から一新し、大幅な性能向上を実現しました。

右の図は簡単なテストプログラムをそれぞれで動作させた場合の秒間処理件数ですが、他社商用アプリケーションサーバやオープンソースの処理性能を上回る世界最高レベルの性能を実現できています。

最近「SOA」という言葉をよく耳にするようになりました。SOA実現のための共通する目標として、「企業内外に散在した新旧サービスをいかに柔軟に、いかに効率よく統合していくか」といったことがあげられます。そういった複数のサービスを「つなぐ」ために使うものとして「Webサービス」が注目されており、今後利用される局面が増えていくと考えられます。

NECが提唱するSOAでは、サービス連携のための基盤としてビジネスプロセス統合基盤製品である「BizEngine」をお薦めしています。

Webアプリケーション処理部分の性能向上

J2EEシステムにおいて、Webアプリケーションである「サーブレットやJSP」は既に欠かせないものであり、高い採用率、かつ多くの採用実績を誇る技術であることは周知の事実です。

WebOTXでは、Webアプリケーションの実行基盤として「Webコンテナ」を提供していますが、バージョン6.3で構成や処理部分全体の見直しを実施し、性能向上を実現しました。

下図は、Tomcat5.0.28とWebOTX Web Edition V6.3を動作させ、Servletでデータサイズ分のHTMLを動的に生成したときの単位時間あたりの処理リクエスト数を測定しています。Servletで生成するHTMLのサイズによっては20%以上の性能向上を実現しており、Tomcatを上回っています。

WebコンテナとTomcatの性能比較

例えば大規模なWebシステムの場合、Webアプリケーションが動作するWebサーバマシンは複数台用意され、ロードバランサによる負荷分散の構成をとる事例が多く見られます。

実際に必要なWebサーバマシンの台数を見積もる際に、Webコンテナの処理性能値も重要なファクタとして検証されることになりますが、高い処理能力を持つWebOTXのWebコンテナの採用はコストの面でも優位と言えます。

EJBコンポーネント配備時間の大幅な短縮

J2EEに準拠したアプリケーションサーバで動作させるWebアプリケーションやEJBコンポーネントを作成した際、実際にアプリケーションサーバ上で動かすためには、「配備」という作業を行います。配備の延長でサーバ上の決まった場所に決まった形式で関連するファイルを配置し、アプリケーションサーバが管理できるようにします。

ただ、これまでEJBコンポーネントをサーバに配備する過程では、EJBの通信処理部分のスタブ・スケルトンコードを自動的に生成していました。EJBコンポーネントで実装しているリモート・インタフェースが増えるとこの生成処理に時間がかかり、配備が完了するまで長い待ち時間が生じるという不満が多く出ていました。

バージョン6.3では、EJBの通信基盤として使われる「RMI-IIOP」部分で、「ダイナミック・プロキシ」という技術を採用しており、スタブ・スケルトンを使わなくても通信ができるようにしました。これによって、EJBコンポーネントの配備時間が大きく短縮されます。例えば、Sunが公開するJ2EE BluePrintsと呼ばれるデモ・アプリケーションの中で、全てのEJBがリモート・インタフェースで構成される「Pet Store Demo 1.1.2」の配備時間は、従来の1/3に短縮されています。

ダイナミック・プロキシ採用により配備時間が70%短縮

実際にEJBが動作するシステムを構築しているお客様の多くが、たくさんの機能をひとまとめにした巨大な1つのEJBコンポーネントを作成し、それをサーバに配備するという運用を行っています。このようなケースでは配備に時間がかかり、円滑なシステム運用とは程遠くなってしまいます。そういう面で今回のような機能強化は必要不可欠であると言えます。

メインフレーム連携機能強化による既存資産活用

オープンシステムへの移行が本格化して久しいですが、コスト面や工数面など数々の要因でメインフレームを利用したいわゆる「レガシーシステム」を使用し続ける企業が数多く存在するのも事実です。

中でも、既存の業務はメインフレームをそのまま使用し、新規に機能追加していく部分はオープンシステムを使用していく、いわゆる「リフロント」形態を採用する事例も増えています。

それに伴って、既存システム上のデータと新規システム上のデータの同時更新を行いたいと言う要件も増えてきており、バージョン6.3では次のような機能拡張を行いました。

ACOS上トランザクションの2フェーズコミット参加

WebOTXでは、ネットワーク上に分散された複数データベースの同時更新を安全に行うための「2フェーズコミットメント機能」をサポートした、「トランザクションサービス」を提供しています。

しかし従来のトランザクションサービスでは、例えばACOS上で動作するトランザクションのように、2フェーズコミットメントに対応していないものを複数データベースを同時更新するトランザクションに参加させることができませんでした。

バージョン6.3ではそれを改善しています。

ACOS-DBとオープンDBの同時更新

上図の例のように、ACOSとオープンサーバのリアルタイム連携を実現するためのランタイムライブラリ「ACOS Access Toolkit」が提供するJDBCドライバと連携することで、ACOS上のデータベースと、オープンサーバ上で動作する、Oracleなどのデータベースとの同時更新が可能になります。

信頼性・可用性向上によるサービスレベルの向上

バージョン6.3では、WebOTXの『ウリ』である高信頼を保証するための機能をさらに追求し数多くのきめ細かな拡張を行いました。そのうちの主なものをご紹介します。

大規模プラットフォームサポート(Ver6.31で強化)

64bit対応アプリケーションへの期待が高まっており、各種プラットフォームで64bitOSがリリースされています。

64bit対応は、パフォーマンスとスケーラビリティの増大という効果をもたらし、大規模なアプリケーションを稼動させる場合には、その効果が大きいとされています。

WebOTXは2003年から64bitに対応しており、今回のバージョンではHP/Windowsに加えてLinuxもIntel Itanium対応をしています。またWindowsプラットフォームでは、Windows2003 R2対応をx86に加えてx64にも対応し、大規模システム構築に必要とされる64bitインフラをさらに強化しています。

対応プラットフォーム拡大

自律運用支援機能の強化

現状のWebOTXでは、トランザクション管理に関する機能の多さもあり、設定する項目が多岐にわたります。中でも、同時に実行可能なオペレーションの数や1つの処理における実行時間上限タイマ値などシステム稼動性能に大きな影響を及ぼす設定要素が複雑に絡まるため、オペレータによるチューニング作業が難解なものになっていました。

そのためバージョン6.3では、サーバアプリケーションでのオペレーションの実行状況やキューへの処理要求の滞留状況を監視して、計算では求めづらい上記のような項目の設定適正値を算出し、推奨値として提示します。また提示した設定を自動的にシステムに動的に反映することもできるようになっており、システムの自律運用を支援します。さらに、CPU時間や実行時間の監視による、CPUループ検出やスローダウン障害検出を行います。

AP実行状況監視機能の強化

これらの強化により、設定の最適化支援、障害の事前回避を実現できます。オペレータにとってわずらわしかった作業の軽減にもつながります。

非同期メッセージ再配信機能の強化

企業内外のシステム連携の際に、メッセージング処理機構を使用した非同期通信は非常に有効な手段となります。WebOTXでもJ2EEのJMS(Java Message Service)仕様に準拠した非同期メッセージ配信機能を提供しています。バージョン6.3では信頼性向上のための機能強化として次のことを行っています。

  • 再配信の遅延と回数制限(ポイズン メッセージ対応)
  • 破棄メッセージの転送機能(バックアウト用キューへの格納)
  • クライアントからのサーバ監視

非同期メッセージ再配信機能の強化

キューイングされたメッセージの配信を実行しようとした場合に、それが失敗してロールバックされるケースがあります。そうなった場合、WebOTXではそのメッセージを元のキューに戻し、一定時間の後に再配信する機能をサポートしていますが、それに加えて、再配信を有限回に制限する機能を追加しています。メッセージを受け取る側の障害によりいつまでたってもメッセージ配信ができない場合、再配信が延々と繰り返し行われるような状況に陥り、システム全体のスループットが低下してしまう事態(ポイズン メッセージ)を未然に防ぐような場合に有効な手段となります。

また、その再配信の回数制限値を超過したメッセージや、有効期限に到達した未配信のメッセージをあらかじめ用意した送信先(バックアウト キュー)に転送することができる機能を追加しました。この送信先からメッセージを取得するプログラムを作成し、ロギングしたり、保持したメッセージから復旧処理を組み込むことが可能になります。

さらにクライアントアプリケーション内部で、メッセージ配信用サーバとの接続を定期的にチェックする機能を追加しています。たとえば、サーバ/クライアント間のケーブルが抜けたり、ネットワークの障害が発生したような場合、メッセージの送信を行わないアプリケーションでは、その異常を検出することができません。これを、クライアント側で、定期的に監視パケットを発行することにより、異常を早期に検出できるようにしました。

負荷分散機能の強化

従来のWebOTXでは、CORBAアプリケーションについて対応していた負荷分散機能をEJBアプリケーションにも適用させました。

EJBのホームインタフェース、ステートレスセッションBeanのリモートインタフェースのオブジェクトリファレンスに複数の接続先情報を含める機能を追加することにより、複数ドメイン間のラウンドロビン負荷分散機能を提供します。

EJBの負荷分散

フェイルオーバーが発生した場合でも正常稼動しているドメインやEJBアプリケーションへ処理を自動的に割り振りを行うようになっているため、障害に対する影響を最小限にすることができます。さらにクライアントアプリケーション側でオブジェクトリファレンスの再取得などの作りこみを行う必要はありません。

サービス実行基盤の運用管理強化

バージョン6で、WebOTXはGUIツールをはじめ、運用管理機構の大幅な変更を実施しました。そのためツールの反応速度の面や操作性の面でいくつか課題があったのも事実です。バージョン6.3ではそれらの課題に対して細かく分析を実施し、数多くの改善を行いました。

また、前述のような自律支援機能の強化に加えて、次に示す機能強化を行っています。

パフォーマンス監視・分析機能の強化

バージョン6.3では、下の図にあるような、EJBに関するデータ(Beanインスタンス数、Bean状態、受信メッセージ数など)や、JDBCデータソースに関するデータ(コネクション数)など、スムーズなシステム運用のために特に欠かせないパフォーマンスに関する情報を新たに採取可能としました。

また、バージョン6.3ではJavaアプリケーションのチューニングを行うためのプロファイリングツールを提供しています。これを使うことによってヒープおよびCPU時間のプロファイリングデータをGUIツールより確認することが可能となります。どこの処理でメモリやCPUを消費しているかなど、ネックとなっている箇所を調査することができます。

パフォーマンス監視・分析の流れ

そのほか、統合運用管理ツールでのパフォーマンスデータ表示部分のインタフェースも改善しており、システム全体の稼動状況を一目で把握することができるようになっています。

Flashベースの運用管理コンソールの提供

WebOTXでは上述したようなGUIベースでの統合運用管理ツールに加えて、Webブラウザベースの統合運用管理コンソールも提供しています。バージョン6.3では、そのWebブラウザベースの統合運用管理コンソールをMacromediaのFlashをベースにして動作させるようにしました。これによって従来のシンクライアントタイプの運用管理コンソールでは実現できていなかったきめ細かな運用操作性を実現しています。

Flashベースの運用管理コンソール

それでは、GUIベースの統合運用管理ツールとはどう違うのか、という疑問をもたれるかと思います。

Webブラウザベースのものは、ファイアウォールを経由したインターネットからの不特定多数からのアクセスも可能としているため、運用ユーザの追加等一部機能を制限していること、GUIベースのものの方が若干操作性はきめ細かなつくりになっていること、などの違いがあります。ただし操作可能な項目についてはほぼ同様のレベルになっています。

改版履歴

ページの先頭へ戻る