クラウドが招くWebパフォーマンス問題を読み解く【第二回】

2つの体感監視手法を徹底比較

　前回は、今日のITシステムにおいてなぜエンドユーザー体感監視が重要なのか、クラウド、仮想化などの環境を例にとって説明しました。今回はもう少し具体的に、エンドユーザー体感監視ツールの種類とその特徴について説明します。

■2種類のエンドユーザー体感監視方法

　エンドユーザー体感監視ツールは、その名が示す通りエンドユーザーがITシステムにアクセスする際に体感するパフォーマンスを監視するツールです。システムのリソース負荷などからパフォーマンスを図るのではなく、エンドユーザーの体感を基にするため、実際のパフォーマンス状況をより的確に捉えることが可能です。

　その方法ですが、パフォーマンス計測は大きく、仮想ユーザーがエンドユーザーのふりをして監視対象サイトにアクセスする「仮想ユーザー方式」と、ネットワーク上の実パケットをキャプチャする「パケットキャプチャ方式」の2つに分けられます。

　どちらもエンドユーザー体感を計測するという目的は同じですが、それぞれの特長に応じて、できること・適した用途に違いがあります。具体的に、それぞれのメリット・デメリットを見てみましょう。

■仮想ユーザー方式

　仮想ユーザー方式ではまず、社内のいずれかの場所に設置したマシンに監視用のエージェントをインストールします。エージェントはあらかじめ決められた定義に従って、監視対象サイトにアクセスします。「ブラウザを使って監視対象サイトにHTTPリクエストを送信し、レスポンスデータを受信する」といった一連の処理を、エージェントが定期的かつ自動的に行います。本当のユーザーではない、仮想のユーザーが計測を実行するという意味で、「仮想ユーザー」方式と呼ばれます。

　エージェントにおける定義は、例えば次のようになります。エージェントはこの定義に従って定期的に監視を実行します。

監視対象はwww.xxx.co.jp。ポータルサイトにログインし、特定の文字列を検索後ログアウトするまでの一連の処理とする
監視実行間隔は10分に1回
しきい値は6秒以上を警告、10秒以上をエラーとする
エラーが3回連続した場合、運用担当者にメールで通知する

　この監視方式ではエージェントをどこに置くかが重要なポイントとなります。エージェントがユーザーのふりをして監視対象サイトにアクセスするので、計測したい場所にエージェントを起きます。例えばADSLのような一般ユーザー向け回線を使ってアクセスするようにしておけば、より一般ユーザーの体感に近い計測結果が得られるでしょう。あるいはWebサーバーと同じLAN上にエージェントを置くことによって、ネットワークの遅延に左右されない、サイトの「本来の」レスポンスタイムを計測することができるでしょう。

　同じロケーションの同じ環境から同じ処理の監視を定期的に行う仮想ユーザー方式は、サービスレベルの計測に有効です。サービスレベルを管理するためには、実ユーザーのアクセスにかかわらず、同じ場所で定期的にレスポンスタイムを計測する必要があるためです。

　さらにエージェントを何カ所に置くかも監視の精度を上げるためには重要な考慮点です。サービスレベル情報の取得だけが目的であれば、社内の一カ所に置けば十分かもしれません。しかし、例えば監視対象がイントラネットで、国内の全支店のレスポンスタイムを監視したい場合には、それらすべての支店にエージェントを置く必要があるかもしれません。

■パケットキャプチャ方式

　こちらの監視方式は、ネットワーク上を流れるパケットをキャプチャしてレスポンスタイムを計測するものです。

　まずパケットをキャプチャするためのソフトウェアがインストールされたマシンを準備します。このマシンを監視対象システム内のネットワーク機器（ルータ、スイッチなど）のモニターポートに接続します。モニターポートからはそのネットワーク機器を通過するパケットがすべて出力されるので、それを分析してレスポンスタイムを計測します。

　パケットキャプチャ方式の最も大きなメリットは、すべての実ユーザーのレスポンスタイムを計測できる点です。あるシステムでパフォーマンス問題が発生した場合に、その影響が及んでいる場所や個人を特定できるため、例えばコールセンターのオペレータがアクセスする顧客システムや、代理店がアクセスする受発注システムなどは、パケットキャプチャ方式が向いていると言えます。こうしたケースでは、どのオペレータ、どの代理店のレスポンスが低下しているかを把握するのが重要だからです。ただし、実ユーザーからのアクセスがない時間帯には、そのときシステムに何らかの問題が起きていても検知できないのが、同方式のデメリットです。

　また、パケットキャプチャ方式には、ハードウェアとソフトウェアをまとめてアプライアンスとして提供されるケースとソフトウェアのみ提供されるケースがあります。一般論として、アプライアンスは設置が比較的容易であり、一方ソフトウェアのみ提供の場合はスケーラビリティ（どれくらいの量のパケットを処理できるか）の面で優れていることが多いようです。

