監視ツールを入れると、グラフの数はいくらでも増やせます。
CPU 使用率、メモリ、ディスク、スレッド数、キューの長さ。
ダッシュボードが埋まるほど安心感は出るのに、障害の第一報がユーザーからの連絡だった、という話は珍しくありません。
この「たくさん見ているのに気づけない」状態への回答がゴールデンシグナルという考え方でした。
Google の Site Reliability Engineering（通称 SRE 本）で示された、ユーザー影響から逆算した4つの指標です。
私も SRE の専任ではないため、原典にあたって定義と使いどころを整理しておきました。
4指標は「ユーザーに見えるもの」から選ばれている
SRE 本の Monitoring Distributed Systems の章には、ユーザー向けシステムで測る指標を4つに絞れるなら何を選ぶか、という問いが置かれています。
答えがレイテンシ・トラフィック・エラー・サチュレーションの4つでした。
並びを見ると、いずれもサーバーの内部状態ではなく、リクエストの通り道で観測できる量だと分かります。
CPU 使用率が高いこと自体は、ユーザーにとって何の意味もありません。
意味があるのは、その結果として応答が遅くなったり、エラーが返ったりする瞬間のほうです。
症状から測り、原因は後から掘るという順番が、この4指標の設計思想になりました。
レイテンシは成功と失敗を分けて測る
レイテンシは、リクエストを処理するのにかかった時間を指します。
ここで原典が強く注意しているのが、成功したリクエストと失敗したリクエストを混ぜないという点でした。
データベースへの接続を失ったときの HTTP 500 は、ごく短時間で返ることがあります。
この速いエラーを成功分と一緒に平均すると、全体のレイテンシがむしろ「改善した」ように見えてしまうのです。
原典は同時に、遅いエラーは速いエラーよりもさらに悪いとも書いています。
そのためエラーのレイテンシは、成功分とは別系統で追う必要がありました。
平均値ではなく分位数（パーセンタイル）で見るのも定石で、遅い側の少数が全体の体験を決めるからです。
トラフィックは需要、エラーは失敗の割合
トラフィックは、システムにかかっている需要の量を高レベルで表した指標になります。
Web サービスなら毎秒のリクエスト数、音声ストリーミングなら同時セッション数と、サービスの性質に合わせて選ぶ指標です。
単体では健全性を表さないものの、他の3指標を解釈するための分母として効いてきます。
エラーが 100 件あったとき、総数が 1,000 件なのか 100 万件なのかで意味はまるで違うのです。
リクエスト数には bot のアクセスも混ざるため、個人開発のサイトで CloudFront の標準ログから訪問者数を数えた記録は、別の記事にまとめました。
エラーは失敗したリクエストの割合を指し、原典は3種類に分けて説明していました。
明示的な失敗が HTTP 500 系、暗黙の失敗が 200 を返しながら中身が誤っている場合、そしてポリシー上の失敗が「1秒以内に返す」といった約束を破った場合です。
とくに200 を返しているのに内容が壊れている型は、ステータスコードの監視だけでは取りこぼします。
サチュレーションはいちばん詰まる資源を見る
サチュレーションは、サービスがどれくらい埋まっているかを表す指標でした。
原典の書き方は「もっとも制約の強い資源」に注目せよというもので、すべての資源を等しく並べる話ではありません。
メモリ律速のシステムならメモリ、I/O 律速なら I/O を主役に据えます。
重要なのは、多くのシステムは利用率 100% に届く前に性能が劣化するという指摘でした。
だから「使い切ったら警告」ではなく、目標とする利用率を決めて、その手前で気づく作りにします。
原典は早期警戒の具体策として、1分程度の短い窓で見た 99 パーセンタイルの応答時間を挙げていました。
応答時間の裾が伸び始めるのは、資源が詰まりかけているサインだという理屈です。
運用に落とすときの注意
4指標をそのまま全コンポーネントに当てはめると、今度はアラートが増えすぎます。
原典は、4つを測って問題があるとき（サチュレーションは問題になりそうなとき）に人を呼べば、監視としてはひととおり足りるとまとめていました。
裏を返せば呼ぶ対象を4つに絞ることが目的で、指標を4つ足すことが目的ではないという読み方になります。
どの水準を割ったら呼ぶのかは、サービスの目標値と合わせて決める話でした。
その考え方は、SLI と SLO の記事で扱っています。
稼働率の桁が1つ増えると運用がどれだけ変わるかも、あわせて読むと目標値の感覚がつかめるはずです。
4つに絞った症状を、今すぐ人を呼ぶアラート・数日内に片づけるチケット・記録だけのログのどれに回すかは、アラート設計の記事で整理しました。
なお、対象がリクエストを受けるサービスではなく資源そのものの場合は、USE メソッド（Utilization・Saturation・Errors）という別の切り口が向きます。
マイクロサービス向けに、レイテンシ・トラフィック・エラーの3つへ絞り込んだ RED メソッドという整理も広まりました。
/)
どれも敵対する流派ではなく、測る対象が違うだけなので、サービス層には4指標、資源層には USE と使い分けられます。
最後に
ゴールデンシグナルは、レイテンシ・トラフィック・エラー・サチュレーションの4つでした。
いずれもユーザーから見える症状を起点にしており、CPU 使用率のような内部指標は原因調査の側に回ります。
レイテンシは成功と失敗を分ける、エラーは 200 を返す失敗も数える、サチュレーションは詰まる資源を1つ選ぶ。
ダッシュボードを増やす前に、呼ばれるべき4つを決めることです。
そこが監視設計の出発点になりました。
以上です。
コメントを残す