「入門監視」は名作なのでインフラエンジニアは読むべし

はじめに

とあるWEB企業でSRE（インフラエンジニア）として働いている者です。 社内環境はオンプレミスで、普段は数百のVMの構築、運用をやっています。

今更ですが、オライリーの 入門監視 を読みました。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

読んだ感想から申し上げると、とても参考になり、常に机の上に置いて指針にしておきたい本、と思いました。

監視、だけでなく、モニタリング項目を決める上でも非常に有用な本です。 ちょうど困っていたのでとっても有り難かったです。

何故困っていたかというと自分が所属する会社では、「何を監視するべきか？」という定義や理由が、いつのまにか社内に埋もれ、曖昧になり、その監視の意味も理解せず、「これまでも○と○は監視していたから設定する」という盲目的な状況だったんです。

Datadog/PagerDutyというモダン？な環境になったものはいいものの、 監視項目は移行前の項目をそのまま新環境で設定しているだけでした。

事例を、ググろうにも、監視の領域って各社毎に環境や設定、ツールも全然違うので、 なかなか調べても、これ！というベストプラクティスがなく、参考にしづらい状況でした。

そんな中、この入門監視という本は、一種のベストプラクティスを示してくれている本であり、非常に実用的だと思いました。

備忘録として、章ごとに自分が参考になった箇所や考えたことメモを記載していきたいと思います。

目次

第Ⅰ部　監視の原則
 1章　監視のアンチパターン
 2章　監視のデザインパターン
 3章　アラート、オンコール、インシデント管理
 4章　統計入門
第Ⅱ部　監視戦略
 5章　ビジネスを監視する
 6章　フロントエンド監視
 7章　アプリケーション監視
 8章　サーバ監視
 9章　ネットワーク監視
 10章　セキュリティ監視
 11章　監視アセスメントの実行
付録
 付録A　手順書の例：Demo.App
 付録B　可用性表
 付録C　実践.監視SaaS

参考になったポイント

第Ⅰ部　監視の原則

1章　監視のアンチパターン

第1章は監視にまつわるアンチパターンの説明で、とても耳が痛かったです。

自分がいる会社だと監視に関しては基本インフラエンジニアが担当し、設定と運用をやっています。アプリのログに関しても申請で受け付けて、設定、と流れです。

そうではなくアプリケーションエンジニアとして連携して、あるべき監視を定義するべきなんですね。。 （組織がでかいと、チームもオフィスも分かれるのでなかなか悩ましい問題ではありますが。。）

特に太字にした「OSのメトリクスに関するアラートは意味がない」、という箇所は目が点でした。これまで当然必要だろ！という感覚で設定していましたが、確かにカスタマーからすると動いていれば何も問題はないので、レイテンシやレスポンスタイムで監視するべき、という意見はまさにその通りだと思いました。

メモ

• ツール駆動なチームはミッション駆動なチームより効率的になることはない
• 監視ツールとダッシュボードは１対１に対応している必要はない。監視は複雑な問題の塊。全てを一つのツール、ダッシュボードに詰め込むと逆に非効率的
• 監視は役割ではなくスキル。チーム内全員がある程度のレベルになるべき
• アラートに関してはOSのメトリクスはあまり意味がない。動かすサービスによってはもともとリソースをたくさん使うものもある。例えばMySQLが継続的にCPUを全て使ったとしていても、レスポンスが許容範囲に収まっていれば何も問題はない。CPUやメモリ使用率のような低レベルなメトリクスではなく、「動いているか」を基準にアラートを送ることが有益
• 監視設定は１００％自働化すべき。各サービスは誰かが設定を追加するのではなく勝手に登録されるようにする

2章　監視のデザインパターン

1で述べられていたアンチパターンをベースにでは、ではどうするべきか？ということが述べられているのが第２章でした。

メモ

• データ収集を行うには二通りあり、プッシュ型とプル型がある。
  • プル型：サービスがリモートノードに対してノードの情報を送りつけるよう要求する
  • プッシュ型：クライアントがデータを他の場所に一定間隔、またはイベントが発生したタイミングでプッシュする
• もっとも効果的な監視ができる方法の一つがシンプルにHTTPレスポンスコード（特に５００番台）を使うこと。その次としてリクエスト時間（レイテンシ）が有益。このどちらも何が問題なのかは教えてくれないが、何かが問題で、それがユーザに影響を与えていることはわかる
• ユーザ視点優先の監視によって個別のノードを気にすることから解放される

3章　アラート、オンコール、インシデント管理

だいたいどの章も耳が痛いのですが、この章もそうでした。いらないアラートをたくさん設定しているなぁと思いました。 1,2章で学んだことから考えると、現在CPUやメモリみたいなOSのメトリクスに固定的な閾値を設けて、さらに超えたらPDに連携するよう設定をしてしまっているので、見直さないとなぁと思いました。太字にした変化量や傾きを注力するっていうのもDatadogだとannormalyモニタを作ればできるので、ディスク等の監視はそうするべきだと思いました。

メモ

• アラートにメールを使わない→アラート疲れの原因になる
  • 以下３つに分類する
    • すぐに応答が必要なアラート（電話）
    • 注意が必要だが、すぐにアクションは必要ないアラート（チャットルームに送る）
    • 履歴や診断のために保存しておくべきアラート
• 手順書を書く
  • 各アラートに紐づく手順書をリンクさせる。
    • なんのサービスで誰が責任者で、依存性、インフラ構成、どんなメトリクやログを送っているのか？どんなアラートが設定されていて理由はなんなのか？
• 固定の閾値を決めることだけが方法ではない
  • この値がXを超えた、という固定的な閾値だとディスクが急激に増加している（本当に知りたいケース）に気づくことができない。対象によっては変化量や傾きを閾値として設定した方が良い
