監視のこれまでとこれから 2025-06-25 社内 Monitoring 勉強会 藤原俊一郎 (@fujiwara) 

自己紹介 @fujiwara (X, GitHub, Bluesky) @sfujiwara (hatena, mixi2) 2011〜2024 面白法人カヤック 2025-02〜 さくらインターネット ISUCON 優勝4回 / 運営(出題)4回 github.com/kayac/ecspresso github.com/fujiwara/lambroll 

なぜ監視(Monitoring)が必要なのか 「動いてないと困るから」 クラウドは「動いているサービス(サーバー含む)にお金をいただく」ビジネス 提供したサービスが健全に動いているをことを自分らで把握する必要がある 障害の発生を100%避けることはできないが、速やかに把握して修正する必要がある 

これは避けたい(可能な限り) 「デプロイ後数時間してから顧客からの問い合わせで動いていないことが発覚」 自分たちの売り物がまともに動いているかどうか分からないのは無責任 

監視は開発を加速する https://speakerdeck.com/fujiwara3/sre-next-2020 開発したソフトウェアはデプロイしなければ価値を生まない 高速・安全にデプロイサイクルを回すには監視が重要 

監視のこれまでを振り返る 歴史を振り返りつつ、現在地と進むべき先を考えていきましょう 今運用しているプロダクトの監視がどの段階かを考えながら聞いてみて下さい 

2000年〜 死活監視とOSメトリクスの時代 死活監視 監視対象が正常かどうかをその時点の値で判断、異常ならアラート送信 ping, TCP, HTTP -- 正常にレスポンスが返るか? CPU, メモリ, disk 使用率 -- 閾値を超えていないか? 0(ok), 1(warn), 2(error), 3(other) せいぜい4状態(=2bit) 実行は5分間隔が普通 代表的なツール: Nagios(1999), Zabbix(2001) 監視というとこれ(死活→アラート)を思い浮かべる人も多い 

No content

2000年〜 死活監視とOSメトリクスの時代 OSメトリクス OS上で取得できる値を時系列データとして蓄積、可視化 時系列データ = 時刻と値(数値)の組 典型的な項目 CPU, メモリ, disk使用率 ネットワークトラフィック(帯域、パケット数) 項目あたり数byte、監視対象あたり数十項目程度、5分ごとが普通(当時) 代表的なツール: MRTG(1995), RRDTool(1999), Cacti(2001), Zabbix(2001) 値を元にアラートできるものとできないもの(可視化のみ)がある 

No content

2000年〜 死活監視とOSメトリクスの時代 データ量は少ない: 監視対象あたり 数十KB〜/日 解像度は低い: 5分毎が普通 当時のWebサービス(アプリケーション)は比較的単純なものが多かった ハードウェアやOSの障害 == サービスの障害 になる確率が高かった ので、これでも何とかなった 

2000年代後半 監視の性能不足 Web 2.0(2004), SNS(mixi 2004, Twitter 2007), ソーシャルゲーム(モバゲー 2006) スマホ(iPhone 2007)などの登場 2000年代後半からWebサービスが急速に高度化・複雑化・大規模化 アプリケーションが原因で障害が発生することが増加 一方でOSSの監視ツールはそれほど進化していなかった GoogleはBorg(コンテナオーケストレーション)に対応したBorgmonを開発(2004) ex-GooglerがBorgmonをOSSで再現したのがPrometheus(2012) https://docs.google.com/presentation/d/1NziwSTwuz91fqsFhXeOGwyhFUoT6ght1irA_0ABLPU0/edit 

