システム管理者とユーザーとで異なる「停止」の基準
IT運用管理は、ますます複雑化している。中でも、管理が難しいのがWebアプリケーションのレスポンスだ。
もちろん、ほとんどの企業がアプリケーションの監視は行っていることだろう。しかし、果たしてそれで十分に満足できるレスポンスを維持できているだろうか。
例えば、管理者はシステムが完全に停止していなければ、大きな問題ではないと判断しがちだ。一方、ユーザーは違う。レスポンスが大きく遅延すれば、それは感覚として「停止」に近い。
もし、ECサイトのような顧客向けサービスであれば、遅延によるストレスを感じた顧客がサービスの利用を敬遠することも十分に考えられる。また、企業内で利用する業務システムであれば、ユーザーの生産性を低下させる上、せっかく投資したシステムが使われなくなるという事態もありうる。いずれのケースも、ビジネスとしては大きな損失だ。
さらにWebアプリケーションの遅延は解決に乗り出しても、簡単には原因を特定できないという問題もある。
マルチクラウドやハイブリッドという言葉が示すように、現在、多くの企業のIT環境は複数のプラットフォームを用いて構成されている。システムを構成するコンポーネントの種類はますます多様化しており、ボトルネックを特定するために様々な可能性を想定しなければならない。
また、レスポンスが遅延しているのは間違いないが、明確な障害やエラーの痕跡がない上、常時問題が起こっているわけではないというケースも多く、このことも遅延の解決を難しくしている。
では、Webアプリケーションのレスポンスは、どのように監視し、遅延した場合には、どうやって解決すればよいのか。次ページでは、実際の企業事例を基に、それを考えていこう。