はじめに
監視を考え始めると、ついダッシュボードに数字を増やしたくなります。レスポンス時間も見たいし、エラー率も見たい。リクエスト数やリソース使用率も、ないよりはあった方が安心に見えます。
ただ、数字を増やしただけでシステムの状態が分かるようになるわけではありません。むしろ、見るものが増えるほど、何を起点に判断すればいいのか分からなくなることがあります。
監視で知りたいのは、メトリクスそのものではありません。ユーザーが問題なくサービスを使えているのか。その状態をシステムが無理なく支えられているのか。このとき考える軸になるのが、SREの Golden Signals です。
Golden Signals は、Latency / Traffic / Errors / Saturation の4つです。この記事では、この4つをユーザー体験から監視を考えるための軸として整理します。
まず「何を判断したいか」から考える
レスポンス時間を見るのは、レスポンス時間という数字そのものが欲しいからではありません。ユーザーが待たされていないかを判断したいからです。
エラー率についても、知りたいのは例外の件数そのものではなく、ユーザーの操作に対して期待した結果を返せているかです。
ここを抜かしてメトリクス名から考え始めると、監視はすぐに「取れる数字を並べる作業」になります。もちろん、数字は必要です。ただ、その数字が何の判断に使われるのかが決まっていないと、ダッシュボードを見ても次の行動につながりません。
Golden Signals は、この最初の問いを作るための考え方です。
Latency：成功していても遅ければ困る
Latency は、リクエストを受けてから応答を返すまでの時間です。
一覧画面を開く処理を考えると分かりやすいです。アプリケーションがDBからデータを取得し、画面に返す。処理自体は成功していて、HTTPステータスも正常かもしれません。それでも、応答までに時間がかかりすぎれば、ユーザーにとっては使いづらい状態です。
Latency を平均だけで見ると、遅い体験が隠れることがあります。ほとんどのリクエストは速くても、一部だけ極端に遅いことがあるからです。そのため、p95 や p99 のように、遅い側の分布を見ることがあります。
「成功しているから問題ない」と思ってしまうと、Latency の悪化は見落としやすくなります。
Traffic：遅さの背景を見る
Latency が悪くなったときは、Traffic を見ると背景を探りやすくなります。
Traffic は、システムに入ってくる仕事量です。Webサービスであれば、ユーザーからのリクエスト量として見ることができます。
同じ処理でも、同時に来るリクエストが増えれば、アプリケーションやDBにかかる負荷は変わります。普段はすぐ返せていた処理でも、仕事量が増えれば待ち時間が伸びることがあります。
Traffic は、増えたからといって悪いわけではありません。サービスが使われているから増えることもあります。だから単独で眺めるより、Latency の変化と合わせて見る方が意味があります。
遅くなったときに仕事量も増えているのか。それとも、仕事量は変わらないのに遅くなっているのか。Traffic を見ると、Latency の見え方が変わります。
Errors：ユーザーにとっての失敗を見る
Errors は、リクエストや処理が期待通りに終わらなかった状態を見るための指標です。
たとえば、ユーザーがフォームを保存したとします。本来なら保存が完了し、次の画面に進めるはずです。しかし、サーバー側で失敗して保存できなかった。このときユーザーにとって重要なのは、内部でどの例外が起きたかよりも、期待した結果が返ってこなかったことです。
Errors も件数だけでは読みにくい指標です。リクエスト全体が増えれば、失敗件数も増えることがあります。見るべきなのは、受けたリクエストの中でどれくらい失敗しているのかです。
Saturation：表に出る前の余力を見る
Latency や Errors は、ユーザー体験に近いところに出ます。一方で Saturation は、その少し手前を見ます。まだ大きな失敗にはなっていないけれど、システムの余力が削られている状態です。
非同期ジョブを例にします。ユーザー操作のあとに、すぐ終わらせなくてもよい処理をキューに積み、Worker が順番に処理する仕組みです。
普段は、キューに積まれたジョブを Worker がすぐに処理できています。しかし、投入されるジョブに対して処理が追いつかなくなると、キューにジョブが残り始めます。この時点では、ユーザーに見える失敗はまだ起きていないかもしれません。それでも、内側では余力が減っています。
flowchart LR
app["アプリ"]
queue["キュー"]
worker["Worker"]
backlog["滞留ジョブ"]
app -->|"ジョブを積む"| queue
queue -->|"処理する"| worker
queue -. "処理が追いつかない分が残る" .-> backlog
この状態を見逃すと、あとから待ち時間や失敗として表に出てきます。キューの滞留のような変化を追っておくと、ユーザー影響が大きくなる前に異変に気づけます。
4つを一緒に読む
Golden Signals は、4つの項目をきれいに並べて覚えるものではありません。実際の監視では、どれか1つだけを見て判断することは少ないです。
たとえば Latency が悪化したとき、Traffic も増えていれば、仕事量の増加が影響しているかもしれません。さらに Saturation も高まっていれば、処理能力に余裕がなくなっている可能性があります。
ここで大事なのは、決まった順番で診断することではありません。数字同士を切り離さずに読むことです。
自分たちのサービスに置き換える
Golden Signals は、そのままダッシュボードに貼るテンプレートではありません。同じ Latency でも、何の待ち時間を見るべきかはサービスによって変わります。同じ Saturation でも、どこに余力の限界が出るかはシステムによって違います。
画面表示が重要なサービスなら、ユーザーが待つのは画面が返るまでの時間かもしれません。非同期処理が重要なサービスなら、ユーザーが待つのはジョブが完了して状態が反映されるまでの時間かもしれません。
APIのレスポンスタイムだけを見ていても、ジョブの完了が30分遅れていることには気づけません。この置き換えをせずに一般的なメトリクスだけを集めると、監視はできているようで判断に使いづらくなります。
まとめ
Golden Signals は、Latency / Traffic / Errors / Saturation の4つです。
ただ、名前を覚えるだけでは、監視設計にはつながりません。大事なのは、ユーザー体験から考えることです。
ユーザーが待たされていないか。期待した結果を返せているか。その背景にどれくらいの仕事量があり、システムにはまだ余力があるのか。
監視は、取れる数字を増やすところから始めると迷いやすくなります。まずは、ユーザー体験について何を判断したいのかを決める。そこから必要な数字を選ぶ方が、監視はずっと考えやすくなります。