サーバー監視で見落とされがちな超重要事項とツールの必須機能

サーバー監視における重要度・緊急度の例

システムを運用する上で重要なのは、サーバーの状態を把握し、サービスを安定的に稼働させることです。この記事では、サービスを安定的に稼働させるために必要なサーバー監視について、これまで10年にわたり、いくつもの大規模なECサイトの運用管理を経験してきた筆者が、ECサイトのシステムを例に説明していきます。

サーバー監視とは？
サーバー監視のミッション
サーバー監視2つの肝
サーバー監視で見落とされがちな超重要事項
サーバー監視ツールに求められる3つの機能
おすすめサーバー監視ツール2選
1. 5分で始められるSaaS型
2. エージェントレスのオンプレミス型

サーバー監視とは？

サーバー監視とは、サーバーの状態を定期的に確認し、異常が確認できたら直ちに関係者に知らせる行為です。

ここで言う「サーバーの状態」とは、CPUやメモリ、ディスクの使用率だけでなく、サーバー上で稼働しているアプリケーションのサービスなども含まれます。また、複数のサーバーで構成されているシステムであれば、ネットワークのトラフィック状況も含まれます。

サーバー監視のミッション

システムを運用していると、突発的にサーバーダウンが発生することがよくあります。ECサイトの場合、Webサーバーやアプリケーションサーバー、データベースサーバーなどの複数のサーバーで構成されますが、その分、サーバーダウンの原因もさまざまあります。

例えば、ユーザーからの急なアクセスの集中によるサーバー高負荷や、大量の商品情報の登録によるサーバー高負荷、また、バッチ処理やバックアップ取得などのシステム間連携処理の障害によるサーバーダウン、アプリケーションのバグによるサーバーダウンなど、意図しないサーバーダウンの発生原因はさまざまです。

当然、サーバーが止まれば売上も止まります。これを防止する、つまり、ビジネスを止めない。それこそがサーバー監視のミッションです。

サーバー監視2つの肝

さて、ビジネスを止めないというサーバー監視の本質がわかれば、重要なことが次の2つであることもわかります。

1. ユーザーに言われる前に障害に気づく

サーバー監視を行う上でもっとも重要な観点のひとつが、ユーザーが「このシステムがおかしい」と気づく前に障害を検知できているか、です。システムを運用する上でユーザーがシステム障害に気が付いて、システム管理者が異常に気が付いていないのは最悪の事態です。そんな管理者は「仕事をしていない」といわれても仕方ありません。

それがECサイトであれば、障害に気が付かないというのは論外です。

ECサイトの場合、Webサイトのページ表示に不具合が発生した際、システム管理者が気が付かなければユーザー（お客様）は不具合が発生したシステムを使い続けることになります。お客様が気づいて連絡してくれれば良いですが、なにも連絡せずに二度とサイトを訪問しないということもあり得るでしょう。その場合、売り上げの損失につながります。

このようなことを避けるためにサーバー監視ではユーザーに言われる前に障害に気づくというのが最低限必要になります。

2. ユーザーへの影響を最小限にできるよう初動を早くし対応を迅速化する

そしてもう一つ大切なのは、障害が起きてしまった時に、迅速に対応することです。システム障害をゼロにすることは不可能です。常にシステムの状態を監視し把握できていても、予測不能な障害は発生します。

繰り返しますが、その復旧に時間がかかればかかる程、そのECサイトのイメージは悪くなり、ユーザー（お客様）は離れていきます。すぐに障害を復旧させなければ、すぐSNSに書かれて炎上して企業イメージが悪くなってしまうことでしょう。

つまり、障害が発生したときに、すぐに原因を特定して復旧させ、被害を拡大させないことが重要なポイントとなります。

サーバー監視で見落とされがちな超重要事項

では、このような対応をするにはどんなことが必要でしょうか。ポイントは以下の2点になります。

1. 抜け漏れのない監視を実現するツールによる予兆検知

サーバー監視には監視ツールを使うことが必須です。サーバーが1台であれば自作のツールを使って監視できるかもしれませんが、複数のサーバーを管理することになると、自作ツールではすぐに限界がきます。

システムの異常にユーザーよりも早く気づくためには、監視ツールを使って各サーバーのCPU、メモリ、ディスク、ネットワークなどのリソース状況を把握することや、リソース使用率の閾値設定など、サービスを提供するうえで漏れのない監視設定をすることが重要になってきます。

