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

Slide 1

Slide 1 text

「入門監視」を読んでみた　2024/11/20　社内LT会　Ryo Ichiki

Slide 2

Slide 2 text

目次 ● 「入門監視」について ● 読もうと思った背景 ● 監視の必要性 ● 監視システムを構成する要素 ● アラートとは ● アラートの３つの使い道 ● アラートの難しさ ● アラートをより良くする方法 ● 監視戦略 ● まとめ

Slide 3

Slide 3 text

「入門監視」について ★ 発行されたのは 2019年1月 (原書は2017年) なので少し前 (約7年前) に書かれた。 ★ 特定のツールに依存しない普遍的な考え方や知識を学ぶことができる。 ★ 2部構成になっている。 ○ 第一部は、監視の基本原則を扱っており、アンチパターンやデザインパターン、アラートやオンコール、基本的な統計学などを学べる。 ○ 第二部は、監視戦略について扱っており、フロントエンド監視からサーバー監視、セキュリティ監視やビジネス監視などを学べる。 ★ 監視の基本を学びたい人にはオススメかも？ ○ 内容はそれなりに濃いが比較的薄い本なのでさっと読める (ページ数は付録含めても 200 いかないくらい)

Slide 4

Slide 4 text

読もうと思った背景 ★ 監視（モニタリング）を雰囲気でやっているのでいつかちゃんと学びたいと思っていた。 ★ 弊社で導入されている DatadogやSentryを十分に使いこなせているか分からない。 ★ 監視（モニタリング）における普遍的な知識や考え方を学びたいと思った。 ○ この書籍は特定のツールに依存しないので適していると思った。 ★ 監視の入門書ということで深く学びたくなった際の足がかりになると思った。

Slide 5

Slide 5 text

監視の必要性 1. アプリケーションが正常に稼働していることを確認するため。 2. 問題を早期に発見して迅速な対応を行うため。 3. パフォーマンスを最適化するため。 4. セキュリティリスクを早期に発見するため。 5. コストの最適化を行うため。

Slide 6

Slide 6 text

じゃあ、新規サービスなどで新たに監視の仕組みを導入するとしたら？どこから監視を始めるべきか？

Slide 7

Slide 7 text

ユーザー視点での監視が重要一番最初に監視すべきはユーザーに近いところ。ユーザーにとってまず大事なのはサービスが使えること。

Slide 8

Slide 8 text

まず「動いている」かどうかを監視しよう ● Webアプリケーションの場合、HTTP GETリクエストの結果を確認する。 ○ HTTP ステータス 200 OKのレスポンスを返すか。 ○ ページに特定の文字列があるか。 ○ リクエストのレイテンシが閾値よりも小さいか。 ● これらは何が悪いのかを教えてくれるわけではないが、何かがおかしいことを示してくれる。

Slide 9

Slide 9 text

監視システムを構成する要素 1. データ収集 2. データストレージ 3. 可視化 4. 分析とレポート 5. アラート

Slide 10

Slide 10 text

監視システムを構成する要素今日はアラートについてだけピックアップ。 1. データ収集 2. データストレージ 3. 可視化 4. 分析とレポート 5. アラート

Slide 11

Slide 11 text

アラートとはアプリケーションが特定の条件や閾値に達したときに通知させる仕組みのこと。異常や重要なイベントが発生した際にリアルタイムで気づけるようにし、問題の早期発見と迅速な対応を支援するために使用される。弊社ではSlackに通知を送っていることが多い。

Slide 12

Slide 12 text

アラートの３つの使い道著者によるとアラートの使い道は以下の３つに集約されると言います。 1. すぐに応答かアクションが必要なアラート 2. 注意が必要だがすぐにアクションは必要ないアラート 3. 履歴や診断のために保存しておくアラート弊社の場合、1 と 2 はSlackに送っている。 3 はよく分からない。が著者はログファイルに送りましょうと言っている。

Slide 13

Slide 13 text

アラートの難しさシステムのメトリクスは急激に変化しやすいのでそのままのデータポイントを使うと誤報を送りやすい。誤報を回避するために移動平均を使ってデータをならすことがある。例えば、5分間のデータを平均して１つのデータポイントにまとめる。しかし、データをならすと情報の粒度が落ち、重要なイベントを見逃すリスクはある。また、通知が多すぎると人の注意力や集中力を奪うので本当に必要なものだけに絞りたい。何でもかんでもとりあえずアラートを送れば良いというわけではない。

