Jump to content 日本-日本語
日本HPホーム 製品 & サービス サポート & ドライバー ソリューション ご購入方法
≫  お問い合わせ

製品とサービス  >  ソフトウェアとOS  >  HP- UX Developer Edge

「ミッションクリティカルJava」の真意とは

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
「ミッションクリティカルJava」の真意とは
Javaの爆発的な普及の原動力となったのが、CやC++とは一線を画すJava Virtual Machine(JVM)のアーキテクチャである。しかしミッションクリティカル環境では、「パッチが提供されない」「サポート期間が短い」というJVMの欠点が逆に「アキレス腱」となることもある。そこでHPでは、これらの問題点を解消する「MC Javaサポートソリューション」の提供を今年5月から開始した。これは、JVMに対してSLA(サービス品質保証制度:サービスの可用性、故障回復時間、障害通知など)ベースの長期サポートと個別障害に対するパッチ提供を実施するという業界初の試みである。同ソリューションが示す「ミッションクリティカルJava(以下、MC Java)」の真意とは何かを明らかにする。
「ミッションクリティカルJava」の真意とは
Javaはミッションクリティカル環境のアキレス腱?
HPの新提案「MC Javaサポートソリューション」とは
2005年6月
テクニカルライター  吉川和巳

Javaはミッションクリティカル環境のアキレス腱?

サン・マイクロシステムズによって1995年に発表されたJava言語は、その後の10年間で爆発的な勢いで普及し、いまや多くのITシステムの根幹を支える存在となった。こうした広がりの原動力のひとつが、CやC++とは一線を画すJava Virtual Machine(JVM)のアーキテクチャである。JVMとは、Java仕様で規定されている仮想的なスタックマシンであり、すべてのJavaアプリケーションはこのJVM用のバイナリコード(クラスファイル)にコンパイルされる。一方、サンやIBM、HPなどのベンダー各社は、WindowsやLinux、HP-UXなどの個々のOSやハードウェア上で動作するJVMとクラスライブラリを提供している。よって、同一のJavaアプリケーションを多種多様なプラットフォーム上でそのまま動作させることが可能だ。もちろん現実にはプラットフォーム間のふるまいの微妙な違いなどもあるが、特定のOSのAPIに依存するアプリケーションと比べれば、Javaアプリケーションのポータビリティーの高さは抜群だ。

しかしミッションクリティカル環境では、Java固有のアドバンテージの源泉であるJVMが、逆に「アキレス腱」となることもある。それは、「JVMにはパッチが提供されない」「JVMのサポート期間が短い」という点だ(図1)。
 
ミッションクリティカル環境でのJavaの問題点
図1:ミッションクリティカル環境でのJavaの問題点

JVMには「パッチ」が出ない

例えばOSにバグがある場合、OSベンダーはすぐさまパッチを公開するのが通例である。Windowsであれば、「Windows Update」を通じて随時パッチを入手してインストールできる。UNIXの場合も、個々の細かなバグについて、ベンダー各社からタイムリーにパッチを入手できる。よって、アプリケーションの修正では対処できないOS側の問題も、適切なパッチさえ当てればすぐに解決可能だ。また例えばHPでは、ミッションクリティカル向けサポート契約を結ぶHP-UXユーザに対し、SLAベースのミッションクリティカルサービスを提供している。これは、HP-UXにバグが発見されたとき、2週間以内のパッチ提供を保証するものだ。よってシステム担当者は、ユーザに対して「いついつまでに問題を修正できます」と回答できる。

しかしJVMのバグについては事情が異なる。例えばサンでは、同社が無償公開しているJVMについて、個々のバグを修正するためのパッチを提供していない。その代わりに、JVMのバグレポートを集めた「Bug Database」を一般公開しており、そこで多くの投票数を集めたバグから優先的に修正し、数ヶ月に1回のマイナーバージョンアップ時に反映させる。個々のバグは、運がよければ次回バージョンアップで修正されるが、再現性の低いバグや日本語環境に固有のバグなどは投票数が集まりにくく、修正までに時間がかかる可能性もある。そのためシステム担当者は、JVMのバグがアプリケーション運用に深刻な影響を与えているような状況でも、それがいつまでに解消されるのかユーザに明確な時期含めた返答ができないのである。

バージョンアップによるバグフィクスの弊害は他にもある。それは、バージョンアップのたびにJavaアプリケーションのテストを繰り返さなくてはならないことだ。JVMのバージョンアップでは数10個のバグが一斉にフィクスされ、時には機能追加や仕様変更も実施される。例えばサンが昨年9月に公開した「J2SE 5.0」では、今年5月の「J2SE 5.0 Update 3」までに3回のマイナー・バージョンアップが実施され、合計で270件以上のバグがフィクスされている。これだけ大量の修正が施されれば、特にミッションクリティカル環境ではアプリケーションの回帰テストを実施せざるを得ず、OSのバージョンアップに匹敵する検証作業が必要となる。また、もし1回のバージョンアップで懸案のバグがすべて解消されなければ、数か月後にはもう一度バージョンアップしなければならない。個別のパッチさえ提供されれば、こうした繁雑さは回避できるだろう。

サポート期間が短い

ミッションクリティカル環境におけるJVMのもう一つの問題点は、サポート期間の短さである。ミッションクリティカル・システムは、一度カットオーバーしたら数年間は大きなバージョンアップせずに継続運用することも少なくない。そのため、ミッションクリティカル向けのOSやアプリケーション・サーバでは長期サポートの提供が一般的である。例えばHP-UXでは10年間、BEA のWebLogic環境では約5〜7年間のサポートが利用可能だ。これに対し、特定バージョンのJVMのサポート期間は、ISV検証にかかる時間を除くと実質3〜3.5年程度。その後はシステムのバージョンアップを余儀なくされるのが実情だ。

このように、ミッションクリティカル環境におけるJava導入には、実のところ「死角」があったと言わざるを得ない。そこで続いては、これらの問題点を解消し、ミッションクリティカル環境でのスムーズなJVM運用を実現するHPのソリューションに注目してみよう。
トップへ   次のページへ

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項 ウェブマスターに連絡