なぜサービス応答時間を測定するのか

ウェブ・アプリケーション・サーバ(以下WAS)でサービスの応答時間はユーザの満足のレベルをはかる物差しです。システムに一部ミスが存在しても、正常な応答時間内にリクエストがミスなく処理されれば問題にはなりません。むしろ、たとえシステムにミスや問題が見られなくても、ユーザが満足できる時間内に応答ができなければ、正常であるとはいえません。

このようにサービスの応答時間はシステムの正常区分を判断する一番重要な基準です。 そのためSLAでもユーザ 応答時間を一番重要な指標として使うのが最近の傾向になっています。 ここでは、 障害解決のための サービス 応答時間モニタリングの方法について説明します。

障害解決のための 応答時間の価値は、実は性能指標などの特性に起因します。 例えば、UNIXで vmstatにより CPU使用量をモニタリングすると仮定します。 CPUの 使用量が 95% 以上を使います。さらに瞬間的に 100%に達することもあります。これは問題でしょうか? ほとんどの システム 担当者はこれを 問題として指摘しません。ただ、現在の運用環境ではCPUをかなり使うという報告をする程度です。このような現象はリソース使用量が100%を超過する リクエストについて、よく分からないためです。いくら多くのリクエストがあっても、CPU使用量は100%を 超過することはできません。これがリソース モニタリングの限界です。

リソース 使用量は 100%を超過できない。

リソース モニタリングのもうひとつの限界は 全ての リソースをモニタリングできないことです。システム 内には多くのH/W的又は S/W的リソースが存在します。 CPU,MEM,NETなどをはじめヒープ MEM, Connection Poolなど数多くのリソースが 存在して運用者は これら 全ての リソースの 使用量を モニタリングすることはできないし、その必要もありません。ただし、運用時、気になるリソース、または重要なリソースを、　適切に指定してモニタリングすることは必要です。

システムの 全ての リソースを モニタリングすることはできない。

この様な二つの限界を克服する方法は応答時間を適切にモニタリングする事で可能になります。リソースのキャパシティを超過するリクエストが発生すると、応答時間は遅延します。リクエストが多ければ多いほど応答時間は長くなるため、 リソースのリクエストがキャパシティを超過したことを簡単に検知可能であることは重要です。また、 全てのリソースの使用量をモニタリングしなくてもサービスが使用するリソースをモニタリングし、障害解決を図るために応答時間をモニタリングすることは必須です。

リソースを超過するリクエストは 応答時間の遅延が現れる。

応答時間は 個別に モニタリングすべきである。

障害解決の観点で応答時間モニタリングはどのような方法で行うのか、 これを説明する前に、サービスとリソースとの 関係を考えてみましょう。 ウェブ システムで サービスは通常 HttpServlet.サービス()から始まり、終了されます。(WASによって少し異なります。) サービスが 実行される時、多くのクラスはDBにアプローチしてLDAPとコネクションできることもあるし、ファイルにアクセスすることもあります。 サービスが使用するリソースを定義するのは、数が多くて困難です。しかし、この様な リソースは 特定 URLリクエストに対してのみ 使用されることもあるし、CPU、ヒープ メモリのように全てのサービスで使われることもあります。つまり、サービスとリソースは N：M関係になります。

サービスとリソースは N：M 関係で明確に定義できない。

一般的な応答時間 モニタリングは平均ラインで表されます。つまりサービス全体についての平均応答時間をライングラフで表すわけです。しかし、全体の平均はシステムの状況(リソースの状況)を観察するのに効果的ではないので、サービスのグループを作って、このグループごとの応答平均ラインをモニタリングする必要があります。 グルーピングの一般的な方法は、入金業務、出金業務 など、業務単位でグルーピングすることです。しかし、これはモニタリング時、少し混乱を招きます。特定の業務グループだけの応答時間が遅延することもありますが、複数の業務グループの応答時間が遅延することもあります。 どちらにしても遅延が発生すれば原因を探すことになります。しかし、実は 応答時間をモニタリングする 根本的な目的は、サービス レベルを改善するためであって、単に応答時間そのものを知るためではありません。しかし、業務重心のグルーピングはサービスと リソースとの関係を基盤としないため、 応答時間遅延時、 根本原因を簡単に反映できないという特性があるのです。入金業務が 遅延した場合、入金業務の 特定サービスが 特定時点においてのみ遅延したのか、あるいはその時、入金業務だけが実行されたためなのかなどを反映しないため、改善ポイントにアプローチするには 限界があります。結局、これでは応答時間をサービス レベルを表す一つの指標程度にしか活用できておらず、それ以上の価値を表せないことになります。

サービス レベル改善を目的としたサービス応答時間モニタリングは個別に実行すべきである。

結論を言えば、サービス レベルの 改善を目的としたサービス 応答時間モニタリングは、グルーピングではなく個別に実行すべきです。個別リクエストに対する個別サービスの応答を別途包括的にモニタリングすべきです。そうすると、ある瞬間に応答時間の遅延が発生した時、関連トランザクションについてのみ集中的に分析する事で、簡単に実行されたサービス間の共通点を探して根本の問題に素早くアプローチすることが可能です。

サービスレベル 改善を目的としたサービス 応答時間モニタリングでサービスの 区分を正確に詳細にすることは重要です。もし、サービス名をHttpServlet.サービス()にする場合、 システムには一つの サービスだけが存在します。したがって、ウェブシステムでは URLを サービス名に使用するのが一般的で、最近は single gate servletを使う パラメータを利用して 実際 サービスに分岐可能な構造を 使用する システムがあります。しかし、この場合URＬだけではサービスの 区分は困難です。このような場合にはサービス名を意味する特別なRequest パラメータをサービス名で使用します。

もしサービス名の 区分がややこしい場合、サービス 基盤の各統計にもまた、ややこしい問題が発生します。また、プロファイル内容を見てサービスを区分するため、 チューニングにも難しい問題が発生します。したがって、サービス名が詳細に区分されることは、統計、障害又は性能改善に おいても重要な意味を持つことなのです。

ジェニファーは個別 トランザクションの応答時間が一目で分かる。

サービスとリソースは分析的に定義して関係を規定することはできません。しかし、個別 トランザクションの応答時間をモニタリングすれば、応答時間の遅延がおこったサービスの共通点を分析して問題のリソースを判断し、効果的に改善することが可能です。

ジェニファーは、XViewにより 個別 トランザクションの応答時間と該当トランザクションの詳細な流れをモニタリングできるようにします。 XViewで問題のありそうなトランザクションだけを選択して分析する事で、障害原因を効果的に判断できます。

サービス： ユーザのリクエストを処理するための応用プログラム
トランザクション：　サービスが実行された個別件