座談会：J2EEミッションクリティカル時代の 課題とは？ 〜Webシステムパフォーマンスを 　　　　　　　　　　　　　　 最大化する開発から運用まで〜

この座談会で浮き彫りになった課題を 克服する方法とは？ その答えはこちらのセミナーで！ ◆　セミナー詳細ページへ ◆ 開催概要 開催日： 2003年6月25日 13:00〜17:30 会場： サンブリッジセミナールーム（渋谷マークシティウェスト17F） 主催： 日本ヒューレット・パッカード株式会社、株式会社アットマーク・アイティ 協賛： 株式会社アイアイジェイテクノロジー、沖電気工業株式会社、エンピレックス株式会社、ボーランド株式会社 参加費： 無料

　J2EEベースのオープンシステムでミッションクリティカルなシステムを構築する案件が増えてきた。しかし、導入が進むにつれて従来のやり方の限界が見えてきた。

　開発者や運用者は、いまどのような点に問題を感じているのか？ その問題の原因とはいかなるものか？ ベンダはそうした声に対応し得るのか？

　そこで、ベンダ、開発に携わるソリューションベンダ、運用者と、立場の異なる6つの企業の担当者が集結し、IT業界が克服すべき課題について議論を交わした。

日本ヒューレット・パッカード　ソフトウェア統括本部 ソフトウェア・マーケティング部 武内烈氏

武内　OpenViewは、運用対象がJ2EEなど、オープン・インフラストラクチャのミッションクリティカルなシステムであり、変化への対応力が求められるようになったのが最近の傾向だと感じています。

木村　運用の現場では、変化やスピードが求められるのはもちろん、基本的なところが整理されていないことに困っています。最近は少なくなってきましたが、OpenViewでさえ引っ掛けられない形式でログを流してしまったり。落ちやすくて、1カ月間すらちゃんと動かないといったケースも結構ありました。

　また、他社が作ったシステムですが、ユーザーから「調子が悪いから来てくれ」といわれるケースもあります。アプリケーションの深い部分は、監視しないと原因が特定できない場合があります。しかし、監視すべきポイントはアプリケーションベンダでなければ分からない。こうした経験から、アプリケーション開発会社と運用者の距離を近くすることは非常に重要だと思います。

粟津　弊社では、運用管理の重要性を特に強調しています。運用管理というと後付けで行うもの、というイメージが強いのですが、初期段階から「監視はどの程度必要か、そのためのインフラをどうするか」など、ある程度、運用を想定して開発することが重要だと認識しています。弊社がアプリケーション開発を手掛ける関連会社と連携してシステムを構築する場合、ユーザーの運用体制を考慮して、ログの出し方などの監視項目を取り決めています。

　「システム発注」「アプリケーション開発」「運用管理」を違う企業が担当している場合、それぞれの連携がとれていないケースが多くみられます。例えば、システムが問題なく稼働していれば、運用管理もうまくいっているように見えますが、いざシステムに障害がおきて初めて、システムの動作特性を考慮した運用管理がされていないことに気づく、といったようなケースです。

ボーランド 営業本部 マーケティング部 部長 藤井等氏

藤井　ボーランドでは、開発会社からの問い合わせが最も多いのですが、運用を行っている会社からの問い合わせもあります。その場合で悲劇的なのは、運用を行っている会社はアプリケーションサーバの状態がまったく分からず、「サポートだけしてくれ」というケースです。これでは、誰も何ともしようがない。

佐々木　J2EEが出始めたころは、初歩的な面でのプロフェッショナルサービスへのニーズが高かったのですが、最近は個別のニーズを満足するためのチューニングに関する問い合わせが増えています。ミッションクリティカル分野でシステムが動くと、「予期しない事態」も発生します。システムが複雑になるほど、システム全体のチューニングが重要になります。

武内　J2EEの「もろ刃の刃」といえるところだと思います。J2EEはメインフレームやクライアント／サーバの短所長所を克服することを考慮して作られ、複雑なミッションクリティカルシステムにも適用できます。

　しかし、複雑であるが故に、開発を担当する業者と運用を担当する業者が密な連絡を取り合わなければならない場面も出てきました。そして、開発段階から運用を考慮することが絶対に必要になった。開発の段階から運用を考慮し、運用のトポロジとはどういうものかを理解し、どこを疎結合にしてどこを密結合にするかを考えなければならなくなりました。

