logo

2024年3月19日

入門監視を読んだ

『入門 監視』（Mike Julian 著、松浦隼人訳）を読んだのでまとめ。

エンジニアになって3年、開発も運用も、そして障害やビジネスの変化も経験したので身に沁みる点もあり、明日からのサービス改善に活かしていきたいと思いました。素晴らしい本を執筆・翻訳くださった方々へ、その努力に敬意を表するとともに感謝申し上げます。

第Ⅰ部 監視の原則

1章 監視のアンチパターン

1.1 アンチパターン1：ツール依存
1.1.1 監視とは複雑な問題をひとくくりにしたもの
1.1.2 カーゴ・カルトなツールを避ける
1.1.3 自分でツールを作らなければならない時もある
1.1.4 「一目で分かる」は迷信

  • ツールを増やすのを恐れる人が多い
    • 仕事ができる最低限の数にする
    • 複数のツールがそれぞれ別の情報を提供しており、かつ情報を関連づけられるなら問題ない
  • 会社内でツールに関する企画を作りたい場合、たくさんの人と気楽で砕けた会話をすること
    • どんな監視ツールがどんな目的で使われているかを知る
    • 彼らのやり方を変えようとしているわけではないことを伝える
  • チームが成功したことによってツールや手順が作られたのであって、ツールや手順によって成功したわけではない
    • 成功するまでの試行錯誤は他者から見えない
    • 誰かが使っている、あるいはチームメンバーが使ったことがあるからという理由で選ぶのではなく、評価し、試してみるのが重要
  • 小さく、何かに特化したツールを自作する
    • 大量のデータから必要な特定のデータを抜き出すといったレベル
    • 全くのゼロからプラットフォームを作ったほうがよいというレベルではない

1.2 アンチパターン2：役割としての監視

  • 理解もできないものを監視する仕組みは作れない
    • ソフトウェアエンジニアはアプリケーションについて誰よりも詳しいので、素晴らしいアプリケーション監視の仕組みをデザインするには最高の場所にいる
  • セルフサービスの監視ツールをサービスとして他のチームに提供すること（Observabilityチームなどと呼ばれる）は正当で、よくあるアプローチ
    • ただしアプリケーションの監視をしたりアラートを作ったりするのは仕事ではない

1.3 アンチパターン3：チェックボックス監視
1.3.1 「動いている」とはどういう意味か。「動いている」かどうかを監視しよう
1.3.2 アラートに関しては、OSのメトリクスはあまり意味がない
1.3.3 メトリクスをもっと高頻度で取得しよう

  • チェックボックス監視とは「これを監視してます」と言うための監視システムのこと
    • 組織の中で上位に位置する人が要求してくることもある
  • アンチパターンに陥っているかどうかの兆候
    • メトリクスは記録しているがシステムがダウンしたことの理由がわからない
    • 誤検知が多すぎるのでアラートを常に無視する
    • 各メトリクスを5分あるいはそれより長い間隔で監視している
    • メトリクスの履歴を保存していない
  • MySQL が継続的に CPU 全部を使っていたとしても、レスポンスタイムが許容範囲に収まっていれば何も問題はない
  • 診断やパフォーマンス分析にとっては重要だが、誰かをアラートで叩き起こすには値しない
  • 最低でも60秒に1回メトリクスを取得する
    • 10秒ごとに取得した CPU のメトリクスデータを１年間保存しておく必要はないはずなので、適切なデータの間引き設定（roll-up）をする

1.4 アンチパターン4：監視を支えにする

  • 壊れやすいレガシーなシステムに対しては監視を増やすのではなく、サービスを安定して回復力のあるものにすることに時間を使おう

1.5 アンチパターン5：手動設定

  • 100%自動化すべき
  • 新しい監視設定やノードの追加をすぐにできないと、よりよい監視システムを作ることがストレスになってしまう

2章 監視のデザインパターン