■導入にあたって留意すべき点

　サーバー監視ツールやネットワーク監視ツールに比べて認知度の低いエンドユーザー体感監視ツールを実際に導入された経験のある方はまだまだ少ないかもしれません。導入を検討する場合、どのような点に気をつけたらいいのでしょうか。

（1）実ユーザーの計測は必要か

　実ユーザーのレスポンスタイムを計測する必要があるか、あるいは仮想ユーザーによる計測で要件を満たすのかは、ツールの選択肢を絞り込む上で重要なポイントとなります。

（2）製品にするかサービスにするか

　仮想ユーザー方式を選択した場合、製品を購入して自社内に監視環境を構築する方法と監視サービスの提供を受ける方法があります。

　自社に環境を構築する場合、外部から閉じたシステムであっても監視できたり、ほかの監視ツールとの連携が可能だったりする点がメリットで、運用管理の手間がかかる点がデメリットです。

　一方、監視サービスを利用する場合、比較的設定や管理に手間がかからなかったり、マシンなどを新たに準備する必要がなかったりする反面、外部からのアクセスを制限しているシステムでは監視が難しく、Webサイト（HTTP）以外のシステムに適用できないなどの制約があります。

　また、監視サービスの中には世界中にエージェントを配置して非常に多くの場所からの監視を実現しているものもあり、よりエンドユーザーに近いレスポンスタイムを計測したい場合にはエージェントの選択肢が多いサービスを選ぶ、という選択肢もあります。

（3）監視対象システムのプロトコル

　一般的にＩＴシステムに使用されるプロトコルはHTTPが多くなったとは言え、まだまだ多くのシステムでHTTP以外のプロトコルが使われています。またエンドユーザーのレスポンスタイム計測を補足する意味で、HTTPなどのクライアントプロトコルのほかにSQLなどバックエンドのプロトコルのレスポンスタイムを計測したい場合があります。

　計測できるプロトコルの種類はツールによって大きく差があり、HTTPしか計測できないツールもあれば数十種類のプロトコルを計測できるツールもあります。監視すべきプロトコルは何なのかをあらかじめ明確にしてからツールの選択を行う必要があります。

（4）パフォーマンス問題の原因分析に利用するか

　エンドユーザー体感監視ツールのメリットのひとつは、パフォーマンス問題が発生した際にその原因を切り分けることができる点にあります。しかしどのような分析機能を持っているかはツールによって大きく異なります。

　ツールによってはレスポンスタイムのみレポートし、分析機能を全く提供しないものもあります。（その分価格が安く抑えられているケースが多いようですが）。多くのツールで見られる分析機能は、レスポンスタイムをサーバー処理時間、ネットワーク時間、クライアント時間などに分割する機能、Webページ内のコンポーネント（各Gifファイル、HTMLファイルなど）ごとにレスポンスタイムを計測する機能などです。

　また、仮想ユーザー方式かパケットキャプチャ方式かによっても、分析に使える機能は変わってきます。一般的に言って、実ユーザーのレスポンスタイムをロケーション毎、Webサーバー毎、ページ毎といった細かい単位で分析できるパケットキャプチャ方式のほうが、分析機能という意味では充実しています。

　重要なのは、ツールをどんな目的で使用するかをはっきりさせることです。サービスレベル管理のための基準値としてレスポンスタイムを利用するだけであれば、それほど細かい分析機能は必要ないかもしれません。逆に運用の現場での問題原因究明を目的として利用する場合には、実際の運用プロセスを考慮しつつ、分析機能がどのように活用できるかを想定しておく必要があります。

　以上、仮想ユーザー方式・パケットキャプチャ方式の違いをまとめると以下のようになります

　これら以外にも、実際にツールを選択する際には、ツールの仕様だけでは判断が難しい基準があります。例えば仮想ユーザー方式では、エージェントが正確に実ユーザーの動作を再現できるかが重要なポイントとなります。またパケットキャプチャ方式ではどれだけのデータ量を処理できるかが問題となることがあります。特に大規模なB2Cサイトでは注意が必要です。これらはツールの仕様を見ただけではなかなか判断できません。導入前にしっかりとした評価が必要でしょう。

　今回はエンドユーザー体感監視ツールを2つに分類してその特徴を説明しました。しかし、実際にはツールごとにさまざまな特徴を持っており、監視対象サイトの特性、監視の目的などを十分に整理した上でツールの選択を行うことが必要です。

　次回は、実際の利用シーンを想定し、エンドユーザー体感監視ツールの利用例を紹介します。特にインフラ監視ツールと併用することで、その効果は何倍にも高まる様子をご覧ください。また、エンドユーザー体感監視の今後のトレンドにも触れ、仮想化、クラウドの時代を迎えて、ツールがどのような進化を遂げているかを紹介します。