- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
前回までは、順位や警報が誰かの判断で作られていることを見ました。今回はその手前、報告の数字そのものが選択を含むことを見ます。
まず結論
「利用者にとって速いか」という1つの問いに、測り方は何通りもあります。SRE Workbook は同じ SLI 仕様に複数の SLI 実装がありうると書き、3つの測り方それぞれの取りこぼしを名指ししています。
だから報告の数字は、事実そのものではなく「どこで測り、何を分母にし、どの期間で切ったか」を選んだ結果です。値より先に、その3つの選択を読みます。
「トップページの表示が100ミリ秒未満だった割合」を、サーバのログから測る場合と、ページ内に仕込んだ計測から測る場合。どうなるでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
測り方は、仕様から一意に決まらない
ここまでの回では、順位や警報が誰かの判断で作られていることを見ました。今回はもう一段手前、報告に載る数字そのものです。SRE Workbook 第2章は、SLI を2つに分けることを勧めています。
SLI specification The assessment of service outcome that you think matters to users, independent of how it is measured.
SLI implementation The SLI specification and a way to measure it.
仕様は「どう測るかから独立」と定義されます。つまり何を良しとするかを決めても、測り方はまだ決まっていない。原文が挙げる仕様の例:
For example: Ratio of home page requests that loaded in < 100 ms
「トップページのリクエストのうち、100ミリ秒未満で読み込めたものの割合」。一見これで終わりそうですが、原文はこの1つの仕様に3つの実装を並べます。
3つの測り方と、原文が自分で名指しする取りこぼし
3つは測る位置が違い、原文自身が取りこぼしを書いています。
測る位置 原文が書く取りこぼし・代償サーバログの Latency 列 backend に到達しなかった要求を取りこぼすVM上のブラウザのプローブ 網に届かない障害は捉えるが、一部の利用者だけの問題は取りこぼすことがあるページ内の JavaScript 体感をより正確に捉えるが、改修と記録基盤が要る
逐語で確かめます。1つ目。
... as measured from the Latency column of the server log. This measurement will miss requests that fail to reach the backend.
2つ目。
... as measured by probers that execute JavaScript in a browser running in a virtual machine. This measurement will catch errors when requests cannot reach our network, but may miss issues that affect only a subset of users.
3つ目。
... as measured by instrumentation in the JavaScript on the home page itself ... This measurement will more accurately capture the user experience, although we now need to modify the code to capture this information and build the infrastructure to record it
まとめの一文が、この回の芯です:
As you can see, a single SLI specification might have multiple SLI implementations, each with its own set of pros and cons in terms of quality (how accurately they capture the experience of a customer), coverage (how well they capture the experience of all customers), and cost.
質・網羅・そして費用。3つ目に費用が入るのが重要です。より正確な測り方には手間がかかるので、どれを選ぶかは技術的な正しさだけでは決まりません。
サーバログの Latency 列から測る方法について、原文が名指ししている取りこぼしはどれですか。
選ばれているのは、位置だけではない
測る位置のほかに、報告を作るとき選ぶものが2つあります。分母と期間です。
分母。 原文は SLI の形をこう勧めます:
While many numbers can function as an SLI, we generally recommend treating the SLI as the ratio of two numbers: the number of good events divided by the total number of events.
そして道具を揃えるため、同じ入力の形にすることを挙げます。
... you can write alerting logic, SLO analysis tools, error budget calculation, and reports to expect the same inputs: numerator, denominator, and threshold.
原文の例は分母が対象ごとに違い、total HTTP requests で割るものも total number of user minutes(利用者の総分数)で割るものもあります。
期間。 原文は窓の切り方を2種類挙げます。ずらし窓:
Rolling windows are more closely aligned with user experience: if you have a large outage on the final day of a month, your user doesn't suddenly forget about it on the first day of the following month.
月末の大障害を翌月1日に利用者が忘れるわけではない——暦の切れ目が体感の切れ目と一致しないことを原文が自分で書いています。一方で暦の窓は more closely aligned with business planning and project work とされます。ずらし窓にも厄介さがあり、30日窓では週末が4回の期間と5回の期間が生じて、
If weekend traffic differs significantly from weekday traffic, your SLIs may vary for uninteresting reasons.
値が動いた理由が、現象ではなく期間の切り方だったという状態です。
対比 — 同じ問いに、別の答えが正しく返る
第13期の性能分析編『平均は、誰のことも指していない』で、平均値が実在のどの1回も指さないことを見ました。あれは1つの数字が何を捨てているかでした。今回はその一段外側です。
選ぶもの 選択肢の例 原文の論点測る位置 サーバログ / プローブ / ページ内 質・網羅・費用が違う分母 リクエスト数 / 利用者の分数 対象ごとに違う期間 ずらし窓 / 暦の窓 体感に近い / 計画に近い
3つとも測定の誤りではありません。どれを選んでも原文の枠内で正しい SLI になります。「どちらかが嘘をついている」という読み方では、食い違う報告を読み解けません。原因は誰がどの選択をしたかです。
SRE Workbook が rolling window(ずらし窓)について挙げている利点は、どれですか。
1つの SLI 仕様に、3つの SLI 実装
1つの仕様に対し、原文は3つの測り方を並べます。どれも正しい実装ですが、取りこぼすものが違うため、同じ日の同じサービスで別々の値が出ます。
測る位置 届かなかった要求 一部の利用者だけの問題サーバログ 写らない 写る外形プローブ 写る 写らないことがある
同じ応答時間の集合に、平均と分位点
同じ測定の集合から平均も分位点も計算できます。どちらも計算としては正しいのに、遅い側の少数の扱いが違うため、示す姿が変わります。
集約の仕方 多数派の体感 少数の極端な遅さ平均 薄まって写る 薄まって消える高い分位点 写らない 写る
測る位置の選択と、集約の仕方の選択。別々の話に見えますが、共通する構造は何でしょうか。
「どちらが正しいか」を決めようとすると、両方の表で行き詰まります。その理由を考えてください。
図にすると — 報告までに挟まる3つの選択
- ・どの段も誤りではなく、原文の枠内で妥当な選択が複数ある
- ・したがって値が食い違っても、どちらかが嘘とは限らない
- ・分母の段で値が変わるという整理は本教材のもの
この章のまとめ
- SRE Workbook は SLI を仕様と実装に分ける。仕様は
independent of how it is measuredと定義され、測り方はそこから決まらない。 - 原文は1つの仕様に3つの実装を並べ、取りこぼしを名指ししている。サーバログは
miss requests that fail to reach the backend、プローブはmay miss issues that affect only a subset of users、ページ内計装は正確だが改修と基盤の費用がかかる。 - まとめの一文が芯:
a single SLI specification might have multiple SLI implementations, each with its own set of pros and cons。違いは質・網羅・費用。 - 分母も選択である。原文は
numerator, denominator, and thresholdを挙げ、例の分母はtotal HTTP requestsからtotal number of user minutesまで幅がある。分母で値が変わるという整理は本教材のもの。 - 期間も選択である。ずらし窓は体感に近く、暦の窓は事業計画に近い。週末の数が違うだけで
your SLIs may vary for uninteresting reasons。 - だから報告の数字は、値より先にどこで測り・何で割り・どこで切ったかを読む。書く側は、その3つを添える。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
SRE Workbook が `SLI specification` と `SLI implementation` を分けているのは、何を示すためですか。
用語集(5語)
- SLI 仕様 (SLI specification)
- 利用者にとって重要だと考えるサービスの結果の評価を、どう測るかから独立に述べたもの。
- SLI 実装 (SLI implementation)
- SLI 仕様に測る方法を添えたもの。同じ仕様に複数ありえ、質・網羅・費用が違う。
- 分子・分母・しきい値
- SRE Workbook が `numerator, denominator, and threshold` として挙げる3点。形を揃えると、警報や集計の道具が同じ入力を期待できる。
- ずらし窓 (rolling window)
- 直近N日・N週というように、現在から遡って切る集計期間。暦の区切りとは無関係に動く。
- 暦の窓 (calendar-aligned window)
- 月や四半期のように暦の区切りに合わせた集計期間。事業計画と揃えやすいが、途中では残りが読めない。