こんにちは、むおんせいです。

今の現場で運用のお仕事をさせていただき、早7年が経過しようとしています。

最近久々に同じチームに業界未経験の新人が入ってきて、運用について教えていたんですが
「これ文章に残しておいたら後々使えるんじゃないか」と思ったので、記録用に残します。

本日のテーマは冗長構成とシステム監視です。
今回は新人さんにもわかりやすくを心掛けながら書いてみます。

▼外から見えるプログラムと「見えないプログラム」

私の会社はシステムを作る会社なので、3ヶ月くらいJava(サーブレット/JSP含む)の研修をやって、あとは「OJTで実務やりながら覚えよう」みたいなスタンスで新人教育していきます。

でも、この研修でやるのはあくまでも「ユーザ顧客が利用するシステム」の作り方なんですよね。

実際作ったプログラムをサービスとして運用していくのであれば、運用者向けの仕組みも作らなければなりません。

運用者向けの仕組みのうち、重要なものとして監視があります。

これは、顧客向けのシステムが正しく動作しているかを確認するものです。

一般ユーザからすると簡単に止まるようなシステムはダメだと言われることもありますが、以前のノートでも記載させていただいたとおり、

サーバは故障するし、ネットワークは切れます。
更に言うなら、プログラマの方には申し訳ない言い方になってしまいますが、プログラムの不具合がゼロなどということはほぼありえません。

なので、ユーザから見ていかに利用出来ない状況を減らすかという発想でシステムを構築していきます。

まずは、監視のお話に入る前に冗長構成のお話からしていきましょう。

▼どっちかは生き残る「冗長構成」

前項でお話した利用出来ない状況を減らすためには、システム構成を冗長構成にすることを検討していきましょう。

冗長構成とは、本来1台で稼働できる機器を2台以上準備し、どちらかが故障した場合にもう一台に運用を切り替える構成のことです。

例えば、下記のようなFW(ファイアウォール)、WEBサーバ、DBサーバの構成でWEBサーバが故障した場合、顧客はその時点でWEBシステムが使えなくなってしまいます。

上記のようにWEBサーバが故障した場合でも、LB(ロードバランサ)などの機器を使ってWEBサーバを冗長化しておけば、片方のWEBサーバが故障しても、サービスとしては利用可能な状況を継続できます。

システムの稼働状況が高いことを優先するのであれば、③のようにネットワーク機器を含めすべての機器を冗長化するのが良いと思われるかもしれません。

しかし、機器が増えれば増えた分だけ、機器の購入費用、機器増加によるラックの維持費増加でコストがかさみ、サービスの収益を圧迫します。

収益を圧迫した結果、サービスが終了してしまっては本末転倒なので、サービスの収益状況を加味して、無理のない範囲で冗長構成を組むようにしていくべきです。

▼縁の下の力持ち「システム監視」

冗長構成にすればサービスの稼働率は上がりますが、それでもサービスが利用できない状況は発生します。

次の手段として、仮に利用できない状況であったとしても顧客が気づく前にサービスを復旧する、もしくは顧客が気づくよりも早くサービスの障害状況を報告し、サービスとして管理できている印象を与えなければなりません。

上記を実現するためには、サービスが利用出来ない状況になっていることにいち早く気付く必要があります。そのため、Zabbix等の監視専用システムを使い、顧客利用システムの監視を継続的に実施します。

なお、極端な例で考えると、顧客側の利用に対する欲求が低く、
平日9:00-18:00で稼働しているシステムで、最大1時間止まっても良いシステムがあれば、誰かが3時間毎に動作確認をし続ければ、それで監視は十分です。

しかし、昨今のWebサービスは24時間365日(通称:24365)で稼働している場合が多く、サービス品質を保証するSLA(サービスレベルアグリーメント)などで月間・年間で停止してよい時間は規定されているため、上記のようなユルい監視は現実的ではありません。

監視する際はサービスのSLAも加味して、どの程度の頻度監視をしていくか計画しましょう。

▼何が監視できるか

監視専用システムで監視できるものは主に下記です。

1. Webアクセス状況
　定期的にWebサイトにアクセスし、ログイン画面が表示されるかを確認する。ログイン出来なければ障害が発生しているとして、運用者に通知する。

2. プロセス監視
　プログラムが動いている時、OS内でプロセスと呼ばれるものが生成される。※画面がないプログラムでもプロセスは発生する。
　サーバがサービス(Web/DB/Mail等)を提供できる状況であれば、必ず特定のプロセスが存在する。
定期的にプロセスがあることを確認し、プロセスがない場合はサービスが提供出来ない状況と判断し、運用者にアラートを通知する。

3. ログ監視
　Webアクセスでログイン画面が表示でき、プロセスが正しく存在しても、必ずしも正常にシステムが動作しているとは言えない。
　プログラムが何らかの理由でエラーとなり、エラーログを出力し続けていることもある。そんな場合に備え、ログを監視し特定のエラーコードが出力されている場合のみ、障害検知し、運用者にアラートをあげることができる。

上記を組み合わせ、システムが正常稼働できるように監視していきます。

▼「本当にマズいもの」だけ緊急通知する

上記のように様々な方法で監視が可能ですが、
何でもかんでも緊急度の高い障害通知としてしまうと、運用担当の方が寝れなくなってしまいます。

障害通知は顧客業務影響を意識し、顧客の運用が止まってしまうものについては最優先の対応となるようアラートを上げ、即時運用担当が気付くような通知方法(電話での呼び出し等)とし、
それ以外のアラートについては、メールでの通知とするなど、障害レベルに応じて連絡方法を変え、運用担当者の負荷を減らすよう考慮しましょう。

▼まとめ

サービスを支える仕組みとして冗長構成や監視があり、こちらを利用することでユーザがサービスを利用できる状況を維持していることをお話しました。

システム開発をしている際にはあまり意識されない部分ですが、こういった観点を考えずにシステム開発を行うと、正常に運用ができず、顧客が利用できない状況を作ってしまうことがあります。

システム運用もサービスの一部です。開発SE・プログラマの皆さんは是非運用しやすいプログラムで運用者を助けてあげてください。

それでは、今日はこのへんで。
次回へ続く ->