メディア

サーバは無事でも、業務が遅滞しては意味がない：ビジネス視点の運用管理（1）（2/2 ページ）

» 2011年03月24日 12時00分公開

[福田慎（日本コンピュウェア），＠IT]

“エンドユーザー体感”を起点に問題原因を特定

　さて、そこでいったん運用管理の原点に立ち返ってみましょう。そもそもITシステムを監視する目的は、「利用者が快適にサービスを利用できていることを確認すること」です。

　しかし、前のページで述べたように、システムが複雑化し、パフォーマンスに影響を与える要素が自社のデータセンター外にまで広がると、サーバ監視だけではシステムの可用性を十分には監視できないため、その監視結果結果と利用者の受けるサービスレベルにズレが生じることになります。

　具体的に言えば、「サーバ監視で障害を検知していないのに、利用者は使えていない」、あるいは「サーバ監視で障害が報告されているにもかかわらず、利用者は快適に使えている」といった状況に陥ることになるのです。サーバ監視をどんなに細かく、詳しく行ってもこの問題は解決しません。むしろ無意味な情報が氾濫し、処理し切れなくなるだけでしょう。

　ではどうすれば良いのでしょうか？――これを解決する最も効果的な方法が、“利用者の視点からレスポンスタイムを計測する”、つまり「エンドユーザー体感監視」だと考えるわけです。

　「エンドユーザー体感監視」はその名の通り、「エンドユーザーが体感するレスポンスタイムを計測する監視手法」です。具体的にはいくつかの方法があります。そのバリエーションは次回からご紹介しますが、それらのポイントは、いずれの方法についても「エンドユーザーが体感するレスポンスタイムを計測すること」、そして、その「計測結果を稼働状況の監視、さらにはITシステム有効活用の重要な管理指標として活用していくこと」にあります。

図3　サーバやネットワークなど、システムの基盤側から問題原因を探るのではなく、ユーザーにとって最も重要なUI側から問題を探る

　その最大のメリットは、システム運用管理の目的、「利用者が快適にサービスを利用できていることを確認できる」ほか、問題を効率的に切り分けられるようになることです。

　例えば、ある企業ではイントラネットを使っていましたが、「エンドユーザー体感監視」を導入するまでは、各業務部門のユーザーからのクレームに基づいて原因の調査を行い、場合によっては各地の営業所にまで赴いてシステムの調査を行っていました。そこでエンドユーザー体感監視を導入し、専用のツールを使ってレスポンスタイムを正確に計測できるようにした結果、クレームの中には、システム側の問題ではないものや、利用者側の勘違いによるものも多く、「実際に対応が必要なクレームは、全クレームの半分以下」であることが分かったのです。

　これには2つのポイントがあります。1つはエンドユーザー体感監視を導入し、レスポンスタイムについてエンドユーザーとの間で明確なSLAを定めたことです。これにより、「短気な人にとってはレスポンスが遅く感じる」といった主観的な判断を排除し、「対応が必要なもの」「対応の必要がないもの」を客観的な指標で明確に切り分けたのです。

　また、（その仕組みは次回以降でお伝えしますが）エンドユーザー体感監視ツールでは、その監視結果から、サーバやネットワークではなく、クライアントPCで時間がかかっていた、ということも把握できます。そこでこの企業では、ツールの監視結果からクライアントPCに原因があると分かった場合、エンドユーザーにその旨を伝え、エンドユーザー側で調査を行うよう指導することにしました。こうした取り組みにより、この企業では障害対応に要していた作業量を90％も削減できました。

　もちろん、すべてのケースでこれほど明確な効果が表れるわけではありません。しかし、サーバやネットワークなど、システムの基盤側から問題原因を探るのではなく、ユーザーにとって最も重要なUI側から問題を探ることで、無駄な回り道をする確率を大幅に低減できます。この点が、運用管理の効率化の1つのアプローチとして、この方法が有効だと考えるゆえんです。

各社のツール、サービスを目的に応じて使い分けよう

　では第一回目の最後に、エンドユーザー体感監視を行うための、技術的な仕組みも簡単に紹介しておきましょう。これを行うためには、複数のベンダから提供されている専用ツールかクラウドサービスを利用する形になりますが、その監視形態は大きく分けて2種類あります。一つは「仮想ユーザー方式」、もう一つは「パケットキャプチャ方式」です。

