サービス監視システムの構築

サービス監視システムの構築

続いて、サービス監視システムについてです。サービス監視システムは、以下の3種類の構築方法が考えられます。

1.ゼロから作成する

Windowsのタスク（もしくはUNIXのcrond）と、バッチファイルを組み合わせ、構築する

2.製品を利用する

商用製品やオープンソースを使い、構築する。ただし製品によって、HTTPSに対応していない場合がある

3.ASPサービスを利用する

ASPサービスを契約し、導入する

サービス監視システムを構築するときのポイントは、「アクセスの時間間隔」と「サービス監視システムの配置場所」です。

まず「アクセスの時間間隔」についてです。例えば1時間といった長い時間間隔でサービス監視を実施していても、障害の発見に時間がかかり、本来の目的は達成できません。逆に1秒や10秒といった短い時間間隔で実施していても、誤報の可能性が高まり、本来の目的を達成することができません。

例えば、冗長化したシステム構成では、障害の発生したサーバやネットワーク機器を切り離すのに1分ほどかかる場合があります。そのため、通報を受けて調査したら、サーバの障害はあったものの、サービスは正常に稼動していたと判明することが考えられます。

このことから、定期的なアクセスの時間間隔はシステム構成や業務要件に応じて決定し、定期的に見直し、修正したほうが良いでしょう。

次に「サービス監視システムの配置場所」についてです。サービス監視システムは、監視対象システムのネットワーク、サーバなどのシステムリソースを共用しないほど、お客様が利用する形式に近づき、良いサービス監視システムとなります。

例えばインターネット経由で利用するシステムの場合、サービス監視システムはお客様が利用する形式と同じく、インターネット経由でアクセスするように配置したほうがよいでしょう。

なお「2.製品を利用する」の例としては、オープンソースである「Big Brother」を使った場合の記事「Big Brotherによるネットワーク監視」も参照してください。
 

ケース2の対応法：障害原因の絞り込み

ケース2の原因は、「障害原因の絞り込みができていない」ことでしょう。特に大規模システムの運用・保守となると、ネットワーク担当、サーバ担当、アプリケーション担当といった複数のベンダーの複数の担当者が、それぞれ運用・保守を行います。そのため、障害原因の絞り込みを行う、連絡すべき担当者やベンダーを特定することで、暫定的な対処から根本的な対策までをすばやく講じることができます。

 

サービス監視の仕組みで絞り込みを可能にする

障害原因の絞り込みの方法は、今まで説明したサービス監視を少し発展させた方法となります。仕組みは図2のようになりますが、大まかな動きは図1のサービス監視と変わりません。定期的なアクセスのパターンを複数用意し、各パターンの結果を組み合わせることで、絞り込みを行います。
 

図2：障害原因の絞り込みの仕組み
（画像をクリックすると別ウィンドウに拡大図を表示します）

Webサーバ、アプリケーションサーバ、データベースサーバといった3階層で構成するシステムでは、以下の3パターンを用意すると、どのサーバで障害が発生しているか、絞り込みが可能となります。
 

パターン1

Webサーバの定期的なアクセス

パターン2

Webサーバを経由したアプリケーションサーバの定期的なアクセス

パターン3

Webサーバ、アプリケーションサーバを経由した、データベースサーバへの定期的なアクセス

ここであげた3パターンの組み合わせ結果から推定される障害原因箇所は、表4のようになります。