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

インフラ監視と併用で多大な相乗効果

　第一回、第二回とクラウド、仮想化環境におけるエンドユーザー体感監視の重要性、またエンドユーザー体感監視ツールの種類について説明してきました。最終回となる今回は、エンドユーザー体感監視が実際の運用でどのような効果を発揮するのか、具体的な例を挙げてご紹介します。また、最後にエンドユーザー体感監視ツールの最近の動向についてもご紹介します。

■エンドユーザー体感監視とインフラ監視は補完関係

　企業で使われているITシステムで何ら監視を行っていないというケースは皆無でしょう。サーバー監視、ネットワーク監視が最も一般的な監視手法です。サーバー監視ではサーバーの死活、CPU、メモリ、HDDの使用率、プロセスやサービスの稼働状態などを監視し、ネットワーク監視ではネットワーク機器の各ポートの稼働状態、通信量、Pingによる疎通などを監視します（総称してインフラ監視と呼びます）。

　当然ながら、エンドユーザー体感監視を行う場合においても、インフラ監視が重要であることは変わりなく、インフラ監視とエンドユーザー体感監視は補完関係にあると言えます。両者を組み合わせた具体例を見てみましょう。

■障害切り分けは体感監視ツールで

　例えば、社内ポータルを使っている際に、ある支店の従業員Aさんからヘルプデスクに「ポータルサイトが重くて使い物にならない」とクレームが入ったとします。運用担当者はサーバー監視ツールを確認しますが、特に障害アラートは上がっていません。そこでネットワーク担当者、アプリケーション担当者などを集めて調査を開始します。しかし、いくら調査しても原因は特定できず、結局よく分からないまま問題の発生した支店に調査に向かう――運用の現場ではよく聞く話です。

　エンドユーザー体感監視によって、これが劇変します。どう変わるか、ここではキャプチャ方式を例にとって説明します。

　クレームを受けた運用担当者はエンドユーザー体感監視の監視コンソールを見て、ここでまず問題の影響範囲を確認します。「問題に遭遇しているのはAさんだけか」「支店全体に影響が及んでいるか」「実はAさんのレスポンスタイムも特に問題なく、単にAさんが気の短い人だったのか」など、正確な影響範囲を把握することにより、対応レベル（プライオリティ）を変えることになります。

　問題の深刻度を判断するには、以外のような情報を利用します。こういった情報と、そのサービス自体の重要性から対応のプライオリティが決定されます。

本当に問題は発生しているか
問題が及んでいる範囲（特定のユーザーか、特定の地域か、全ユーザーか）
問題はレスポンスの低下か、完全にダウンしているのか
問題が継続している時間
特定のWebサーバーで発生している問題か

■ツールによってどこまで分析できるかは異なる

問題原因の分析例

　問題による影響が大きく、迅速な対応が必要な場合は、さらなる分析に入ります。一般的にエンドユーザー体感監視ツールは、遅延の原因を簡単に切り分ける機能を持っています。それによって遅延がデータセンター内で発生しているのか、ネットワークで発生しているのか、あるいはクライアントのPC内で発生しているのか、といった切り分けが可能です。

　データセンター内に問題があると分かった場合、さらにどのサーバーに問題があるのかを切り分けていきます。ツールによってはさまざまな方法を駆使して、JAVAのメソッド、DBへのアクセスなどのレスポンスタイムまで計測できるものがあります。どこまで細かい情報が必要となるかは運用ルールによって異なりますので、ツール選びの際に十分な検討が必要です。

　エンドユーザー体感監視ツールによる切り分けが終わると、そこから先は個別の分析ツール、あるいは運用経験に基づいて作成された運用手順に従うことになります。エンドユーザー体感監視ツールで問題の根本原因までピンポイントで解明することは難しいですが、パフォーマンスに問題があるか、どれくらい深刻な問題かを、明確な数値で示せるのが重要なポイントです。

■インフラ監視とひも付けて「構成管理」を実現

　問題の切り分けを行った後、インフラ監視ツールで詳細な分析を行います。このとき、両ツールを連携させるのが理想です。

　両ツールの併用で最も効果が上がる方法は、エンドユーザー体感監視ツールで管理している「サービス情報」、インフラ監視ツールで管理している「インフラ情報」を関連付けることです。

