監視のデザインパターン
デザインパターン1 : 組み合わせ可能な監視
専門化させたツールを疎結合で組み合わせて総合的な「監視プラットフォーム」を作ること
監視の構成要素
専門化させたツールを疎結合で組み合わせるためにまず監視の構成要素を分解してみると…
- データ収集
- データストレージ
- 可視化
- 分析とレポート
- アラート
これらを一つずつ紐解いていく
データ収集
文字通りデータを収集する要素。
収集方法
大きく分けて主に2つの手法に分けられる。
- プル型……
- サービスがクライアントに対してノードの状況を送り付けてくるよう要求する。
- サービスが全てのクライアントを把握しスケジューリングしないといけないのでスケールしづらい
- プッシュ型
- クライアントが監視サービスに対して一定間隔あるいはイベント発生時に情報を送る。
- ポーリングを行う必要はないのでクラウド環境のような分散アーキテクチャに向いている
どちらにもメリットとユースケースがあるので使い方次第ではある。
種類
- メトリクス
- カウンタ……増加していくメトリクス。Webサイトの訪問数を数えるといった用途に最適
- ゲージ …… ある時点の値を表すメトリクス。現時点を表すため過去の値についての情報はない。時系列データベース（TSDB）に保存して過去のデータを取り出し扱う。主に扱うものはこちら
- ログ
- 構造化……キーと値がペアになっているようなもの。例としてはJson
- 非構造化…… 各フィールドに明確な意味のマッピングはない。例としてはApacheなどのログ
データストレージ
収集したデータをどのように保存しておくかを考える必要がある。データ次第では特別な方法で保存することになる。
上記で主に扱うと書いたメトリクス（ゲージ）での話になりますが時系列データベースに保存する。
ここにはタイムスタンプをキーとして値が保存される設計。
データを無制限には保存しておけないので「間引き」や「有効期限切れ」について考えなければならない。
データが古くなってきたら複数のデータを1つにまとめることである。例えば、1分ごとのデータを1週間後には1時間平均にまとめるなどしてディスク容量の確保やデータ読み出しの速度改善に使われる。
ログデータに関してはシンプルなストレージに保存するか検索エンジンに保存する方法がある。
より高度に検索や活用をしたい場合は後者のほうが便利である。
こちらもデータ容量に関しては圧縮や保存期間を設定して保存しておく
可視化
監視プラットフォームを目に見える形にする要素。たくさんのデータを収集することはよいことであるが目的に沿った形でデータを理解できないといけない。
目的に合わせてダッシュボードを構築すること。より良いダッシュボードはそのサービスやシステムを最も詳しく理解している人たちによって作られて運用されている時である
分析とレポート
監視データによっては分析とレポートの分野に踏み込むと有益なこともある。
よく使われる例としてSLA（サービスレベルアグリーメント）がある。
SLAの話が大半であったので割愛する
アラート
監視の目的を理解しないまま監視の仕組みを構築している場合が多い。こういう場合は何か起きたときにアラートを出すことが監視の目的になっている。
本書にはこう書かれていた
「監視は、質問を投げかけるためにある」-- Dave Josephsen, Monitorama 2016
監視=アラートではなくシステムをより知るためだと解釈しました。
収集しているメトリクスやグラフそれぞれに作った目的に合わせてアラート（通知）を設定すればよいと考える。
デザインパターン2 : ユーザ視点での監視
多くの可動部分から成り立っているシステムに対してどこから始めたらいいのか。
計測する必要な場所はたくさんありますがまずはユーザ視点が手を付け始めるのに最適な場所である。
ユーザがアプリケーションとやり取りするところをまずは監視に追加する。
ユーザから見ると裏側の構成なんて気にしていない（意識していない）のでとにかくアプリケーションが動いているほうが大切。
効果的に監視できる方法の1つがHTTPレスポンスコードを使うこと、その次がリクエスト時間（レイテンシ）である。どちらも何が問題かの特定はできないがユーザ影響が出ていることはわかる。
これにより個々のノードを機にすることから解放される。
（とあるサーバのCPUが急上昇したところでユーザに影響が出ていなければ問題なしとの考え方）
だだし、これだけ取っていればいいのではなく、万能でもないのでそれぞれのワーカーノードで何が起こっているかなどの監視へ広げていく。
広げていく中でも「このメトリクスはユーザへの影響をどう教えてくれるか」と常に考え設計すること。
本デザインパターンが実装するうえで一番参考になった。
実際の体験でもシステムに着眼せず個々の機に集中することをよく目にしていたのでこれはよい方法だと考える。
デザインパターン3 : 作るのではなく買う
実際にツールを導入する際に起こるツール依存アンチパターンに対する方法。
始めるにあたっては基本的な監視から始めてツールを気にするのは最低限にしておく
デザインパターン4 : 継続的改善
監視の仕組みの短い時間でできるわけもなく、日々改善していくこと。
もちろん、1年後には使われなくなることもあるがよい仕組みは長い期間にわたり継続した注意深さと改善から生まれるものである。
まとめ
- 組み合わせ可能な監視の仕組みはモノリシックな仕組みよりも効果的
- ユーザして優先での監視によって、より効果的な可視化ができる
- 監視の仕組みは可能な限り自分で作るのではなく買うことを選ぶ
- 常に改善し続ける
長々と書いてしまったがまずはデザインパターン2から考えるのがわかりやすく、重要だと考えました。