「システム負荷を監視する」ということ

“何のために監視するのか”を押さえなければ意味がない

システムの運用管理をする人に必要な姿勢は、「サービスの価値を最大限に高めること」です。言い換えれば、サービスがシステム全体で利用可能である状態を保証し続けることが、管理者に求められる責務でしょう。そのため運用を監視する必要があるわけで、例えば個々のサーバー負荷に対して閾値（しきいち）を設け、これを超えた場合に障害として検知するということが行われています。しかし、システム管理者に真に求められるのは、閾値を監視することではありません。

以前は単一機能しか持たないサーバーが普通でした。バックアップサーバーやプリントサーバー、ファイルサーバーなどでは、基本的にサーバー負荷状況を監視する必要はありません。例えば「誰かが大きなファイルを印刷していると処理が遅くなる」というように、適切な処理をするためには負荷が上がるのが当たり前だったからです。

次に登場してきたのは単一機能のシステムです。会計処理専門システムや勤怠管理専用システムでは、昼間の業務遂行に必要なリソースを確保するため、夜間にバッチ処理やバックアップ処理を行っていました。ある程度は負荷を予測できたので、サーバー単位でシステムの増強や縮小を行うこともできるようになりました。

現在では、並列処理が可能なシステムが普通になっています。例えばバックアップサーバーであれば、複数の仮想ストレージやオートローダーを同時に利用しながらバックアップを行えるようになっています。また、多数のサーバーを複数のシステムで同時並列的に利用するシステムも登場しました。様々な仮想サーバーが同居するプライベートクラウドはその典型例と言えるでしょう。

では、複数の機能を持つサーバーの負荷を予測することは可能なのでしょうか？　実際には、負荷上昇の原因を掴むことは困難です。サーバー負荷の特定には個々のサーバーによる差異や原因となっている機能の調査など、複合要因が絡みます。負荷が上昇しているのかと思ったらサーバーそのものの不具合だった、ということもあり得ます。閾値を設定して障害検知を行うことはデータ収集としては良いのでしょうが、システムの負荷状況という些細な変化までアラートで知らせるように設定しても、仕事が増えるだけでほとんど意味はないでしょう。

システム負荷を監視する立ち位置として大事なのは、本当に負荷が上昇しているのか見極めること、何を障害として検知すべきなのかを判断すること。それがサービスの価値を高めるために欠かせないことなのです。