4. 性能管理のためのシステム運用監視

　

性能管理のためのシステム運用監視
システムの開発が完了しリリースした後も、そのシステムに対して運用監視を継続的に行ってゆくことは、システム性能を管理する上で非常に重要であると言われて来ております。

特に、今日のWebのシステムのような、実際の負荷の予測が難しく、またシステム構成が複雑で単純な切り離しによる計測では把握しきれないようなシステムを扱う場合には、システムの計画・設計や、総合テスト段階における性能テストだけでは、性能管理を十分に行っているとは言えません。

もちろん、設計段階でのシステムの性能的な予測値や、リリース前の性能テストでの予測シナリオに基づいた負荷検証は、システムの性能問題を考える上でのモデルとして有用な理論的基盤になります。

しかしどのような管理にも言えることですが、理論モデルだけで現実経験のフィードバックが伴わないような管理手法では、現実的な意味を見失った空論に陥ってしまうことがあります。

そのため性能管理では、この現実経験のフィードバックを十分に行い設計や性能テストでの予測モデルとの関係の検証を行うことが、システム運用監視の重要な目的になります。

システムの現実経験とは
例えばWebシステムにおいて、フィードバックすべき現実経験とは何か？

簡単に言えば、サービス利用者にとってのシステム性能的な満足度に関すること全てがあてはまります。

具体的には、システムを使う利用者がシステムの応答速度や大量アクセス時の安定性に対して不満を持たないこと、また、利用者の視点で必要なサービスが正常に機能しているかどうかに焦点を置いて、システム側の問題点を検証することです。

なぜなら、ユーザーの視点に基かない他のシステム内部情報等による計測値は、利用者が満足するサービス提供という視点では、間接的で副次的な価値しか持たない情報に過ぎませんし、間接情報を元に利用者のサービス満足度を判断しようとすると、解釈という恣意的フィルターが更にかぶせられるため、指標としては好ましく無いからです。

そのために、利用者の視点やユースケースや操作に基づくシステムの計測や検証で、問題が無くなることを、性能管理上の目的として設定します。

そしてその計測で問題が発見された際には、問題改善を行う行為主体のアプリケーション開発者やインフラやDBの管理者に対して、適切な情報のフィードバックが行われ、改善や確認の活動を支援出来るように、例えば数値情報のような客観的で明確に伝達出来る形態の現実情報のフィードバックが行われることが望ましいです。

Webアプリケーション性能監視を行う組織体制
実際の情報の流れは以下の担当者順で渡されてゆければ効率的です。

* 上流工程設計・管理者
従来、監視というとネットワークやサーバーOSやプロセス等の死活監視を行うインフラ分野の運用監視担当者の役割でした。

しかし、Web アプリケーションの性能監視は顧客視点の性能や機能性のチェックが目的であるために、より上流工程を意識する担当者が担う必要があります。

それぞれのユーザー操作フローやユースケースのビジネス的な重みを識別した上で性能管理を行う必要があるためです。役割は問題の認識とそのビジネス的な重要度の定義です。

* インフラ運用管理者
システムのインフラの運用管理者は、上記の上流工程設計・管理者を補佐し、問題がどのレベルから発生しているかの切り分けを行います。
　
* 個別の設計・実装担当者
問題点が切り分けられた所で、DBやアプリケーションやインフラの担当者に渡されて、原因の究明と、応急の対応や、抜本的な対策などのアクションがとられます。

具体的なWebアプリケーション性能監視手法

* 死活監視では手遅れ
従来のシステム運用監視は、対象ホストにてPingでの応答が無かったり、サービス提供中の筈であるポートに対して外部から接続出来なかったり、アプリケーションのプロセスが落ちていたりするような場合に、即座に管理者にアラートを飛ばすというような、いわば障害検出型の監視でした。

しかし、障害検出が出来るタイミングは、システムのサービス提供が完全に停止してからになりがちですので、顧客サービス的には手遅れです。この停止が頻繁に起きるようなシステムでは性能監視に取り組む前に、この安定性問題の解明と対策を講じたほうが良いでしょう。性能監視はシステムの可用性が安定した上でさらにそのシステムが提供するサービスの向上を目指す為に取り組むアプローチであるからです。

