memo.takur.in

Appearance

Return to top
On this page

【読書感想文】入門監視を読んだ

2024-02-28

あまりに自分が監視まわりの知見がなく、もう少し知っておきたいなと思ったので、今更ながら入門監視という本を読んだ。

https://www.oreilly.co.jp/books/9784873118642/

具体の手法の話や特定のツールの話というよりは、監視におけるアンチパターンであったりデザインパターン、APM から OS、ネットワークの監視、監視に対する心構えみたいな感じのメタ的な部分についての内容がメインだった。

全体的な感想

今回そもそも

  • 自分に監視の知見がない
  • チームでそういう話をする機会があった

あたりが背景としてあった。その上で読み進めたのもあって、具体のケースを想像しながら読んでみたが、できている・できていないが見えたり、耳が痛いシーンがあったりして面白かった。

最初に、監視に銀の弾丸は存在しないということが書かれていた。監視の基盤を作ってもその後の継続的な改善が必要だったり、ビジネス的に本当に必要なものを考えたりと自分たちの監視の仕組みとソフトウェアに継続的に向き合うことが一番大事なんだなと再認識した。

また、自分は監視はアラートを出してシステムの不具合に気づくためのものだと思っていたが、実際はそうではなくアラートは結果としての形であり、監視は質問を投げかけるためにあるということが書いてあってハッとした。大事なのは継続してソフトウェアを監視することであり、アラートを飛ばすこと自体ではないということを認識できた。

各章ざっと振り返り

割と 1 章と 2 章が 1 番参考になったかもしれない。（そのため感想のボリュームにかなり差がある）

自分たちに足りないものややっておきたいもののケースが具体で話されていたからそう感じるのかもしれない。

逆に、ネットワーク監視から後ろはあまりイメージが湧かなかったりした。知見のなさかもしれないので別で深める機会が欲しい。

最後の監視アセスメントについては実際の例題を元にケースが書いてあって面白かった。

1 章 アンチパターン

1. ツール依存

業務をする上で、このツールを使えばいいというような銀の弾丸は存在しないということが書かれていた。

現在のツールの課題を非難して乗り換えたとしても、半年後には同じような話をしてる…。

ざっくりメモ

  • 監視は常に苦痛が伴うもの
  • 必要であればツールを増やすことを躊躇しない
    • そういえば sentry と併用してる理由ってなんなんだっけ？
      • エラー通知とアラート・ログ収集みたいな棲み分け？
      • どっちも datadog でできるし、どちらか片方でいい？
      • 監視とは別の文脈だけど、ブラウザテストとかもこの類な気はする
  • カーゴカルトなツールは避ける
    • 本来の目的を見失わないようにする
  • 時には自分たちでツールを作らないといけない
    • しかし、大抵の場合は不要

2. 役割としての監視

監視する専門のチームや人が存在してもいいが、そこに全責任を押し付けるのはアンチパターン。自分たちで理解していないソフトウェアを監視する仕組みを作るのは難しいため、普段からコードを触ってない人がそれをやるのは無理がある。

また、監視は特定のスキルではなく、チーム内の全員がある程度のレベルに至っておくべきということが書かれていて、これはかなり耳が痛かった。

ざっくりメモ

  • 監視をする専門部隊はいてもいいが、普段からそのソフトウェアを作ってる人が監視するべき
    • ある程度チームの全員が知っておく必要がある
    • 理解してない人が監視の基盤作るのは難しい
  • 監視はソフトウェア開発の最優先事項
    • 耳が痛い

3. チェックボックス監視

割とやりがちな「これを監視しています」リスト。これは全く物事の本質に向き合ってないということが書かれていた。

2 の役割としての監視と通ずるが、何を持ってして動いてる状態なのかの理解が進んでいないとこのようなことになる。また、属人化してるとこういうのが起きがち。

