「体感速度」の向上に着眼したアプリケーション監視手法

エンド・ツー・エンドのボトルネック検出でビジネス損失を回避する

（2007年03月27日）

業務アプリケーションのパフォーマンスが低下すれば業務生産性が下がり、ECサイトでは売上げにも響く。そのため、アプリケーションの監視体制の構築は必須となる。だが、多種多様な要素で構成されるオープン系システムの場合、アプリケーション・パフォーマンス低下の原因は、そのアプリケーションのみならず、サーバやネットワークなども考えられ、問題判別だけで多大な労力と時間を要する。本稿では、パフォーマンスをエンドユーザーの「体感速度」ととらえ、これに着眼したアプリケーション監視手法を紹介する。

武田邦義／坂田大輔
日本コンピュウェア

「体感速度」に着眼した運用管理が必要な理由

　かつての企業情報システムでは、取り扱うユーザー数とデータ量を予測することは決して難しくなかった。基本的に社内での利用が多く、社外との連携もB2B（企業間）が中心であったからだ。処理形態もシンプルであり、日中はオンライン処理、夜間はバッチ処理と明確に区分されていた。そうしたシステムの運用管理においては、安定稼働とIT資産の有効活用が最大のテーマとなり、長期的な視点から立案された運用計画の下に「スケジュール管理」と「可用性の保持」という点が重視されてきた。

　それが今日、Webアプリケーションの急速な普及やB2C（企業対消費者）ビジネスの拡大などによって、ユーザー数の予測が困難になり、トランザクションは不定期に増減するようになった。加えて、不正アクセスやウイルス／ワームへの対策、企業間競争を勝ち抜くために追加される新サービス、次々と登場する新たなテクノロジーといった要因も重なり、企業情報システムの複雑化が大幅に進んだ。

　その結果、運用管理のあり方にも変化が求められるようになった。多種多様な要素で構成されるオープン系システムが主流となった今日では、障害を引き起こす問題がさまざまな個所で日々発生していると言っても過言ではなく、その原因の特定も容易ではない。かつての手法では、今日の運用管理には対応しきれないのだ。

　こうした事情に加えて、企業におけるITの重要性が高まるのと同時に、システム障害によるビジネス上の損失に対するIT/IS部門の責任も増大している。そのため、運用管理においても、個々のアプリケーションがどのくらいのビジネス価値を有しているかということは、無視できない要素なのだ。

　例えば、登録された数万人の会員に対して数千万円単位の高額な金融サービスを提供するアプリケーションと、無料の業界ニュースを配信するアプリケーションでは、言うまでもなく前者のほうがビジネス価値が高い。こうしたビジネス価値の異なるアプリケーションを1つのサーバ・マシンで稼働させる場合は、アプリケーションごとのビジネス価値に従って、ネットワーク帯域やCPUの使用率、ディスクI/O処理などを最適化しなければならない。サービス・レベルもビジネス価値に従った順守率に設定しなければならず、一律90％といったビジネス価値を無視した管理目標は何の意味もなさない。

　以上のことから考えると、今日の運用管理においては、複雑なオープン系システムにおける障害の防止と、ITリソースの最適配分が重要な課題であると言えよう。

　そして、アプリケーションを使ってビジネス価値を生み出すのはエンドユーザーである。彼らの視点で見ると、アプリケーションのパフォーマンスは「体感速度」として認知される。仮にサーバ稼働率がほぼ100％でも、レスポンスが遅くエンドユーザーがアプリケーションの利用を中断せざるをえないようであれば、その稼働率に価値はない。また、全体のネットワーク使用率が50％であっても、重要な業務のパケットが遅延しているのであれば、そのネットワーク構成は適切ではないということになる。アプリケーションのビジネス価値を生かすためには、パフォーマンス監視にあたってエンドユーザーが感じる体感速度に着眼することが不可欠であると筆者は考える。

パフォーマンス状況をユーザー単位で把握する

