Loading
|
|
＠IT｜＠IT自分戦略研究所｜QA＠IT｜イベントカレンダー＋ログ |
|
Loading
|
| ＠IT > J2EEミッションクリティカル時代のソリューションセミナー レポート |
 |
企画：アットマーク・アイティ
営業企画局 制作：アットマーク・アイティ 編集局 掲載内容有効期限：2003年8月18日 |
|
|
|
|
6月25日（水）、東京・渋谷で「J2EEミッションクリティカル時代のソリューションセミナー」として「Webシステムパフォーマンスを最大化する開発から運用まで」が開催された（アットマーク・アイティ主催、日本ヒューレット・パッカード共催）。
ミッションクリティカル分野に向けたJ2EE Webシステム開発が本格化してきた現在、パフォーマンス管理の重要性が再確認されている。様々なコンポーネント、技術が複雑に絡んだJ2EEシステムでは、従来型の管理手法は通用しない面が多い。開発、運用の連携による新しい管理手法が求められている。 当日は、J2EEソリューションを提供するツールベンダー、運用管理会社、Sierがそれぞれの立場から、J2EEシステムにおけるパフォーマンス管理の問題点と解決策を披露した。
■ J2EEシステムでは各レイヤの構成要素がボトルネックに J2EE Webシステムの構造は複雑化している。アクセスからプレゼンテーション、アプリケーション、データの各レイヤで構成技術が多様化。それが複雑に絡み合い、J2EEの多階層アーキテクチャ分散処理環境を実現している。日本ヒューレット・パッカードの武内氏は、「J2EEのWebシステムでは、各レイヤで多くのコンポーネント、技術を管理しなければならず、非常に管理が難しい」とした上で、それらの管理に「hp
OpenView」製品群がどのように対応しているかを示した。
そして武内氏は「Webシステムのすべての構成要素がボトルネックとなる可能性がある。特にビジネスロジックに関わるWebアプリケーションサーバがボトルネックになる場合が多い」と分析。ボトルネックの所在を明らかにする「Webトランザクションの可視化が極めて重要」と提案した。 Webトランザクションの可視化では、「hp OpenView」製品が様々なレイヤで活用できる。まずエンド・ツー・エンドのパフォーマンス管理では「hp OpenView internet services」により、ユーザーのアクセス状態をシミュレート、アクティブに監視できる。問題が発生した場合、その所在をJavaのコンポーネントレベルにブレークダウンしていく際に有効なのが「transaction analyzer」である。 次に武内氏は「パフォーマンスが良いということの条件」として、「飽和点における最大同時ユーザー数が多い」「レスポンスタイムが短い」「スループットが高い」の3点を挙げた。同時ユーザー数が増えていくに従ってスループットが高まり、飽和点を過ぎると同時ユーザー数が増えてもスループットは一定。これがパフォーマンスが良いというわけだ。逆に飽和点以降、同時ユーザー数が増えてスループットが下がる場合はパフォーマンスが悪い。「パフォーマンス・チューニングがきちんとされていないと、予想外の同時接続でサービスダウンを招く」（武内氏）と指摘する。 パフォーマンス・チューニングの考え方として、武内氏は「WebサーバからJ2EEサーバ、データベースサーバへの流れ全体を見て、バランスを考慮しなければならない。開発から運用のフェーズをまたがって、最終的なアウトプットを考えるべき」と指摘する。その上でシステムの導入前には、負荷計測で目安となる基礎データの蓄積が重要だとする。導入後、何か問題が発生すれば、その基礎データを付き合わせて対処できるわけだ。 最後に「開発と運用がコラボレーションしながら、設計から開発、テスト、運用の各フェーズで、それぞれがパフォーマンス管理を意識する必要がある」（武内氏）とし、「運用は開発時から始まっていると」指摘して、締めくくった。
■反復開発を重ねリスクを軽減させる このセッションでは、開発の各フェーズで検証すべき問題や開発の側面から見たパフォーマンス問題を取り上げ、ボーランド製品を活用した解決法が示された。 ボーランドの藤井等氏は、様々な部品と技術が絡んだJ2EEアプリケーションの構造を提示。実際のプロジェクトでは、いくつもの不安要素があり、確実にプロジェクトを進めるには「早く適切なタイミングでその不安を1つ1つ取り除いていくしかない」と指摘した。検証作業を先送りにしたまま開発を進めると、リスクが高まるので、従来のようなウォーターフォール型の開発手法では、J2EEアプリケーションの開発は難しい。問題を段階的に検証できる反復的な開発プロジェクトが必要というわけだ。
続けて、開発の各フェーズで検証すべき問題について言及。「計画・設計段階では、選択したアーキテクチャや技術が有効かどうかを検証する必要があり、プロトタイプによる検証が一般的だ」（藤井氏）と述べた。実装段階に入ると、当然各部品のパフォーマンス問題を検証する必要があるが、「それぞれの部品がしっかりしていても、組み立てるとボトルネックが発生する可能性もあり、その特定が必要」（同）と、総合段階での検証も重要になってくる。 次に挙げられたのは、開発側から見たパフォーマンス問題だ。「メモリリークやテンポラリーオブジェクトの使いすぎ、RPC（リモート・プロシージャ・コール）を考慮しないオブジェクトの配置など、様々な要因によりパフォーマンス劣化は起きる」（藤井氏）と語る。膨大な同時アクセスがあるWebアプリケーションでは、わずかなメモリリークでも致命的なシステム障害を招く。藤井氏は、「わずか1行のプログラムミスが障害を招く以上、開発の早期、中期の段階で、開発者がパフォーマンス問題を検証しなければならない」と主張する。 そこでどうすべきか。藤井氏はボーランドの「Optimizeit Suite」のようなツールを用いて効率的に問題解決に取り組むべきだという考えを示した。Optimizeit Suiteを利用すると、本来は隠蔽されたガベージコレクションの実行を視覚的に制御できる。また、「Optimizeit ServerTrace」を利用すれば、J2EEの各コンポーネント、レイヤ間の通信を監視できるので、問題を発見しやすいというメリットもある。デモではJBuilderに統合されたOptimizeit Suiteを使い、Stringオブジェクトの不適切な使い方によって、ガベージコレクションの動作にどのような影響が出るかを示した。また、メモリリーク箇所を特定し、すばやくコードを修正して見せた。 最後に「反復的開発を実行するにはツール群の統合が必要」（藤井氏）とし、ボーランドのJ2EEソリューションを紹介した。「ボーランドは各フェーズを担当する製品間での統合を進めている。例えば、TogetherとJBuilderの連携により、設計フェーズと開発フェーズをシームレスに連携できる」とのことだ。藤井氏はデモを交えて、「JBuilderで」開発したアプリケーションコードの設計を、設計ツール「Together」を使って変更すると、JBuilder側のコードが自動で修正される様子を説明。ボーランド製品が、反復的な開発に適していることを証明した。
■ユーザーの視点でパフォーマンスを評価せよ エンピレックスの山岡英明氏は、システム検証の観点からパフォーマンス問題を取り上げ、ツールの活用法を紹介した。
山岡氏は冒頭、「企業にとってWebは顧客との必要不可欠なインターフェースとなってきた」と述べた。その上で、「Webシステムの性能問題に気付かないのは、ビジネス上大きなリスクになる」と指摘。サービスに不満を持ったユーザーは、競合他社のサイトへ簡単に乗り換えてしまうからだ。そのためWebシステムの性能を管理する場合、「システムが落ちなければ良い」という開発者視点ではなく、利用のしやすさなどユーザー視点が必要だという。 次に山岡氏は、ドラッガーの「測定できなければ管理することはできない」という言葉を引き合いに出し、性能管理には負荷テストが不可欠になると語った。さらに自身が関わった事例を紹介しながら、「数カ月という短期間開発の流れから負荷テストを省く傾向が強まっているが、問題点の修正は、後になればなるほど高くつく」（山岡氏）と指摘した。そのため、ミッションクリティカルなWebシステムでは、運用を想定した同時接続ユーザー数での負荷テストを実施しなければ、運用に入るのはリスクが高いことが分かる。ある調査レポートによると、Webシステム運用に成功した企業の94％は負荷テストを実施し、逆に失敗した企業の60％が実施していないそうだ。 また、「3階層Webシステムのスケラビリティ問題の50％以上はJ2EEが関わるミドル層にある」という調査データも披露。「ミドル層はビジネスロジックとかかわっていることも多く、カットオーバー直前の統合試験時にこの問題を検知しても解決が難しいこともある。このため、スケラビリティ問題を発見・対処するには、週単位の余裕しかない統合試験時ではなく、月単位の時間があるコンポーネント開発・テスト期間から実施するべきだ」と述べた。 実際のWebシステムでボトルネックとなるポイントもいくつか上げられた。例えば、アプリケーションサーバのCPU使用率が高く、動的ページの対応が遅い場合は、プログラムコードの非効率性に問題がある典型例だという。こうした問題を確実に洗い出すために、コンポーネントテストとボリュームテスト、性能テスト、耐久・限界テストをサイクルで繰り返すことが重要になるわけだ。 エンピレックスは負荷テストツール「e-Load」をはじめとしたツール製品で、こうしたサイクル型の総合テストソリューションを提供している。特にe-Loadは、同時接続数400人分の負荷テスト環境をPC1台〜数台で構築できるなど、効率良く負荷テストを実施できる点が特徴だ。後半、山岡氏はデモを交えてE-Loadの機能を紹介、使いやすさと多機能性をアピールした。 「最適化手順を探る！」
■効率的にパフォーマンスを改善する3つの方法 沖電気工業の久野氏は、SI企業の立場から、パフォーマンスツールを効果的に利用したJ2EEシステムのパフォーマンス改善とその実際について述べた。 久野氏は「パフォーマンスの観点から言えば、J2EEは様々なポイントがあり、分からない点も多い」とし、ある顧客がWebシステムのパフォーマンスに漠然とした不満を抱えていた際、沖電気がどのような手法で改善したかを紹介した。その手法とは、（1）現行システムの限界を知る、（2）現行システムをどれぐらい最適化できるかを知る、（3）現行システムの“使用状況”を評価する、の3つだ。
（1）の「現行システムの限界を知る」では、エンドユーザーの利用実態に即したサービスの流れをシナリオで定義。ここでシステムの使い方（使われ方）を再認識することが重要となる。なぜなら、「顧客やシステム発注者、システム開発部門、運用部門などシステムに関わるすべての利害関係者の間でシナリオが共有されていないためにパフォーマンス等に関するトラブルが発生することが多い」（久野氏）からだ。その上で、負荷検証ツールを利用して、シナリオごとに仮想ユーザー数を増やし、システム負荷をかけ、TPS（Transaction per Second）がどの時点で頭打ちになるかを見極める。ある時点でCPU能力が限界になれば、アプリケーションの見直や、CPUを追加したりといった選択肢が登場する。逆にCPUに余裕があるのにTPSが頭打ちになるようであれば、システム構造のどこかにボトルネックがあることが分かるわけだ。 （2）の「現行システムをどれぐらい最適化できるか」は、これらのボトルネックを発見、システム機器構成を変えないで改善するものだ。例えば、Webサーバには多くのアクセスがあるのに、J2EEサーバ側にはほとんどアクセスがないためプロファイラ等にて解析した結果、Webサーバの多重処理に問題があったという。結局、ボトルネック処理を日本BEAシステムズのWebアプリケーションサーバ「WebLogic Server」へと移行し、多重度を引き上げてスループットを2.5倍に拡大した。「目標スループットを達成するためには、Webサーバ、J2EEサーバ、DBサーバなど各サーバごとに最適化するだけではなく、システムとして全体最適化を目標にすることが重要。またボトルネックの部位を特定するために注目すべき『パラメータ』は、使用するプロダクトごとに異なる。これらのパラメータをあらかじめ洗い出しておくことが重要」（久野氏））と指摘する。また、「ボトルネックの解析・原因究明作業は様々なツールの登場のおかげで楽にできるようになってきたが、ボトルネックの部位によっては未だにツールだけで解決できるとは限らない」（同）と現場作業の厳しさものぞかせる。 （3）の現行システムの使用状況評価については、「評価に必要なデータ値を洗い出すことが必要」と指摘する。CPU使用状況やヒープメモリ使用状況など、J2EEサーバでは取得するべき一般的項目を踏まえた上で、一定期間監視した結果をもとに、J2EEサーバのパラメータ設定を見直し、パフォーマンスを改善できる。例えば、ある時間帯にヒープメモリ使用量が極端に跳ね上がっている場合、ヒープメモリを必要以上に確保しなくとも、メモリサイズの動的拡張で改善できる場合もあるという。 久野氏は最後に、「システムの使い方（使われ方）を明確にした上で、3つのアプローチを活用すれば、現行システムの能力を最大限に引き出すことが可能になる。ひいては、お客様のビジネスに沿ったシステムの拡張も実現できる」と述べた。
|
|
