⛳

SLO Math in SLOconf 2021の意訳

に公開
SRE
アドベントカレンダー
idea

Qiita Advent Calendar 2025の海外SRE関連セッション意訳の2日目です。ひとりアドベントカレンダーですが、完走できるように頑張ります。

前回はKeys to SREという、まさにSREの始まりの物語でした。一部Googleに特化した内容もありそうですが、かなり一般的で応用が効く原理原則を説明されていました。特にエラーバジェット枯渇時の強いポリシーの起源を知ることもできて、よかったです。
Keys to SRE in SRECon14の意訳

このアドベントカレンダーでは、海外のSRE関連のセッションを翻訳しながら、私の意見や疑問や補足を追加したものです。私の誤解から誤った説明になっている箇所は、コメントでご指摘お願いします。

このアドベントカレンダーでは、私の意見やコメントは可能な限り、下記の記法で要約と区別します。ただ、そこまで厳密にできないため、要約文中に私の思想が混じってしまうことはご容赦ください。(気がついたらご指摘ください)

紹介するセッションについて

今回はSLOconf 2021から、SLO Mathというセッションです。

https://www.youtube.com/watch?v=-lHPDx90Ppg

セッション詳細：SLO Math | SLOconf 2021

SLOの考え方、また高いSLOを達成する際の考え方を紹介してくれています。このスライドは、図や数式で説明している部分が多くあるので、ぜひ元動画と合わせて読んでみてください。

要約

SLOとは何か

SLOはサービスの内部指標ではなく「顧客体験の品質ターゲット」として扱う。

顧客体験の代表的な軸:

  • Available:サービスが利用可能である
  • Fast:十分に速く応答する
  • Complete:処理が最後まで完了する

そして「完璧さを期待しない」ことが前提になる。現実のシステムは必ず失敗するので、「どこまでなら許容か」をSLOとして定める。

「うちのシステムはもっと複雑です」問題

よくある反応:

  • 「うちのシステムはSLOで表現できるよりもっと複雑」
  • 「スタック全体を自分たちで所有していない(クラウド、サードパーティ依存が多い)」

セッションでは「OK、そうだよね」と認めたうえで、それでもSLOで考えるべき理由を説明していく。

Bad Naive Math(素朴な掛け算)の危険さ

ありがちな誤解

典型的な誤解は「全部のレイヤーのSLOを掛け算して設計する」こと。

例:

  • ユーザー体験を99.0%にしたい
  • だからWebサーバは99.9%
  • DBは99.99%
  • インフラは99.999%
  • さらにデータセンター、電源、冷却も…とどんどん積み上げる

これはクラシックなIT戦略:

  • 高価で壊れないハードウェア
  • 絶対壊れないソフトウェアを入れる
  • ドアに鍵をかけて二度と触らない

航空機の制御システムのような世界では意味があるが、一般的なオンラインサービスではスケーラビリティやフレキシビリティを犠牲にするため現実的ではない。
この「全部を常に完璧に動かそうとする」考え方をコンポーネントレベル信頼性と呼ぶ。

クラウドでの設計

ピラミッド

クラウドでは発想が異なり:

  • 個々のコンポーネントを完璧にするのではなく
  • 全体としてのアベイラビリティを集約(冗長化、フォールバック)して確保する

その結果、いちばん下の「土台コンポーネント」はそれほど高いSLOでなくてもよく、その代わりに構成と冗長化で全体の信頼性を作っていく。

分散システムとは

サービス指向アーキテクチャやマイクロサービス化で、システムは複雑な分散システムになる。

Leslie Lamportの定義:

自分が存在すら知らないコンピュータの障害によって、自分のコンピュータが使えなくなるようなシステム

という意味で、依存関係が増えるほど「知らないどこかの故障」に巻き込まれやすくなる。

サイコロによるSLOイメージ

1つの6面ダイスで「1」が障害だとする:

  • 障害が起きない確率 = 5/6 ≒0.833
    これを単一コンポーネントのSLOとみなす。

毎回4つのサイコロを振り、どれか1つでも1が出たら障害とすると:

  • 障害が起きない確率 = (5/6)^4 ≒0.482
    単体のときより大きく悪化する。

6面ダイス2つ+10面ダイス1つ+20面ダイス1つなど、違う種類を混ぜても全体の成功確率は約0.59程度にしかならない。

ここでの教訓:

  • 直列にコンポーネントを積めば積むほど、全体の信頼性は必ず単体より悪くなる

直列・並列・冗長構成とSLO集合理論

直列なサービス

直列なサービス

