「Webエンジニアのための監視システム実装ガイド」を読んで

Observability

はじめに

f:id:muroon:20200414160209j:plain

Webエンジニアのための監視システム実装ガイドについていい本だったのでネタバレしない程度にご紹介させていただきたいと思います。

下記の点で非常に良い本だと思います。

  • Datadog、Prometheus、GrafanaなどのObservabilityに関連する技術の紹介は各所で見かけるようになりましたがそれぞれなんのために存在するか、また監視技術におけるどこの位置づけなのかを非常にわかりやすく教えてくれます。

  • システムの監視環境を構築について必要なことが目標設定から使用技術、組織・人為的な面に至るまで触れられてます。

  • トラブルに見舞われたときのエンジニアの対応方法や心構えなどについても記載されています。

各章について

1章 監視テクノロジーの動向

まず監視には異常検知・状況把握があります。監視とは狭義・広義それぞれ下記を示しますが、この本ではどちらも大事だと述べてます。

監視とは
内容
狭義 定期的・継続的に観測し異常を検知・復旧させること
広義 定期的・継続的に観測しシステムの価値を維持・向上させる営みすべて

また、監視テクノロジーが今日まで発展してきた経緯を〜2000年代、2000年代後半〜、2010年代〜、2010年代中盤〜に分けて説明しています。

2章 監視テクノロジーの概要

可用性(Availability)の計算方法や監視システムの各構成要素(チェック・メトリクス・ログ・トレース・APM)の位置づけを定義しそれぞれどのような関連があるかを説明しています。さらには自己修復機能とその必要性についても述べています。ちなみにChaos Engineeringとは自己修復システムを継続運用させるためのものです。

  • 可用性の測定方法
  • 監視システムの種類・構成要素
  • 自己修復機構について

3章 監視テクノロジーの基礎

メトリクスの種類・データ収集方式の基礎を述べた上で観測誤差や欠損が生じてしまうことなどメトリクスツールの基礎を教えてくれてます。 それと時系列DBとメトリクス結果の保存方法などメトリクスシステムの裏側の概要が説明されてます。 また、メトリクスだけでなくログの基礎技術についても触れています。

  • メトリクスの種類(ゲージ、カウンター)について
  • 観測誤差・欠損について
  • メトリクスのデータ収集方式(Push型、Pull型)
  • 時系列DBとメトリクス結果の保存・閲覧方法について
  • ログの基礎技術

4章 監視テクノロジーの導入

SLIやSLOなどの数値的なものも含めて目標設定の必要性、それに対してどのような通知計画を行うべきなどを説明してます。 そのためにはステークホルダーの洗い出しなど監視システム設計を行うための情報収集・整理が大事です。 目標設定、ステークホルダーの選定、ドキュメント整理、各監視ツールの選定のポイントなどがまとめられています。

  • 異常検知も大事だがそれのみに注意を向けるのではなくSLI導入が大事
  • アラート通知の出し過ぎは注意
    • 通常・正常・異常の判断
  • SLIやSLOなどは元となる情報がないと設定できないので闇雲にはつくらない
    • 中度半端な情報をベースにとりあえずの感じで作らない
  • ステークホルダーの洗い出し
    • 組織・体制観点
    • 製品・サービス観点
  • ドキュメント
  • テスト(検知・発報)
  • 監視ツールの選定
    • Agentのインストール
    • 監視対象からのデータ収集方式
    • アラーティング機能
    • コミュニケーションツールの選定
    • ドキュメントツールの選定
    • チケットツールの選定

5章 監視テクノロジーの実装

監視システムを実装していくために抑えておくべき項目を説明してくれてます。 まずはアラートの目的と観測項目(無尽蔵なアラートはかえって形骸化を生む)。 そして、レスポンスタイムなどエンドポイントのモニタリングからCPU使用率などのOSのモニタリングなど定番の観測項目について取り上げられています。

  • アラート通知の有無の判断
  • アラートの目的と観測項目を決める
  • 定番の観測項目
    • エンドポイント(レスポンスタイムなど)
    • 物理インフラ層(CPUファンの回転数など)
    • ネットワーク(送信・受信データ量・パケット量など)
    • OS(CPU、メモリ…)
    • ミドルウェア(Webサーバー・DBなど)
    • フロントエンド(Javascript、コンテンツ)
    • ビジネス(KPIなど)

6章 インシデント対応実践編

インシデント(トラブルなどの事象)対応に対してエンジニアはどのように準備、対応を行えばいいかを技術面だけでなく精神的側面について述べられてます。 どういう理由でどういう人事配置が大事か、それぞれがどういう心構えや行動をすべきかなどが記載されています。 また、p162のトラブルシューティング時の思考について書かれたコラムはおすすめです。プレッシャーがかかるときこそ論理的思考が大事だということがわかります。

  • インシデント対応の基礎知識
  • インシデント対応の心構え
  • インシデントの各ステータスOpenで行うこと
    • 事実確認
    • 暫定対応
  • インシデントの各ステータスResolvedで行うこと
    • 振り返り
  • 恒久的対応・改善対応

7章 監視構成例

チェック・メトリクス・ログ・トレース・APMの構成を旧来型OSS、最新型OSS、Saas型のツール・サービスを使用した場合を構成図にまとめて説明してくれています。 例えば、旧来型OSSならNagiosを中心としてOSSを使用した構成、最新型OSSならPrometheus、Jaegerなどを使用した構成です。 各ツールがどういう位置づけにあるかがひと目でわかります。

  • チェック・メトリクス・ログ・トレース・APMの構成図
  • 通知・コミュニケーション・ドキュメント・チケット例

最後に

個人的にはk8sを使用した自己修復機能やカオスエンジニアリングなんかに興味があり、いつか携わってみたいと思ってます。 ではなぜそれが必要になるのでしょうか？ かえってコストがかかる可能性もありますし、リスクを犯して導入する必要はあるのでしょうか？

この本を読んでいて1章の「監視とは"定期的・継続的に観測しシステムの価値を維持・向上させる営みすべて"」とあるようにシステムの価値の維持・向上の為だと思いました。 そのためにもSLIなどの目標設定を設け、そのシステムが有るべき価値を定めてから監視システムを導入・運用していく必要性があると感じました。