また、アラートに関しての話だと OS のリソース使用量などの低レベルなアラートは意味がないのでやめるということも書かれていた。（動いているかどうかが大事）

ざっくりメモ

  • これをチェックすればいい！というようなチェックボックス式の監視は意味がない
    • 何を持ってして動いてる状態なんだっけ？を考える
      • 自分たちのソフトウェアを理解することがチェックボックス監視を避ける一番簡単な方法
  • アラートに限っては OS のメトリクスはあまり意味がない
    • リソース使用量などの低レベルなアラートはやめる
    • リソースが増えてても動いていれば問題ない
    • 動いてるかどうか基準にアラートを投げることが重要
    • ただ、パフォーマンスに影響を与えるようなリソースの変化は大事なので監視はする
  • 2 の役割としての監視と一緒に見つかることが多い
    • 割とこれは属人化してる組織でも起きそう
    • 理解してる人が考えた最強のチェックリストを理解してない人（自戒）がチェックリストに従って作りました、みたいな
    • 理解してる人はもうチームにはいませんみたいなところまでセットで…。

4. 監視を支えにする

監視は問題を通知するのに長けているのであって、修正しないと直らないし、そもそも監視は壊れたシステムを直してくれない。

それよりは、サービス自体を安定して回復力のあるものにする方が大事。

ざっくりメモ。

  • サービス自体を安定して回復力のあるものにする
  • 監視は壊れたシステムを直してくれない
    • それはそう！

5. 手動設定

各サービスの監視は自動化しておくべきということが書かれていた。

クラウドベースの監視の場合は個々のシステムの監視というよりは全体の集合を監視する方にフォーカスした方がいい。

ざっくりメモ

  • 監視は自動化しておくべき
  • 自動化されていないとより良い監視システムを作ること自体がストレスになってしまう

2 章 デザインパターン

1. 組み合わせ可能な監視

専門化されたツールを複数使い、それらを独立した形でガチャガチャして監視プラットフォームを作ることが書かれていた。メリットは 1 つのツールに依存しないことがあって、自身のソフトウェアのスケールや変化によって not for me になったときに切り離せることが挙げられていた。

監視サービスのコンポーネントについて触れられていて、それについての詳細な説明もあった。個人的にここらへんはまさに知りたい情報だったので読んでいて面白かった。

「監視とはアラートを出すために存在しているのではありません」と書いてあって、ここはハッとした。割と自分の中でアラートを出してシステムの異常に気づくことができるために監視をしていると思っていた節があったので、考えを改めさせられた。

ざっくりメモ

  • 監視サービスのコンポーネントは以下がある
    • データ収集
    • データストレージ
    • 可視化
    • 分析
    • アラート
  • データ収集は push 型と pull 型がある
  • メトリクスには 2 つの表現がある
    • カウンタ
      • 累計情報などの足されていくもの
      • 車の走行距離での例えがあった
    • ゲージ
      • ある時点の値
      • 車のスピードでの例えがあった
  • ログは構造化しておいた方がいいが、単に人間が読むだけであれば非構造化ログでも問題ないパターンがある
  • データストレージは時系列データベースの紹介や rollup、ageout の説明があった
  • 監視とはアラートを出すためにしているのではない
    • 監視は質問を投げかけるためにある
    • メトリクスやグラフがアラートと 1:1 になっていないあたりがそれを表している
  • SLA ほとんどの場合願望や嘘である
    • 言い過ぎな気はする…。w
    • 可用性 100%は非現実的
      • 可用性 99.95%でも年間 4 時間ダウンする（EC2 がこれ）

2. ユーザー視点での監視

色々監視したい箇所はあるにしても、一番最初に手をつけるのはユーザーに一番近い部分の監視。

ユーザーは中で何が起きてるかは知らない、唯一ユーザーが知りたいのはソフトウェアが動いているかどうか。

