ますます重要となるWebシステムの堅牢性

ますます重要となるWebシステムの堅牢性

Webシステムは、今や企業情報システムにおいて主流のアプリケーション・アーキテクチャーとなりつつある。ここで1つ考慮しておかなければならないのは、信頼性や性能の問題だ。どうすれば信頼性と性能の両者が並び立つのだろうか。

■ Webシステムが主流となりつつある理由

　企業において、Webシステムの存在が重みを増すようになってきた。これはその特性を考えれば理解できる。つまり、Webシステムは企業の情報システム部門に対して、以下に示すような２つのメリットを与えている。

　1つ目はクライアントアプリケーションを配布しなくてすむということ。社員の常駐する拠点が1カ所にまとまっている企業であればそれほど気にならないかもしれないが、拠点がいくつかに分散していると、そのアプリケーションを配布する労力、コスト、時間というのは本当にバカにならない。エンドユーザーのPC操作の習熟度がそれほど高くないケースは意外と多く、結局は情報システム部門で面倒を見なければならないというケースも多々見受けられる。Webシステムであればそのプロセスが一切なくなるのであるから、利点は非常に大きい。

　2つ目はアプリケーションをバージョンアップしやすく、その機能進化を全社で享受しやすくなるという点だ。メンテナンスするのはサーバ上のアプリケーションだけでよく、これに手を入れてアップロードすれば、その瞬間から全社で新機能や改善された機能を利用し始めることができる。事業環境が刻々と変化する現代にあっては、このことは時代にキャッチアップする上において、もはや不可欠の条件といえるかもしれない。

　こうしたことから、企業情報システムの世界では次々とアプリケーションのWebシステム化が進んでいる。クライアント／サーバ型システムがこれに置き換わるだけでなく、従来までならメインフレームでなければ、と考えられてきた種々の基幹業務も、徐々にこのテクノロジー・フィールドに移行されつつある。製造業における受発注管理や生産管理のシステム、金融業における預金管理、証券取引システムなど、例を挙げればきりがない。まさにWebシステムがミッション・クリティカルな業務を担うようになってきたのである。

■ 進化と引き替えに信頼性と性能が低下するようであれば本末転倒

　ただ、ここで、Webシステムへの移行を考える企業が考慮しなければならない大きな問題が1つある。それは、高い信頼性、性能の実現である。メインフレーム上で稼働していたアプリケーションをWebシステムへ移行した場合、移行後にそうした点が少なからず低下してしまった、と告白する情報システム部門の関係者は意外と多い。

　これはある意味で進化を享受するためのトレードオフともいえるのだが、バックグラウンドのことなど関知しないエンドユーザーの目にとっては、単にサービス品質が低下したとしか映らない。それが社内で完結するシステムならまだしも、顧客や取引先が利用するシステムであったりすれば、企業そのものへの信頼が損なわれてしまう。Webシステムが基幹業務を担うようになった現在、メインフレームクラスの性能や信頼性が要求されるのではないだろうか。

　「そうはいっても、そもそもメインフレームとオープンシステムの性能を同列で語ることに無理がある」と反論される読者もあることだろう。それは確かにそうかもしれない。だが、信頼性や性能における両者の差を埋める取り組みもいろいろな形でなされていることも事実だ。

　例えば、複数のサーバを用意し負荷分散装置を用いて、ハードウェア的にレベルを上げるというのもその1つだ。しかし、これはめざすレベルの分だけハードウェアを用意せねばならず、どうしてもコストがかかってしまう。一方、ソフトウェアでこの問題を解決した例もある。具体的には、Webアプリケーションサーバというミドルウェア層での仕掛けだ。

■ 基幹業務システムに求められる信頼性、性能を有するWebアプリケーションサーバ

　企業において求められるメインフレームクラスの処理品質を熟知している富士通では、同社のWebアプリケーションサーバ「Interstage Application Server」に対して、信頼性、性能を向上させるエンハンス機能を数多く盛り込んでいる。その1つが、J2EEアプリケーション実行環境であるJavaVMへのエンハンスである。

