今週末を使って、入門監視を読みました。 以前話題だったときに読めば良かったので、少し乗り遅れた感はありますが、良書でした。
入門の名に恥じない内容で、監視に対する考え方が広く学べます。 読み終わったので、感想や覚えたことをメモします。
監視の重要性
私はWebアプリケーションエンジニアを生業としていますが、多くのWebサービスは常時稼働を基本としているため、監視とは切っても切れない人生です。 ECは24時間いつでも商品を購入できるし、今記事を書いているはてなブログも、いつでも記事が書けます。
しかしながら、サービスは突然の障害で落ちることがあるため、それを検知するための監視は欠かせません。
サービスが落ちる理由
私が過去に経験しただけでも、多種多様な理由があります。
- ディスクフル
- アクセス過多（DOS攻撃）
- サーバー故障
- SSL証明書の期限切れ
- アプリケーションのバグ・・・など。
監視の始め方
監視の重要性は前述した通りですが、それでは監視のないサービスに監視を導入するには、どうすれば良いでしょうか？
ユーザー視点から始める
本書を読んで最初に感心したのは、『ユーザー視点から始める』というアプローチです。 つまり、実際に稼働しているサービスにアクセスすることで、期待する応答が返ってくるかを検証します。
いわゆる外形監視です。
ユーザー視点で足りない部分を補う
ユーザー視点の監視でも相応の効果が得られそうですが、たとえばロードバランサーで4台のサーバーに負荷分散している場合は、1台だけ故障しても3/4の確率でアクセスは成功します。
まずは始めやすい外形監視を基本にしつつも、その後、監視対象を個々のサーバーへと拡張していくのが良さそうです。
アラート対応について
『ディスクがフルになった』『Webサーバーが落ちた』といった障害は、いつ発生するかわかりません。 監視を導入することで検知はできるようになりますが、そこから先の具体的な障害対応は、もっと重要です。
本書にはオンコール担当という、何か問題があったとき呼び出しに答えられる担当という例が登場します。 また、アラートは深夜も祝日も関係なく発生する可能性があるため、基本的にアラート対応は疲労する仕事です。
私自身も、いつ障害が起きるか分からず気の休まらない日々から脱却したくて、Webエンジニアをやめたいと思ったことが何回もあります。
アラート対応の方針を決めよう
前述した通りアラート対応は疲れる仕事なので、負荷を下げるための工夫が必要です。
- 代表的な障害対応は事前にマニュアル化しておくことで、対応時の負荷を下げる
- アラート対応メンバーをローテーションすることで、特定メンバーだけ疲労することがないようにする
- 自動復旧できそうな障害であれば、自動復旧の仕組みを入れておく
これらは、組織やサービス単位で検討するのが良いでしょう。 大前提として、監視の導入とアラート対応はセットで考える必要があります。
ビジネスを監視する
本書の第2部は、サーバやアプリケーションといった、個々についての監視戦略です。 フロントエンド監視は軽視されがちなので得るものも多かったのですが、個々の中でも初耳だったのが、ビジネス監視です。
ビジネス監視という言葉ははじめて聞きましたが、読んでみたら意外とすでに、実践している企業も多そうでした。 たとえばGoogle Analyticsで広告のクリック数やPVを監視（計測）したり、ビジネス用のKPIを監視（計測）するために、Google Analyticsを導入しているサービスは多いと思います。
まとめ
監視についての基本的な考え方がわかる、良い本でした。 オライリーだけど厚くないので、さくっと読めるのも良いです。
後日再読して、理解を深めておきたいと思います。 （余談ですが、アラート対応だけでも1冊の本になる気がするので、もし続編で入門アラート対応があったらぜひ買いたい）
