「予防」と「原因特定」

前項で、「サービスの監視」を実施していれば、サービスの継続性は監視できていると定義した。それでは、なぜ「サービスの監視」だけでなく、「インフラの監視」が必要なのだろうか。

「インフラの監視」は「、予防」と「原因特定」のために存在する。「サービスの監視」でエラーを検知するということは、エンドユーザーへのサービス提供が不可能な状態を意味するのだ。こうなると、機会損失は計り知れず、サービス継続のためには「障害の前兆を検知する」予防が必要となってくる。

「予防」と「原因特定」の具体例として、図3を示す。

図3 サービス継続可能な障害

図3では、web1とweb2は冗長化されており、通常は、web1とweb2の2台にアクセスが割り振られる。web1とweb2は、ともにアクティブであり、片側がダウンした場合、1台での運用となる。また、http://abc.comのコンテンツを表示するためには、WebサーバーからDBサーバーへ、格納されたデータを取得しなければならない。

「予防」

図3のような、webサーバーが冗長化された構成のシステムにおいて、web1サーバーがダウンしたことを検知することは、「予防」となる。web1とweb2のどちらかかが稼働していれば、http://abc.comへのアクセスは可能なため、直接的な影響は発生しない。

しかし、web1、web2の両系で稼働していたシステムで、web1がダウンした場合、http://abc.comは、web2のみでサービスを提供する片系の稼働になる。図4は、web1がダウンしたため1台での運用となり、http://abc.comを提供するサービスは継続可能となっている。そうなるとweb2サーバーは、web1サーバーの負荷も担わねばならず、web2の負荷状況に、サービス継続性が左右されてしまうことになる。

図4 サービス継続不可な障害

このような、「現状ではサービスの継続はできているが、安定したサービスの継続が難しい」という状況は、「サービスの監視」のみでは検知できないため、「インフラの監視」が必要となるのだ。

「原因特定」

一方、冗長化していないDBサーバーであるdb1がダウン（図4の下部）した場合には、WebサーバーとDBサーバーの連携が崩れることになり、データの同期に問題が生じ、http://abc.comにアクセスしてもエラーとなる。その結果、「サービスの監視」においてエラーが発生したという事実はつかめる。しかし、検知時点では、http://abc.comへのアクセスが不可であるということ以外の情報は判明しない、とも言える。

これでは、復旧作業にとりかかる前に、原因は外部の回線にあるのか、それとも内部の回線なのか、Webサーバーなのか、あるいはDBサーバーなのか、内部プロセスなのか、ハードウェア自体なのか、などなど、すべて検証して「原因特定」に努めなければならない。サービスの継続ができていない状態から、障害原因ポイント、復旧作業の特定のためにも、適切な監視ポイントを設けた「インフラの監視」は必要となる。