ざっくりメモ

  • ユーザーにいちばん近いところから監視を始める
    • 一番シンプルな方法は HTTP のステータスコードを使った監視
    • HTTP のレイテンシも効果的
    • 何が問題かは教えてくれないけど何かがおかしいかは教えてくれる
  • 中で DB の CPU 使用率が上がってるだとかとかも気にしたくなるけど、ソフトウェアが動いているのであれば問題ない、まず見るところはそこではない

これに関するツイートを最近見た 👀

https://twitter.com/integrated1453/status/1760632069183701288

3. 作るのではなく買う

以下の理由から買う方がいいと書いてある。

  1. 安いから
  2. 監視ツールを作る専門家ではないから
  3. 自分のプロダクトにフォーカスできるから
  4. 結局買った方がいい

全部それはそうみたいな話で、そこにコスト割くくらいなら金払って契約して使う方がいいという話が書いてある。

ざっくりメモ

  • プロダクトが大きくなり、ニーズに耐えられなくなって監視ツールを作る場合もある
  • しかし、いまだに Pinterest や Airbnb も監視ツールを使っている
  • 間違いなく今の自分達には監視ツールを作ることは不要
    • 監視ツール作らないといけないくらい大きな組織になるといい
    • けど、大きな組織になって今と違うデータやメトリクスを取りたいとなったときに、それは一体どんなデータやメトリクスなんだろう
      • あまり想像がつかない

4. 継続的改善

Google, Facebook, Twitter, Netflix, Etsy のような企業が、高度な監視の仕組みを作り、今日の状態に至るまでに長い年月をかけていることを忘れない。

世界レベルの仕組みは 1 週間やそこらではできない。世界レベルの監視の仕組みは数ヶ月、数年間にわたる継続した注意深さと改善から生まれる。

ざっくりメモ

  • 各社監視ではどんなデータやメトリクスを扱っているんだろう
  • どういうアラートが飛んでくるんだろう
  • おそらくインシデントレポートや表に出すための仕組みも充実していそう

3 章 アラート、オンコール、インシデント管理

1. どうしたらアラートをよくできるか

より良いアラートを設計するための内容が書いてある。

特に手順書を書いた方がいいであったり、アラートを減らすのあたりは結構できてない自覚があるので自戒を込めて頑張ろうと思った。

ざっくりメモ

  • アラートにメールを使うのをやめよう
    • これは Slack に置き換えられる
    • なんでも Slack に通知するのは良くない
    • ログを溜めておいて後で通知するとかでもいい
  • 手順書を書いた方がいい
    • 具体的には
      • これは何のサービスで、何をするものか
      • 誰が責任者か
      • どんな依存性を持っているか
      • インフラの構成はどのようなものか
      • どんなメトリクスやログを送っていて、それらはどういう意味なのか
      • どんなアラートが設定されていて、その理由は何なのか
  • 固定の閾値を決めることはだけが方法ではない
  • アラートを減らす
    • アラートにメールを使うのをやめようと似てる
    • 本当に必要な方法での通知なのか、そもそもそれは本当に必要な通知なのかは常に考えるべき
    • 割とこれは開発環境改善定例でも話されているけど、どこかで整理をしたい
  • アラートのレベルを定義する
    • ログレベルとかもこの類かな
  • 自動復旧を使う

2. オンコール

ざっくりメモ

  • オンコールの経験がないのであまりイメージがわかなかった
    • オンコールを自分なりに当てはめようとしても無理だった
    • アラート対応もそのとき気づいた人がやるスタンスの人生だったので
      • またはその機能を開発した人
    • まあ言いたいことはわかったのでお k
  • 不要な場当たり対応を減らす
  • ローテーションを組む
    • 不要な気がした

3. インシデント管理

発生した問題を扱う、正式な手順。ITIL のプロセスを採用する。

ITIL 初めて聞いたが、なるほど。

ITIL とは – システム管理者向け用語集

