「ユーザーの視点」を導入・運用プロセスに組み込もう：ビジネス視点の運用管理（5）（1/2 ページ）

エンドユーザー体感監視＝APM（Application Performance Management）のポイントをあらゆる角度から紹介してきたが、最終回となる今回はAPMの効用を最大化する3つのポイントを紹介する

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

　本連載もいよいよ最終回となりました。今回も前回に引き続き、エンドユーザー体感監視ツールを選ぶ際のポイントから説明していきます。 今回は、製品カタログの比較では分かりにくい、しかしエンドユーザー体感監視の効果を最大限に発揮させる上では非常に重要なポイントを、実際の導入プロセスに沿ってご紹介します。続いて、連載のまとめとして、エンドユーザー体感監視を真に有効なものとする秘けつをお教えしましょう。

最適なAPMツールを選ぶための4つのポイント

　では早速、本論に入りましょう。まず、エンドユーザー体感監視に求める要件を明らかにしたら、いよいよツールを購入するわけですが、この段階から気を付けなければならない点がいくつかあります。

ツールを購入するか、サービスの提供を受けるか？

　従来、エンドユーザー体感監視の導入は、ツールを購入し、自社内のサーバにインストールして利用するのが一般的でした。しかし最近は複数のベンダがエンドユーザー体感監視をサービスとして提供するようになり、その選択肢も豊富になりつつあります。

　サービス利用のメリットは何と言っても、専用のサーバなどを準備しなくてもすぐに監視が始められる点です。また、クラウドサービスやCDNなど、ファイアウォールの外にある要素と連携しており、それらがパフォーマンスに影響を与える可能性が高いシステムでは、外部からレスポンスを計測する「サービス」の方が、より実体に近い結果を得られるかもしれません。

　一方で、サービスは外部からの監視のため、企業内で閉じたシステムについては監視できない場合があります。図1にツールの購入とサービス利用、それぞれのメリット、デメリットをまとめました。参考にしてください。

図1　「エンドユーザー体感監視ツールは購入するべきか、サービスとして利用するべきか」、購入とサービス利用のメリット・デメリット比較

物理的に監視ツールの設置は可能か？

　パケットキャプチャ方式の場合は、監視対象システムのネットワーク機器に、パケットキャプチャ装置を接続する必要があります（第4回を参照）が、クラウドのような環境ではネットワーク機器が共有されているため、装置を接続できないことがあります。

　一方、仮想ユーザー方式の場合は、計測用エージェントをいずれかの場所に置いて、“ユーザーのふり”をして監視対象サイトにアクセスさせることで計測を行います。このため、社内またはデータセンター内への設置は容易ですが、監視要件によってはデータセンターの外から計測したい場合があります。その際、セキュリティポリシーの事情から、計測用のインターネット回線を独自に引くのが難しい可能性があります。その場合にはツールの導入ではなく、サービスの提供を受けることを検討した方がいいかもしれません。

ツールが監視対象システムで使われる技術に対応しているか？

　監視対象となるシステムのプロトコルは、ほとんどの場合HTTPでしょう。しかし一口にHTTPと言ってもそこで使われている技術はさまざまです。 Ajaxのようなアプリケーション技術、ストリーミング技術、さまざまな認証方式などですが、これらの技術をサポートしているかどうかは、ツールの仕様を見てもなかなか判断できません。少しでも心配がある場合は、購入前に実際にそのツールを試し、きちんと監視できるかを確認することをお勧めします。

大規模なシステムに対応できるか？

　パケットキャプチャ方式は「ネットワーク機器から全ユーザーのパケットをキャプチャする」という性質上、大規模なシステムではそのスケーラビリティが問題になることがあります。BtoCサイトなどアクセスが多いサイトを監視する場合には、その監視ツールがどのくらいのパケット量に対応しているかをあらかじめ見極めておく必要があります。

ツールは入手した。ではその効果を最大化するにはどうすれば？

