ゴールデンシグナル

英語名 Golden Signals
読み方 ゴールデン シグナルズ
難易度
所要時間 30分〜1時間
提唱者 Google SRE Book
目次

ひとことで言うと
#

GoogleのSREプラクティスに基づく「レイテンシ・トラフィック・エラー率・飽和度」の4つのシグナルで、サービスの健全性を漏れなく監視するフレームワーク。

押さえておきたい用語
#

押さえておきたい用語
Latency(レイテンシ)
リクエストを受けてからレスポンスを返すまでの所要時間のこと。成功リクエストと失敗リクエストを分けて計測する。
Traffic(トラフィック)
サービスに到達するリクエスト量を指す。HTTP req/sec、トランザクション数などで表す。
Errors(エラー率)
リクエスト全体のうち失敗したリクエストの割合。明示的な5xxだけでなく、遅すぎるレスポンスもエラーとみなす場合がある。
Saturation(飽和度)
CPU・メモリ・ディスク・ネットワークなどのリソース使用率。上限に近づくと性能劣化が始まる指標である。
SLI(Service Level Indicator)
SLOの達成度を測るための具体的な計測指標。ゴールデンシグナルはSLIの代表的な候補になる。

ゴールデンシグナルの全体像
#

ゴールデンシグナル:サービス健全性を測る4指標
Latency(レイテンシ)リクエストの応答時間p50, p95, p99で計測成功と失敗を分けて追跡ユーザー体験に直結Traffic(トラフィック)リクエスト量・負荷req/sec, 同時接続数異常な増減はインシデントの予兆キャパシティ計画の基礎Errors(エラー率)失敗リクエストの割合5xx, タイムアウト, 不正レスポンスビジネスロジックエラーも含む最も直接的な障害指標Saturation(飽和度)リソース使用率CPU, メモリ, ディスクI/O80%超で予兆アラートを設定障害の予兆を捉える4つのシグナルをすべて監視することで障害の盲点をなくす各シグナルをSLI/SLOと紐づけてアラート閾値を設定する
ゴールデンシグナル監視の導入フロー
1
4指標の計測
各サービスでLatency/Traffic/Errors/Saturationを取得
2
閾値とアラート設定
SLOに基づいてアラート条件を定義する
3
ダッシュボード構築
4シグナルを一画面で確認できる形にする
継続的チューニング
誤報率を見ながら閾値を調整していく

こんな悩みに効く
#

  • 何を監視すればいいかわからず、とりあえずCPU使用率だけ見ている
  • アラートが1日50件以上鳴り、重要なものが埋もれている
  • 障害が起きてからユーザーの報告で気づくことが多い

基本の使い方
#

各サービスで4つのシグナルを計測する
Prometheus + Grafana、Datadog、New Relicなどの監視ツールでLatency(p50/p95/p99)、Traffic(req/sec)、Errors(5xx率)、Saturation(CPU/メモリ/ディスク)を取得する。まずは最も重要なサービスから始める。
SLOに基づいてアラート閾値を設定する
「p99レイテンシが500msを超えたらWarning、1000msを超えたらCritical」のように段階的に設定。飽和度は80%で予兆アラート、95%でCriticalが目安。アラートの条件は「X分間のY%が閾値を超えた場合」のようにノイズを減らす。
ダッシュボードで4シグナルを一画面に集約する
サービスごとに4シグナルが一目で確認できるダッシュボードを作る。オンコールのファーストレスポンダーが障害の影響範囲と原因の仮説を30秒で立てられる状態が理想。

具体例
#

例1:EC企業がゴールデンシグナルでセール時の障害を未然に防ぐ

月間300万PVのEC。年に2回の大型セール時にサーバーダウンが発生し、前回は 3時間のダウン で推定 2,400万円 の機会損失が出た。

ゴールデンシグナルの4指標を導入。

シグナル通常時セール時閾値アラート
Latency p99200ms800msWarning
Traffic500 req/sec3,000 req/sec自動スケール
Errors0.05%1%Critical
Saturation (CPU)30%75%Warning

セール開始30分前にTrafficが急増し始めた段階で自動スケールが作動。飽和度が**75%**に達する前にインスタンスが追加され、ダウンタイムゼロでセールを完走。売上は前年比 +35% を記録した。

例2:SaaS企業がアラート疲れを解消する

エンジニア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分 に短縮された。

例3:フィンテック企業がSaturationで容量限界を事前検知する

決済処理を行うフィンテック。月末の給与振込日にDB接続プールが枯渇し、決済処理が 15分間 停止するインシデントが3ヶ月連続で発生していた。

Saturationとして「DB接続プール使用率」を追加し、70%で予兆アラートを設定。

月末3日前から使用率が徐々に上昇するトレンドをダッシュボードで確認し、事前に接続プールのサイズを 100 → 250 に拡張。当月の給与振込日はピーク時の接続プール使用率が 62% にとどまり、障害ゼロで乗り切った。

やりがちな失敗パターン
#

  1. 平均値だけで監視する — レイテンシは平均ではなくパーセンタイル(p95, p99)で見る。平均200msでもp99が5秒なら一部ユーザーに深刻な影響が出ている
  2. アラート閾値を厳しくしすぎる — CPU 50%でアラートを鳴らすとノイズになる。SLOに基づいた閾値設定と、継続時間条件でノイズを削減する
  3. エラー率に明示的なHTTPエラーしか含めない — 200応答でも中身が空やタイムアウト寸前のレスポンスはユーザーにとってエラー。ビジネスロジックの失敗も含める
  4. 飽和度を後回しにする — Saturationは障害の予兆を捉える唯一の先行指標。Latency/Errors/Trafficだけでは「起きてから気づく」監視になる

まとめ
#

ゴールデンシグナルはLatency・Traffic・Errors・Saturationの4指標でサービスの健全性を監視するGoogle SRE発のフレームワーク。4つのシグナルをすべて計測することで監視の盲点をなくし、SLOに基づいたアラート閾値を設定することでアラート疲れを防ぐ。ダッシュボードに集約し、閾値を継続的にチューニングする運用が定着すれば、障害の予兆検知と迅速な対応の両方が実現する