こんにちは、エンジニアリンググループ SREチームの高橋(@tshohe1)です。
「入門 監視」という本が各所で話題になっていますが、エムスリーのエンジニアリンググループでも予約購入していました！
監視というSREと非常に親和性の高いテーマの本だったこともあり、多くのSREメンバがこの本に目を通していたようです。 そこでぜひチーム内で感想を共有しようということになり、先日感想共有会が実施されました。
本記事ではそのときに挙がった感想を一部抜粋して公開したいと思います。
各章の感想
「1章 監視のアンチパターン」について
この章では監視におけるアンチパターンがいくつか紹介されていました。
思いっきり踏み抜いているアンチパターンなどもいくつかあり、今の監視環境を見直すいい機会になりました...！ 最初にこういう駄目なポイントを理由を添えて教えてくれると改善しやすくていいですよね。
感想共有会で挙がった意見：
- アンチパターンから始める解説わかりやすかった。
- 「リソース使用量などの低レベルなアラートはやめる」とあるが、現状エムスリーでは Load Average が一定値を超えた場合でもガンガンアラートメールを投げてしまっている。とりあえず、この辺はなくしてしまっても良さそう。
- 壊れやすいから監視を増やすのは良くなくて、サービス自体の回復力を高めたほうがいいとあるが、その通りだなと思った。問題の原因がわからないときはひとまず監視を増やすしか無いとは思うが。
- 監視設定は100%自動化すべき、とあるがなるべく早めにそのような仕組みを作りたいと思った。
- エムスリーでは一部のサービスディスカバリが出来ているものもあるがまだ多くは都度登録が必要になっているので、そのあたりをどうにかしたいと思った。
- 監視を設定している人はシステムの動作を理解していない状態だと、チェックボックス監視になりがち、ということなので、サービスの理解度が高い人にダッシュボードを作り込んでもらったほうがいいのかも？
「第2章 監視のデザインパターン」について
この章では監視のデザインパターンがいくつか紹介されていました。
その中でも私が特に共感したのは継続的改善のところです。
一度監視の仕組みを作って終わりではなく、課題が発生したら都度対応していくという姿勢はとても大事だなと思いました。そして、定期的な改善活動を実施しやすくするためにはメンテナンス性にも気をつけながら設計しないといけないなと。
感想共有会で挙がった意見：
- エムスリーだとltsvが結構使われているが、jsonのほうが階層構造扱いやすかったり、パースしやすかったりしそう（直接閲覧した場合の見やすさはltsvの圧勝だろうけど...）
- 「デザインパターン3: 作るのではなく買う」についてはトータルコストを考えて安くなると言っているのは合理的で良いと思った。
- SaaSってDatadog, Mackerelが良いのだろうか。
- Pindom, StatusCakeのようなシンセティック監視も紹介されている。
- デザインパターン4: 継続的改善についてとても大事だと感じた。
- 今は結構放置してしまっているノイズとなっているメールもあるので、改善したいと思った。
- 全部PrometheusのAlertManagerを通すようにしたらいい感じになるかも？
「3章 アラート、オンコール、インシデント管理」について
SRE本等の他の書籍でも書かれているようにアラートに区分を設けたほうがいいというようなことが書かれており、普段の個人端末へのアラート量を考えると非常に納得できる内容でした。このあたりについては、近々導入予定のPagerDutyでTicket/Pageといった区分で上手いこと通知を分けられるようになればいいなと思っています。
また、システムのことを伝えるためのドキュメント（手順書等）があったほうがよいという記載がありましたが、エムスリーでもサービス立ち上げ前にConfluenceに各種情報を記載するような運用にはなっています。しかし、この本で推奨されている依存性、アラート設定などの幾つか項目が抜けていました。確かにこのあたりも記載しておくとサービス停止時や移行時の確認の負担が減っていいですよね。（問題はちゃんと維持していけるか...）
感想共有会で挙がった意見：
- アラートをレベルで分けるという考え方はPegerDutyやSRE本とも通じるものがあると思った。
- アラートを受け取っても手順わからないと困る気がする。
- エムスリーではシステムの概要をWikiに記載しているが、記載が不十分なものもあるので、そのあたりもしっかり記載せねばと思った。（新規SREメンバのキャッチアップ的にも）
- 「このアラートは前にも見たな。数分したら勝手に消えるはずだから、何もする必要ないんじゃないかな」、あるある...
「5章 ビジネスを監視する」について
ビジネスKPIの監視も重要という話で、サーバのメトリクスよりはビジネスへの影響度が高いメトリクスを監視すべき、という旨の記載がありましたが、とても共感できました。
エムスリーでも各サービスごとにビジネスKPIがあり、各サービスの担当チームではその推移を逐次確認していると思うのですが、まだSLIとの相関などは見えていない状況です。なのでSLIの設定が適切かも実際のところよくわかっていないという...。
基本的にはPM等のサービスオーナ側で確認できていれば良いとは思いますが、SREとしても現状どのような値になっていて、どのメトリクスと相関があるのかは把握しておいたほうがいいのかなと思いました。
感想共有会で挙がった意見：
- 一部サービスでしかPrometheusでアプリのメトリクス取れるようになってないけど、他のサービスでも設定していこう。
- 今はSLIとビジネスKPIが結びついてるか実際のところ不明なので、相関を見えるようにする仕組みがあったら良さそう。
- みんなで監視するということなのでアプリ側の人にやってもらおう？
「6章 フロントエンド監視」について
レスポンスタイムと収益の関係性の実例が載っており、とても参考になりました。 この辺をまとめておくだけでも、SLO設定の際に参考になりそうですよね。ただ、サービスによって関連性はぜんぜん違うと思うので、ちゃんと自社サービスでも測るべきだとは思いますが。
「7章 アプリケーション監視」について
感想共有会で挙がった意見：
- APMツールについて、「これらのツールは、アプリケーションやその背後にあるビジネスロジックに関する何のコンテキストも把握していません」として、APMツールに頼りきってしまうことへの注意を喚起していて、なるほどなと思った。
- アプリケーション開発時にはログ設計だけでなくメトリクス設計も必要であり、後者にも前者と同じくらい熟考する必要がある、ということだと理解した。
- ログ設計だけでも困難な場合が多いのにメトリクスまで設計が必要となると、指針あるいは支援が必要になりそうだと感じた。（この本自体もそれの導入には使えそう）
- Distributed Tracing をちゃんと組み込むのは大変なのでまずは単体でちゃんとログを出すなどした方が良いと書いてあって、確かにと思った。
まとめ
長くなってしまったので、このへんで打ち切りたいと思いますが、その他のパートもとても内容が濃く参考になりました！
単純にサーバの監視をどのように実践していくかというプラクティスが載っているだけではなく、そもそも監視とはなんのためにすべきかといった監視の根本の考え方についても多く触れており、今後の監視構成を考える上で非常に参考になる本でした。
（それとNagiosやネットワーク監視への熱い思いもよく伝わってきました...!!）
自社でアプリケーションを運用している会社に勤めているのであればアプリエンジニア/インフラエンジニアを問わず、ぜひ読んでおくべき一冊だと感じました。そして、今回改めて感じた自社の監視の悪い点、足りない点を継続的に改善していこうと強く思いました...!!
We're Hiring!
エムスリーでは一緒にサービスの監視の仕組みを設計/構築してくれるエンジニアを募集しております！（また継続的改善も）
- 監視設定の自動化
- サービスディスカバリ
- Push型監視への移行検討
- 偽陽性の低いアラート設計
- バーンレートを利用したアラート設定（参考: http://landing.google.com/sre/workbook/chapters/alerting-on-slos/）
- 分散トレーシング（「入門 監視」ではまだ早いと言われてはいましたが...）
- 監視SaaSの積極活用
少しでも興味がございましたら、ぜひ下記フォームからお気軽にエントリーしてみて下さい。
