障害発生を考えていますか？

トラブル事例

「第1回：Javaで重要なことは開発ではない？」では障害対応について解説しました。今回は、障害発生を切り口として、どのように対処していくのかを具体的に説明してきます。

   実際にお客様のシステムで発生した障害において、このような経験はないでしょうか。

ケース1：障害が発生したのに、気が付かなかった

お客様から、「システムにつながらない」という連絡が入る。調べてみたら、障害が発生しており、連絡を受けるまで、まったく気が付かなかった。

ケース2：障害の原因調査に時間がかかってしまった

障害発生の連絡を受けて調査していたが、サーバの台数が多く、原因調査に時間がかかってしまい、暫定対処が遅れてしまった。

どちらも、いろいろな原因があるかと思います。では、それぞれのケースにおける対処法を説明していきます。
 

ケース1の対応法：サービス監視の実施

ケース1の原因は、「サービス障害監視を行っていない」ことでしょう。システム運用・保守を行っている以上、お客様よりも早く障害に気が付き、対応すべきです。

そのため商用製品・オープンソースを使った監視ツールを導入していることが多いのですが、監視対象がハードウェア、OSのプロセス、ネットワーク（ping）といった監視だけでは障害が発生しているのに気が付かず、このような経験をすることがあります。

ここで重要なのは、お客様が利用する形式（サービス）での監視です。そのためにも、必ずサービス監視を実施しましょう。

サービス監視はそれほど難しい仕組みではありません。典型的な仕組みは図1のようになります。
 

図1：サービス監視の仕組み

「サービス監視システム」は利用者と同じようなアクセスを定期的に実施します（図1-1）。アクセス先は「サービス監視アプリケーション」であり、このアプリケーションでサービスが稼動しているかを判断します。アクセスの際、通常と違うレスポンスの場合は、監視対象システムに障害が発生しているとみなし（図1-2）、障害の通報を行います（図1-3）。

 

サービス監視アプリケーションの作成

具体的に、監視対象システムがWebアプリケーションの場合を考えてみましょう。

まず、サービス監視アプリケーションについてです。監視対象システムがWebアプリケーションの場合、利用者と同じようなアクセス方法（図1-1）は、HTTP（もしくはHTTPS）通信になります。つまり、サービス監視を行うべき対象アプリケーションもWebアプリケーションになります。

サービス監視アプリケーションは「サービスが稼動していると判断する基準」に従って作成します。この基準はシステムによって様々ですが、「データベースアクセスを行い、1つのページを表示する」といった挙動ができれば、サービスは稼動していると判断してもよいのではないでしょうか。

そのほかにも、「すべての機能を実行する」「1つの機能を実行する」といった、より厳しい判断基準も考えられます。しかし費用対効果を考えると、1つのページを表示するだけで、ほぼ同等の効果を得ることができます。

以下はサービス監視用のアプリケーションの例です。

サービス監視用アプリケーションの例

サービス監視用アプリケーションでは、正常稼動時は固定のレスポンスとなります。そのため、サービス監視システムでは正常稼動時と異なるレスポンスのときにサービス障害と判断し、障害を通報します。