2.1 デザインパターン1：組み合わせ可能な監視
2.1.1 監視サービスのコンポーネント

  • 専門化されたツールを複数使い、それらを疎に結合させる
  • 1つのツールややり方に長期間コミットする必要がなく、合わなくなればそのツールだけを置き換えればよいメリットがある
  • データ収集
    • メトリクス
      • カウンタ（Counter）
      • ゲージ（Gauge）
    • ログ
      • 構造化ログ
      • 非構造化ログ
  • データストレージ
  • 可視化
  • 分析とレポート
    • よくあるのは SLA のレポート
      • 標本化定理によると、２分間のダウンタイムを計測するには1分間隔でデータを収集する必要がある
      • 高い精度の SLA を計算することは難しい
  • アラート

2.2 デザインパターン2：ユーザ視点での監視

  • まずは HTTP レスポンスコード（特に 5xx）やリクエスト時間（レイテンシ）の監視から着手するとよい

2.3 デザインパターン3：作るのではなく買う
2.3.1 安いから
2.3.2 あなたは（おそらく）監視ツールを設計する専門家ではな> いから
2.3.3 SaaSを使うとプロダクトにフォーカスできるから
2.3.4 実際のところSaaSの方がよいから

  • 監視に SaaS を使うのを非難する人の多くは、意識的か無意識的か偏った考えがあり、技術的あるいは経済的な理由を元にしているわけではない

2.4 デザインパターン4：継続的改善

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

  • 理由はともかく、インフラは真夜中におかしな動きをしがち。どうしてそういう問題はいつも午前3時に起きるのか
    • そこでアラート
  • しかし人間の注意力には限りがある

3.1 どうしたらアラートをよくできるか
3.1.1 アラートにメールを使うのをやめよう
3.1.2 手順書を書こう
3.1.3 固定の閾値を決めることだけが方法ではない
3.1.4 アラートを削除し、チューニングしよう
3.1.5 メンテナンス期間を使おう
3.1.6 まずは自動復旧を試そう

  • 誰かを叩き起こすためのアラート
  • 参考情報（FYI）としてのアラート
  • 固定の閾値を超過したかよりも変化量あるいはグラフの傾きを使ったほうが役にたつ
  • アラートに対するアクションが既知でかつ用意されたドキュメントの手順に沿って対応するだけなら、コンピュータにやらせよう

3.2 オンコール
3.2.1 誤報を修正する
3.2.2 無用の場当たり的対応を減らす
3.2.3 上手にオンコールローテーションを組む

  • ソフトウェアエンジニアもローテに入れることで「丸投げ」を避ける
  • オンコールは、睡眠の質や家族との時間など、生活の多くの部分に対してよくない影響がある

3.3 インシデント管理

  • 対応手順
    1. インシデントの認識（監視が問題を認識）
    2. インシデントの記録（インシデントに対して監視の仕組みが自動でチケットを作成）
    3. インシデントの診断、分析、解決、クローズ（オンコール担当がトラブルシュートし、問題を修正し、チケットにコメントや情報を添えて解決済みとする）
    4. 必要に応じて問題発生中にコミュニケーションを取る
    5. インシデント解決後、回復力を高めるための改善策を考える
  • 数分以上かかる本当のサービス停止を伴うインシデントについては明確に定義された役割が重要になる
    • 現場指揮官（IC、incident commander）：決断する仕事。調査の監督のみ
    • スクライブ（scribe）：書記
    • コミュニケーション調整役（communication liaison）
    • SME（subject matter expert）：実際にインシデント対応する人
  • マネージャがコミュニケーション調整役に就くことで割り込みからチームを守れるかも

3.4 振り返り

  • ポストモーテム（postmortem）
  • ミスした人が罰せられたり、問題を覆い隠さざるを得ないような雰囲気のチームはよくない

4章 統計入門

