「入門 監視 ―モダンなモニタリングのためのデザインパターン」を読んでみた
こんにちは！@Ryo54388667です!☺️
普段は都内でフロントエンドエンジニアとして業務をしてます！
主にTypeScriptやNext.jsといった技術を触っています。
今回は入門 監視 ―モダンなモニタリングのためのデザインパターン という書籍を読んだので、考えたことなどをつらつら書いていきます。書籍の内容の要約ではなく、かいつまんで紹介します。
📌 はじめに
このオライリーの書籍は、ホントに「入門」です！！
オライリーの書籍の中には~入門と題されていても、初心者には難しい内容のものもあったりします。オライリーあるあるですね。。
根底にある理論や歴史的背景が中心となり、まとめられています。
監視のデザインパターンや、サーバー、アプリなどの各種コンポーネントで取得する指標についても述べられています。
監視というと、ソーシャルメディアでは特定のTipsはよく目にします。
こうした個々の具体的な事例は見かけるのですが、それがどのような考え方を基底として行われた結果なのかは共有されることは稀なのかなと感じています。あくまで自分の観測範囲ですが。。
この現象は、ロゴデザインにおけるベースの背景が存在するのと同様の状況に感じます。
たとえば、ユニクロやNIKEのロゴは広く知られていますが、それらの背後にはフォントの工夫や黄金比といったデザインの基本的な考え方があります。監視に関するナレッジも同様の状況なのかな、と個人的には思っています。
この書籍を通じて、そのような根底にある理論を体系的に学ぶことができます。
インフラやクラウドのエンジニアに限らず、全てのエンジニアにとって必読の書籍ですね！
では、印象に残った部分をかいつまんで紹介します。
📌 ピックアップ
監視のデザインパターン
どのような考え方に基づいて監視体制を整えるとよいか書かれています。
- 組み合わせ可能な監視
特化ツールを組み合わせてプラットフォームを作成する。
入れ替え可能なように疎結合にしておく。- ユーザー視点での監視
はじめに監視を追加すべき箇所はアプリとユーザーの接点。
具体的には、HTTPレスポンスコード、リクエスト時間など。- 作るのではなく買う
初期の段階は監視SaaSを利用するなど、フェーズごとに考える。- 継続的改善
リリースして終了ではなく、常に改善し続ける。
項目３にあるように「フェーズごと」に柔軟に変更することを、あらかじめ織り込んでおく考え方が良いなーと思いました。確かに、アプリが成熟していないとき、監視の機能も自前で用意するのは困難で、SaaSを頼ることが多いと思いますし、さらに、運用フェーズになると取得したいメトリクスが増えてきて、SaaSでカバーできる範囲外に及ぶことも考えれます。
例えば、スタートアップフェーズでは基本的なシステムメトリクスとアプリケーションパフォーマンスの監視から始め、成長に伴いUXの監視やセキュリティ監視を強化していくようなこともあるでしょう。こうした時に、「恒久的に同じSaaSで運用する！」と決め打ちされていては柔軟な対応ができませんね！
フェーズごとに変更することが念頭にあれば、各種ツールとも疎結合を意識できるでしょう。もし、そのツールの運営母体が撤退した場合に、ツールが密結合だったら、目も当てられません。。
この考え方はインフラに関わるエンジニアだけではなく、アプリのエンジニアにも共有しておくべき考え方だと思いました！
「フェーズごとに柔軟に変更する」ことがアプリのエンジニアに理解されない場合、ややもすると、変更することに反対されたり憎まれたりするかもしれません。僕自身も普段はアプリ側にいる人間なので、こうした考え方に触れられてよかったです☺️
アラートの留意点
以下はアラート設定時に留意すべきポイントです！
- アラートにメールを使うのはやめる
メールを使うのではなくChat Room に通知するように推奨されています。緊急時の即時性と、情報が全員に閲覧可能であるため、情報共有がスムーズに行える点がメリットです。
- 手順書を書く
アラートが発生した際の対応手順を明確にするため、ドキュメントを作成することが推奨されます。手順書には、アラートの種類ごとにどのようなメトリクスが監視されているのか、どのチームが対応責任を持つのか、どのような手順で問題を解決するのかなど、詳細な情報を含めることが重要。
- 固定の閾値を決めることだけが方法と思わない
固定の閾値に依存するだけではなく、一定期間の変化量や傾きを監視する手法が推奨されています。
- アラートを削除し、チューニングする
定期的にチューニングをすることが推奨されています。アラートの過剰な発生は、「アラート疲れ」と呼ばれる現象を引き起こし、最終的には重要なアラートが無視される原因となります。オオカミ少年状態ですね！😅定期的にアラートをレビューし、不要またはあまり価値のないアラートを削除することが重要。
- メンテナンス期間
システムのメンテナンスやアップグレード時には、メンテナンス期間を設定して誤警報を防ぐことが推奨されています。これにより、メンテナンス作業によって誤ってアラートがトリガーされることを防ぎ、チームの焦点を本来の作業に集中させることができます。多くの監視ツールでは、メンテナンスウィンドウが提供されています。
6.自動復旧を試す
手動ではなく自動で復旧できるシステムを設定することが推奨されます。
こうした基本的な留意点を示してくれるのはありがたいです！
📌 まとめ
入門 監視 ―モダンなモニタリングのためのデザインパターンを読んで、いくつかの箇所をピックアップしました。
🔵 監視のデザインパターン
- 組み合わせ可能な監視
- ユーザー視点での監視
- 作るのではなく買う
- 継続的改善
🔵 アラートの留意点
- アラートにメールを使うのはやめる
- 手順書を書く
- 固定の閾値を決めることだけが方法と思わない
- アラートを削除し、チューニングする
- メンテナンス期間
- 自動復旧を試す
全エンジニアの必読書になりうる一冊でした！
最後まで読んでいただきありがとうございます！
気ままにつぶやいているので、気軽にフォローをお願いします！🥺
Discussion