すべてのサービスが相互依存していて、どれか1つでも失敗すると全体が失敗する構成。
この場合は「全部成功する確率」を掛け算することになり、サービスを積み上げるほどシステム全体のSLOは低くなる。

並列だが全て必須なサービス

並列だが必須なサービス

一見並列に見えても「4つのサービスが全部必須」であれば、条件としては直列と同じ(全部成功しないとダメ)。
そのため全体のSLOはやはり悪化する。

冗長なサービス(フォールバック構成)

冗長なサービス

あるサービスが失敗したときに、別のサービスにフォールバックできる構成では話が変わる。

冗長度がnで、1つのコンポーネントのfailure_ratio(失敗率)がpのとき:

  • 全部失敗する確率 = p^n
  • 少なくとも1つ成功する確率 = 1-p^n

この考え方を広げて:

  • 直列的な条件(全て必要)をIntersection availability
  • 冗長的な条件(どれか動いていればいい)をUnion availability

集合理論

とみなして、システム全体のSLOを設計するのが「SLOの集合理論」になる。

ボトルネックと「自分で撃ち抜く足」

現実には、ボトルネックとなるコンポーネントを自分たちで所有していないことも多い:

  • ネットワーク
  • ロードバランサ
  • クラウド基盤など

さらに、自分たち自身が問題を作ることも多い:

  • テスト不足
  • 危険な変更
  • バグの持ち込み
  • 障害から十分に学ばず、浅い対処だけして終わる

だからこそ、顧客満足につながるSLOを設定し、そこに向かって改善を積み上げる必要がある。

回復力のあるソフトウェアとアーキテクチャ

回復力のあるソフトウェア(resilient software)はインフラ設計をシンプルにする。
チームとしては特定レイヤーだけを見るのではなく、End-to-Endで問題に取り組む姿勢が重要。

2つの代表的なモデル

1.Stacksモデル

  • 上位にロードバランサがあり、そこでトラフィックを分散
  • その後は決まったサービスの束に流れていく
  • 従来型の構成に近く、比較的扱いやすい

2.FullMeshモデル

  • 依存関係がフルメッシュで、どこからどこにアクセスしてもよい状態
  • 柔軟で強力だが、
    • ネットワークやストレージのコスト
    • 一貫性、シャーディング、レプリケーション
      などの問題が非常に複雑になる

YOLO的な適当モデルは推奨されず、FullMeshを採用するにしてもコストと複雑さをきちんと理解したうえで設計すべきというニュアンス。

低い信頼性の上に高い信頼性を築く

よくある質問:

  • Q: レイヤーが深くなるほどSLOはきつくならないか
  • A: 回復力を意識したエンジニアリングで、信頼性の低いコンポーネントの上により高い信頼性のシステムを構築できる

もう1つの質問:

  • Q: 自分はスタック全体を制御できている
  • A: 本当に?ロードバランサも?携帯の基地局も?電源も?

世界は本質的に「信頼性の低いもの」で構成されている。
その上に「より高い信頼性」をどう設計するかがSREの仕事であり、他のSREカンファレンスでも繰り返し語られているポイント。
この言葉は、SREcon EMEA 2019からのものだ。まだみてない人は是非みてほしい。

コンポーネントSLOとシステムSLOはいつ定義するか

同僚からの質問:

  • 「コンポーネントとシステムのSLOはいつ定義するべきか」

この問いに対しての答え:

  • SLOは「玄関口」で設定するのが基本

コンウェイの法則に従ってチームの境界ごとにSLOを定義することは多いが、そのまま積み上げると:

  • 計算が不適切になる
  • 責任分界が不自然になる
  • チーム間でフラストレーションが溜まりやすい

本当に守りたいのは:

  • ユーザーが入ってくる玄関口での体験SLO

全体を通してコメント

依存している外部サービスのせいで、ユーザー体験のSLOがこれ以上上げられないであるとか、外部依存部分を取り除いたSLOを設定して改善するといった話はよく聞く。一見、コンウェイの法則によって境界づけられたチームに対してアクションを明示してくれる点で良いことに思える。でも、そのせいでユーザー体験のSLOを改善できていないサービスは多いのかもしれない。

そういえば、アドベントカレンダー初日に見たKeys to SREでは、「エラーバジェットがリリースチェックリストの代わりとなる」という文脈で説明されていたので、リリースする組織単位でSLOが必要になるという理解だった。でも、このSLO Mathではユーザー体験の単位で玄関口でSLOを設定するという話になっている。これはどう考えたらいいんだろう？
The Keys to SRE in SRECon14の意訳 | Zenn

Discussion