　以上の観点で利用するツール／サービスを吟味すれば、一つに絞り込めると思います。次はいよいよ導入です。エンドユーザー体感監視をより効果的に活用するためには、どのような点に注意すればいいのでしょうか。

「エンドユーザー体感管理責任者」を置く

　エンドユーザー体感監視ツールを導入したにもかかわらず、有効に活用できていないケースも数多くあります。そうしたケースを詳しく見てみると、ITシステムのパフォーマンス管理について、責任の所在がはっきりしていないことが多いようです。

　例えば一般的なシステムは、IT部門が構築・運用に責任を負い、ビジネス部門も「システムに関する全ての責任はIT部門にある」と考えています。しかし残念ながら、多くの企業のIT部門は「エンドユーザー体感」については責任を持ちたがらず、「サーバが立ち上がっていれば良し」と考えがちです（だからこそエンドユーザー体感監視の導入が必然なのですが……。第1回の冒頭をご参照ください）

　よって、できればビジネス部門にエンドユーザー体感を管理する責任者を置きましょう。もちろん、その責任者は専任である必要はなく、他の業務との兼務で構いません。サービスレベル管理を導入しているのであれば、その責任者が兼務しても良いでしょう。ビジネス部門から担当者を出すことが理想ですが、それが難しければIT部門のスタッフが責任者になっても構いません。

　この「エンドユーザー体感管理責任者」は、「エンドユーザー体感」を「管理」する責任者であり、エンドユーザー体感が悪化した際に「その問題の責任を負う」わけではありません。あくまで、エンドユーザー体感をどう管理すべきか、そして問題に対してどう対応すべきかを管理します。重要なのは、エンドユーザー体感という、今まで責任があいまいだった（しかし最も重要な）点に明確な責任者がおり、その責任者が対応をリードするということです。

負荷テストとの連携

　「エンドユーザー体感監視が有効に機能している」というユーザーにその理由を聞いてみると、開発フェイズと運用フェイズを連携させている――つまり、負荷テストとエンドユーザー体感監視を連携させていることを挙げる人が多いようです。実際、「システムのパフォーマンスを管理する」という意味では、開発の最終段階で行う負荷テストと、実運用段階で行うエンドユーザー体感監視は“一連のもの”と捉えることができます。

　例えば、あるシステムについて、まず「目標とする同時ユーザー数は1000人、サービスレベル管理上、目標とするレスポンスタイムは5秒」といったようにKPIを定めます。その上で、開発時の負荷テストでは1000人の同時負荷を掛けて「期待するレスポンスが得られるか」を確認し、その後の実運用でエンドユーザー体感監視を行います。これによって、期待したレスポンスが得られなくなった場合には、システムを改修した上で再び負荷テストを行います。

図2　負荷テストとエンドユーザー体感監視を連動させることで、開発部門と運用部門をパフォーマンスの視点で有効に結び付けることができる。開発段階から運用段階まで一貫してパフォーマンスを管理することは、システムの安定性を担保する上で非常に効果的

　これは「パフォーマンス管理という視点によるシステムのライフサイクル管理」と言えます。一般に、パフォーマンス管理について、開発部門と運用部門が十分に連携・協働できているケースはまだ多くありません。しかし上記のように、負荷テストとエンドユーザー体感監視をうまく連動させることによって、開発部門と運用部門をパフォーマンスの視点で有効に結び付けることができるのです。

　このライフサイクル管理をスムーズに行うためには、負荷テストツールと親和性の高いエンドユーザー体感監視ツールを選択するのが理想です。しかし、たとえツール同士の相性は良くなくても、「負荷テストとエンドユーザー体感監視は一連のもの」と考え、開発段階から運用段階まで一貫してパフォーマンスを管理することは、パフォーマンス問題が起こる可能性が至る所に潜んでいるような今日のシステムでは、その安定性を担保する上で非常に効果的です。