システム監視入門

Transcript

1. システム監視入門 システム監視入門 みんなで考えるシステム監視のベストプラクティス #srelounge_h 2026/07/26 SRE Lounge Hiroshima #2 1
2. システム監視入門 whoami Wataru Tsuda / gr1m0h SWE, SRE at Topotal, inc. Waroom: インシデントマネジメントSaaS SRE as a Service(SREの技術支援) 竹原市で生まれ育ち、広島市在住 広島商船高専 -> 東京 -> 2023年にUターン 2026/07/26 SRE Lounge Hiroshima #2 2
3. システム監視入門 今日のゴール 1. 監視の目的とオブザーバビリティの基礎を理解する 2. 自分たちの監視の現状を振り返る 3. ディスカッションで知見を共有する 正解は1つじゃない、色んなやり方を知ろう 2026/07/26 SRE Lounge Hiroshima #2 3
4. システム監視入門 1. 監視とは 何のために監視するのか — 目的から考える 2026/07/26 SRE Lounge Hiroshima #2 4
5. システム監視入門 監視とは？ システムの状態を継続的に観察し、 異常や障害の兆候を早期に検知・対応するための仕組み CPU使用率が90%を超えたらSlackに通知 ヘルスチェックが失敗したらオンコールを呼ぶ 証明書の期限が近づいたらチケットを起票 Discussion: みなさんのシステム、何のために監視を入れていますか？ 2026/07/26 SRE Lounge Hiroshima #2 5
6. システム監視入門 監視には4つの目的がある 目的 内容 障害の早期検知 人間より先にシステムが教えてくれる状態を作る 障害の未然防止 止まってから気づくのでは遅い。予兆段階で対応する 安定稼働の維持 「稼働している」を定義し、数値で測り続ける セキュリティ 意図しないアクセスや動作を見逃さない ポイント: 目的が違えば手法も違う Discussion: この4つ、みなさんの監視はどこまでカバーしていますか？ 2026/07/26 SRE Lounge Hiroshima #2 6
7. システム監視入門 迷ったらまず 4 Golden Signals シグナル 何を見るか 例 Latency リクエストの処理時間 レスポンスタイム Traffic 需要の量 リクエスト数/秒 Errors 失敗のレート 5xxの割合 Saturation リソースの飽和度 CPU・メモリ・キューの詰まり 「4つだけ計測するなら、まずこの4つ」 出典: Beyer et al. "Site Reliability Engineering" ch.6 (O'Reilly, 2016) 2026/07/26 SRE Lounge Hiroshima #2 7
8. システム監視入門 USEとRED — 見る対象で切り口を変える USE 対象 インフラリソース 見るも Utilization / Saturation / Errors の 向く場 サーバー・ネットワークのリソース分 面 析 RED リクエスト駆動サービス Rate / Errors / Duration マイクロサービスのリクエスト分 析 出典: Brendan Gregg "The USE Method" (2012) / Tom Wilkie "The RED Method" (2015) Discussion: 何を測るか・しきい値をどこにするか、どうやって決めていますか？ 2026/07/26 SRE Lounge Hiroshima #2 8
9. システム監視入門 2. 監視だけでは足りない 「何が起きたか」の先へ 2026/07/26 SRE Lounge Hiroshima #2 9
10. システム監視入門 監視は「何が起きたか」を見ること あらかじめ監視項目としきい値を決め、超えたらアラート わかるのは「CPU使用率が90%を超えた」という結果だけ 想定外の障害では 「エラーが出ているが、理由がわからない」 に陥る システム構成がシンプルだった時代は、これで十分だった Discussion: 「エラーは出ているが理由がわからない」経験、ありませんか？ 2026/07/26 SRE Lounge Hiroshima #2 10
11. システム監視入門 システムが複雑になり、想定外が日常になった クラウドネイティブな分散システムの普及で運用が複雑化 個々のコンポーネントは正常でも、組み合わせで未知の障害が起きる 事前に決めた監視項目 = 既知のパターンだけでは対処しきれない 2026/07/26 SRE Lounge Hiroshima #2 11
12. システム監視入門 3. オブザーバビリティ 「なぜ起きたか」を探り出す能力 2026/07/26 SRE Lounge Hiroshima #2 12
13. システム監視入門 オブザーバビリティ = 「なぜ起きたか」を探り出す 能力 システムの内部状態を把握するためのデータを取得し、関連付けて保持する 事前に想定していなかった原因でも、データを横断して特定できる 監視が不要になるわけではない — 両者は補完関係 2026/07/26 SRE Lounge Hiroshima #2 13
14. システム監視入門 3本柱 — ただし関連付いて初めて意味がある 柱 役割 メトリクス 数値の集計。「何が起きているか」を秒単位で検知 ログ 根本原因究明の入り口。構造化すると検索性が上がる トレース 「どこで問題が起きたか」を突き止める。分散システムでは不可欠 メトリクスで検知 → トレースで追跡 → ログで特定 バラバラに持つだけでは従来の監視と変わらない Discussion: ログにトレースIDは入っていますか？ 2026/07/26 SRE Lounge Hiroshima #2 14
15. システム監視入門 3本柱 + 変更イベントで「何によって」まで辿る メトリクス・ログ・トレースはあくまで 「結果」のデータ デプロイ・設定変更・フィーチャーフラグなどの変更イベントを重ねる 「レイテンシ悪化と同時刻にデプロイ」→ 原因の仮説に直結する Discussion: メトリクスのグラフに、デプロイのタイミングは見えますか？ 2026/07/26 SRE Lounge Hiroshima #2 15
16. システム監視入門 実例: 「決済が遅い」と苦情が来たら 計装がないと わかる 「どこかが遅い」だけ こと 動き方 各チームに問い合わせて回 る 原因特定に時間がかかり影 影響 響が長引く 計装があれば フロント 200ms → 認証 500ms → 決済API 6.5秒 → DB 500ms 決済APIが原因だと即特定 ロールバック・改修の判断がすぐできる ※ 計装 (instrumentation) = 追跡データを取得する仕組みをコードやインフラに仕込むこ と 2026/07/26 SRE Lounge Hiroshima #2 16
17. システム監視入門 監視でよくある課題 課題 状況 アラートが多すぎて無視される 「また鳴ってる」で誰も見ない しきい値が勘 前任者の設定のまま、根拠は不明 ユーザーからの連絡で気づく 監視より先にお問い合わせが来る ダッシュボードが形骸化 作ったきり、障害時に誰も開かない Discussion: 鳴っても誰も見ないアラート、ありませんか？ 2026/07/26 SRE Lounge Hiroshima #2 17
18. システム監視入門 アラートを減らす定石 症状ベースでアラートする — ユーザー影響が出ているものを最優先 鳴ったら必ず行動するものだけに絞る (actionable) 今すぐ対応が不要なものはチケットや日次レビューに回す 出典: Beyer et al. "Site Reliability Engineering" ch.6 (O'Reilly, 2016) Discussion: そのアラート、鳴ったら「何をするか」決まっていますか？ 2026/07/26 SRE Lounge Hiroshima #2 18
19. システム監視入門 明日からできる3つのこと 1. 自分のサービスの「稼働している」を定義する 測るものは目的から決まる 2. 迷ったら 4 Golden Signals から始める 3. データが関連付いているか確認する ログにトレースIDは入っている？グラフにデプロイは重なっている？ この確認だけなら、今夜ダッシュボードを開けばできる 2026/07/26 SRE Lounge Hiroshima #2 19
20. システム監視入門 まとめ 1. 監視には複数の目的がある — 目的から設計する 2. 何を測るかはフレームワークで抜け漏れを減らす — 4 Golden Signals / USE / RED 3. オブザーバビリティ = 想定外の「なぜ」を探れる能力 — 3本柱 + 変更イベントを関連 付ける 監視は「何が」、オブザーバビリティは「なぜ」 2026/07/26 SRE Lounge Hiroshima #2 20
21. システム監視入門 参考 書籍 『SRE サイトリライアビリティエンジニアリング』ch.6（Google / O'Reilly） https://sre.google/sre-book/monitoring-distributed-systems/ Web The USE Method / Brendan Gregg The RED Method: How to Instrument Your Services / Grafana Labs (2018) 2026/07/26 SRE Lounge Hiroshima #2 21
22. システム監視入門 Appendix: 監視・オブザーバビリティ 用語の解説 2026/07/26 SRE Lounge Hiroshima #2 22
23. システム監視入門 外形監視と内部監視 システムを「外から」と「中から」見る 種類 見方 用途 外形監視 (ブラックボック ユーザーと同じ経路でアクセス ユーザー影響の検知 ス) する 内部監視 (ホワイトボック メトリクス・ログなど内部デー 原因調査・トレンド分 ス) タ 析 ポイント: アラートは症状ベース = ユーザー体験に近い外形監視側を重視する 参考: Site Reliability Engineering ch.6 2026/07/26 SRE Lounge Hiroshima #2 23
24. システム監視入門 SLI・SLO・エラーバジェット 「稼働している」を数値で定義する道具 用語 意味 SLI サービスの状態を測る指標（例: 成功リクエストの割合） SLO SLIの目標値（例: 30日間で99.9%） エラーバジェット SLOまでの余裕。開発スピードと信頼性のバランスの判断材料 ポイント: 本編の「『稼働している』を定義する」を実践する枠組み 出典: Beyer et al. "Site Reliability Engineering" ch.4 (O'Reilly, 2016) 2026/07/26 SRE Lounge Hiroshima #2 24
25. システム監視入門 ツールの選び方 今日の話はツール非依存。選定基準は2つ 3本柱を関連付けて横断調査できるか 変更イベントを重ねられるか 分類 例 OSS OpenTelemetry + Prometheus / Grafana / Loki / Tempo SaaS Datadog / New Relic など 2026/07/26 SRE Lounge Hiroshima #2 25
26. システム監視入門 計装はどこから手を付けるか OpenTelemetry の自動計装 (auto-instrumentation) なら Java・Python・Node.js などはコード変更ほぼなしで始められる まずユーザー影響が最も大きいクリティカルパス（決済など） 1本に絞って計装するのがおすすめ 3本柱を全部揃えることが目的ではない → バラバラの3本柱より、関連付いたメトリクス + ログの2つの方が「なぜ」に辿り着 ける 2026/07/26 SRE Lounge Hiroshima #2 26
27. システム監視入門 補足: 「3本柱」という整理への批判 3本柱はあくまでデータの種類の話 — 集めるだけでは「なぜ」に答えられない ツールが柱ごとにサイロ化し、同じ事象を3回保存してコストが増えるという指摘 幅広い構造化イベントを単一の情報源に持つ「Observability 2.0」という議論も ポイント: 批判の方向は共通 — 「柱をバラバラに持つな、関連付けろ」 出典: Ben Sigelman "Three Pillars with Zero Answers" (Lightstep, 2018) / Charity Majors "Observability 2.0" (Honeycomb, 2024) 2026/07/26 SRE Lounge Hiroshima #2 27