複雑化したシステムのパフォーマンスをどう守るか【第3回】

失敗しないアプリケーションパフォーマンス管理製品の選び方

複数のベンダーから提供されているAPMツールは、当然ながら監視方式や搭載機能がそれぞれ異なっている。自社のニーズに最適な製品を選ぶためには、どのようなポイントに留意すればよいのだろうか？

公開 2012年12月19日 08時09分

[日本コンピュウェア]

印刷する Googleで優先するソースとして追加

　前回の「【技術解説】アプリケーションパフォーマンスを測る4つの手法」では、APM（Application Performance Management）ツールで採用されている4つの監視方式――「仮想ユーザー方式」「パケットキャプチャー方式」「クライアントインストール方式」「JavaScript付加方式」と、それぞれのメリット、デメリットを紹介した。

これまでの記事

　今回はそれに基づき、自社のニーズに適切なAPMツールを選ぶための7つのチェックポイントを紹介する。

1. 監視すべきプロトコルは何か？

　APMツールの選択に当たってまずチェックしたいのは、その製品が「監視できるプロトコル」だ。一般に、Webを介して使う業務システムはHTTPを使っているケースが多いが、SAPなど広く使われているパッケージシステムでは、HTTP以外のプロトコルが使われているケースがある。また、APMツールを「システムのレスポンスの把握」だけでなく、「パフォーマンス低下の原因分析」にも利用する場合、HTTPなどフロントエンドのプロトコルだけでなく、TCP/IPなどバックエンドのプロトコルにも対応している方が望ましい。

　製品には、HTTPしか計測できないツールもあれば、数十種類のプロトコルを計測できるものまである。事前に「監視対象システムがどのプロトコルを使っているのか」「どのプロトコルを監視する必要があるのか」を明確化しておきたい。

APMの関連コンテンツ

2. エンドユーザーが実際に感じているレスポンスタイムを把握する必要があるか？

　これは「システムのレスポンスが、業務の遅滞を招く原因になっているかどうか」の調査などに当てはまる。例えば、監視対象システムがコールセンターの顧客対応システムで、「全オペレータの体感レスポンスタイムを正確に把握したい」といった場合だ。

　仮想ユーザー方式は、APMツール自身が仮想ユーザーとしてパケットを送信する方式を取る。このためエンドユーザーが実際に感じているレスポンスタイムを計測することはできない。従って、エンドユーザーが送受信するデータを分析することでレスポンスを把握するには、その他の3方式から選ぶことになる。

　ただし、クライアントインストール方式のみ、エンドユーザーのWebブラウザにエージェントをインストールする必要があるため、エンドユーザーの協力が不可欠となる。分析作業をよりスムーズに進める上では、パケットキャプチャー方式か、JavaScript付加方式の方が有利だろう。

　監視対象が大規模なB2Cサイトで、「必ずしも全ユーザーが実際に体感しているレスポンス情報は必要なく、サンプルとなるレスポンスタイムを把握したい」という場合には、同じ場所から同じ処理を定期的に繰り返す、仮想ユーザー方式が適している。

3. パフォーマンスの問題原因分析も行う必要があるか？

　多くのAPMツールは、レスポンス監視機能とともに、「レスポンス遅延の原因が、サーバ側とエンドユーザー側のどらちにあるかを切り分ける機能」を持つ。だがシンプルなツールの場合、レスポンス遅延の原因分析機能を備えていないものもあるので注意が必要だ。自社のシステム運用管理プロセスを整理し、どのような機能が必要か、あらかじめ明確化しておきたい。

　なお、問題原因箇所の切り分け機能については、クライアント側から計測するクライアントインストール方式とJavaScript付加方式はクライアント側の分析に優れ、サーバ側から計測するパケットキャプチャー方式はサーバ側の分析に優れている傾向が強い。

統合運用管理の関連コンテンツ

4. エンドユーザーが気付く前に障害を検知する必要があるか？

