株式会社リゾーム 技術部 システム開発 第4グループの平松です。
読書会の第12回目のレポートです。 第11回目のレポートは、こちらになります。
tech.rhizome-e.com
12回目レポート
今回は、「付録C 実践 監視 SaaS C.6~C.8」で、参加者は5名でした。
それぞれの感想・意見交換
テスト駆動開発と監視
- ソフトウェア開発とテストがセットであるように、システム運用と監視はセットで語られるべき
- システム運用側の視点が薄かったかなと思った
- 監視とテストを同じ枠で考えたことがなく、頭の中で何か別のものとして切り離していた
- 確かに毎回テストしているようなものだ
- 燃料警告灯を付け忘れないのはそれが既に完成されているからであって、新しい何かを作るときは監視まで意識していないとできない気がする
- 今後はより本質的な捉え方をしていこうと思う
- 監視しやすいシステムを作っていくにはシステム運用と監視の両方の視点が必要になってくる
- そのシステムをどれだけ理解しているかが重要になってきそう
- システムの監視に自覚的にならないといけない
- ヘルスエンドポイントのように、開発していく中で、そういった観点は必要になる
自分で監視を作る
- テストは不安なところを書くべきとは自分もよく言っているのだけれども、監視も同じなのか
- 何を監視するべきかを知っているのは開発者自身…なのかもしれないが、だったらなんで開発者は何を監視すればいいのかこんなに悩んでいるのか
- ちゃんと自分たちの運用の不安と向き合う時間がいるんだよなと思う
- アラートが上がってるけれど、なにをすればいいのか？となったら、放置してしまいそう
- 監視はビジネスロジックを理解していないと作れない
- 「後で修正するときにテストがないと漏れる可能性ある」「テストなかったら常に改修で壊れていないかどうか心配しないといけないじゃない？」
- この考え方を監視にも当てはめて考えればいいのか
- SQLでデータベースの状態をメトリクスとして引っ張れるなら、色々計測できそうな気がしてくるが、具体的に何を取得したらいいのか悩むところ
- 締め処理など非同期Jobの結果が格納されるレコードのステータスなんかは見たほう良さそうだが、SC BASE*1は基本的にデータを蓄積していくアプリなので
- テストと同様に、開発しているアプリケーションの心配事を監視するべき
- でも何を監視するべきか悩んでいる...
- 「テスト」という観点だと、「仕様どおりに」「バグを起こさないように」といったことが考えられるが、監視という観点だと、どのような不安があるか...
監視を育てる
- ヘルスエンドポイントパターンに変更する…。監視も育てる思考
- たしかにヘルスエンドポイントパターンに移行すれば、テストが可能になるので良い
- 標準化の視点を持てる
- アプリを作成しているとバージョンアップや改修など、作りきりでないことは一般的になってきていると思うが
- 育てると聞くと、育てない場合の罪悪感が半端ない
- より良い監視の方法を模索し続けないと現状より悪くなることはあっても良くなることはないのでコードのリファクタリングなど同じで定期的な見直しは必要
- 今一度何が監視できていて、何が監視できていないのか整理したい
自動復旧のためのアイデア
- アラートのWebhookを使って自動復旧用のリクエストを行うわけか
- そういう発想自体がなかった
- 何らかの復旧が必要な異常を検知し、これを契機として作動させるということか
- 教科書に書かれている仕組みではなくて、応用みたいな話になってくるのかも
監視パラダイムの変遷
- 便利な反面に複雑化している昨今のシステム構成。
- 監視SaaSならば分散トレーシングにも対応しやすいというのは、確かにそうかも…
- 「Observability」、最近よく聞くワード
機械学習と異常検知
- 監視に対する機械学習の適用。たしかに膨大なデータがあるので、何かしら兆候を察知させるのに使えるのかも
- データが膨大にある監視SaaSならではのサービス
- こんなところにも機械学習の波が
- 機械学習の場合はデータセットの質や量にかなり影響されるかもしれないが、サーバー監視ならある程度揃っているだろうし使えそう
- 考慮漏れの可能性があるからレビューなどがあるわけでその部分を機械学習で補填してくれるのはとても便利
- 監視SasSは膨大なデータ量を扱うので、確かに機械学習を利用出来るな
- 標準的なメトリクスを監視することは有効ではないが、兆候を検知して通知するのは、長期的に保守していくBOND GATE*2で非常に助かりそう
監視SaaSのまとめ
- 昔に比べると監視のハードルはずいぶん下がっているんだから、自分たちの手で監視したいものを決めていけたらいいなと思った
- 監視の民主化は、今後取り組んでいくべき箇所
- 監視SaaS(New Relic/Mackerel)を利用して、みんなが見れる状態を整備したい所存
まとめ
今回は監視SaaSの活用や今後について各々、疑問や課題などを上げてそれについて話し合うことができました。 特に監視する上での考え方は今後、監視に取り組む際に必要な基礎の部分になるため、それを今回の読書会で学ぶことができてとても良かったです。 「入門 監視」を読む前は、監視についての理解も浅く、監視SaaSを導入してもあまり活用できてない状況でした。 ですが、この本から監視についての様々な知見を得ることができました。 すでに取り組んでいるものもありますが、今後、本から学んだことを実践してより充実した監視が行えるように環境を整えていきたいと思います。
「入門 監視」読書会はこれで終わりですが今後も、読書会を行いたいと思います。
