「入門 監視」を読んでみた / I read "Practical Monitoring"

Googleスライド版：https://docs.google.com/presentation/d/1zJbfWer3kVfRRQMiiEZc6QAv7xLP6rg60ervRmoYRxw/edit?usp=sharing

「入門 監視」：https://www.oreilly.co.jp/books/9784873118642/
原書「Practical Monitoring」：https://www.oreilly.com/library/view/practical-monitoring/9781491957349/

Transcript

1. 「入門 監視」を読んでみた 　2024/11/20　社内LT会 　Ryo Ichiki
2. 目次 • 「入門 監視」について • 読もうと思った背景 • 監視の必要性 • 監視システムを構成する要素 • アラートとは • アラートの３つの使い道 • アラートの難しさ • アラートをより良くする方法 • 監視戦略 • まとめ
3. 「入門 監視」について ★ 発行されたのは 2019年1月 (原書は2017年) なので少し前 (約7年前) に書かれた。 ★ 特定のツールに依存しない普遍的な考え方や知識を学ぶことができる。 ★ 2部構成になっている。 ◦ 第一部は、監視の基本原則を扱っており、アンチパターンやデザインパターン、アラートやオンコール、基本的な 統計学などを学べる。 ◦ 第二部は、監視戦略について扱っており、フロントエンド監視からサーバー監視、セキュリティ監視やビジネス監 視などを学べる。 ★ 監視の基本を学びたい人にはオススメかも？ ◦ 内容はそれなりに濃いが比較的薄い本なのでさっと読める (ページ数は付録含めても 200 いかないくらい)
4. 読もうと思った背景 ★ 監視（モニタリング）を雰囲気でやっているのでいつかちゃんと学びたいと思っていた。 ★ 弊社で導入されている DatadogやSentryを十分に使いこなせているか分からない。 ★ 監視（モニタリング）における普遍的な知識や考え方を学びたいと思った。 ◦ この書籍は特定のツールに依存しないので適していると思った。 ★ 監視の入門書ということで深く学びたくなった際の足がかりになると思った。
5. 監視の必要性 1. アプリケーションが正常に稼働していることを確認するため。 2. 問題を早期に発見して迅速な対応を行うため。 3. パフォーマンスを最適化するため。 4. セキュリティリスクを早期に発見するため。 5. コストの最適化を行うため。
6. じゃあ、 新規サービスなどで新たに監視の仕組みを導入すると したら？ どこから監視を始めるべきか？
7. ユーザー視点での監視が重要 一番最初に監視すべきはユーザーに近いところ。 ユーザーにとってまず大事なのはサービスが使えること。
8. まず「動いている」かどうかを監視しよう • Webアプリケーションの場合、HTTP GETリクエストの結果を確認する。 ◦ HTTP ステータス 200 OKのレスポンスを返すか。 ◦ ページに特定の文字列があるか。 ◦ リクエストのレイテンシが閾値よりも小さいか。 • これらは何が悪いのかを教えてくれるわけではないが、何かがおかしいことを示してくれる。
9. 監視システムを構成する要素 1. データ収集 2. データストレージ 3. 可視化 4. 分析とレポート 5. アラート
10. 監視システムを構成する要素 今日はアラートについてだけピックアップ。 1. データ収集 2. データストレージ 3. 可視化 4. 分析とレポート 5. アラート
11. アラートとは アプリケーションが特定の条件や閾値に達したときに通知させる仕組みのこと。 異常や重要なイベントが発生した際にリアルタイムで気づけるようにし、問題の早期発見と迅速な対応を支援す るために使用される。 弊社ではSlackに通知を送っていることが多い。
12. アラートの３つの使い道 著者によるとアラートの使い道は以下の３つに集約されると言います。 1. すぐに応答かアクションが必要なアラート 2. 注意が必要だがすぐにアクションは必要ないアラート 3. 履歴や診断のために保存しておくアラート 弊社の場合、1 と 2 はSlackに送っている。 3 はよく分からない。が著者はログファイルに送りましょうと言っている。
13. アラートの難しさ システムのメトリクスは急激に変化しやすいのでそのままのデータポイントを使うと誤報を送りやすい。 誤報を回避するために移動平均を使ってデータをならすことがある。 例えば、5分間のデータを平均して１つのデータポイントにまとめる。 しかし、データをならすと情報の粒度が落ち、重要なイベントを見逃すリスクはある。 また、通知が多すぎると人の注意力や集中力を奪うので本当に必要なものだけに絞りたい。 何でもかんでもとりあえずアラートを送れば良いというわけではない。
14. アラートをより良くする方法 1. 手順書を書こう 2. アラートを削除し、チューニングしよう 3. 自動復旧を試そう
15. １. 手順書を書こう 手順書はアラートが来た時に素早く進むべき方法を示す方法。 良い手順書は、特定のサービスについて以下の質問に答えるように書かれている。 • これは何のサービスで、何をするものか。 • 誰が責任者か。 • どんな依存性を持っているか。 • インフラの構成はどのようなものか。 • どんなメトリクスやログを送っていて、それらはどういう意味なのか。 • どんなアラートが設定されていて、その理由は何なのか。 各アラートには、対象サービスの手順書へのリンクを入れよう。
16. ２. アラートを削除し、チューニングしよう アラート疲れが起きる前にアラートを減らせないか検討しよう。 アラートを減らすための３つの方法 1. 全てのアラートを誰かがアクションする必要があるものに絞る。 2. 1ヶ月のアラート履歴を見て、どんなアラートがあったか、どんなアクションを取ったか、各アラートの影響 はどうだったか振り返り、削除できそうなアラートを削除したり、閾値を変更したりできないか検討する。 3. アラートを削除するために自動化の仕組みを作れないか検討する。
17. ３. 自動復旧を試そう 手順書は、自動化が不十分であることを知るきっかけになる場合がある。 もし手順書が単純なやることの羅列なら更なる自動化が可能かもしれない。 例えば「このコマンドを実行、これを確認、そして別のコマンドを実行」のような手順書。 あるアラートを解決するための手順書が上記のようなものならば、その手順を自動化し、アラートを送る前にそれを 実行できないか検討しよう。 自動復旧できればそのアラートは不要。復旧できなかった時にアラートを送れば良い。 手順書は、問題を解決するのに人の判断と診断が必要な時のためのもの。
18. 監視戦略 何をどのように監視すべきか。 1. ビジネス監視 2. フロントエンド監視 3. アプリケーション監視 4. サーバー監視 5. ネットワーク監視 6. セキュリティ監視
19. まとめ 今回この書籍を読んで改めて監視の重要性と難しさを認識することができました。 「入門 監視」は約７年前の書籍ですが、監視の基礎を学ぶのにはおすすめです。 しかし、それでも少し古いんじゃないかと思われる内容もあるので注意が必要です。 また、DatadogやSentryはこの書籍には出てこないので、これらを使う前提で考えたらどうなんだろう？といった 内容もあり、普段の業務にそのまま活かせるものばかりではありませんでした。 DatadogやSentryをもっと活かすためには、そのドキュメントなどを読んだりするのが良いかなと思いました。 Datadogに関しては、Datadog Leaning Centerというものがあり、時間がある時にやってみようと思っていま す。 監視に関する足がかりはできたので、今後はより詳細に深ぼって学んでいきたいなと思っています。
20. 終わり。
21. おまけ
22. アンチパターン：形だけの監視 以下のような兆候が見られる場合、形だけの監視に陥っているかもしれません。 • システム負荷、CPU使用率、メモリ使用率などのメトリクスは記録しているが、システムがダウンした理由 は分からない。 • 誤検知が多すぎるのでアラートを常に無視する。 • 各メトリクスを 5 分以上長い間隔で監視している。 • メトリクスの履歴を保持していない。
23. アンチパターン：監視だけを行う役割を置くこと • 監視だけを行う専門家を配置するなど、誰か１人に監視の全責任を押し付けるのはアンチパターン。 • 監視は役割ではなくスキルであり、チーム内の全員がある程度のレベルに至っておくべきスキル。 ◦ Webアプリケーションの監視は Webエンジニアが行うべき。 (Webアプリケーションについては Webエンジニアが誰よりも 詳しいはずなので） • サービスを作って管理することになったら監視を最優先項目の１つにするように努力しましょう。 • 監視するまで本番環境とは言えないことを覚えておきましょう。 (戒め)
24. 監視システムを構成する要素 データ収集について。 1. データ収集 2. データストレージ 3. 可視化 4. 分析とレポート 5. アラート
25. データ収集の方法 データ収集を行う方法には プッシュ型 と プル型 の2種類ある。 • プル型は、中央サーバーがアプリケーションに対してデータを送信するように要求を出すタイプ。 ◦ 欠点は、中央サーバーが全てのアプリのデータ送信タイミングをスケジュールし、それぞれの応答をパースしなけ ればならないため、スケールしにくい点。 • プッシュ型は、アプリケーションが監視サービスに対してデータを一定間隔またはイベントが発生したタイミン グで送信するタイプ。(DatadogやSentryはプッシュ型) ◦ ポーリングを行う中央サーバーが必要ないため、分散アーキテクチャなどアプリが増えた場合でもスケールしやす い。
26. データの種類 データの種類にも メトリクス と ログ という2種類がある。 • メトリクスには カウンター (Counter) と ゲージ (Gauge) という2種類の表現方法がある。 ◦ カウンター は、増加していくメトリクス。 Webサイトの訪問者数の累計など。 ◦ ゲージ は、ある時点の値。例えば、ある時点の CPU使用率とか。 • ログには、構造化ログと非構造化ログの2種類がある。 ◦ 構造化ログ は、JSONなどのフォーマットで構造化されたログのこと。 ◦ 非構造化ログ は、プレーンテキスト 。RailsやNginxのログなど多くの人にとって馴染みがあるのはこっち。 ▪ 人にとっては読みやすいが機械による解析やフィルタリングが難しい。
27. 監視システムを構成する要素 データストレージについて。 1. データ収集 2. データストレージ 3. 可視化 4. 分析とレポート 5. アラート
28. データストレージ データ収集したらそれをどこかに保存しておく必要がありますね。 時系列データであるメトリクスは、時系列データベース (TSDB、Time Series Database) に保存される。 (DatadogやSentryも内部で使われているらしい ) TSDBは、タイムスタンプと値 (メトリクスなど) というキーと値のペアで構成される時系列データを保存するためにデ ザインされた専用データベース。
29. TSDBについてちょっとだけ深掘り 🤏 TSDBの多くは一定期間後にデータの間引き (roll up) や有効期限切れ (age out) が発生する。 これは、古くなった複数のデータポイントが１つのデータポイントにまとめられるということ。 データの間引きは、ディスク容量の圧迫を避けるためとディスクからのデータ読み出し時間を削減するため。
30. 監視における統計学： meanとaverage meanとaverageはどちらも 平均 と訳される。 meanを計算するのは簡単で、集合内の値を全て足した値をその集合の要素数で割る。 時系列データでよく使われるものに 移動平均 (moving average) がある。 集合の全ての値を使うのではなく、最近取得したデータポイント群で平均を計算する。 TSDBではこの移動平均が使われている。
31. 監視における統計学：分位数（ quantile） 分位数は、データセットのある点を表す統計的手法。 最もよく使われる分位数はパーセンタイルで、これは 0 〜 100 %でデータセット内の点を表現する方法。 n パーセンタイルの計算方法は、まずデータセットを昇順に並べ替え、下位 100 - n %の値を取り除き、残った中の最 大値が n パーセンタイルの値。(雑な定義) パーセンタイルのより完全な表現は「 Statistics For Engineers」に書かれている。 パーセンタイルは、帯域幅に対する課金やレイテンシのレポートによく使われる。
32. ビジネス監視って何？ 要はビジネス KPIのこと。 エンジニアでも経営層がするような質問ができるようになれば非常に重要でレバレッジが効いた問題に取り組め るようになる。 • 顧客はサービスを利用できているか？ • 成長しているか、縮小しているか、停滞しているか？ • どのくらいの利益が出ているか？ • 収益性は改善しているか、悪化しているか、停滞しているか？ • 顧客は喜んでいるか？
33. 事業責任者がよく使うメトリクス • 月次経常収益 • 顧客あたりの収益 • 課金顧客の数 • 顧客生涯価値 (LTV) • 顧客あたりのコスト • 顧客獲得単価 • 顧客の解約数 • アクティブユーザー数 • ネットプロモータースコア • バーンレート • ランレート • TAM (Total Addressable Market) • 粗利 弊社の場合 • 推薦数 • 求人数 • 成約数 • etc...
34. 会社のビジネス KPIを見つけよう 何を計測するのが重要か理解するために人と話そう。 まず話すべきはプロダクトマネージャー。 プロダクトマネージャーの仕事は、顧客が何を必要としているかを理解し、それを実現するためにエンジニアリン グチームと協力することなので、何が問題なのかを高いレベルで把握していることが多い。 次に話すべきは、ソフトウェアエンジニアリングのマネージャーで、 その後はシニアソフトウェアエンジニアと話してみよう。 弊社の場合は月１のグループ MTG で重要な KPI の話が出てくるので注意深く聞いてみよう。
35. フロントエンド監視について ブラウザやモバイルアプリケーションで実行される全てをフロントエンドと定義する。 最近では React などで構築された SPA (Single Page Application) が広く使われるようになってきて、 HTTPエ ラーが起きてないのに JavaScript エラーは起きるというようなケースも多くなってきた。 それらのエラーを検知することも重要。 また、フロントエンドのパフォーマンスを監視することも重要。 JavaScriptやCSSや画像などの静的アセットのサイズがフロントエンドのパフォーマンスに影響を与える。
36. フロントエンド監視の２つのアプローチ 1. リアルユーザー監視 (Real User Monitoring, RUM) 2. シンセティック監視 (Synthetic Monitoring)
37. リアルユーザー監視 監視データに実際のユーザートラフィックを使って行う監視。 Google AnalyticsやSentryが該当する。 各ページに JavaScriptの小さなスニペットを入れ、ユーザーがページをロードすると、そのスニペットが監視サー ビスに対してメトリクスを送信する。
38. シンセティック監視 監視データを得るために色々なテスト環境下で偽のリクエストを生成して行う監視。 WebpageTest.org がシンセティック監視に該当する。
39. フロントエンドパフォーマンスのメトリクス ブラウザは、W3Cによって推奨されている Navigation Timing API という仕様に基づいたAPIを通じて、ページ パフォーマンスをのメトリクスを公開している。 このAPIはデフォルトで各ページで有効化されていて、ページパフォーマンスに関するたくさんの情報を提供して いる。
40. Navigation Timing API のメトリクス 出典：ナビゲーションタイミング - Web API | MDN
41. • navigationStart ブラウザによってページリクエストが開始されたタイミング • domLoading DOMがコンパイルされロードが始まったタイミング • domInteractive ページが使用可能になったと考えられるタイミング。だたし、ページロードが終わっているとは限らない • domContentLoaded 全てのスクリプトが実行されたタイミング • domComplete ページが全て (HTML、CSS、JavaScript) のロードを終えたタイミング 常に有益なメトリクス
42. Speed Index Speed Indexは、秒間10フレームのビデオキャプチャを使って、視覚的な観点でページがロードされ終わったの がいつかを判断する。 ユーザーの体感を判断する場合に有効。
43. テスト環境にシンセティック監視を統合する Webアプリのパフォーマンスは、能動的かつ定期的にパフォーマンスを最適化していかないと、時間の経過と共 に悪化していく傾向がある。 計測していないものを改善することはできないので、例えば、プルリクエスト毎にフロントエンドのパフォーマンス への影響を計測できるようにしてみよう。 これにはWebpageTestのプライベートインスタンス が役に立つかも。 WebpageTest APIをCI環境などで使えるようにすれば、新機能がパフォーマンスに影響しないかなどをチーム で考慮しながら開発を進めることができる。