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

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

（2007年03月27日）

エンド・ツー・エンドのパフォーマンス監視例

　それでは、体感速度の把握を目指したエンド・ツー・エンドのパフォーマンス監視手法の具体例を解説しよう。ここでは、コンピュウェアが開発／販売する「Vantage Agentless Monitoring」を取り上げる。これは、データを常時収集し、トランザクションを監視する製品である。監視対象にエージェントをインストールする必要がなく、監視シナリオを定義するスクリプトの作成も不要だ。

　図2は、Vantage Agentless Monitoringの配置例である。同製品は、下記の3種のアプライアンス・サーバで構成される。パケットをリアルタイムで収集／分析するには、きわめて高い処理能力が求められ、個々の製品で性能差が大きい汎用サーバでは、対応しきれないケースもあると考えられる。このため、コンピュウェアでは同製品をアプライアンス化して提供している。

図2：Vantage Agentless Monitoringの配置例

■Agentless Monitoring Device（AMD）

　AMDは、パフォーマンス分析に必要となる情報をネットワーク・トラフィックから収集するためのアプライアンスである。トランザクションが集中するスイッチのミラー・ポートまたはタップに接続してパッシブかつ定常的にデータを収集する。収集したデータのユーザーおよびアプリケーションを識別したうえで、それぞれのパフォーマンスを測定する。その測定結果をメタデータとして加工するという処理も行う。そして、さらなる分析／リポートのために、後述するVASとAWDSにデータを転送する。

■Vantage Analysis Server（VAS）

　VASは、Vantage Agentless Monitoringの中核となるリポーティング・サーバで、AMDから読み込んだデータをさらに加工し、分析リポートやアラートを生成する。監視項目に関して閾値をあらかじめ設定することで、その閾値を超えた場合にメールやSNMPトラップで運用管理者あるいは他の監視ツールに対してアラートを送信する。

■Advanced Web Diagnostics Server（AWDS）

　AWDSは、VASによるパフォーマンス分析／リポート機能を拡張するための解析コンポーネントである。より詳細にアプリケーションのパフォーマンス低下の原因を分析し、トラブル・シューティングに役立つ診断項目を含んだ分析リポートを生成する。例えば、Webページを構成するテキストや画像、テーブルといった要素ごとに、サーバの処理時間などを測定することを可能とする。

　Vantage Agentless Monitoringでは、3種のアプライアンスを通して得たデータを基に、Webブラウザ・ベースのGUIを用いてアプリケーション・パフォーマンスの監視や分析を行う。

「Vantage Agentless Monitoring」による問題解決

　ここでは、Vantage Agentless Monitoringによる問題解決の例を、「パフォーマンス低下の検知」「問題の切り分け」「ビジネスへの影響度の確認」という3点から説明する。

パフォーマンス低下の検知

　画面1は、アプリケーションのパフォーマンス状況を概観するための「Application Performance Overview」である。ここでは、3つのアプリケーションの状況を表示しており、各アプリケーションについて、ロードされたページ数（Pages）、ユーザー数（Users）、閾値以上のロード時間がかかったスロー・ページ数（Slow Pages）、アプリケーションのパフォーマンス（Performance）、スロー・ページの影響を受けたユーザー数（Affected Users）などの情報が記載されている。

画面1：パフォーマンス状況を概観するための「Application Performance Overview」

　「SSL_DECRYPTED」というアプリケーションに着目すると、パフォーマンスは97.9％と良好だが、ロードされた約47万4,000ページのうち約9,900ページがスロー・ページであり、それに影響を受けたユーザーは約3,030人のうち約1,690人、つまり55％と半数を超えるユーザーがスロー・ページに行き当たっている。

　では、どのページがスロー・ページになっているのだろうか。それを明らかにできるのが、画面2の「URLs Performance Overview」である。ここでは、各ページのURL（URL Name）ごとの情報が表示され、影響を受けたユーザー数（Affecte Users）でソートすることで、最も多くのユーザーが遭遇したスロー・ページ、すなわちビジネス上の損失が最も大きいページを特定することができる。

画面2：ページごとのパフォーマンス情報を詳細に示す「URLs Performance Overview」

