システム障害の発生を早急に知るために最低限やるべきこと

こんにちは！CODE CLUB965のKです！

今回は、無事にシステムのリリースができた後の話しについて書きたいと思います。

苦労してシステムの開発を完了させることができ、無事にリリースができたら、その地点がある意味でスタートだとも言えます。
システムを安定稼働させて、業務を効率化させたり、売上を上げなくてはなりません。

システムが止まるような事態は極力避けなければならないし、障害が起こってしまったらなるべく早く復旧させなければなりません。

まずは障害の発生を早急に知る必要がある

システムの運用保守の基本は、まずは早急に障害の発生を知ることです。

例えば、東証のシステムであれば、止まれば大騒ぎになるので、すぐに止まっていることに気付くことができます。

しかし例えば、何十万人とユーザーがいるわけではない、小規模のECサイトではどうでしょうか？

システムが止まっても、大騒ぎになるわけではないでしょう。

訪れたユーザーが、サイトにアクセスできないのを確認して、ひっそりと離脱していってしまうだけです。
つまり、運営側が障害の発生に気付くまでは、機会損失が続くわけです。

これでは困ります。
かといって、運営者が定期的にサイトが動作しているか確認しにいくのも現実的ではありません。

そこで、自動的にサイトの死活監視をする仕組みを構築するのが一般的です。
例えば「5分に1回サイトのトップページにリクエストを投げて、レスポンスが返って来なければ、運営者にメールを送る」というようなものです。

この仕組みが構築されていれば、自ら見ていなくても、サイトがダウンした時には5分以内に検知ができます。

メールが来なければ、サイトが生きているということなので、安心もできますね。

DBの疎通まで確認する

先ほど書いた方法で、トップページが表示できるかどうかの確認はできるのですが、万が一、その先のデータベースサーバーがダウンしていた場合には検知ができません。

なので、もう一歩踏み込んで、DBの疎通まで含めて確認する方法があります。

それが、Webサーバーに死活チェック専用のAPIを用意する方法です。
例えば、/health-checkというようなAPIを用意して、そのAPIでDBにも接続するようにします。

そして、/health-check を5分に1回叩くようにしてやります。
Webサーバーが落ちるか、もしくはデータベースサーバーが落ちれば、 /health-checkは正常に動作しなくなるので、検知することができます。

このように、データベースサーバーまで含めて死活監視できるようにするのも、割と一般的に行います。

これで、最低限サーバーがダウンしていないことを自動で監視できるようになりました。

最低限であればこの程度なのですが、もっと監視をした方が良い項目があります。
それについては、また別の記事で紹介したいと思います。

それでは、また！

Follow me!