　JavaVMに関しては、多くのソフトウェアベンダーはサン・マイクロシステムズ社のサイトからダウンロードしてそのまま利用している。しかし、富士通は、メインフレームクラスの性能の実現や基幹業務処理の実行の更なる安定化のため、サン・マイクロシステムズとのライセンス契約のもと、JavaVMのソース公開を受け、チューニングを行っているのである。しかし、これは決してJavaVMそのものに改変を加えているわけではない。あくまでVM内における詳細制御部分でのエンハンスである。

　その例をいくつかあげてみよう。1つ目は、メモリ管理がある。Javaというプラットフォームの特徴にガベージコレクション［注］があるが、これを標準機能のまま利用すると、定期的にフルガベージコレクションが発生してしまう。これが起きるとJavaの制御が止まってしまい、レスポンスが大きく低下してしまう。そのため「Interstage Application Server」では、随時細かなガベージコレクション（マイナーガベージコレクション）を発生させることでフルガベージコレクションを発生させないようにチューニングを行い、システム全体に影響を与えるのを防いでいるのである。これにより、標準のJavaVMと比べ、信頼性や性能に優れている。

［注：ガベージコレクション］　OSのメモリ管理機能の1つ。プログラムが使用しなくなったメモリ領域や、プログラム間の隙間のメモリ領域を集めて解放すること。これにより、連続した利用可能なメモリ領域を増やすことができる。

　2つ目は、予兆の監視や警告。アプリケーションの実行中に何か通常と違う事態が発生したらアラートを発信する。この予兆監視機能により、24時間365日の業務継続が実現できる。なお、これもJavaVMのチューニングの中で行っていることである。3つ目はチューニングツールである。Javaではアプリケーション異常が発生した際に問題の特定が難しい。そこでクラスをトレースしたり、デバッグ情報を出すといったトラブルシューティング機能を付加するとともに、ボトルネック早期検出のためのチューニングツールの提供も行っている。

■ アプリケーションのみを多重化し、処理性能を最大化

　JavaVMを多重化し、複数のアプリケーションを搭載することで処理性能を稼ごうというものであり、マルチコンテナというアーキテクチャーで実現する。これは「Interstage Application Server」の高信頼、高性能を実現するための大きな特長である。

　マルチコンテナはマルチスレッドとは根本的に違う。マルチスレッドは1つのJavaVMの中に、マシン制御やアプリケーションなどすべてを実装するために、これを多重にしていくと、VM内での排他制御でいろいろと問題が起きやすい。一方、マルチコンテナは図1にあるように、マシン制御の部分を外に出し、アプリケーションのみ多重化する。これによりJavaVM単体で動かすよりも処理性能をリニアに上げられるという利点がある。


図1 マシン制御の部分を外に出し、アプリケーションのみ多重化する

　マルチコンテナの大きな効用がもう1つある。それは障害発生時の問題の局所化だ。ある業務を複数のJavaVMに多重化して動かすケースを想定していただきたい。JavaVMが1つであった場合は、そこで何らかのトラブルが発生すると、業務全体が中断してしまう。しかし、複数のJavaVMで多重化していれば、JavaVMの1つに何かが起こったとしても業務の継続が可能である。また、異常が発生したJavaVMについても「Interstage Application Server」ではこれをちゃんと監視しており、そのJavaVMに対して自動的に再起動をかけ、稼働を回復させることができるのである（図2）。


図2 JavaVMの1つに何かが起こったとしても業務の継続が可能

■ 落ちない、止まらないメインフレーム級のWebシステム構築を実現

　JavaVMに対する配慮の行き届いたエンハンスも、マルチコンテナという画期的なアーキテクチャーの開発も、長らくメインフレームの開発を手がけ、お客様のシステム運用で発生した数々の要件に応え、基幹業務処理における企業が求める信頼性、性能要求の高さを熟知する富士通ならではの工夫といえる。単純に性能を上げるだけでいいのならいくらでも方法はあるが、ソフトウェアでの対応は費用対効果の高さという面で大きなメリットがある。それがWebシステムにおいてまさに中核エンジンといえるWebアプリケーションサーバで行えるならなおさらだ。加えて、現在のWebアプリケーションサーバは、かつてのメインフレームが誇った長期的な稼働時間の保証も求められている（「業務アプリを10年連続稼働させるカギはミドルウェア技術とサポート力」）。業務アプリケーションのWebシステム化を検討するすべての企業に、いま一度、高い信頼性および性能の実現という観点からの製品選びを勧めたいと思う。