　サービス情報からは、監視対象サイトでどんなサービスが稼働しているかが分かり、インフラ情報からは、監視対象サーバーやネットワーク機器の情報が分かります。これらを関連付けることで、エンドユーザーの視点から見たパフォーマンスの悪化を検知した場合に、そのサービスを構成するインフラが何なのかが即座に判明し、原因究明を容易にします。逆にパフォーマンスに問題が及んでいない場合も、インフラに障害発生した際に、その影響が及ぶ可能性のあるサービスを即座に認識できるようになります。

サービスとインフラを関連付ける

　これは、ITILで言うところの「構成管理」そのものです。通常、構成管理ツールはシステム内に存在するサーバー・ネットワーク機器・アプリケーション・サーバー間の通信プロトコルなどを検知して構成図を作成します。もし、すでに構成管理ツールを導入している場合には、エンドユーザー体感監視ツールとインフラ監視ツールを構成管理ツールで結ぶことで、簡単にこの監視手法が実現できます。

　また、エンドユーザー体感監視ツールの中には、インフラ監視ツールとの連携を想定し、あらかじめ構成管理機能を備えているものもあります。まだ社内で構成管理を行っていない場合は、その機能を利用するのも手でしょう。

「構成管理」の位置づけ

■エンドユーザー体感監視は負荷テストにも効果的

負荷テストとエンドユーザー体感監視

　エンドユーザー体感監視ツールは、実運用に入ったシステムの監視に使うのが一般的です。しかしツールの特性から、開発段階、特にカットオーバー前の負荷テストでも大きな効果を発揮します。

　負荷テストでは、ツールを使って実運用段階と同等の負荷をかけます。ここでエンドユーザー体感監視ツールがあれば、高負荷状態でのシステムの挙動を正確に把握できます。例えば、500人、1000人と負荷を上げていく段階でのエンドユーザーレスポンスタイムの推移や、データベースへのアクセスに要する時間の推移が分かります。

　負荷テストで得られた情報は、実運用時のサービスレベル管理指標として、そのまま活用できます（同時1000人アクセスの状態ではエンドユーザーレスポンスタイムは5秒が基準である、など）。また、実運用時にもツールを使い続けることで、ユーザー数の増加に伴うインフラ増強、アプリケーションの改修などを行う場合の判断基準となります。

■エンドユーザー体感監視ツールの最新動向

　この連載の最後に、エンドユーザー体感監視ツールの最新動向と今後について紹介します。エンドユーザー体感監視ツールも進化しており、特に最近のクラウド・仮想化環境に対応した新機能が登場しています。

　1台の物理サーバー内で複数のサーバーが稼働する仮想化環境では、仮想マシン間で通信が行われる場合、それはあくまでサーバー内で仮想的にやり取りされるため、外部からは監視できません。物理サーバー内での通信がブラックボックスとなってしまうのです。

　ツールによっては、この部分についても、エンドユーザーレスポンスタイムと仮想サーバー内でのレスポンスタイムを照らし合わせて、詳細な分析を可能にしているものがあります。

　もうひとつ、WAN最適化ソリューションも最近注目の技術です。一般的なWAN最適化ソリューションは、WANの両端（例えば本社と支店）に最適化用の通信機器を設置し、WANに流れるパケットを効率化することで細い回線での高速化を実現します。

　しかし使いこなすためには、機器設置前と後でどれだけ効果が出たかを十分に検証する必要があります。ツールによっては、WAN部分の「最適化」されたパケットを分析できるものがあります。エンドユーザーレスポンスの計測結果と合わせて分析すれば、WAN最適化が本当に効果を発揮しているか、詳細な検証が可能となります。

WAN最適化とエンドユーザー体感監視

　エンドユーザー体感監視ツールは今まで一部のインターネットに依存した企業が使うニッチな監視ツールでした。しかしクラウド、仮想化といった環境の変化により、エンドユーザー体感監視ツールがあらゆる企業になくてはならないツールになりつつあります。今後はITシステム管理の他の領域と密接に結びついて、さらに効果を発揮するようになるでしょう。また、構成管理との連携のほか、キャパシティプラニング、データセンター自動化などの分野においても、エンドユーザー体感に基づいたデータが必要となり、より密な連携が図られるはずです。

　三回にわたってエンドユーザー体感監視の有効性について説明してきました。クラウド、仮想化環境において、その重要性がお分かりいただけたかと思います。この連載がこれからエンドユーザー体感監視の導入を検討する際の一助となれば幸いです。