　仮想ユーザー方式は、いずれかの場所に準備したPCに専用エージェントをインストールし、そのエージェントによって本当のユーザーと同じように対象システムにアクセスして、そのレスポンスタイムを計測する仕組みです。実際にユーザーが使っているPCを使わないのは、ユーザーの作業内容によってはそのPC自体の負荷が高くなり、正確なレスポンスタイムが測れなくなる恐れがあるためです。

　一方、パケットキャプチャ方式には複数の仕組みが存在しますが、最も一般的な方式は、対象システム内のスイッチなどのネットワーク機器に、パケットキャプチャ用装置を接続し、そこを流れるすべてのパケットを分析してレスポンスタイムを計測する方式です。

図4　エンドユーザー体感監視には、専用エージェントからシステムにアクセスする方式と、ネットワーク機器で処理されるパケットを分析する方式がある

　2つの監視方式の最大の違いは、実ユーザーの代わりに「仮想ユーザーがアクセスしてレスポンスタイムを計測するのか」、対象システムにアクセスする「実ユーザーのレスポンスタイムを計測する」のか、という点です。

　こう説明すると、一見、実ユーザーのレスポンスタイムを計測するパケットキャプチャ方式の方が優れているように思われますが、実ユーザーのアクセスを計測するということは、そのアクセスがない場合には何も計測しない――つまり「障害が発生していても検知できない」ということになります。その点、仮想ユーザー方式は、実ユーザーではない代わりに、常時障害を検知できることになります。従って、両者の特性を見極めて、自社の状況やエンドユーザー体感監視を導入する目的に応じて、どちらかを選ぶ必要があります。両者のメリットをまとめると以下の通りです。

仮想ユーザー方式のメリット

監視ツールが自らパケットを送信してレスポンスタイムを計測するため、実ユーザーがアクセスしていない時間帯でも、障害を検知できる
「同じ場所から、一定の間隔で、同じ処理を実行するため、サービスレベル管理の基準値となるデータを取得するのに向いている
データセンター内に監視用のサーバ、機器などを設置する必要がない

パケットキャプチャ方式のメリット

実ユーザーのパケットをキャプチャするため、ユーザーが体感している“本当のレスポンスタイム”を計測できる
全ユーザーのパケットをキャプチャするため、パフォーマンスの悪化や障害が「どれだけのユーザーに影響を与えているか」を正確に把握できる
仮想ユーザー方式が特定の処理／特定のWebページ上でのレスポンスだけを計測するのに対し、パケットキャプチャ方式は、全ての処理、Webページを計測対象とするため、特定の処理／特定のWebページだけで発生するような問題も見逃さず、確実に検知できる

　こうした特性を基に、自社の状況に合わせていずれかの方式を選ぶことになるわけですが、選択のポイントとなるのは、「あなたの会社では現在、以下のどちらを重視しているか」ということです。

エンドユーザーが体感するレスポンスタイムを数値で把握することにより、サービスレベル管理を実現する
ITシステムの監視項目にエンドユーザー体感を加えることによって、問題の原因究明に要する時間を短縮し、運用負荷を軽減する

　あなたの会社にとって、優先課題はサービスレベル向上なのか、運用負荷軽減なのかを事前に計画しておけば、自社の状況と上記の特性を考え合わせることで、どちらの方式が適しているのか、あるいは両方とも必要なのか、自ずと見えてくるのではないかと思います。

　今回は、いまエンドユーザー体感監視が求められる理由について解説しました。次回からは、エンドユーザー体感監視を行うツールの種類や効果的な活用方法などについて、詳しく説明していきたいと思います。

著者紹介

▼著者名　福田慎（ふくたしん）

日本コンピュウェア営業本部シニアソリューションアーキテクト。長年に渡り、ITサービス管理の分野に従事。 BMCソフトウェアや日本ヒューレット・パッカードなど、米国リーディングカンパニーの日本法人にて、プリセールスとして数多くの案件に携わり、IT部門が抱える課題解決を支援。現在は日本コンピュウェアにて、シニアソリューションアーキテクトとして顧客企業への提案を推進する傍ら、講演活動にも積極的に取り組み、アプリケーションパフォーマンス管理の啓発活動を展開している。

「ビジネス視点の運用管理」バックナンバー

前のページへ 1|2 　　　　　　