シンプルにしたのは以下。

  • 認識
  • 記録
  • 診断、分類、解決、クローズ
  • 必要に応じて、問題発生中にコミュニケーションを取る
  • 解決後、回復力を高めるための改善策を考える

インシデント時には役割分担ができるといい。

  • 現場指揮官
    • 決断することが仕事
  • スクライブ
    • 書記
  • コミュニケーション調整役
    • 社内外問わず利害関係者に最新状況のコミュニケーションを取る
  • SME（Subject Matter Expert）
    • 実際にインシデント対応をする人

ざっくりメモ

  • ITIL
    • IT サービスマネジメントにおけるベストプラクティス（成功事例）をまとめた書籍群
  • インシデント時には役割分担ができるといい
    • 割と自分はインシデント対応の経験がほぼないのもあって、テンパってしまって役割とか考えられなさそう
    • 冷静に対処できるといい

4. 振り返り

ポストモーテムの話。誰かを非難するようなことはしない。（当たり前）

ざっくりメモ

  • 振り返りとかやると思うけど、絶対に誰かを非難しない

4 章 統計入門

ここは一般的な統計の話だった。移動平均や平均値、周期性あたりの紹介があった。

その中に中央値についての説明があったが、監視において中央値を用いて何かをするケースって何があるんだろう。パッと思いつかなかった。

5 章 ビジネスを監視する

ビジネス的・事業的な KPI の監視も切り離せないという内容の話が書いてあった。これは本当にそうで共感できる反面、自分がまだ解像度上げきれてないのはここらへんかなと思った。

ざっくりメモ

  • これうまい具合に可視化できたら結構面白そう
    • 技術指標と事業の KPI を組み合わせる
  • アプリケーションが動いてる定義ってなんだっけ
    • アプリケーションが動作しているかどうかを知るためにはどうすればいいんだっけ
    • アプリケーションの KPI はなんだっけ
    • なぜその KPI なんだっけ
    • その KPI により何がわかるんだっけ
  • ここらへんは事業責任者と認識合わせていけるといいと思いつつ、自分たちがどの程度入り込んで行って理解し切れるのかあまり見えてない
    • 雑談的に sync しながら少しずつ進めていけるといいのかな
  • 16 サービスメトリクスなるものが

6 章 フロントエンド監視

フロントエンドの監視として以下が書かれていた。

  • リアルユーザー監視
    • 実際のユーザーが見ているページのロード時間の監視
  • シンセティック監視
    • 監視データを得るためのリクエスト

サイトのレスポンスタイムと収益性の関係性が載っていて面白い。ここらへんは toC 向けの話な気はするけど、toB のシステムでも同様のことが言えそう。

ちなみに web.dev にも同じような話がある。

Fast load times  |  web.dev

ざっくりメモ

  • リアルユーザー監視に目が行きがち
  • レスポンスタイムと収益性の話いは web.dev にもある
    • https://web.dev/fast
    • toB SaaS なので収益に直接パフォーマンスが響くかどうかはちょっとわからないけど、必ず影響はあると思う（速ければ速いほどいいし）
  • Navigation Timing API を使うとユーザーの視覚的なページロードの時間だったり、ボトルネックの判定に便利
    • 大抵の監視サービスはここらへんが考慮されて実装されている
    • 指標を出すのもある程度簡単にできるはず
  • WebpageTest.org を CI に組み込むことで継続的にパフォーマンスの計測をすることが可能
  • 今ってフロントエンドの監視どんな感じでやってるんだっけ？
    • sentry でエラーを拾ってるのは理解してる

7 章 アプリケーション監視

アプリケーション監視に関する汎用的な知識が書いてあった。

アプリケーションの監視も、データベースのクエリの実行にかかった時間や外部の API のレスポンスにかかった時間等のシンプルで当たり前のことから始めるべきということが書かれていて、それはそうだなと思った。

（自分は知らなかったが）StatsD というツールが紹介されていた。StatsD はコードの中にメトリクスを追加するためのツールで、2011 年作られた。