4.1 システム運用における統計を学ぶ前に
4.2 計算が救いの手を差し伸べる
4.3 統計は魔法ではない
4.4 meanとaverage
4.5 中央値
4.6 周期性
4.7 分位数
4.8 標準偏差

  • 算術平均（arithmetic mean）：計算が簡単。全部を足して要素数で割るだけ
  • 移動平均（moving average）：スパイクを平準化する効果
    • 重要なデータポイントを失ってしまう欠点もあるので適切な度合いで平準化する必要がある
  • 中央値（median）：平均が対象を正確に表さないときに便利
  • 周期性（seansonality）：データポイントがパターンを繰り返すこと
  • 分位数（quantile）：データセットのある点を表す統計的手法
    • e.g. 第2四分位数はデータセットの真ん中の点（中央値）
    • よく使われる分位数はパーセンタイル。パーセンテージ（0〜100）でデータセット内の点を表す
    • データセットを昇順に並べ替え、上位 n パーセンタイルの値を取り除き、残った内で最大の値が n パーセンタイルの値
    • 外れ値を無視して、大部分についての情報が得られる
  • 標準偏差（standard deviation）：平均からどの程度離れているか、どの程度近いかを表現する手法
    • 罠：正規分布しているデータセットじゃないと正しい結果にならない

第Ⅱ部 監視戦略

5章 ビジネスを監視する

5.1 ビジネスKPI

  • 経営者や創業者の関心
    • 顧客はアプリケーションあるいはサービスを支えているか
    • 儲かっているか
    • 成長しているか、縮小しているか、停滞しているか
    • どのくらい利益が出ているか。収益性は改善しているか、悪化しているか、停滞しているか
    • 顧客は喜んでいるか
上記に答えるために事業責任者がよく使うメトリクス
  • 月次経常収益（monthly recurring revenue）：SaaS やマネージドサービス
  • 顧客あたりの収益（revenue per customer）：通常は年ごと
  • 課金顧客の数（number of paying customers）：大きくなっていって欲しい
  • ネットプロモータスコア（net promoter score、NPS）：ユーザあるいは顧客の満足度の指標
    • どのくらい他人に勧めるかを、10を最高として1〜10までの段階（リッカード尺度）で格付け
    • ヘルプデスクなど
  • 顧客生涯価値（customer lifetime value、LTV）
  • 顧客あたりのコスト（cost per customer）：下がっていって欲しい
  • 顧客獲得単価（customer acquisition cost、CAC）：マーケティング
  • 顧客の解約数（customer churn）：ビジネスの特性に大きく依存するので、自社のビジネス内の時間経過で比較
  • アクティブユーザ数（active users）：DAU、WAU、MAU
  • バーンレート（burn rate）：賃金からオフィス賃料までを含む会社全体の支出。後期のスタートアップや大企業など収益を上げている会社では基本的に使われない
  • ランレート（run rate）：現在の支出レベルを続けたときに資金がなくなるまでの期間。収益を上げている会社では基本的に使われない
  • TAM（total addressable market）：ある特定のマーケットがどのくらいの大きさなのかの指標
  • 粗利（gross profit margin）：販売したもののコストを除いた利益を表す指標

5.2 2つの事例
5.2.1 Yelp
5.2.2 Reddit
5.3 ビジネスKPIを技術指標に結び付ける
5.4 自分のアプリケーションにそんなメトリクスはないという時は
5.5 会社のビジネスKPIを見つける

  • ビジネス KPI が「購入」であれば、技術的には「購入失敗」や「購入のレイテンシ」がメトリクスとなる
  • 必要な計測データをアプリケーションが出してくれないなら、自分でアプリケーションを変更する
  • 計測すべきメトリクスを考えるにはまずはプロダクトマネージャと会話
    • 彼らは顧客が何を必要としているかを理解し、それを実現するためにエンジニアリングチームと協力することが仕事なので、問題を高いレベルで把握していることが多い
    • 「私が会社に入りたてだとして、アプリケーションが動いていることをどうやって知ったらよいでしょうか？　何をチェックしていますか？　どう動いたらよいのでしょうか？」
    • 「アプリケーションの KPI は何ですか？　なぜその KPI を使っているのですか？　その KPI はどんなことを教えてくれますか？」

6章 フロントエンド監視

  • ここでのフロントエンドの定義：ブラウザあるいはネイティブなモバイルアプリケーションによってパースされて実行されるすべて

