システム運用における、5つの大間違いとは（4）

間違い4：システムの負荷上昇を障害検知

新卒でシステム管理部門に配属されたSは、先輩Tの指導のもとで新しいシステムの監視設定を任された。作業対象外のサーバーで設定されている監視項目を眺めてみると、ロードアベレージ（サーバーの負荷平均）ではなくCPU使用率の、しかもディスクI/O（外部記憶装置へのデータの読み書き）のみ閾値が設定されていることを見つけた。

Sは大学の授業で、「ロードアベレージが1以上ならダメなシステムだ」と教わってきたが、ロードアベレージに閾値が設定されていなかったため、Tに質問してみたところ、「DBサーバーだから」という素っ気ない回答であった。その回答に対して、理解に苦しむSであった。

以前はシステム負荷の監視など必要なかった

20世紀型のシステムでは、プリントサーバーやファイルサーバー、バックアップサーバーなど、単一の機能を持つサーバーが多く存在した。単一の機能しか持たないサーバーは、処理中に負荷が上がり、未処理時に負荷が低下することは自明である。

例えばプリントサーバーの場合、なんとなく処理が遅いと感じるときは、たいてい誰かが大きなファイルを印刷しているときだ。その処理が終わらない限り自分のファイルは印刷できないため、待ち続けるしかなかった。このように、サーバーに求められている適切な処理を行うために負荷が上昇するので、このシステムでは、サーバー負荷状況を監視することそのものに意味がなかった。

一方、単一機能のサーバーだけでなく、単一機能のシステムも多数存在した。

例えば、勤怠管理専用システムや会計処理専用システムなどの、各種専用システムがそれである。それら専用システムは、夜間にバッチ処理やバックアップ処理を集中させることによって、昼間の業務遂行のシステムリソースを確保するといったように、日中と夜間でシステムに求められる業務がそれぞれ決まっていた。このためシステム内のサーバー単位で、ある程度の負荷を予測し、システムの増強や縮小を行うことが可能であった。

今やシステム負荷の監視は必須となったが…

その後時代は変わり、複数のプリンタを管理・印刷しながら画像ファイルを同時出力するプリントサーバー、複数のオートローダーや複数の仮想ストレージを同時に利用しながらバックアップを行うバックアップサーバーといった、単一機能でも並列処理が可能なシステムが、市場多数出回るようになった。

また、会社全体でのコストダウンを目指し、システムごとに多数のサーバーを導入するのではなく、多数のサーバーを複数のシステムで同時並列的に利用するようにもなってきた。この代表的な例として、自社専用のプライベートクラウドなどが挙げられる。プライベートクラウド上には、勤怠管理システム用の仮想サーバーやスケジュール管理システム用の仮想サーバーなど、さまざまなシステムが同居することになる。