可観測性

Google SRE Book の第4章(SLO)と第6章(分散システムのモニタリング)を取得して読み、 理解した内容を自分の言葉で書いたもの。本文の引用はしていない。

このリポジトリで長く空いていた領域。 テストもレビューも 「リリースするまで」の話なので、動かし続ける側の基準がないと片肺になる。

SLI / SLO / SLA

用語	中身
SLI(指標)	サービスの水準を定量的に測った値。リクエストレイテンシ、エラー率、スループット、可用性、耐久性など
SLO(目標)	SLI に対する目標値、または目標の範囲
SLA(合意)	SLO を満たせなかったときの結果を伴う、利用者との明示的または黙示的な契約

SLO と SLA を見分ける問いは「満たせなかったら何が起きるか」。 何も起きないならそれは SLO であって SLA ではない。

何を指標にするか

システムの種類で優先度が変わる。

ユーザー向けシステム   可用性、レイテンシ、スループット
ストレージ             レイテンシ、可用性、耐久性
ビッグデータ           スループット、エンドツーエンドのレイテンシ
すべてに共通           正しさ

出発点は測りやすいものではなく、利用者が何を必要としているか。

平均を使わない

平均はテールを覆い隠す。 大半のリクエストが速くても、ごく一部が桁違いに遅いという状態が普通に起こりうる。

だからパーセンタイルで見る。99パーセンタイルや99.9パーセンタイルが最悪ケースを、 中央値が典型的な体感を表す。

具体例として、平均レイテンシ100ms・毎秒1,000リクエストのサービスで、 1%のリクエストが5秒かかっていることは十分にありうる。

計測は平均値ではなく、指数的に分布させたバケットのヒストグラムで取る。

目標値の決め方

5つの原則が挙げられている。

1. 現在の性能を基準に目標を決めない。 維持できない英雄的努力に自分を縛りつけることになる
2. 単純に保つ。 複雑な集計をすると、性能の変化が見えなくなる
3. 絶対値を避ける。 無限のスケーラビリティや可用性100%を要求しない
4. SLO はできるだけ少なく。 守るつもりのない SLO は消す
5. 完璧は後回し。 定義は反復して磨けばよい

100%を要求するのは非現実的で、しかも望ましくない。 イノベーションとデプロイの速度を落とすから。

エラーバジェット

SLO は違反してよい割合を許容する。これを日次・週次・月次で追跡したものがエラーバジェット。

これがリリース判断の入力になる。 信頼性への期待を保ったまま、変化のための余地を明示的に確保する仕組み。

SLO は利用者の期待を作ってしまう

• 安全マージンを取る。 対外的に公表する SLO より、内部の SLO を厳しくしておく
• 過剰達成しない。 利用者は公表値ではなく実際の挙動に依存する

Chubby の例が挙がっている。信頼性が高すぎたために、 利用者側が「常に動いている」前提で作ってしまい、依存が脆くなった。

これは Hyrum の法則の運用版。 観察可能な挙動には、それが仕様かどうかに関係なく依存者が現れる。

定義を組織で揃える

集計間隔、対象リージョン、測定頻度、データの取り方を標準化しておく。 似た指標のたびに同じ議論をしなくて済む。

モニタリング

ホワイトボックスとブラックボックス

	見るもの	分かること
ホワイトボックス	内部のメトリクス、ログ、プロファイリング	これから起きる問題。リトライで隠れている障害も見える
ブラックボックス	利用者から見える外形的な振る舞い	今まさに起きている問題

両方いる。ホワイトボックスだけだと利用者影響が分からず、 ブラックボックスだけだと予兆が掴めない。

4つのゴールデンシグナル

これだけは必ず取る。

シグナル	見るもの
レイテンシ	リクエストの処理時間。成功したリクエストと失敗したリクエストを分けて測る(速いエラーより遅いエラーの方が悪い)
トラフィック	需要の量。Web なら毎秒のリクエスト数
エラー	失敗率。明示的な失敗、暗黙の失敗、ポリシー違反を含む
サチュレーション	どれだけ満杯か。多くのシステムは利用率100%に達する前に性能が劣化し始める

症状と原因

モニタリングは2つに答える。何が壊れているか(症状)と、なぜか(原因)。

• ページを出すのは症状ベースにする
• 原因ベースのモニタリングはデバッグ用

層になったシステムではある人の症状が別の人の原因になるので、 どちらで見ているかを意識する。

ページの出し方

ページは稀で、かつ行動可能でなければならない。

鳴るたびに、緊急性を持って反応できる状態であること
すべてのページが行動可能であること
ページへの対応には知性が要る。機械的に処理できるならそれは自動化すべき
ページは新しい問題を示すもので、繰り返し起きる既知の問題を示すものではない

アラートのルールを作る前に通す5つの問い。

緊急で、行動可能で、利用者から見える状態を検知しているか
無害だと分かっていて無視することがあるか
利用者が実際に不利益を被っていることを示しているか
自分が行動できるか。それは自動化すべきではないか
他の人にも同じページが飛んでいないか

通知の種類を使い分ける

種類	使いどころ
ページ	人が今すぐ動く必要があるもの
チケット	対応は必要だが即時ではないもの
ログ	診断のために残すだけで、通知しないもの

メールアラートは無効化するか、最小限にする。 すぐにノイズになって誰も見なくなる。

実務的な目安

毎秒の計測が本当に必要かを疑う。内部で集約・サンプリングする
可用性99.9%を狙うなら、外形監視は毎分1〜2回で十分。それ以上は無駄
ダッシュボードにも出さず、アラートも使わないシグナルは消す
ページの頻度を四半期ごとにレビューし、1シフトあたりの件数で測る

ダッシュボード

中核となる指標を出して、サービスについての基本的な問いに答えられるようにする。

モニタリングシステム自体は単純で理解可能に保つ。 複雑な依存階層や、閾値を自動検出する「魔法」のような仕組みは避ける。

長期の視点

一時的に可用性が下がることを受け入れてでも、根本原因を直す。 定型的なアラートに自動対応を当てているなら、それは技術的負債のサイン。 短期的な痛みがあっても、正しい修正を優先する。

関連

• インシデント対応 — ページが鳴った後の話
• リリース — エラーバジェットがリリース判断に入る
• 廃止 — アラート疲労は同じ問題
• エンジニアリング生産性の計測 — 測る価値があるかの判断