6.1 遅いアプリケーションのコスト
6.2 フロントエンド監視の2つのアプローチ
6.3 DOM
6.3.1 フロントエンドパフォーマンスのメトリクス
6.3.2 素晴らしい！ でもどうやったらいいの？
6.4 ロギング
6.5 シンセティック監視

  • ページロード時間は4秒以下を目指そう
  • Navigation Timing API
    • navigationStart, domLoading, domInteractive, domContentLoaded, domComplete の5つのメトリクスは常に有益
  • WebPageTest が事実上の標準フロントエンドパフォーマンステストツール
    • ✏️ 本書が書かれた後の2020年に Catchpoint 社に買収されているようです。
      私個人的には Google の PageSpeed Insights の方が馴染みがあるけどどうなんでしょう？ 🤔
  • フロントエンドのロギングに関して選択肢は限られているが SaaS 製品で実現できるかも
  • WebPageTest のプライベートインスタンス を CI に組み込んでみるのもいいかも

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

7.1 メトリクスでアプリケーションを計測する
7.1.1 内部ではどのように動いているのか

  • シンプルに始めるのが鍵
    • データベースクエリの実行にかかった時間
    • 外部ベンダの API が応答するのにかかった時間
    • 1日に発生したログインの数
  • StatsD は Etsy によって作られたコードの中にメトリクスを追加するためのツール
    • カウンタ、タイマなど
    • UDP で動作するためアプリケーションのパフォーマンスに大きな影響を与えない
    • 設定されたフラッシュ間隔に従って、収集したすべてのメトリクスをバックエンドに「フラッシュ」する
    • フラッシュの間に収集されたあらゆるメトリクスは集約されてバックエンドに送られる
      • ✏️ 生のメトリクスが送られるのではなく、平均や合計、上限下限などのデータに集約されるみたいです。

7.2 ビルドとリリースのパイプラインの監視

  • ビルドは「動くか動かないか」だけだが、メタ情報（デプロイがいつ始まったか、いつ終わったか、どのビルドがデプロイされたか、誰がデプロイを実行したか）は重要
    • 例えば、API エラー率にデプロイイベントを重ねてみると関係性がわかることもある
  • デプロイのタイミング、ビルドデータ、デプロイを実行した人を記録しておくと、トラブルシューティングのためにさらに役立つ情報が得られる

7.3 healthエンドポイントパターン

  • アプリケーションの健全性を伝えるアプリケーション内の HTTP エンドポイント
  • カナリアエンドポイント（canary endpoint）やステータスエンドポイント（status endpoint）と呼ばれることもある
  • メトリクスベースのやり方では得られない利点
    • ロードバランサやサービスディスカバリツールによるヘルスチェックにも使用できる
    • デバッグにも便利。ビルド情報を公開すると、環境内で何が動いているのかも簡単に判断できるようになる
    • ヘルスチェックで詳しい情報を得られるようにすることで、アプリケーションが自分自身の健全性を把握できるようになる
  • DB などの外部依存との接続性をチェックするとよい
  • ユーザからはこのエンドポイントにアクセスして欲しくないので Web サーバでアクセス制限をかける

7.4 アプリケーションロギング
7.4.1 メトリクスにすべきか、ログにすべきか
7.4.2 何のログを取るべきか
7.4.3 ディスクに書くべきか、ネットワーク越しに送るべきか

  • 何でもかんでも全部ロギングしてはいけない。 以下の質問を考えよう
    • 何かがおかしくなった時に、最初にする質問はなんでしょうか
    • トラブルシューティングあるいは単なる仕組みの説明時に、あったらとても便利な情報とは何でしょうか
  • まずはディスクに書き込み、定期的に外部にデータを送る機能があるサービスを選ぶ

7.5 サーバレスまたはFunction-as-a-Service

  • 多くの場合、実行時間、呼び出す回数、エラー率などある程度のメトリクスがすでに記録されている
  • 関数の中で何が起きているかを知りたければ StatsD を使えばよい

7.6 マイクロサービスアーキテクチャを監視する

  • 分散トレーシング（distributed tracing）はリクエスト ID を「タグ付け」して追跡する
    • 根気がない人や、スタッフ不足だったり過労気味のエンジニアリングチームには向いていない
    • ✏️ 自分の開発しているサービスでリクエスト ID をほとんどのロギングで記録するというのをやったらログを追跡しやすくなったのでおすすめします。

