>>前編 

[選ぶ]まず製品タイプで絞り警告やレポートの機能を比べる

 製品を選定する場合,現場の担当者は主に三つのポイントに注目している(図1)。まず,(1)エージェントの有無と,(2)実クライアント型か仮想クライアント型かを検討し,4種類の製品タイプのどれかに絞り込む。そのうえで(3)警告やレポートの充実度を比べる。例えば,警告のリアルタイム性や,“誤報”を減らすのに重要なしきい値の設定方法などに,選定担当者は注目している。

図1●ユーザー企業の担当者が重視する三つのポイント
図1●ユーザー企業の担当者が重視する三つのポイント
(1)エージェントの有無,(2)実クライアント型か仮想クライアント型か,(3)警告やレポートの充実度 に注目して製品を選定する現場担当者が多い
[画像のクリックで拡大表示]

 なお,ほとんどの製品は,レスポンス時間以外にも多くの性能指標を計測できる。アプリケーションやデータベースの性能管理ソフトと連携し,ボトルネックを詳細に分析できる製品もある。製品選定に当たっては,レスポンス時間以外に計測したい性能指標があるかどうかも考慮すべきだろう。

「性能を犠牲にしたくない」

 製品選定の具体例を,大手製造業A社の例で見てみよう。A社では,数万人の社員が使用する基幹Webシステムのレスポンス時間を測定するために,Web性能管理ソフトを導入した。

 製品選定では,実クライアント型にこだわった。理由は,Webサーバーに余分な負荷をかけたくなかったからだ。「仮想クライアント型の場合,(疑似リクエストを受け取る)Webサーバーに,本来は不要な負荷がかかる。性能を測定するために性能を犠牲にするのはナンセンスと感じた」(選定担当者)。それに,導入の手間をかけたくないという事情もあった。当時のA社は物理的な拠点数だけで60以上あり,全拠点に仮想クライアントを設置することは難しかったのである。

 前述したように,実クライアント型にはエージェントあり型とエージェントなし型があるが,エージェントあり型を導入すると「エージェントをダウンロードするようアプリケーションを書き換えるのが大変」(A社の選定担当者)。最終的に選択肢として残ったのは,実クライアント型でエージェントを使わない「RTbandwidth」(開発はオーリック・システムズ)だった。

リアルタイム警告に注目

 仮想クライアント型を選択した担当者もいる。ディーシーカードの小林氏は,クレジットカード会員向けWebシステムのレスポンス時間を測定するために,仮想クライアント型のWeb性能管理ソフトを導入した。

 このWebシステムには,毎月数回,「トップページにアクセス→ユーザー認証→利用代金明細を照会→結果を表示」という特定の操作パターンでアクセスが殺到することが分かっていた。そこで小林氏は,この特定の操作パターンを実行したときにかかるトータルの時間を計測したいと考えた。

 特定の操作パターン(シナリオ)でページ遷移したときのトータルの時間を測定しやすいことから,小林氏は候補を仮想クライアント型の製品に絞り込んだ。

 そのうえでリアルタイムの警告機能を搭載する製品を探した。「利用代金明細の照会は3秒以内など,様々な目標値を定めた。目標値を下回ったらすぐにメールで通知する警告機能が必要だった」(小林氏)ためである。最終的に小林氏が選択したのは,管理サーバーで性能情報を受信した直後に警告メールを送信できる「OneSight」(開発は米Empirix)だった。

[使う]蓄積した情報の使い方が肝心開発と運用の双方で生かす

 Web性能管理ソフトは,警告機能を駆使してシステムのサービス品質を維持したり,トレンド分析でキャパシティ計画を効率化したりする用途で使える。しかし導入した担当者の多くは,「計測・収集した情報はもっと多くの用途で活用できるし,そうしないともったいない」(大手製造業A社の選定担当者)と認識している。

 例えばRTbandwidthを導入したA社では,アプリケーションの機能を拡張した後の性能低下を防ぐ目的で性能情報を利用している。RTbandwidthで計測したレスポンス時間やWeb/APサーバーのCPU使用量などを参考に,アプリケーションの機能拡張時の性能目標を設定しているのだ。この性能目標は,運用担当者にもレビューしてもらう。開発終了後にアプリケーションを運用担当者に引き渡すときは,性能目標を達成していなければならないルールも定めている。

 計測・蓄積した性能情報は他のアプリケーションで活用することもできる。システム運用代行サービスを提供するソフトバンク・テクノロジーは,Web性能管理ソフトで収集した性能情報を障害管理ソフトに引き渡す仕組みを作り,性能問題の解決を迅速化することを検討中だ(図2)。従来はシステムごとや顧客ごとにバラバラだったWeb性能管理ソフトを既に「OneSight」に一本化済みで,今後障害管理ソフトと連携させる予定である。

図2●Web性能管理ソフトと障害管理ソフトとの連携
図2●Web性能管理ソフトと障害管理ソフトとの連携
ソフトバンク・テクノロジーは,運用を代行する顧客システムで性能問題が発生した場合に,迅速に解決できる仕組み作りを進めている。第一段階として,従来はバラバラだったWeb性能管理ソフトを「OneSight」に一本化した。第二段階では,障害管理ソフトとの連携を予定する

Webの構成要素ごとに性能を把握する

 性能問題が発生した場合にWeb性能管理ソフトを使えば,大まかに「ネットワーク側の問題か,それともサーバー側の問題か」を切り分けることは可能だ。だが,サーバー側の問題であることを突き止めても,実際には構成要素のどこにどんなボトルネックが潜んでいるかを特定して改善策を打たないと,性能問題は解決しない。

 このようなケースでは,構成要素ごとに性能情報を取得するソフトを使用するとよい(図A)。例えば米CAの「Wily Introscope」は,JVM(Java Virtual Machine)に「プルーブ」と呼ぶ専用ソフトを組み込むことで,Javaのメソッドやクラスの単位で呼び出し時間を測定できる。アプリケーションの変更は,基本的に必要ない。さらに「Introscope SQL Agent」を組み合わせれば,JDBC(Java DataBase Connectivity)経由でデータベースに送るSQL文の実行時間も測定できる。

図A●構成要素ごとに性能情報を取得するソフトの仕組みと取得できる情報の例
図A●構成要素ごとに性能情報を取得するソフトの仕組みと取得できる情報の例
Webサーバー,APサーバー,アプリケーション,DBサーバーなど,構成要素にエージェントなどを組み込む。エージェントが構成要素に特有の性能情報を取得し,管理サーバーに送付する。これにより,ボトルネックの詳細分析が可能になる
[画像のクリックで拡大表示]

 Web性能管理ソフトの中には,構成要素ごとの性能管理も可能だったり,構成要素ごとの性能管理ソフトと連携したりすることで,性能問題の原因個所を次第に絞り込んでいけるタイプの製品もある。システムの設計担当者や開発担当者であれば,こうした製品を選定した方が,問題解決が容易になる分だけメリットが大きい。実際最近では,「Web性能管理ソフトだけでなく,同時にアプリケーションの性能管理ソフトも導入する開発担当者が増えている」(シマンテック プロダクト・マーケティング部 朝倉英夫氏)という。

■変更履歴
図Aをクリックしたときに表示される画像が別の図になっていました。お詫びして訂正します。図のリンクは修正済みです。[2014/01/24 21:00]