藤井　自分が作った部分が悪いのか、アプリケーションサーバの問題なのか、分からないという場面が出てきます。しかも、実はフレームワークの問題だったということもある。アプリケーションサーバをブラックボックスの状態にしたままにするのではなく、「ここに問題がある」と解明できるように可視化することが必要だと思います。

粟津　開発プロセスの中で、開発を受け持った人が運用する人を意識して開発するのはやはり難しいですね。開発する前に、運用、管理をする各人がどのような役割を担っているのかを確認し、運用、管理に最低限必要な仕様を先にしっかり決めておくことが必要です。また、それを他システムでも流用できるように運用管理を共通化することも必要です。これにより、運用管理スキルのばらつきや監視の漏れを未然に防ぐことができます。

アイアイジェイテクノロジー アウトソーシングサービス部 テクニカルコンサルタント 木村真理氏

木村　バグなのにメーカーさんはバグといってくれない場合は、本来の解決とは違う方法で対処するしかありません。

　負荷テストをしても、アプリケーションやデータベースのどの部分で問題が起こっているのか判明しません。データベースの場合、1カ月くらい稼働させないとテストにならないというケースもあります。そうしたノウハウは多くの場合、会社ではなく個人が持っています。社内の人間だったら、「あの製品なら彼に聞いてみよう」と問い合わせると答えが出てくることも多いのです。そういうノウハウは、社外には出しにくいでしょうが、何とかみんなで共有できないものかと思うのですが。

山岡　「開発」「テスト」「運用」という要素を統合的にとらえないと、大規模なシステムになるほどコストが膨らむ傾向にあります。例えば、「10億円で開発するシステム」として請けたのに、実際には15億円かかって赤字になってしまう。むしろ、1000万円くらいの規模のシステムを短期間で開発した方が黒字になる。

　期待するレスポンス時間が得られないと、大手メーカーは無料でハードウェアを入れてしまいます。これでパフォーマンスが上がる場合もありますが、コストが膨らんで赤字になってしまうというわけです。1社ですべて丸抱えというケースでは、そういうことが起こりがちです。

武内　それはベンダ側の責任が大きいと思います。われわれベンダは、「こういうテクノロジを持っています」とアピールしますが、自社製品のアピールにとどまっている。本来は、各社の製品でそれぞれ何ができるか、それらを組み合わせたら何ができるか、そこまで説明して始めて「ソリューション」です。各社の製品を使って、SIerや運用を担当する会社が楽になるためのサポートを行うようにしないと、ITはいつまでたっても使いやすいものにはならないでしょう。

日本BEAシステムズ システム技術部 部長 佐々木政和氏

佐々木　ユーザーさんの典型的なケースは、パラメータがデフォルトのままで、パフォーマンスが出ないというものです。この場合、チューニングだけであっさり全体のパフォーマンスが向上することも少なくありません。もちろん、全体のリソースを最適化することはさらに重要です。最近のバージョンは、複雑なシステムに対応するためにオプションが増えています。ベンダとして、セミナーなどを通じて実践的な情報を伝えるように努力していますが……。

粟津　機能が多すぎて、実際の使い方に即していないという現実もあると思います。現実の開発者は、使い慣れた開発ツールやテストツールを使い続けます。よほどのメリットがない限り、新しい製品には移行しません。むしろ、足りない機能があったら自分で作ってしまうくらいです。

　「これだけ新しい機能がつきましたよ」とアピールしてくれるのもいいのですが、それよりも、もう少し簡単なオペレーションで使え、作業効率があがることの方が具体性があり、使う動機になりますね。

この座談会で浮き彫りになった課題を 克服する方法とは？ その答えはこちらのセミナーで！ ◆　セミナー詳細ページへ　◆ 開催概要 開催日： 2003年6月25日 13:00〜17:30 会場： サンブリッジセミナールーム（渋谷マークシティウェスト17F） 主催： 日本ヒューレット・パッカード株式会社、株式会社アットマーク・アイティ 協賛： 株式会社アイアイジェイテクノロジー、沖電気工業株式会社、エンピレックス株式会社、ボーランド株式会社 参加費： 無料