Slide 14

Slide 14 text

アラートをより良くする方法 1. 手順書を書こう 2. アラートを削除し、チューニングしよう 3. 自動復旧を試そう

Slide 15

Slide 15 text

１. 手順書を書こう手順書はアラートが来た時に素早く進むべき方法を示す方法。良い手順書は、特定のサービスについて以下の質問に答えるように書かれている。 ● これは何のサービスで、何をするものか。 ● 誰が責任者か。 ● どんな依存性を持っているか。 ● インフラの構成はどのようなものか。 ● どんなメトリクスやログを送っていて、それらはどういう意味なのか。 ● どんなアラートが設定されていて、その理由は何なのか。各アラートには、対象サービスの手順書へのリンクを入れよう。

Slide 16

Slide 16 text

２. アラートを削除し、チューニングしようアラート疲れが起きる前にアラートを減らせないか検討しよう。アラートを減らすための３つの方法 1. 全てのアラートを誰かがアクションする必要があるものに絞る。 2. 1ヶ月のアラート履歴を見て、どんなアラートがあったか、どんなアクションを取ったか、各アラートの影響はどうだったか振り返り、削除できそうなアラートを削除したり、閾値を変更したりできないか検討する。 3. アラートを削除するために自動化の仕組みを作れないか検討する。

Slide 17

Slide 17 text

３. 自動復旧を試そう手順書は、自動化が不十分であることを知るきっかけになる場合がある。もし手順書が単純なやることの羅列なら更なる自動化が可能かもしれない。例えば「このコマンドを実行、これを確認、そして別のコマンドを実行」のような手順書。あるアラートを解決するための手順書が上記のようなものならば、その手順を自動化し、アラートを送る前にそれを実行できないか検討しよう。自動復旧できればそのアラートは不要。復旧できなかった時にアラートを送れば良い。手順書は、問題を解決するのに人の判断と診断が必要な時のためのもの。

Slide 18

Slide 18 text

監視戦略何をどのように監視すべきか。 1. ビジネス監視 2. フロントエンド監視 3. アプリケーション監視 4. サーバー監視 5. ネットワーク監視 6. セキュリティ監視

Slide 19

Slide 19 text

まとめ今回この書籍を読んで改めて監視の重要性と難しさを認識することができました。「入門監視」は約７年前の書籍ですが、監視の基礎を学ぶのにはおすすめです。しかし、それでも少し古いんじゃないかと思われる内容もあるので注意が必要です。また、DatadogやSentryはこの書籍には出てこないので、これらを使う前提で考えたらどうなんだろう？といった内容もあり、普段の業務にそのまま活かせるものばかりではありませんでした。 DatadogやSentryをもっと活かすためには、そのドキュメントなどを読んだりするのが良いかなと思いました。 Datadogに関しては、Datadog Leaning Centerというものがあり、時間がある時にやってみようと思っています。監視に関する足がかりはできたので、今後はより詳細に深ぼって学んでいきたいなと思っています。

Slide 20

Slide 20 text

終わり。

Slide 21

Slide 21 text

おまけ

Slide 22

Slide 22 text

アンチパターン：形だけの監視以下のような兆候が見られる場合、形だけの監視に陥っているかもしれません。 ● システム負荷、CPU使用率、メモリ使用率などのメトリクスは記録しているが、システムがダウンした理由は分からない。 ● 誤検知が多すぎるのでアラートを常に無視する。 ● 各メトリクスを 5 分以上長い間隔で監視している。 ● メトリクスの履歴を保持していない。

Slide 23

Slide 23 text

