予測ノウハウよりも定常的な性能監視が一番重要だよね

web

Webアプリケーション、というかサービスにおけるパフォーマンスは「要件定義が肝心」というのは良く見る。
だけど、実際に最も重要なのは(そして意外と無視されているというか成り行き的に忘れ去られるのは)、サービス開始後=運用中の「パフォーマンス監視」だと思う。そして、これが一番の落とし穴。
「パフォーマンスに影響を与える変数」は無数にあって、将来に渡って何かが予定外の変動を見せるケースなどを完全に予測することは実質不可能だ。結局、運用しているサービス(システム)の将来のパフォーマンスは約束できないことになる。スペックとかなんとか、やたらとバッファを取る(例えばスペックの良いマシンやネットワーク環境を準備するなど)ことである程度リスクを『軽減』することが可能だが、それは問題を先延ばしにできるかもしれない、という程度の話で、「予想外の事件」の幅によっては対策にならない。
つまり、何が起こるかわからないこんな世の中じゃ、起きたときにすぐ対応できるようにしておくほうがベター、ということになる。リスク軽減策とは別に、リスク顕在化時の対処方法とは別に、そもそもの「リスク顕在化検出」をフローに入れておかないといけない。

昨今の優秀なWebサービスプロバイダはこのへんはしっかりしているのだろうけど、まあ、まったくやられていないケースも多いんじゃないかなあ。私の知る少ない例だけで一般化は出来ないけど。

で、いろいろ方法はあると思うのだけど、ユーザーのイクスペリエンスを要件とするなら、Webサーバへの入り口から出口の数値を監視して統計的に俯瞰するのがいい。処理に時間がかかっていてもAjaxだったり、javascriptでゴマカシが効いていたりするなど考慮する余地はあるが。

  • 有償製品を使うなら RTbandwidth が優秀だった記憶がある
  • Javaベースの場合、案外導入障壁が低いのは ServletFilterを使うケース
  • Java+S2StrutsとかAOPが使える環境では、応答時間がしきい値を超えたときにログで警告してくれるようなInterceptorを実装するのも好例
  • Apache httpdの場合、粗いオーダーでいいならアクセスログの出力フォーマットで応答時間を記録することが出来る

ほかにもいろいろありそうだが、「忙しくて忘れ去られる系」なので、導入コストが低くてすぐにでも出来そうなのがいいよね。