問題の切り分け

　影響度の大きいスロー・ページを特定できても、遅延の原因となりうるのはさまざまである。「LOB Details」（画面3）では、スロー・ページの原因を、ネットワーク、データセンター、ページ・デザイン、クライアントなどで色分けしてパイ・チャートで示すとともに、原因の時間推移を棒グラフで示している。この情報を基に、パフォーマンス低下の原因を詳しく追求していくわけだが、Vantage Agentless Monitoringにおいては、特にページ・デザインにおけるボトルネック要因を追求する機能に特徴がある。

画面3：遅延の原因となりうる要素をパイ・チャートなどで表示する「LOB Details」

　通常、Webページはテキストやテーブル、CSS（Cascading Style Sheets）、JavaScript、画像などさまざまな要素で構成されており、ページ・デザインがパフォーマンス低下の原因であることが判明しても、これらの要素のうち、どれが根本的な原因なのかを特定できなければ適切な対策を施すことはできない。例えばJPEG画像のファイル・サイズが大きすぎる場合は圧縮率を高めたJPEG画像に置き換えなければならないし、JavaScriptの実行に時間がかかりすぎている場合はそれを最適化するといった対応が必要になる。

　「Load Sequence」（画面4）では、ページを構成する要素ごとにロードを開始したタイミングやロードに要した時間から、パフォーマンスを分析することが可能になっており、1つのWebページの中からボトルネック要因をピンポイントに特定することができる。ここでは、このページの構成要素のうち「gateway.asp」というASPファイルをサーバ側で処理する時間に8秒以上を要していることが示されており、これがスロー・ページの主原因であることがわかる。

画面4：ページを構成する要素ごとのロード時間などを示す「Load Sequence」

　また、ここで対象としているWebページがアプリケーションのユーザー・インタフェースとして機能している以上、SQLクエリがボトルネック要因となる可能性もある。Vantage Agentless Monitoringでは、クエリの発行回数や閾値を超えたクエリの数と、それらに影響を受けたユーザー数を把握することができ、アプリケーションのパフォーマンス低下が生じた時間に発行されたクエリを分析することで、データベース側の原因追跡にも対応できる。

ビジネスへの影響度の確認

　ここに挙げた以外にも数多くの項目が監視／分析の対象となる。それらの多岐に渡る監視対象からボトルネック要因を追求することで、エンドユーザーからアプリケーションに至るエンド・ツー・エンドのトランザクションをリアルタイムに監視し、エンドユーザーが感じる体感速度の向上を目指すパフォーマンス監視を実現することが可能となる。

　さらに、このようなアプリケーション監視で得た個々のエンドユーザーの待ち時間を合計すれば、パフォーマンス低下によるビジネスへのインパクトを数値化することが可能となる。画面5は、その待ち時間の合計値を示す「People Hours Lost」である。

画面5：パフォーマンス低下のビジネス損失を数値化できる「People Hours Lost」

　ここで再度、SSL_DECRYPTEDアプリケーションに着目すると、アプリケーションのパフォーマンス低下によって発生した全ユーザーの待ち時間（lost）は約24時間、そのうち可用性に起因するもの（lost〈availability〉）が約15時間、パフォーマンスに起因するもの（lost〈performance〉）が約9時間と示されている。そして、これらに加え、設定した閾値以内の待ち時間を含めた合計値（Total wait time）はおよそ9日半だ。

　以上、Vantage Agentless Monitoringによる問題解決の例を示した。最終的に得た値を無視できない損失と見るか、それほどのインパクトではないと見るかは、アプリケーションの重要度や企業の考え方などによって異なるだろうが、アプリケーションのパフォーマンス低下が発生したときには、適切な対応策を示す指針となるはずだ。

＊　　＊　　＊

　体感速度に着眼した監視手法は、ソフトウェアの更改やハードウェアの追加といった投資の必要性を役員たちに納得してもらうのにも役立つだろう。ビジネス損失の大きさと、検討した対策の妥当性の根拠となるデータは、すでに手もとにあるのだから。

（月刊Computerworld 2007年4月号に掲載）

前のページへ < ｜1｜2｜