StatsD についてはこの記事がわかりやすかった。

StatsD とは何か。具体的な中身について。 - 山が見えるテラス付きログハウスでダラダラ生きていたい

ログレベルについて、自分は結構いい塩梅で扱っていたが、ログレベルは syslog protocol として RFC になっていることを初めて知った。

RFC 5424 - The Syslog Protocol 日本語訳

マイクロサービスの監視についても触れられていた。KARTE だと結構それぞれの system は独立してるので、ここでいうマイクロサービスは Internal API がそれにあたるだろうか、とか思いながら読んでいた。

マイクロサービスは分散トレーシングを検討できるといい。しかし、分散トレーシングは正しく実装するのは非常に難しい。ここは具体の方法を別の本なり実際に触るなりして学びたい。

分散トレーシングはこの記事とかが面白かった。

大規模サービスにマッチした可変レート分散トレーシング - Tabelog Tech Blog

ざっくりメモ

  • datadog の APM を想像してこの本を読み始めたので、この章がなんだかんだで一番楽しみだった
  • StatsD について
  • デプロイの監視はしたほうがいい
    • builder.js のあれではなく、アプリケーションのデプロイの監視
    • もしそれがトリガーになった不具合を見つけやすくなる
    • いつ始まっていつ終わってどのビルドの実行を誰がしたか、あたり

  • これらのツールは、アプリケーションやその背後にあるビジネスロジックに関する何のコンテキストも把握していません

    • APM に頼り切ることはダメ
  • アプリケーション開発にはログ設計もだけどメトリクス設計も同じくらい大事
    • ログ設計やメトリクス設計、知見が無さすぎて難しい
    • ここらへんはトライアンドエラーを繰り返すしか無さそうなので、チャレンジしてチームに還元して失敗して頑張ってを繰り返すしかない
  • health チェックは有効
    • health チェック、エンドポイントだけ作って DB コネクションとかまで見ない例をたまに見るのでアプリケーション全体のチェックしろよって書いてあるのは良かった
    • パイプラインとしてここが正常に動いていると、問題の切り分けがしやすくなる
      • DB が壊れてるのか、コネクションができていないのか、それともそのエンドポイント特有のものなのかの切り分けが早い
      • health check ができてるだけでアプリケーションレイヤーの問題だね、みたいな話にいきつきやすくなる
  • ディスクに書くべきか、ネットワーク越しに送るべきか
    • まずはディスクに書き込み、定期的に外部にデータを送る機能があるサービスを組み合わせる
    • 直接投げてるといつかそこが無視できないボトルネックになる
    • これは確かにそうだけど、自分が適当に脳死で作ったら直接投げてしまう気がしたので考えを改めた（なるほどなって感じ）
  • syslog
  • ログレベル
    • ログレベルは正常に動いている前提で priority をつけてしまうという問題がある
    • 場当たり的にログを追加するのではなく、トラブルシューティングや仕組みの説明をするときにあったらとても便利な情報とは何かを考える
  • 分散トレーシングは正しく実装するのは非常に難しい

8 章 サーバ監視

2 章で OS のアラートは意味がないとあったが、ここでは OS のメトリクスについて全く意味がないというわけではないということが書かれている。それはそうで、アラートに関しては意味があまりないだけで、トラブルシューティング等の文脈では非常に効果的に働く。

OS のメトリクスは全システムで自動的に記録しつつアラートは設定しないようにするのが良い。

OS のメトリクスやよく使うサービス（web server, db server）、サーバ観点からのロギングについて触れられていた。あまり普段意識していなかった部分なので耳が痛い反面、学びになった。