8章 サーバ監視

8.1 OSの標準的なメトリクス
8.1.1 CPU
8.1.2 メモリ
8.1.3 ネットワーク
8.1.4 ディスク
8.1.5 ロードアベレージ

  • 本書全体を通じて、OS の標準的メトリクスへの依存を批判してきた
    • アプリケーションが動いているかという重要事項とは関連が弱いから
    • 2章で取り上げたように高いレベルから始める必要がある
  • しかし、診断やトラブルシューティングといった正しいコンテキストで使えば強い味方になる
  • CPU: top
  • メモリ: free
  • ネットワーク: ifconfig ip
    • 情報源は /prox/net/dev
  • ディスク: iostat
    • 情報源は /proc/diskstats
  • ロードアベレージ: uptime
    • コアあたりロードが1.0なのは完全に許容範囲内
    • 15分平均のロードが500を超えていたとしても顧客に問題がないなら問題ではない

8.2 SSL証明書

  • 何らかのチェックツールを使うか、なければ自作しよう

8.3 SNMP

  • SNMP をサーバ監視に使うのはやめよう
  • ネットワーク機器の監視目的には使い続ける必要があるが、サーバの監視についてはその必要はない
  • collectd、Telegraf、Diamond といったプッシュベースのツールがよい

8.4 Webサーバ

  • 秒間リクエスト数：パフォーマンスとトラフィックのレベルを測る決定版のメトリクス
  • HTTP ステータスコードの監視：パフォーマンスにはそこまで致命的でないが全体の見通しの点で重要
  • キープアライブの仕組みがあるので、コネクション数よりはリクエスト数に注目すべき

8.5 データベースサーバ

8.6 ロードバランサ

  • フロントエンドとバックエンドの2つのメトリクスを両方取る必要がある
    • ロードバランサ自体の状態と、バックエンドのサーバの状態という別々の情報を知るため

8.7 メッセージキュー

  • キューの長さ：キューの中でサブスクライバに取り出されるのを待っているメッセージの数
  • 消費率：キューから取り出され処理されたメッセージの比率（秒間メッセージ数で表される）

8.8 キャッシュ

  • キャッシュから追い出されたアイテム数（evicted items）：キャッシュ容量が足りない可能性を表す
  • ヒット・ミス比率またはキャッシュヒット率：キャッシュの目的は応答速度を上げることだが、キャッシュミスはその速度を下げてしまう

8.9 DNS

  • ゾーン転送：設定により全転送（AXFR）と増分転送（IXFR）のどちらかの転送方法を選べる
  • 秒間クエリ数：負荷の指標

8.10 NTP

  • NTP クライアントだけを運用していて、stratum 1 の NTP サーバを持っていないなら、注意すべきはサーバクライアント間のドリフト（time drift）だけ
  • ntpstat コマンド

8.11 それ以外の企業インフラにおける監視
8.11.1 DHCP
8.11.2 SMTP
8.12 スケジュールジョブの監視
8.13 ロギング
8.13.1 収集
8.13.2 保存
8.13.3 分析

  • syslog 管理か、それ以外か
  • Syslog 転送 UDP vs TCP 問題：メッセージが消えてしまうのは困るので、筆者的には TCP をすすめる
  • ログは SaaS の監視ツールや機能豊富なオンプレミスのツールに送ろう
    • syslog サーバに送ってもログを活用して価値を得られない

9章 ネットワーク監視

9.1 SNMPのつらさ
9.1.1 SNMPとは
9.1.2 SNMPの仕組み
9.1.3 セキュリティについて
9.1.4 SNMPの使い方
9.1.5 インタフェイスのメトリクス
9.1.6 インタフェイスとログ
9.1.7 SNMPに関するまとめ

  • https://datatracker.ietf.org/doc/html/rfc1067
  • 本質的にセキュアでないプロトコル
    • SNMP v3 では暗号化したりして解決しようとしているが、機器の負荷が増えたりサポートされていなかったりする
  • メトリクス
    • 帯域幅：ある接続から一度に送れる理論上の最大情報量（秒間ビット bps で表す）
    • スループット：ネットワークリンクの実際のパフォーマンス（秒間ビット bps で表す）
      • iperf2 でテストできる
    • レイテンシ：パケットがネットワークリンクを通じてやり取りされるのにかかる時間
      • iperf2 または smokeping で計測できる
    • エラー：送受信エラー、ドロップ、CRC エラー、オーバーラン、キャリアエラー、リセット、コリジョン
    • ジッタ：あるメトリックの、通常の測定値からの狂いのこと。レイテンシに関して使われることが多い