* 直接的なユーザー体験以外のアラートは不要
上述の死活監視では無く、システムに対して各種の性能情報やシステムリソースの動態を監視することは性能管理上、意義があります。

しかし、例えばCPU使用率が100%になったとか、サーバーのコネクション数が500本を超えたとか、Pingの応答時間が100ミリ秒を超えたというような現象の全てにアラートのアクションを仕掛けたりして監視を行う必要はありません。

これらの指標は確かにシステムの動態を把握する上で貴重な情報です。しかし、アラートは本当にビジネス的な観点での問題に絞って上げられるべきです。具体的には、ユーザー操作時に起きる性能問題や機能性の不足で、これ一点に絞るべきなのです。

この的確に対象手法を絞った監視が出来ない場合には、多くの運用の現場で実際に問題となっているように、分野がかぶってしまいインフラ運用者が性能管理をやらざるを得ず、結果的にビジネス的なユーザー視点と乖離した運用になってしまったり、忙しい上流工程の担当者が監視のアラートを受け取ることを嫌がって、実際に性能管理が機能しなかったりすることになります。

過多な情報が提供された場合には、整理と抽出という作業を経て人が理解可能な情報に変換されなければなりませんので、もし、情報が多すぎる場合には、整理と抽出の作業量も膨大になり意味ある情報に辿り着く事に至らないという、情報量の多さと即座の有用性が反比例するパラドックスが存在するということを忘れてはなりません。

顧客の視点での応答速度劣化アラート
より少なく、しかし十分な性能問題の検出を行うためには、ユーザー視点でのユーザー操作における性能問題という、この一点のみに特化する必要があります。

ユーザーの操作上で問題があれば異常あり、問題が無ければ異常無しというシンプルな考え方です。性能監視の要点は基本的にこの一点でカバー出来てしまうのではないでしょうか。

ただし、ユーザー操作に基づくのならば、例えば、Webサービス上で

　　　“ログイン”→“メニュー選択”→“フォームへ情報入力”→“閲覧”→“ログアウト”

といったような一連の操作を全てエミュレートし、例えば、他のページでは問題が無くとも"閲覧"のページで応答速度が劣化していることを検出する必要があります。そのためにはログイン後のセッションを引き継いで後半のページにたどり着くような技術的にやや高度な監視手法も要求されることになります。

しかし、性能管理を行う上ではこの部分は欠かすことが出来ません。

レポート

* 性能劣化前後の各種詳細レポートグラフ
システムリソースや他のユーザー操作に直接関連しない応答速度については、性能管理においては、いちいちアラートを上げる必要は無いことを指摘しましたが、だからと言って、監視すること自体が無用なわけではありません。

例えば、実際にユーザー操作時の性能劣化が発生しアラートが届いた際に、まず、この現象が発生した前後のシステムリソースやその他関連項目の動態と比較分析を行うことで、原因がどこにありそうなのか洗い出すことが出来ます。

アラートに使われるページの応答速度劣化の監視はあくまでも「問題の発見」であり、　　「原因の追究と解明」にはより多くのデータソースから参考になりそうな情報を選び出して検証する作業が必要であるのです。そのために時系列推移を追って確認することが出来るグラフ形式のレポートと、他のデータソースの推移情報の蓄積が求められます。

* 長期間の傾向分析
また、レポートグラフで、比較対象として1年前の過去や、システム更新前の過去と現在の比較を行うことが出来ると、その変化の度合いを把握することが出来、有用です。特に一般的なWebシステムでは、バックエンドのDBのデータが蓄積されるにつれて、応答速度が徐々に劣化することがあるため、長期スパンの時系列変化の度合いを分析することには意義があります。また、応答速度以外のCPU使用率等のシステムリソースと、応答速度の経年変化の度合いを相関分析することで、システムリソースのサイジング計画を適切に行うことも可能になります。