アンチパターン：監視だけを行う役割を置くこと ● 監視だけを行う専門家を配置するなど、誰か１人に監視の全責任を押し付けるのはアンチパターン。 ● 監視は役割ではなくスキルであり、チーム内の全員がある程度のレベルに至っておくべきスキル。 ○ Webアプリケーションの監視は Webエンジニアが行うべき。 (Webアプリケーションについては Webエンジニアが誰よりも詳しいはずなので） ● サービスを作って管理することになったら監視を最優先項目の１つにするように努力しましょう。 ● 監視するまで本番環境とは言えないことを覚えておきましょう。 (戒め)

Slide 24

Slide 24 text

監視システムを構成する要素データ収集について。 1. データ収集 2. データストレージ 3. 可視化 4. 分析とレポート 5. アラート

Slide 25

Slide 25 text

データ収集の方法データ収集を行う方法にはプッシュ型とプル型の2種類ある。 ● プル型は、中央サーバーがアプリケーションに対してデータを送信するように要求を出すタイプ。 ○ 欠点は、中央サーバーが全てのアプリのデータ送信タイミングをスケジュールし、それぞれの応答をパースしなければならないため、スケールしにくい点。 ● プッシュ型は、アプリケーションが監視サービスに対してデータを一定間隔またはイベントが発生したタイミングで送信するタイプ。(DatadogやSentryはプッシュ型) ○ ポーリングを行う中央サーバーが必要ないため、分散アーキテクチャなどアプリが増えた場合でもスケールしやすい。

Slide 26

Slide 26 text

データの種類データの種類にもメトリクスとログという2種類がある。 ● メトリクスにはカウンター (Counter) とゲージ (Gauge) という2種類の表現方法がある。 ○ カウンターは、増加していくメトリクス。 Webサイトの訪問者数の累計など。 ○ ゲージは、ある時点の値。例えば、ある時点の CPU使用率とか。 ● ログには、構造化ログと非構造化ログの2種類がある。 ○ 構造化ログは、JSONなどのフォーマットで構造化されたログのこと。 ○ 非構造化ログは、プレーンテキスト。RailsやNginxのログなど多くの人にとって馴染みがあるのはこっち。 ■ 人にとっては読みやすいが機械による解析やフィルタリングが難しい。

Slide 27

Slide 27 text

監視システムを構成する要素データストレージについて。 1. データ収集 2. データストレージ 3. 可視化 4. 分析とレポート 5. アラート

Slide 28

Slide 28 text

データストレージデータ収集したらそれをどこかに保存しておく必要がありますね。時系列データであるメトリクスは、時系列データベース (TSDB、Time Series Database) に保存される。 (DatadogやSentryも内部で使われているらしい ) TSDBは、タイムスタンプと値 (メトリクスなど) というキーと値のペアで構成される時系列データを保存するためにデザインされた専用データベース。

Slide 29

Slide 29 text

TSDBについてちょっとだけ深掘り 🤏 TSDBの多くは一定期間後にデータの間引き (roll up) や有効期限切れ (age out) が発生する。これは、古くなった複数のデータポイントが１つのデータポイントにまとめられるということ。データの間引きは、ディスク容量の圧迫を避けるためとディスクからのデータ読み出し時間を削減するため。

Slide 30

Slide 30 text

監視における統計学： meanとaverage meanとaverageはどちらも平均と訳される。 meanを計算するのは簡単で、集合内の値を全て足した値をその集合の要素数で割る。時系列データでよく使われるものに移動平均 (moving average) がある。集合の全ての値を使うのではなく、最近取得したデータポイント群で平均を計算する。 TSDBではこの移動平均が使われている。

Slide 31

Slide 31 text

監視における統計学：分位数（ quantile）分位数は、データセットのある点を表す統計的手法。最もよく使われる分位数はパーセンタイルで、これは 0 〜 100 %でデータセット内の点を表現する方法。 n パーセンタイルの計算方法は、まずデータセットを昇順に並べ替え、下位 100 - n %の値を取り除き、残った中の最大値が n パーセンタイルの値。(雑な定義) パーセンタイルのより完全な表現は「 Statistics For Engineers」に書かれている。パーセンタイルは、帯域幅に対する課金やレイテンシのレポートによく使われる。

Slide 32

Slide 32 text

ビジネス監視って何？要はビジネス KPIのこと。エンジニアでも経営層がするような質問ができるようになれば非常に重要でレバレッジが効いた問題に取り組めるようになる。 ● 顧客はサービスを利用できているか？ ● 成長しているか、縮小しているか、停滞しているか？ ● どのくらいの利益が出ているか？ ● 収益性は改善しているか、悪化しているか、停滞しているか？ ● 顧客は喜んでいるか？

Slide 33

Slide 33 text

事業責任者がよく使うメトリクス ● 月次経常収益 ● 顧客あたりの収益 ● 課金顧客の数 ● 顧客生涯価値 (LTV) ● 顧客あたりのコスト ● 顧客獲得単価 ● 顧客の解約数 ● アクティブユーザー数 ● ネットプロモータースコア ● バーンレート ● ランレート ● TAM (Total Addressable Market) ● 粗利弊社の場合 ● 推薦数 ● 求人数 ● 成約数 ● etc...

Slide 34

Slide 34 text

会社のビジネス KPIを見つけよう何を計測するのが重要か理解するために人と話そう。まず話すべきはプロダクトマネージャー。プロダクトマネージャーの仕事は、顧客が何を必要としているかを理解し、それを実現するためにエンジニアリングチームと協力することなので、何が問題なのかを高いレベルで把握していることが多い。次に話すべきは、ソフトウェアエンジニアリングのマネージャーで、その後はシニアソフトウェアエンジニアと話してみよう。弊社の場合は月１のグループ MTG で重要な KPI の話が出てくるので注意深く聞いてみよう。

Slide 35

Slide 35 text

フロントエンド監視についてブラウザやモバイルアプリケーションで実行される全てをフロントエンドと定義する。最近では React などで構築された SPA (Single Page Application) が広く使われるようになってきて、 HTTPエラーが起きてないのに JavaScript エラーは起きるというようなケースも多くなってきた。それらのエラーを検知することも重要。また、フロントエンドのパフォーマンスを監視することも重要。 JavaScriptやCSSや画像などの静的アセットのサイズがフロントエンドのパフォーマンスに影響を与える。

Slide 36

Slide 36 text

フロントエンド監視の２つのアプローチ 1. リアルユーザー監視 (Real User Monitoring, RUM) 2. シンセティック監視 (Synthetic Monitoring)

Slide 37

Slide 37 text

リアルユーザー監視監視データに実際のユーザートラフィックを使って行う監視。 Google AnalyticsやSentryが該当する。各ページに JavaScriptの小さなスニペットを入れ、ユーザーがページをロードすると、そのスニペットが監視サービスに対してメトリクスを送信する。

Slide 38

Slide 38 text

シンセティック監視監視データを得るために色々なテスト環境下で偽のリクエストを生成して行う監視。 WebpageTest.org がシンセティック監視に該当する。

Slide 39

Slide 39 text

フロントエンドパフォーマンスのメトリクスブラウザは、W3Cによって推奨されている Navigation Timing API という仕様に基づいたAPIを通じて、ページパフォーマンスをのメトリクスを公開している。このAPIはデフォルトで各ページで有効化されていて、ページパフォーマンスに関するたくさんの情報を提供している。

Slide 40

Slide 40 text

Navigation Timing API のメトリクス出典：ナビゲーションタイミング - Web API | MDN

Slide 41

Slide 41 text

● navigationStart ブラウザによってページリクエストが開始されたタイミング ● domLoading DOMがコンパイルされロードが始まったタイミング ● domInteractive ページが使用可能になったと考えられるタイミング。だたし、ページロードが終わっているとは限らない ● domContentLoaded 全てのスクリプトが実行されたタイミング ● domComplete ページが全て (HTML、CSS、JavaScript) のロードを終えたタイミング常に有益なメトリクス

Slide 42

Slide 42 text

Speed Index Speed Indexは、秒間10フレームのビデオキャプチャを使って、視覚的な観点でページがロードされ終わったのがいつかを判断する。ユーザーの体感を判断する場合に有効。

Slide 43

Slide 43 text

テスト環境にシンセティック監視を統合する Webアプリのパフォーマンスは、能動的かつ定期的にパフォーマンスを最適化していかないと、時間の経過と共に悪化していく傾向がある。計測していないものを改善することはできないので、例えば、プルリクエスト毎にフロントエンドのパフォーマンスへの影響を計測できるようにしてみよう。これにはWebpageTestのプライベートインスタンスが役に立つかも。 WebpageTest APIをCI環境などで使えるようにすれば、新機能がパフォーマンスに影響しないかなどをチームで考慮しながら開発を進めることができる。