9.2 構成管理
9.3 音声と映像
9.4 ルーティング
9.5 スパニングツリープロトコル（STP）
9.6 シャーシ
9.6.1 CPUとメモリ
9.6.2 ハードウェア
9.7 フロー監視
9.8 キャパシティプランニング
9.8.1 逆算する
9.8.2 予測する

10章 セキュリティ監視

10.1 監視とコンプライアンス
10.2 ユーザ、コマンド、ファイルシステムの監査
10.2.1 auditdのセットアップ
10.2.2 auditdとリモートログ
10.3 ホスト型侵入検知システム（HIDS）
10.4 rkhunter
10.5 ネットワーク侵入検知システム（NIDS）

  • HIPAA（ヘルスケアデータの保護）、PCI-DSS（クレジットカードデータの保護）、SOC2（会計以外の統制情報の保護）など異なるコンプライアンスがある
  • 各統制についてログを集約しておくことで証明できる
  • auditd がレポートできるイベントの例
    • すべての sudo の実行、コマンドの実行、誰が実行したか
    • ファイルアクセスや特定ファイルの変更、その時刻、誰によって変更されたか
    • ユーザ認証の試行と失敗
  • audisp-remote というプラグインで中央サーバに自動でログを送信するようにできる
    • rsyslog が無効化されていても監査イベントを転送し続けられる

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

11.1 ビジネスKPI
11.2 フロントエンド監視
11.3 アプリケーションとサーバの監視
11.4 セキュリティ監視
11.5 アラート

付録C 実践.監視SaaS

松木雅幸（@songmu）氏による解説です。

C.1 筆者と監視SaaS
C.2 監視SaaSの利点
C.3 監視SaaSは信用できるのか
C.3.1 監視SaaSビジネスそのものに対する信頼性
C.3.2 事業の継続性について
C.3.3 サービス品質について
C.3.4 悪意はないか
C.4 監視SaaSの選定時に考えること
C.4.1 課題を見つける
C.4.2 機能要件を精査する
C.4.3 組み合わせて使う
C.4.4 運用をサービスに合わせる
C.4.5 ハッカビリティを備えているか
C.4.6 外部の力を活用できるか
C.5 監視SaaSを導入する
C.5.1 監視エージェントのインストール
C.5.2 監視エージェントが収集するメトリクス
C.5.3 シンセティック監視のすすめ
C.6 監視SaaSを活用する
C.6.1 テスト駆動開発と監視
C.6.2 自分で監視を作る
C.6.3 監視を育てる
C.6.4 自動復旧のためのアイデア
C.7 監視SaaSのこれから
C.7.1 監視パラダイムの変遷
C.7.2 機械学習と異常検知
C.8 まとめ

  • 監視は開発者自身が自主的に行うべきもので、属人的な権威があってはいけない
    • 監視 SaaS は「怖くない」画面を設計しているので、「監視の民主化」が実現される
  • エージェント自体の挙動の調査
    • どのような情報を収集しているのか
    • システムリソースをどれくらい消費するのか
      • インタプリタ型のスクリプト言語で実装されていたり、JVM で動くものは注意
    • ポートを開放しているか
      • 開放している場合、どのような目的でどれくらいのポートを開放するのか
  • ハッカビリティ：API が整っていて自動化がやりやすいかが大きなポイント
  • OpenMetrics: Prometheus の exporter の出力フォーマットを由来とし、標準的なメトリクスフォーマットとして仕様が提案されているもの

やむを得ず最近のOpenSSLでレガシーなプロトコルを使いたい時の設定

2024年3月27日

Raspberry Pi 5を M.2 SSDブート

2024年3月3日