たいていの場合、障害が発生する前にはリソースの使用率が増えるなどのサーバーの異常が見られます。その異常をいち早く検知し、事前に対応することでサーバーの障害を未然に防ぐことができます。

また、もし障害が発生した時、どこの部分に異常が発生しているのか把握することができれば、迅速な障害対応が可能になります。最近ではオンプレミスだけの構成ではなく、クラウド環境になったり、オンプレミスとクラウド環境にまたがったシステムになるなど、システムはどんどん複雑になってきています。そのような環境でも一元的に管理でき、抜け漏れのない監視ができるツールが求められます。

2. 検知した異常の緊急度・重要度の定義設定

そして何より、システム管理者がもっとも見落としがちな点が、検知した異常の重要度、緊急度が明確に定義されていないことです。

運用をしていると、アラートで異常を検知したときにすぐに対応しなければいけないのか、後で対応していいのか、人によって認識が全然違うことに気づかされます。

例えば休日にディスクの閾値が80%を超えてアラートが発生したとします。ユーザーへの影響が出てなく、翌日の営業日までディスクの空きは持ちそうなので翌朝の対応でよいと、自分では判断しても、会社の上司あるいはシステム納品先の人にとってはそうではなかったというような事があります。

「アラートの発生＝すぐに対応しなければならない緊急事態」と思っている人がたまにいますので、アラートの重要度・緊急度を定義してシステムに関係している人全員と認識をあわせないと、不要不急のアラートにも対応しなければならなくなります。

●●● 緊急度の例

緊急度　高　＝　すぐに対応が必要な障害：
お客様がサービスを利用できない

緊急度　中　＝　高ほどではないが、比較的すぐに対応が必要な障害：
お客様は使えるがシステム運用者がサーバーへアクセスできない

緊急度　低　＝　緊急度は低いが、調査が必要：
お客様は問題なく利用可能

●●● 重要度の例

重要度　大：
データベース関連やネットワークなど影響範囲が大きいもの

重要度　中：
WebサーバーやAPサーバーなど比較的影響範囲が小さいもの

重要度　低：
バックアップなど、サービスに関係がないサーバーの障害

●●● 具体例（夜間に異常を検知した場合）

DBの冗長化構成の1台が故障した
→サービスに影響がでていないので翌営業日対応
SSL証明書が切れてWebの表示画面にエラーがでるようになった
→サービスに影響がでているので即対応
DBのバックアップが突然できなくなった
→サービスに影響がでてないので翌朝対応
Webサーバーの1台がディスクがいっぱいになってアクセスできなくなった
→サービスに影響がでているので即対応
運用者がWebサーバーへアクセスできなくなった
→運用者は夜間利用していないので翌朝対応

※休日・夜間の対応は、ユーザー（お客様）が利用できないものについては即対応とし、緊急度の低いものについては、翌営業日の対応とするなど、運用を取り決める。

サーバー監視における重要度・緊急度の例

ECサイトの例で説明しましたが、システムごとに提供しているサービスやユーザーの定義、システム構成が違いますので、緊急度・重要度の定義はそれぞれのシステムによって変わってきます。システムに関連する人全員と認識を合わせ、必要な時に適切な対応を行うような運用をすることが大切です。

サーバー監視ツールに求められる3つの機能

さて、これまでの話を踏まえ、サーバー監視に求められるツールの機能がどのようなものか整理していきましょう。

1. 網羅的なシステム視点の監視

まず、CPU、メモリ、ディスク、ネットワーク、プロセスなどの監視項目が網羅されている事が第一です。オンプレミス環境とクラウド環境を併用している場合は、その両方に対応しているとなお良いでしょう。

ただし、監視システムの構築が面倒ではいつまでたっても実現しません。それほど時間をかけずに網羅的な監視を実現できることが求められます。。

2. 本質に迫れるユーザー視点の監視

また、サーバーの機能だけでなく、ユーザーが利用できているかきちんと把握できることが重要です。複数の監視ツールを導入してしまうと、管理が大変になるだけでなく、障害ポイントの判断に時間がかかることになりますので、一元的かつ網羅的にサーバー監視できることが重要です。

3. 緊急度・重要度の可視性

CPU使用率が99%を超えていてもそのサーバーの役割によって緊急度・重要度は異なります。ユーザーが利用できていることがわかれば、緊急度・重要度の判断もしやすくなります。これだけではなく、これらのアラートや通知メールが赤・オレンジ・緑といった色で示されれば、担当者は事態を瞬時に把握し、レベルに応じた適切な対応を取れるようになります。