はじめに
アプリケーションの「監視」についてまとめた名著である、『入門 監視』を読み始めました。
記憶定着のため、簡潔に各章をまとめてアウトプットしてみようと思います。
第一章も読みましたがメモが手元に無いのでひとまず二章から…
項目まとめ
2-1 組み合わせ可能な監視
監視サービスのコンポーネント
下記項目によって構成されるが、モノリシックなツールでもこれらの要素が含まれる。
- データ収集
- データストレージ
- 可視化
- 分析とアラート
- アラート
印象的なのは可用性の項目。
仮にシックスナイン(99.9999%)の可用性であっても、年間ダウンタイム31秒 を考慮しておく必要がある。
可用性100%は現実的でない。
2-2 ユーザー視点での監視
ユーザーに最も近い部分で監視する
ユーザーに最も近い部分 とは下記のようなものが挙げられる。
- レスポンスコード(500系エラー)
- リクエスト時間(レイテンシの状況)
当たり前ではあるが改めて大切であると実感できる。
また当然、上記だけではなくミドルウェアやDB領域へも監視を広げていくことを意識すること。
2-3 作るのではなく買う
監視の初歩としてSaaSを使う形から自作ツールへ移行することもある。
ただし、下記理由から基本的にはSaaSを使う方が良い。
コスト
結局のところ自作ツールは作成に対しても、保守に対してもコストが掛かってくる。
- 作成工数
- 保守コスト
私たちはSaaSの専門家ではない
餅は餅屋である。
専門で監視のことを考えている人たちに頼るのが吉。
プロダクトフォーカス
自作ツールを作成する場合、どんなに早くても数日は掛かってしまう。
ドキュメント等の準備も考えるとSaaSを使うほうが手っ取り早く、プロダクト自体にフォーカスすることができる。
結局SaaSの方が良い
下記のような理由からSaaSを敬遠する人もいるかもしれない。
- プロダクトに対してSaaSの監視機能が物足りない
- セキュリティ・コンプライアンスの点を懸念
しかしながら上記については実際には 稀な話 である。
コスト面が理由になることもあるが、これも 偏った考え で拒否しているに過ぎない(アメリカ政府ですらSaaSを使用している…)
自前の構築チームの方が低コスト とでも言うのだろうか…
2-4 継続的改善
どのような企業でも1週間程度で監視環境を構築してきたのでない。
年単位での継続改善 によって現在の環境を作り上げてきている。
変化に応じて改善を継続することが重要だ。
おわりに
当たり前のことから、「言われてみれば…」という点までためになる章でした。
特に 2-4 継続的改善 には一人のエンジニアとして励まされると同時に、「努力しないとな…」となる項目でした。
今後も監視についての勉強を継続していきます。