【読んでみた】入門 監視 ―モダンなモニタリングのためのデザインパターン

こんな本を買ってみました。

入門 監視 ―モダンなモニタリングのためのデザインパターン

最近ではクラウドを使っていれば当たり前にログは出てきますし、それらのメトリクスをダッシュボードにするサービスも当たり前になってきています。 ただ、ツールを使うことが当たり前過ぎて監視の基本を見落としている気がしたので、今回は読んで考えてみたことのメモです。

tl;dr;

• 監視に銀の弾丸はない

監視

監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。 入門 監視 ―モダンなモニタリングのためのデザインパターン

監視はシステムの振る舞いが想定したとおりになっていることを確認し続けるために行います。 その過程で、メトリクスやログ、アラート、など様々なテーマに分けられますが、大本にあるコンセプトはこちらになると思います。

監視の仕組みの全体像を示すとこのようになっているかと思います。

分析の位置づけは、やや微妙ですが、大まかにはこんなもんでしょう。

なぜやるのか/何を見るか

なぜ監視が必要なんでしょうか？

この問がおそらく最も重要かつ監視の設計を決める大元の問です。 例えば、

• 少人数でシステムの安定性を重視している
• ビジネス要件を重視している
• UXを重視している

など重視する点は様々ですし、そのために必要な仕組みは少しずつ異なるかもしれません。

システムのレイヤーごとにどのような監視があるかを下記に示します。

各レイヤーで見たい目的と観点は異なっています。 監視にはそれぞれ重視している観点と目的があって、必ずしも共通化できるものではないということです。

ビジネス

ビジネスの中でシステムを運用する場合は、必ずビジネス的な目標(売上、アクティブユーザー数、コンバージョンなど)があります。 その上で、それらを支える小さな単位のKPIがあるはずで、それらを監視することでビジネスがうまく行っているかどうかを確認することが目的になります。

これらのKPIに関してモデリングを行い、監視によって取得できる指標を紐付けます。 監視する際には、それらの指標がKPIに対してどう影響しているかを踏まえて監視を行っていきます。

余談ですが、この辺を考える上でデータサイエンティストは力を発揮するんだと思います。 KPIがあって、それに対してどの指標に注目して改善していく必要があるのかを選定するためには、モデリングというプロセスが入りますし。

フロントエンド

フロントエンドのパフォーマンス監視のゴールは、動き続けることではなく、素早くロードされることです。 入門 監視 ―モダンなモニタリングのためのデザインパターン

早い話が、ビジネスのKPIに大きく影響を与える要因の一つとして、フロントエンドのロード時間がありますよってことです。 これを軽視せず、ちゃんと監視し続けることは非常に重要です。

具体的に何を見るかという点に関しては、 Navigation Timing Level 2 を使用したりして、DOMの挙動について測定します。 簡単にやるなら、Google Analyticsを使うことですかね。

アプリケーション

もう少しサーバーサイドの話になると、アプリケーションの監視にいきつきます。 具体的にはアプリケーションの応答時間ですね。 アプリケーション自体や、ビルド〜リリースにおいて、どこにどれだけの時間がかかっているかを測定することで、改善につなげます。

面白かったのはhealthエンドポイントですね。 システムが正常に稼働しているかどうかの情報を取得するエンドポイントになります。 マイクロサービスを作るときなど、このデザインパターンは非常に有効そうです。

サーバー

OSな標準的なメトリクスとして、下記を監視することが一般的かと思います。

• CPU
• メモリ
• ネットワーク
• ディスク
• ロードアベレージ

そのほか、SSL証明書の期限なんかも確認すべきでしょう。（誰しも一度はやらかしたことを経験しているはず... ）

役割別だと

• Webサーバ
• DB
• メッセージキュー
• キャッシュ
• DNS

などは、それぞれの観点で個別に監視を行っていく必要があります。

ネットワーク

ネットワークはSNTPを使って、監視を行っていくようです。 この辺は、ネットワークの専門性が 必要で、あんまりよくわからなかったので、またの機会に。。。 (専門じゃないので、読んでもあんまりピンときませんでした)

セキュリティ

まったくわかりませんでした。 この辺もいつかちゃんと勉強します。(多分)

どうやって見るか

上で大まかな監視についての観点を示しましたが、それぞれのコンポーネントにおけるポイントを確認します。

監視サービスのコンポーネントは大きく次の5つになっています。

• データ収集
• データストレージ
• 可視化
• 分析とレポート
• アラート

データ収集

収集するものとしては、

• メトリクス
  • カウンタ
  • ゲージ
• ログ
  • 平文
  • json

となることが一般的です。 これらを収集する方法には大きく二種類あり、

• プル型(一定時間ごとにログを転送要求する)
• プッシュ型(特定の送り先にログを送信し、それを別のコンポーネントがreadする)

となっています。

データストレージ

こちらについては、とにかくデータの管理が問題になります。 メトリクスはまだしも、ログを愚直に保存し続けると、データ量は肥大化して痛い目を見ることになります。

直近のログについては保存しておき、古くなったログについては間引きつつ次第に破棄していくのが現実的な解法でしょうか。

可視化

ダッシュボードツールは様々ありますが、価値あるダッシュボードは、監視対象のサービスを良く理解している人によって作られ、自分たちで運用される必要があります。 こうした、良い可視化の条件を考えつつ、可視化とその周辺について取り組んでいく必要があります。

分析

監視の文脈で分析というとSLAが挙げられるかと思います。 ポイントは、目標と実態の差分を現実的な範囲で測定することです。

アラート

アラートは手段であって目的ではありません。 アラートは、サービスについての問を人間に投げかけるために行います。 そして、それを解釈して行動を起こすのは人間の役割です。

監視の仕組みの入り口

多くの組織では監視専門の仕組みを作るのはコストがかかりすぎます。 必要になったら独自の監視のサービスを検討すればいいとして、はじめはOSSやクラウドサービスを使いましょう。

有名なところだとPrometheusやDataDogなどがありますので、目的に合ったものを導入すればいいと思います。 ただし、監視に対する努力は継続していくものなので、ツールに縛られることなく、目的を見失わずに、必要に応じて拡張・開発を行うことを忘れてはいけません。

アンチパターンにもありますが、ツール依存は本当にだめです。目的を持って、最適な手法を常に追い求める姿勢が監視を改善していく第一歩かもしれません。

感想

本当は一年前くらいに購入してたんですが、積ん読になってました。 今回たまたま監視についてちゃんと取り扱う機会があったので読んでみました。

勉強になりました。