• メンテナンス期間を使う
  • 監視抑止のこと

• 自働復旧を試す

  • 復旧手順が決まっているなら、アラート疲れを避けるためにコンピュータにやらせる

• アラートにメールを使うのをやめよう

4章　統計入門

システム運用における統計という観点で、meanやaverage,median,パーセンタイル等の基本的な用語についての解説されている章です。 Datadogを使っているとここら辺の用語が普通にでてくるので、いい復習になりました。

メモ

• パーセンタイル：データセットを照準に並べ、上位n%の値を取り除き、残った内での最大の値がnパーセンタイル値。バーストするようなデータに対して使用する

第Ⅱ部　監視戦略

5章　ビジネスを監視する

この章は数ページなのですがビジネスKPIと技術指標を結びつける、というSREとして働くうえですごく大切なこと書かれている、と思いました。 SREとしての監視、モニタリング戦略はまずSLO/SLI/SLAを定義することだと思うのですが、その大上段にはビジネスKPIがあって、それらと紐づいていないといけないんですよね。 この章ではあるサービスを例にビジネスKPIと技術指標を結びつける例がでていて、自分の中に溜まっていたモヤモヤがすっきりしました。 例 ビジネスKPI⇄技術指標 ユーザのログイン⇄ユーザのログイン失敗、ログインのレイテンシ

6章　フロントエンド監視

メモ

• ページのロード時間が一秒遅くなると平均でページビューが11％、コンバージョンが7％、顧客満足度が16％下がる。最適なページロード時間は2秒以下で5.1秒を越えるとビジネスに影響が出始める
• shopzillaはページロード時間が6秒から1.2秒に短くなったことで売り上げが12％増え、ページビューも25％増えた。Amazonはロード時間が100ｍｓ改善するごとに売り上げが１％増えることを突き止めた
• ページロード時間はどのくらいにするべきか？
  • 　→4秒以下を目指す。Amazonは2017年プライムデイでも2.4秒に保っていた
• 　計測：SpeedIndex（ユーザが体感するページのロード時間を計測。計測数値は短ければ短いほど良い）

7章　アプリケーション監視

• StatsD:コードの中にメトリクスを追加するためのツール。簡単さと柔軟性からモダンな監視スタックには不可欠な存在
• なんのログを取るべきか？
  • ロギング文をあちこちに書くより、アプリケーションの振る舞いについて考える。トラブルシューティングに便利な情報は何か？仕組の説明に有用な情報は何か？まずは自分達に問いかければ、必要なログ、メトリクス、アラートは明らかになる。
• ディスクに書くべきか？ネットワーク越しに送るべきか？
  • まずはディスクに書き込み、定期的に外部にデータを送るサービスを組み合わせる
    • アプリケーションの内部から直接ネットワーク越しにログを転送すると、トラフィックが増えるにつれボトルネックになることがある（度々ネットワークコネクションをはるため）

8章　サーバ監視

• OSのメトリクスは診断やトラブルシューティング等の正しいコンテキストで使えば有用で強力
• おすすめは自働的に記録されるようにし、アラートは設定しないでおくこと
• 取るべきメトリクス
  • CPU使用率
  • メモリ
  • NW
    • インターフェースのインとアウトのオクテット数、エラー数、ドロップ数
  • ディスク
  • ロードアベレージ
    • 代理指標として役立つ
  • SNMPをサーバ監視に使わない
  • WEBサーバ
    • 秒間リクエスト
    • HTTPステータスコード
  • DBサーバ
    • コネクション
    • 秒間クエリ
    • IOPS
• ロギング
  • 分析
    • HTTPレスポンス
    • sudoの使用
    • SSHログイン
    • cronジョブの結果
    • DBのスロークエリ

9章　ネットワーク監視

• NWの可用性をあげる→依存するものを改善するための「てこ」

10章　セキュリティ監視

11章　監視アセスメントの実行

筆者のコンサルティングを例に、これまで学んだことをベースにいかにあるサービスの監視を設定していくか、ということが述べられています。 この章もとても勉強になりました。

付録

付録A　手順書の例：Demo.App

付録B　可用性表

付録C　実践.監視SaaS

監視SaaSを選び、運用する上での重要なポイント等が記載されていました。 特に「ですよねですよね！」と思ったポイントが以下です。

• 運用をサービスに合わせる
  • SaaSを利用する上での鉄則はサービスを自分たちの運用に合わせるのではなく、自分たちの運用をサービスに合わせるということ
• 選ぶサービスはハッカビリティが備わっているか
  • APIが整っていて自働化がやりやすいかが大きいポイント

SaaSを導入しようとすると大体、『現行業務一覧と新SaaS基盤の業務紐付け表』、みたいな資料を作って「SaaSでできるかどうか○✖︎つけろ！」、みたいなナンセンスなことを言う人必ずいるんですよね。 そう言う人に付録Cだけコピーして送りつけたくなりました。

ハッカビリティが備わっていること、ということがとても重要なことも身をもって知っております。 APIが解放されていることによって、監視の追加や修正はterraform、 メンテナンスウィンドウ（リリーズ時の監視の抑止）の設定などは全てPythonを用いて効率化しています。

まとめ

回し者でもなんでもないのですが、とにかく素晴らしい本なので、私のようなインフラエンジニアで監視に悩まれている方にはとてもおすすめだと思います。

ビジネスKPIから技術的指標を結びつけ、実際にどのようなメトリクスを設定するか？という一連のあるべき流れが記載されています。 もちろんこんな上手くはいかないとは思いますが、非常に参考になります。

量も200ページに凝縮されていて、オライリーさんには珍しく（失礼）読みやすかったです。自分は現在３周目に入っております。

引用、参考本の書籍 入門 監視 ―モダンなモニタリングのためのデザインパターン