　体感速度に着眼したアプリケーション・パフォーマンス監視を実践するためには、エンドユーザーの状況を個別に把握し、現実のサービス・レベルを評価しなければならない。だが、これまでの運用管理ツールは擬似データ方式と呼ばれるものが多く、あらかじめデータ量／データ内容が設定されたテスト用トランザクションを実行して測定し、そこで得られた結果を基に統計処理を行ったうえで、パフォーマンス値を推測するというアプローチを採用してきた。

　しかし、現実のネットワークではデータ量とパフォーマンス低下は単純に比例するわけではなく、通信の断絶や突発的なピークといった特異点も数多く存在する。そうした事情も含めて個々のエンドユーザーが体感するパフォーマンスを管理者側で把握するためには、エンドユーザーのPCとアプリケーションとの間で発生する一連のトランザクションをエンドツーエンドで監視できるようにする必要がある。サーバのCPU使用率、メモリ使用量、ネットワークのトラフィックなど、システムを構成する個々の要素を監視したり、特定ユーザーのサンプル・データや平均値を分析したりするだけでは不十分なのである。

　言葉にすると簡単なようだが、このトランザクションは多数のサーバや複雑なネットワークを通過する。B2Cアプリケーションなどであれば、インターネットを経由した後にファイアウォールを超えなければならない。また、プロトコルに関しても異なる複数のものに対応する必要がある。こうした複雑なネットワークに存在する多種多様な構成要素に対してパフォーマンスを測定して初めて、エンドユーザーが体感するアプリケーションの実行速度を理解できるのだ。

　注意してほしいのは、監視対象とするトランザクションには、エンドユーザーが接続要求を出しながら、アプリケーションの利用を中断したものも含むべきだということである。そうしたトランザクションを考慮することで、画面が表示されるまでの待ち時間の長さにいらだち、エンドユーザーがアプリケーションの利用をあきらめたことを把握することが可能となる。換言すれば、障害によるビジネス損失の大きさを認識できるということだ。

　これがいかに重要であるかは、B2Cアプリケーションのケースを考えるとわかりやすいだろう（図1）。米国ガートナーとレスポンステックの調査によれば、78％のユーザーがオンライン・ショップの体感速度に満足しているが、残りの22％は不満に思っているという。さらに、その22％のうち実際に苦情を言うユーザーは2％にすぎない。苦情があれば対策を立てられるが、大半のユーザーが何も言わないため、サービス提供者は問題を把握できないまま、多くの顧客を逃がしてしまっているのが現状なのである。この点を考えると、アプリケーション利用の中断によるビジネス損失の大きさを理解できるだろう。

図1：パフォーマンス低下がオンライン・ショッピング・サイトにもたらす機会損失の例

現在の運用管理ツールに求められる5つの条件

　エンドユーザーの状況を個別に把握し、実際のサービス品質を評価できるということは、今日の運用管理ツールに求められている第1の条件と言えよう。

　第2の条件として挙げられるのは、プロアクティブ（事前予測）型の監視が行えることだ。エンドユーザーからの連絡があって初めて問題の発生を知るのでは、対応が後手に回らざるをえない。プロアクティブな検知が可能であれば、問題が表面化する前に、すばやく解決に向けたアクションを取ることができる。

　第3の条件は、問題のビジネスへの影響度を把握することである。今発生している問題に影響を受けているエンドユーザーの数、ネットワーク上におけるエンドユーザーのロケーション、エンドユーザーが損失する時間などの情報から、問題のビジネスへの影響度を把握できれば、優先順位を付けて問題に対処していくことが可能となる。

　第4の条件は、問題の切り分けを容易に行えることだ。パフォーマンス低下の原因となりうるのは、サーバ、ネットワーク、アプリケーションあるいはデータベースなどさまざまである。これらから迅速にボトルネックを特定できる必要がある。

　第5の条件は、導入と保守が容易であることだ。既存の運用管理ツールの多くはサーバへのエージェントのインストールや監視スクリプトの作成／保守が必要になる。だが、既存システムへの影響が少なく、保守が容易であることが望ましい。

｜1｜2｜ > 次のページへ