ひとことで言うと#
GoogleのSREプラクティスに基づく「レイテンシ・トラフィック・エラー率・飽和度」の4つのシグナルで、サービスの健全性を漏れなく監視するフレームワーク。
押さえておきたい用語#
- Latency(レイテンシ)
- リクエストを受けてからレスポンスを返すまでの所要時間のこと。成功リクエストと失敗リクエストを分けて計測する。
- Traffic(トラフィック)
- サービスに到達するリクエスト量を指す。HTTP req/sec、トランザクション数などで表す。
- Errors(エラー率)
- リクエスト全体のうち失敗したリクエストの割合。明示的な5xxだけでなく、遅すぎるレスポンスもエラーとみなす場合がある。
- Saturation(飽和度)
- CPU・メモリ・ディスク・ネットワークなどのリソース使用率。上限に近づくと性能劣化が始まる指標である。
- SLI(Service Level Indicator)
- SLOの達成度を測るための具体的な計測指標。ゴールデンシグナルはSLIの代表的な候補になる。
ゴールデンシグナルの全体像#
こんな悩みに効く#
- 何を監視すればいいかわからず、とりあえずCPU使用率だけ見ている
- アラートが1日50件以上鳴り、重要なものが埋もれている
- 障害が起きてからユーザーの報告で気づくことが多い
基本の使い方#
具体例#
月間300万PVのEC。年に2回の大型セール時にサーバーダウンが発生し、前回は 3時間のダウン で推定 2,400万円 の機会損失が出た。
ゴールデンシグナルの4指標を導入。
| シグナル | 通常時 | セール時閾値 | アラート |
|---|---|---|---|
| Latency p99 | 200ms | 800ms | Warning |
| Traffic | 500 req/sec | 3,000 req/sec | 自動スケール |
| Errors | 0.05% | 1% | Critical |
| Saturation (CPU) | 30% | 75% | Warning |
セール開始30分前にTrafficが急増し始めた段階で自動スケールが作動。飽和度が**75%**に達する前にインスタンスが追加され、ダウンタイムゼロでセールを完走。売上は前年比 +35% を記録した。
エンジニア60名のBtoB SaaS。監視ツールから1日平均 87件 のアラートが飛んでおり、オンコールのエンジニアがアラートを無視し始めていた。
ゴールデンシグナルの4指標に集約し、それ以外のアラートを「情報」レベルに格下げ。
| 変更前 | 変更後 |
|---|---|
| CPU > 50%でアラート | Saturation > 80%でWarning |
| 1回の5xxでアラート | Errors > 0.5%が5分継続でCritical |
| レスポンス > 100msでアラート | Latency p99 > 500msが3分継続でWarning |
1日のアクション必要アラートが 87件 → 4件 に削減。Critical アラートの対応率が 34% → 98% に向上し、MTTRも 45分 → 12分 に短縮された。
決済処理を行うフィンテック。月末の給与振込日にDB接続プールが枯渇し、決済処理が 15分間 停止するインシデントが3ヶ月連続で発生していた。
Saturationとして「DB接続プール使用率」を追加し、70%で予兆アラートを設定。
月末3日前から使用率が徐々に上昇するトレンドをダッシュボードで確認し、事前に接続プールのサイズを 100 → 250 に拡張。当月の給与振込日はピーク時の接続プール使用率が 62% にとどまり、障害ゼロで乗り切った。
やりがちな失敗パターン#
- 平均値だけで監視する — レイテンシは平均ではなくパーセンタイル(p95, p99)で見る。平均200msでもp99が5秒なら一部ユーザーに深刻な影響が出ている
- アラート閾値を厳しくしすぎる — CPU 50%でアラートを鳴らすとノイズになる。SLOに基づいた閾値設定と、継続時間条件でノイズを削減する
- エラー率に明示的なHTTPエラーしか含めない — 200応答でも中身が空やタイムアウト寸前のレスポンスはユーザーにとってエラー。ビジネスロジックの失敗も含める
- 飽和度を後回しにする — Saturationは障害の予兆を捉える唯一の先行指標。Latency/Errors/Trafficだけでは「起きてから気づく」監視になる
まとめ#
ゴールデンシグナルはLatency・Traffic・Errors・Saturationの4指標でサービスの健全性を監視するGoogle SRE発のフレームワーク。4つのシグナルをすべて計測することで監視の盲点をなくし、SLOに基づいたアラート閾値を設定することでアラート疲れを防ぐ。ダッシュボードに集約し、閾値を継続的にチューニングする運用が定着すれば、障害の予兆検知と迅速な対応の両方が実現する。