ざっくりメモ

  • OS のメトリクス
    • CPU
    • メモリ
    • ネットワーク
    • ディスク
    • ロードアベレージ
  • そのほかに以下のメトリクスや監視について触れられていた
    • SSL 証明書
    • SNMP
    • web server
    • db server
    • load balancer
    • queue
    • cache
    • dns
    • ntp
  • ロギング
    • 収集
      • syslog とそれ以外にグルーピングしたくなる
    • 保存
      • 検索しにくい方法でログを保存すると活用されることがなくなってしまう
    • 分析
      • 以下のログをまずは取って分析してみる
        • HTTP レスポンス
        • sudo の使用
        • SSH
        • cron
        • スロークエリ

9 章 ネットワーク監視

ネットワークのレイヤーは自分が苦手意識があるので、知らないことや聞いたことはあるけどよくわかってないものが多かった。

SNMP というワードが本の序盤からかなり出てきていたので、そこの詳しい説明があるのは良かった。

ざっくりメモ

  • SNMP について
    • https://datatracker.ietf.org/doc/html/rfc1067
    • https://e-words.jp/w/SNMP.html
    • SNMP は古く使いづらいが、現状ネットワーク監視に使える唯一の選択肢
    • 本質的にはセキュアではない
      • インフラにセキュリティの仕組みを組み込んだ上でセキュアでないプロトコルをその上で使う予定であることを理解することが必要
      • 守られていないネットワークの上では使うべきではない
  • ネットワークのメトリクス
    • 帯域幅
      • ネットワークの幅
    • スループット
      • ネットワークリンクの実際のパフォーマンス
      • スループットはリンクの帯域幅より小さくなる
      • スループット性能が疑わしい場合は、パケットドロップ数やオーバーラン、コリジョン数などを確認
    • レイテンシ
      • 結局物理的な制約を受けるので、レイテンシは一定発生する
    • エラー
      • 送受信エラー
      • ドロップ
      • CRC エラー
      • オーバーラン
      • キャリアエラー
      • リセット
      • コリジョン
    • ジッタ
      • あるメトリックの通常の測定値からの狂いのこと
      • レイテンシの幅が大きい時に、ジッタが大きい
  • フロー監視
    • 一定方向へのパケットのシーケンスで、以下の 7 つを共有している
      1. 入力インターフェイス
      2. 送信元 IP アドレス
      3. 宛先 IP アドレス
      4. L3 プロトコル
      5. UDP または TCP の送信元ポート
      6. UDP または TCP の宛先ポート
      7. IP ToS
    • IP ごと、プロトコルごと、アプリケーションごと、サービスごとといった単位で帯域幅の使用率を分析するのに役立つ
  • キャパシティプランニング
    • 逆算する
      • ビジネス上のゴールから逆算する
      • 監視データは用いらない
    • 予測する
      • 監視データから予測する

10 章 セキュリティ監視

セキュリティとは、脅威とリスクを見積もり、不正アクセス時に決断を下すことのことを言う。

rkhunter を使うと監視を簡単に始めることができる。bash で書かれているため、たいていの環境で動く。

rkhunter - ArchWiki

ざっくりメモ

  • セキュリティとは、脅威とリスクを見積もり、不正アクセス時に決断を下すこと
  • 監視とコンプライアンス
    • コンプライアンスを満たすためにも監視は効果的
  • auditd
    • モダンなディストリビューションには入っている
    • 設定可能性の高い、ユーザーのアクションやイベントを追跡するツール
    • auditd を使うことで Linux のユーザー関連の監視を簡単に始めることができる
  • rkhunter
    • ユーザー、コマンド、ファイルシステムの監査
    • ルートキットやその他のホストレベルの侵入を防ぐのは難しいけど、まずは rkhunter から始めるのが効果的
    • https://wiki.archlinux.jp/index.php/Rkhunter
  • ネットワークセキュリティにはファイアオールは十分ではない

11 章 監視アセスメントの実行

ここまでの内容を例題に沿って見ていく章。

ビジネス KPI の設定や、フロントエンド、アプリケーションサーバの監視、アラート、メトリクス、セキュリティについて例題をベースに実際に考える。

Next Action