2010年〜 クラウドとログの時代 アプリケーションの複雑化、クラウドサービスの普及に伴ってログの重要性が増加 従来型の監視ではカバーできない領域をログによって解決する 1日/1時間ごとにscpなどでファイルを転送 → Fluentdなどで即時転送 バッチ処理で解析 → ニアリアルタイム・オンデマンドで解析 システム監視だけではなくビジネス上の要求によるデータ収集、解析も必要に → アクセスログやアプリケーションログを構造化(JSON)、即転送、集約、解析 代表的なツール 転送: Fluentd, Beats 集約: Elasticsearch, HDFS, S3, (MongoDB...) 解析: Kibana, Grafana, Hadoop, Spark 

2010年〜 クラウドとログの時代 ログを解析することで ログに含まれる情報(URL, status, レイテンシなど)を集計、可視化、検索 ログに含まれる文字情報を元にアラート など高度な監視が実現できるようになった 扱うデータ量は急激に増加: (例 250byte/行 × 100rps = 2GB/日) 

2015年〜 コンテナとマイクロサービスの時代 Kubernetes(2015), Amazon ECS(2015)などコンテナオーケストレーターが登場 3層構造(Web+App+DB)モノリス → マイクロサービス化 (コンテナ運用ではログ集約は前提) 複数コンポーネントからそれぞれ発行されるログを関連づけて扱う必要性 連鎖する複数コンポーネントの「どこで」障害が発生したのかを追跡する必要性 → 従来のログだけでは不足 

2015年〜 コンテナとマイクロサービスの時代 分散トレーシング技術が登場 一連の処理をspanと呼ばれる単位で追跡 spanは処理の開始時刻、終了時刻、span ID、親spanID、タグなどを持つ spanは複数のspanからなるトレースを形成 

2015年〜 コンテナとマイクロサービスの時代 分散トレーシングの代表的なツール Zipkin(2012) Google Cloud Trace(2015) AWS X-Ray(2016) OpenTracing(2016) → OpenTelemetry(2019) Jaeger(2017) Datadog APM(2017) Googleの Dapper 論文(2010)が始祖 https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ 

2020年〜 分散トレーシングの時代 分散トレーシングの重要性が認識され、OSSやクラウドサービスでの対応が進む データ量はさらに増加 ログ: 250byte/行 × 100rps = 2GB/日 (1台あたり) ↓ トレース: 2KB/span × 20span/req × 100rps = 300GB/日 TB/日のオーダー 量が多すぎて、すべて保管するとコストが見合わない(ことが多い) サンプリング(一部のリクエストだけを保存)することが一般的 1%のリクエストだけトレースを取得(head sampling) エラーが発生したリクエストのみトレースを保存(tail sampling) 

2020年〜 分散トレーシングの時代 オブザーバビリティ(Observability) 「システムの内部状態を外部から観測できる能力」 メトリクス: 数値で表現できるもの (集計した値、何が起きたか) ログ: 文字列で表現できるもの (生の値、何が起きたか) トレース: 処理の流れを表現できるもの (どこで起きたか) 従来の監視 = 死活監視とメトリクス ← 既知の障害を検知する オブザーバビリティ = メトリクス+ログ+トレース ← 未知の障害も検出可能にする 

2025年〜 監視の未来 (???) AI/LLMの活用 生成AIによる自動化 ログ・トレース自動分析 異常検知の精度向上 根本原因分析の高速化 eBPF統合 Linuxカーネルレベルでシステムの挙動を観測 コード変更なしで全システムをトレーシング 

まとめ 監視はサービスの健全性(商売の種)を保つために不可欠 開発と運用の両方において監視は重要な要素 2000年〜 死活監視とOSメトリクスの時代 2010年〜 クラウドとログの時代 2015年〜 コンテナとマイクロサービスの時代 2020年〜 分散トレーシングの時代 段階的に追いかければよいだけなので、やっていきましょう Sacloud OpenTelemetry collector https://github.com/sacloud/sacloud-otel-collector 

参考図書 入門 監視 https://www.oreilly.co.jp/books/9784873118642/ バックエンドエンジニアのためのイ ンフラ・クラウド大全 14章 https://www.shoeisha.co.jp/book/detail/9784798184913