Closed11
入門監視を読んでみてポイントをまとめる
ピン留めされたアイテム
ega4432はじめに
今回扱っているのはこちらの本。
きっかけ
システム開発・運用に携わる中で、運用面に関する知見が少ないので危機感を感じていた。インフラのリソース、API などのパフォーマンスなどそれぞれのスコープについての一般的な手法や考え方などを知りたかったため。
目的
- 監視についての基本的な理解を深める
- 実践的かつ実用的な手法を学ぶ
ega4432はじめに
監視とは
あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。
対象読者
- 監視の基礎的な理解を深めたい人
- 監視の知識を強化したい非技術的な人
ega4432目次
- 第 Ⅰ 部 監視の原則
- 1 章 監視のアンチパターン
- 2 章 監視のデザインパターン
- 3 章 アラート、オンコール、インシデント管理
- 4 章 統計入門
- 第 Ⅱ 部 監視戦略
- 5 章 ビジネスを監視する
- 6 章 フロントエンド監視
- 7 章 アプリケーション監視
- 8 章 サーバ監視
- 9 章 ネットワーク監視
- 10 章 セキュリティ監視
- 11 章 監視アセスメントの実行
1 章 監視のアンチパターン
- 「何をするか」よりもツールに焦点を当てて失敗しているケースが多い
- アプリケーション、サーバ、ネットワークなどさまざまなレイヤー、スコープに分けて考える。
- 場合によって適切なツールを使い分け、必要であればツールを増やすことを恐れない。
- 全員が本番環境に対して責任を持つ
- 1 人の肩に全責任を押し付けるような会社はアンチパターン。
- チェックボックスに「これを監視してます」とだけで監視はできない
- 「動いている」を定義する。
- 何か起きた際の原因を特定できるよう最低でも 1 分毎にメトリクスを取得する。
- 監視項目を増やすことよりも問題の修正に時間を使う
- 監視項目の登録・解除を自動化する
ega44322 章 監視のデザインパターン
- デザインパターン 1: 組み合わせ可能な監視
- 複数のツールを使って監視プラットフォームを作る。
- 監視サービスのコンポーネントは疎結合にしておく。
- データ収集
- データストレージ
- 可視化
- 分析とレポート
- アラート
- デザインパターン 2: ユーザ視点での監視
- サーバが何台動いているかよりも「ユーザに影響を与えているか」を基準に考える。
- デザインパターン 3: 作るのではなく買う
- エンジニアの賃金 + 機会損失 + 仕組みを作る時間 + メンテナンス > SaaS
- SaaS を導入するメリット
- プロダクト開発にフォーカスできる。
- SaaS でできないことはほとんどない。
-
SaaS 導入を嫌がる人は、意識的か無意識か偏った考えがあり、技術的あるいは経済的な理由をもとにしている訳ではない。
- デザインパターン 4: 継続的改善
- 常に改善し続ける。
ega44323 章 アラート、オンコール、インシデント管理
- よいアラートの仕組み
- アラートにメールを使わない。
- すぐに応答が必要な場合 -> SMS
- 注意が必要だがすぐにアクションは必要ない -> チャット、Web アプリ
- 履歴や診断目的 -> ログ
- 手順書（runbook）を作る。
- シンプルな閾値で決められるわけではない。
- "アラート疲れ" にならないように定期的に見直そう。
- メンテナンス期間を作ろう。
- 自動復旧の仕組みを作ろう。
- アラートにメールを使わない。
- オンコールの仕組みを改善する
- 誤報を削除する。
- システムの回復性や安定性について取り上げ、無用の場当たり対応を減らす。
- ローテーションを組む。
- インシデント管理
- 基本的には ITIL のインシデント管理 のプロセスを基準にして、あとはやりすぎない。
- インシデント解決後、回復力を高めるための改善を考える。
ega44324 章 統計入門
- 重要な原則としては監視サービスが過去に送ったメトリクスを削除しないこと。
- 過去のデータを使うことで統計を使った問題の発見ができる可能性が広がるため。
- 集合のすべてを使って平均を算出する代わりに最近のデータ群で平均を算出する方法を移動平均という。
- データを平準化できるというメリットと一方で極端な値が隠されることになるというデメリットもあるので、どれくらい平準化するか適切な度合いを決める必要がある。
- 一方向に大きな偏りがあるデータを扱う場合に適しているのが中央値という。
データセットが [3, 2, 1, 81, 19, 3, 58] で与えられる時
昇順に並び替えて [1, 2, 3, 3, 19, 58, 81]
データセットのエントリ数 n とすると
(n + 1) / 2 が中央値となるので
この場合は 3 が中央値となる。
- データポイントがあるパターンを繰り返すことを周期性という。
- データのある点を表す統計的手法を分位数という
- 第2四分位数 = 中央値
- 最も良く使われるのがパーセンタイル
- 平均からどの程度離れているか、どの程度近いかを表現することを標準偏差という。
- 正規分布しているデータセットにしか効果がない。
ega44325 章 ビジネスを監視する
- ビジネス KPI
- 「サービスは動いているか？」「ユーザへの影響はあるか？」という一番外側の指標から監視の仕組みを考え始める。
- 例
- 月次経常収益
- 顧客あたりの収益
- 課金顧客の数
- 顧客生涯価値
- 顧客あたりのコスト
- 顧客獲得単価
- 顧客の解約数
- パーンレート
- ランレート
- TAM( total addressable market )
- 粗利( gross profit margin )
- 「サービスは動いているか？」「ユーザへの影響はあるか？」という一番外側の指標から監視の仕組みを考え始める。
- ビジネス KPI を技術指標に結び付ける
- ある機能についてもっと詳細な情報を得たい場合は「失敗率」を取得すること。
- 会社のビジネス KPI を見つける
- 話すのが最も近道
- プロダクトオーナー
- エンジニアチームのマネージャ
- シニアソフトウェアエンジニア
- 「アプリケーションが動いているのを確認する方法」、「アプリケーションの KPI が何かとそれを指標にしている理由」
- 話すのが最も近道
ega44326 章 フロントエンド監視
- ユーザが見ているページのロード時間を監視する
- 最適なページロード時間は 2 秒以下で、5.1 秒を超えるとビジネスに影響が出てくる - ref. Aberdeen Research
- JavaScript のエラーを監視する
- ページを動的にするため、ページがロードされた後でも HTML 要素を参照し、必要に応じてデータを変更できる。
- JavaScript が引き起こしがちな混乱について理解する。
- DOM, ソース HTML, モダンな Web の仕組み, etc ...
- メトリクス取得ツール
- Navigation TIming API
- User Timing API
- Speed Index
- Google Analytics
- ロギング
-
console.log()でユーザのブラウザコンソールを埋め尽くすのはよくない - 「exception tracking saas」でググるといっぱい出てくるはず
-
- ページロード時間を CI システムで計測し続け、許容時間時収める
ega44327 章 アプリケーション監視
- メトリクスとログでアプリケーションを監視することは、アプリケーションのパフォーマンスを把握し、トラブルシューティングする能力を高めるために最も重要なこと
- 小さなことから始める（DB クエリの時間、外部 API のレスポンスタイム、DAU/MAU）
- アプリケーションのインフラのリソースやパフォーマンスに関係することを追跡する
- ビルドとリリースのパイプラインを監視する
- デプロイとエラーの減少の因果関係や、逆に障害発生といった関係性を早く発見できるため。
-
/healthエンドポイントパターン- ヘルスチェック（ロードバランサー/サービスディスカバリ）やデバッグとして使用可能
- DB や依存する外部サービスと正常に繋がるかもテストする
- 最低限 HTTP ステータスコードを返すようにする
- セキュリティや懸念があるなら特定の IP からだけアクセスできるようにしておく
- サーバーレス or マイクロサービスの監視
-
分散トレーシング と言う手法を使う
- この仕組みの構築はかなり根気のいることなので、向いているケースにだけ実行するようにする。
-
分散トレーシング と言う手法を使う
ega44328 章 サーバ監視
- 標準的な OS のメトリクス
- アラートを送るのには適さない
- 効果的な使い方
- SSL 証明書
- ドメインレジストラや CA の仕組みを使って通知を受け取る or アラートを送る or 自動更新する
- Web サーバ
- 秒間リクエスト数（request per second [req/sec]）
- HTTP ステータスコード
- リクエスト時間
- DB サーバ
- コネクション（スレッド）数
- 秒間クエリ数（queries per second [qps]）
- ロードバランサ
- 特定のポートに対してコネクションができるかどうか
- ヘルスチェック
- メッセージキュー
- キューの長さと消費率（キューから取り出させた比率）
- サーバ観点からのロギング
- 別のサーバにログを送りたい場合は TCP を使う
- 下記の項目を分析
- HTTP レスポンス, sudo の使用の有無, SSH ログイン, cron ジョブの結果, MySQL のスロークエリ
このスクラップは2021/07/31にクローズされました