## 概要 [[Steve McGhee]](Google, Reliability Advocate)が Nobl9 主催の SLOconf 2021 で行った 16 分のトーク。SLO を構成するサービス群の依存関係(直列/並列・必須/冗長)を確率のダイスアナロジーで説明し、「集約可用性は SLO の depth 乗で悪化し、冗長化は 1-(1-SLO)^redundancy で改善する」という 2 つの合成式を導く。動画概要欄には併せて「chained services slo = SLOs ^ depth」「redundant parallel services ≈ SLO of the LB above」という要約が付されている(Source: metadata.json)。 ## 主要メッセージ - 顧客体験の期待値設定(可用性・速度・完全性が「十分」であること)にまずフォーカスし、配下のサービングシステムは後回しにする「フロントドア SLO」から始めるべきである(Source: frame-002)。 - 従来の IT 戦略(component-level reliability、各コンポーネントを完璧に保ち total availability を目指す「ピラミッド」)と、クラウド的な scalable reliability(aggregate availability を目標に下層ほど緩い SLO を許容する「逆ピラミッド」)は逆方向のモデルである(Source: frame-003)。 - 直列/必須並列の依存は SLO^depth で悪化し、冗長並列の依存は 1-(1-SLO)^redundancy で改善する。この 2 つの合成式を「SLO の集合論(Set Theory of SLOs)」と呼び、intersection availability(全依存必須)と union availability(いずれか 1 つで十分)として整理する(Source: frame-007, frame-008)。 - それでも 11 nines に届かない理由は、ネットワーク・ロードバランサーという自チームが所有しない依存先がボトルネックになること、変更・ミス・近道が信頼性を損なうこと、障害の詳細を浅く理解して終わらせてしまうことの 3 点である(Source: frame-009)。 - 「下位が信頼性を積み上げていく必要がある」「スタック全体を自分たちが制御している」という 2 つの前提は誤りうる誤謬(fallacy)であり、正しくは「信頼性の低いものの上に信頼性の高いものを工学的に構築できる(resilience via engineering)」こと、および「ロードバランサー・モバイル塔・電池のような制御外の依存が存在する」ことを認識すべきである(Source: frame-011)。 ## 映像で確認できる重要点 - ![[_attachments/sloconf21-mcghee-slo-math/frame-002.jpg]] frame-002「The Front Door SLO」: 顧客の幸福("Available (enough)" "Fast (enough)" "Complete (enough)")にまず焦点を当て、配下のサービングシステムは後回しにする("Don't think about the serving system (yet)")。標語は "Meet Expectations, Don't Expect Perfection"。 - ![[_attachments/sloconf21-mcghee-slo-math/frame-003.jpg]] frame-003「Context: The Pyramids」: 左が component-level reliability(正三角形、solid base・各コンポーネントを最大限稼働・total availability が目標・"scale up")、右が scalable reliability(逆三角形、less-reliable な cost-effective base・software が可用性を改善・aggregate availability が目標・"scale out")。2 つのモデルが正反対の三角形として対比されている。 - ![[_attachments/sloconf21-mcghee-slo-math/frame-006.jpg]] frame-006「Probability, real quick」: 6 面ダイスの出目「1」を障害と定義すると、障害確率は 1/6 = 0.1667、可用性 SLO は 5/6 = 0.833。6 面ダイス 4 個を直列で振ると (5/6)^4 = 0.482 まで悪化し、異なる面数のダイス(6 面×2・10 面・20 面)の組み合わせでは 5/6 × 5/6 × 9/10 × 19/20 = 0.59 になる。結論として赤字で "you'll never do as well as the worst case single throw" と示される。 - ![[_attachments/sloconf21-mcghee-slo-math/frame-008.jpg]] frame-008「Set Theory of SLOs」: intersection availability(全依存必須)は SLO^depth(例: 0.999^3 = 99.7%)、union availability(いずれか 1 つで十分)は 1-(1-SLO)^redundancy(例: 1-(1-0.999)^3 = 99.9999999%)。下段の表は component availability(99%〜99.999%)ごとに、intersection ではコンポーネント数 3/10/100 で可用性が急落する一方、union では冗長数 2/3 で可用性が急騰することを対比して示す。 - ![[_attachments/sloconf21-mcghee-slo-math/frame-009.jpg]] frame-009「Bottlenecks」: 11 nines に届かない理由として、(1) ネットワーク・ロードバランサーが「nines のリンチピン」で修正・所有が困難、(2) 変更・ミス・近道(SDLC 全体を自分たちで所有する必要がある)、(3) 浅い理解・過度な単純化(「障害の詳細こそが全てである」)の 3 点を挙げる。 - ![[_attachments/sloconf21-mcghee-slo-math/frame-011.jpg]] frame-011「Wait, that's Way Too Simple / False!」: 2 つの誤謬(fallacy)を提示する。(1)「SLO は深さとともに厳しくなければならない」→ 解: resilience via engineering(信頼性の低いものの上に信頼性の高いものを構築できる)。(2)「スタック全体を自分たちが制御している」→ 解: ロードバランサー・モバイル塔・電池は自チームの所有物ではない、と問いかける。 - ![[_attachments/sloconf21-mcghee-slo-math/frame-012.jpg]] frame-012「Closing」: 「システムに対していつ SLO を定義すべきか、コンポーネントに対してはいつか」という同僚の問いに対し、システムは「フロントドア」で設計すべきであり、Conway's law に従ってチーム境界で SLO を定義するのはよくある間違いだと述べる。結びは "Build a platform that lets you focus on customer happiness. All else will follow." ## 口頭説明・補足 **話者の経歴**(Source: transcript 冒頭): McGhee は Google で約 10 年 SRE を務め、モバイル検索・Android・Google Fiber・YouTube・Compute Engine を担当した後、いったん Google を離れてクラウド顧客側でオンプレミスからクラウドへの移行を経験した。Google に復帰後は Anthos のソリューションアーキテクトとして DevOps・CI/CD・インシデント対応・リスク管理・キャパシティプランニングの導入を支援し、現在は Reliability Advocate として Google 内部のプラットフォーム開発者にクラウド顧客の実際のニーズを伝える役割を担う。 **なぜこのトークをするか**(Source: transcript): クラウド顧客だった時期に SLO の導入自体に失敗した経験があると明かす。大規模で相互に接続され、複数チームが管理する、十分に理解されていないスタックにおいて、「間違った SLO を選んだら他チームが期待を満たせなくなるのでは」という不安が導入の障壁になったと述べる。 **直列/必須並列サービスの図解**(Source: transcript, frame-007): ロードバランサー配下に svc A(99.99%)・svc B(99.9%)・svc C(99.999%)・svc D(99.9%)が並び、4 つ全てが必要な場合、それぞれの可用性を掛け合わせると (0.9999 × 0.999 × 0.99999 × 0.999) = 99.789% になる。McGhee は「並列に配置しても、全てが必要という条件を変えない限り、直列の場合と数学的には同じ("might as well say width or breadth")」と述べる。 **"stacks" と "full mesh" という 2 つの実装モデル**(Source: transcript, frame-010): "stacks" モデルは伝統的な構成を世界各地に複製し、ロードバランシングでフェイルオーバーする方式。"full mesh" モデルはより高機能(draining・spilling 等)だが、コンピュータ・ストレージ・ネットワークのコスト増、運用・認知的複雑性、一貫性/シャーディング/レプリケーションの課題を伴う。McGhee は "YOLO"(場当たり的)や "megalith"(単一障害点となる分散モノリス)を非推奨とし、どちらのモデルでもよいので明示的なモデルを持つことを推奨する。 **Resilience via Engineering**(Source: transcript, frame-011): 「下層ほど緩い SLO でよい」という逆ピラミッドの主張に対し、"machines that fail all the time" の上に信頼性の高いサービスを構築できることを強調し、これを "resilience via engineering" と呼ぶ。ただしこれはスタック全体を制御しているという前提に依存し、実際にはロードバランサー・モバイル網・端末バッテリーなど制御外の要素があるため、エンドツーエンド体験は 11 nines ではなく 4〜5 nines 程度に留まると述べる。SREcon EMEA 2019 の "Yaniv" の発表(McGhee は "Essary" と発音しているように聞こえるが、自動文字起こしのため綴りは不確実)を「より信頼性の低いものの上に信頼性の高いものを構築する」話として参照している。 ## 概念・実体への接続 - [[サービスレベル目標]] — intersection/union availability の合成式(SLO^depth・1-(1-SLO)^redundancy)は、同 concept の「SLO Algebra はいまだ未解決」という横断的知見に対する具体的な数学的モデルを提供する。 - [[信頼性スタック]] — "resilience via engineering"(信頼性の低いものの上に信頼性の高いものを構築する)は、同 concept の「マイクロサービス群で各サービスの信頼性スタックをどう合成すべきか」という未解決の問いに部分的な回答を与える。 - [[Steve McGhee]] — 本人のキャリア・SLO 数学の一次資料。 ## 限界・不確実点 - 動画本体・音声は取得後に破棄しており、`.raw/videos/youtube--lHPDx90Ppg/` には音声(`audio.m4a`)・代表フレーム(`frames/`)・字幕由来 transcript のみを保存している。 - transcript は YouTube の字幕(自動生成の可能性が高い)から得たもので、話速が速い箇所は文の区切りが不自然になっている。固有名詞の綴り(例: "Essary Khan EMEA 2019" と聞こえる箇所)は文脈から判断できず、そのまま不確実として扱った。 - 代表フレームは動画全体から均等間隔で 12 枚抽出したものであり、フレーム間(特に frame-004〜frame-005 の間や frame-009〜frame-010 の間)のスライドは未確認。特に "Good Math needs a Model"(frame-005、シャーディング/レプリケーションの分散システムモデル図)はスライドとしては確認したが、対応する口頭説明の詳細箇所は transcript から明確に切り出せなかった。 - 動画概要欄(Source: metadata.json)には "Parallel isolated services slo = min(SLOs)" という記述があるが、これに対応するスライド・口頭説明は取得した 12 枚のフレームと transcript の中には見当たらず、未確認のまま概要欄の記述として扱う。 - 公式イベントページ(SLOconf 2021 の公式サイト)への裏取りは行っていない。