　パケットキャプチャー方式、クライアントインストール方式、JavaScript付加方式は、実際のエンドユーザーのパケットを監視するため、システムのレスポンスが遅延していても、エンドユーザーのアクセスがなければ遅延を検知できない。例えば、監視対象が夜間は誰もアクセスしないような業務システムの場合、夜間に何らかの障害が発生していても、エンドユーザーのアクセスがない以上、障害を検知できない。

　その点、仮想ユーザー方式なら、ツール自ら定期的にシステムにアクセスするため、障害が起きていれば必ず検知できる。従って「障害のより早い発見」という目的がある場合、必然的に仮想ユーザー方式を選ぶことになる。ただし、仮想ユーザー方式は一定間隔での監視のためリアルタイムでの検知はできない。また、あらかじめ定義しておいたページしか監視しないため、特定のページの障害は検知できない可能性もある。

5. レスポンスの計測場所を選ぶ必要があるか？

　“レスポンスを測る上で最適な場所”は、監視対象システムによって変わる。例えば、全従業員が使う社内システムなら、本社だけではなく、従業員がいる全拠点からシステムにアクセスし、レスポンスを計測する方が望ましい。一方、Eコマースのように不特定多数が利用するシステムの場合、「ユーザーがいる全ての場所」からレスポンスを測ることはできないため、「データセンター内、あるいはデータセンター外のクライアントPCからシステムのレスポンスを計測する」といった取り組みが必要になる。

　従って、以上のように、レスポンスの計測場所を選ぶ必要がある場合は、クライアントPCに計測用エージェントを設置する仮想ユーザー方式が最適ということになる。これならIT部門が管理しているクライアントPCにエージェントをインストールし、そのPCを任意の場所に設置してシステムのレスポンスを測ることができるためだ。

　パケットキャプチャー方式の場合、ネットワーク機器を流れるパケットを計測するため、計測場所はデータセンター内に限定される。HTMLの中にJavaScriptを付加するJavaScript付加方式と、エンドユーザーの端末のWebブラウザにエージェントをインストールするクライアントインストール方式も、計測ポイントはエンドユーザーの端末となるため、IT部門側で計測場所を任意に選ぶことはできない。

6. パブリッククラウド、CDNなど外部サービスのレスポンス計測が必要か？

　近年は業務システムやWebサイトを展開する上で、CDN（Contents Delivery Network）やストリーミングサービスなど、社外のサービスを利用する機会が増えた。SaaS、IaaS、PaaSといったパブリッククラウドもこれに含まれる。これらの外部サービスがパフォーマンスのボトルネックとなるケースは少なくないだけに、外部サービスのレスポンスも計測可能かどうかはツール選びの重要な視点となる。

パブリッククラウドの関連コンテンツ

　その点、パケットキャプチャー方式はネットワーク機器、つまりデータセンター内で計測する方式のため、データセンター外にあるサービスのレスポンスは計測できない。従って、必然的にパケットキャプチャー方式以外から選択することになる。

7. スマートデバイスにおけるシステムレスポンスを監視する必要があるか？

　近年はスマートデバイスのビジネスへの影響が増しているだけに、スマートデバイスにおけるシステムレスポンス監視への対応もチェックしておきたい。ただ、これについてはまだ標準的な監視手法は確立しておらず、各ベンダーがあらゆる手法を提案しているのが現状だ。

　比較的多いのは、端末に計測エージェントをインストールする仮想ユーザー方式を使い、システムのパフォーマンスを計測する方法だが、これ以外にも「端末を監視ツールに接続して、その端末から定期的にリクエストを送信しレスポンスを計測する方法」「iPhoneやAndroid端末用のアプリケーションにレスポンス計測用のプログラムを追加し、エンドユーザーがそのアプリを実行した際にレスポンスを計測する方法」など、さまざまな方法がある。従って、「どのようなモバイル端末を、どのように監視したいのか」を事前に明確化しておくことが重要だ。

◇

　以上、APMツールを選ぶに当たって、考慮すべき7つのチェックポイントを挙げた。レスポンス監視・分析に対するニーズを明確化した上で、これらに沿って製品を絞り込んでいけば、製品選びはスムーズに進むはずだ。

印刷する

この記事の著者

福田慎