# 意味のあるSLI設計 ## 定義 意味のある SLI 設計とは、SLI(サービスレベル指標)をどのような基準に基づいてユーザーの観点から選び出すかという質問駆動の方法論である。[[Alex Hidalgo]] は『SLO サービスレベル目標』3 章で、単純なリクエスト/レスポンスサービスを題材に、信頼性を判断するための質問を「サービスは稼働しているか?」「使用可能か?」「レスポンスがあるか?」「十分な良好応答率か?」「正しいフォーマットか?」「正しいデータか?」の 6 段階へ段階的に積み上げる思考実験を示す。重要なのは、これらすべてを独立に計測する必要はなく、末端に近い 1〜2 個の計測(正しいデータの受信確認)が上流の複数の質問を暗黙にカバーするという「少数の計測による多数の計測」の原則である。複雑な多コンポーネントサービスでは、ユーザージャーニーの経路上の 1 点(例: マイクロサービス間の境界)を計測すれば、ユーザー体験全体を完全に模倣しなくても十分な代表性を得られるとされる。意味のある SLI は平易な一文(例: 「レイテンシーの P95 が 400 ミリ秒以内に正しいデータで応答する」)として記述でき、真/偽の二者択一に還元できるため SLO のパーセンテージ目標へ変換しやすい (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]])。 ## 横断的知見 - **「症状から始めて原因を後から調べる」という発想は、SLI 設計とオブザーバビリティ設計の双方に独立して現れる**: Hidalgo(3章)は SLI 設計の出発点を「サービスが何を実行すべきか」から「ユーザーが何を実行する必要があるか」へ転換すべきだと説く。これは [[ユーザー中心オブザーバビリティ]] が定義する「まずユーザーの意図・成果指標の変化を検知し、そこから技術的異常を切り分ける」という検知順序の反転と同じ発想であり、SLI 設計とオブザーバビリティ設計という異なる文脈で独立に到達した収束点である。前者は事前の指標選定(何を SLI にするか)、後者は事後の異常検知(何から調べ始めるか)に焦点があり、適用フェーズが異なる点で相補的である。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]], [[@2026__OReilly__Observability Engineering 2E - Chapter 19 Observability for Mobile and Frontend]]) - **RED メソッドとは異なる出発点から、似た指標集合に収束する**: [[RED メソッド]](Rate, Errors, Duration)はマイクロサービスの技術計装から出発し、要求率・エラー・処理時間を機械的にチェックする。一方 Hidalgo(3章)はユーザーの言葉による質問(稼働しているか、エラーなく応答するか、レスポンス時間は許容範囲か)から出発する。出発点はまったく異なる(技術指標 対 ユーザー体験の言語化)にもかかわらず、行き着く先の指標(エラー率・レイテンシー)には重なりがあり、良い SLI 候補は複数の方法論から独立に導出できることを示唆する。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]], [[RED メソッド]]) - **USE メソッド的なリソース計測は、意味のある SLI の代替にはならないと本書は明示的に注意する**: Hidalgo(3章 §3.2)は、メモリや CPU の使用率のようなリソース指標に着目していると、リクエストが高い率で正常処理されている限りユーザーにとってはリソース使用率は無関係であるため、状況が実際より悪く見える場合があると指摘する。これは [[USE メソッド]](Utilization, Saturation, Errors)が担う「リソースの健全性」と、意味のある SLI が担う「ユーザー体験の健全性」が異なる関心事であり、どちらか一方だけでは全体を代表できないことを示す。両者は診断目的(USE)と体験計測目的(SLI)で役割分担すべき指標群だと解釈できる。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]] §3.2, [[USE メソッド]]) - **3 章の小売り Web サイト例は、サービストポロジを人手で静的に作った簡易版として読める**: Hidalgo(3章)の表3-1 は、対話操作(ホームページ訪問・商品購入等)ごとに経由するコンポーネント(ロードバランサー・Web アプリ・カートサービス等)を人手で整理したものであり、[[サービストポロジ]] が解決しようとする「どのコンポーネントがどのユーザー操作に関与するか」という課題を、自動構築ではなく手作業のドキュメント化によって解いている。サービストポロジがリアルタイムに自動更新される依存グラフを目指すのに対し、3 章の例は SLI 設計の前段階として一度だけ手で描く静的な依存マップであり、両者は「依存関係を可視化して調査・設計の起点にする」という同じ目的を自動化の有無で異なる手段によって達成している。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]] §3.3, [[サービストポロジ]]) - **6 段階の質問駆動法(Hidalgo)と 2 問だけの判定テスト(Legeza)は、同じ「ユーザー起点」の原則を粒度の異なる形で運用可能にする**: Hidalgo(3章、既出)は信頼性判断を「稼働しているか」から「正しいデータか」まで 6 段階に積み上げ、末端に近い計測が上流を暗黙にカバーするという設計論を示す。『SREの探求』9章の Legeza は、あるメトリクスを SLA(実質的には SLI 候補)に含めるべきかを「(1) このメトリクスはユーザーが把握できるか」「(2) このメトリクスはユーザーにとって所定のレベルを維持する必要があるほど重要か」という 2 つの疑問だけで判定するとし、この基準に照らして「毎秒 1,000 リクエスト」という指標が複数解釈を許すために不適格であり、「単一のユーザーアカウントからは毎秒 1,000 リクエスト以下」と明示して初めてユーザー側で計測可能な指標になる例を示す(§9.1.3)。Hidalgo の 6 段階が「どの計測点を選ぶか」という設計プロセスの縦の分解であるのに対し、Legeza の 2 問テストは「候補となったメトリクス 1 つ 1 つを採用するか棄却するか」という横の選別フィルタであり、両者は SLI 候補を生成する段階(Hidalgo)とそれを検証する段階(Legeza)という異なるフェーズを担う、相補的な方法論として組み合わせられる。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]], [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] §9.1.3) - **Legeza(9章)の「コンポーネント別 SLA」は、Hidalgo の「ジャンクションでの計測」を内部サービス間の境界にまで一般化した実例を提供する**: Hidalgo(3章、既出)はユーザージャーニーの経路上の 1 点(マイクロサービス間の境界=ジャンクション)を計測すれば十分な代表性を得られると説くが、複雑サービスでどのジャンクションを選ぶかの体系的基準は示さない(既出の未解決の問い)。9章は、4 コンポーネントからなるメッセージ配信サービスの各コンポーネント境界に「通過時間」という SLI を割り当て、入力/出力比を実験的に測定してボトルネックコンポーネントを特定する手順を示す(§9.2)。これは「ジャンクションをどう選ぶか」という問いに対し、「サービスを構成するコンポーネントすべての境界を漏れなく計測点にする」という具体的な選定方針を与える一事例であり、Hidalgo の未解決の問いに部分的な実務的回答を提供する。ただし 9 章はこれを SLI 設計論としてではなくスケーリング/ボトルネック特定の手段として提示しており、両者の接続は本 wiki 側の解釈である点に留意する。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]] §3.3, [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] §9.2) ## 未解決の問い - 「少数の計測による多数の計測」の原則(末端に近い 1 点計測で上流の複数質問を暗黙にカバーする)は、末端で異常を検知しても上流のどの段階が原因かという箇所特定情報を失う。SLI としての妥当性と障害調査時の箇所特定能力のトレードオフはどう管理すべきか。 - SLI = ユーザージャーニー = KPI = インターフェイステストという用語の重複は、組織間の合意形成コストを増やす。統一用語を採用するのと、各部門固有の言葉を残したまま同じ計測を SLI として機能させるのと、どちらが実務的に優れているか(3 章はこの問いへの明確な結論を示さない)。 - 複雑なサービスにおいて「どのジャンクション(接続点)で計測するか」を選ぶ体系的な基準は、3 章のログイン例(Web アプリ⇔ユーザーマイクロサービス間)からは一般化されていない。この選択を体系立てる基準は、7 章(SLI/SLO の計測)や 9 章(統計)で補われるか。 ## 関連 - ソース: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]] / [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] - 実体: [[Alex Hidalgo]] / [[Vladimir Legeza]] - 概念: [[サービスレベル目標]](SLI/SLO/SLA の一般的定義) / [[信頼性スタック]](SLI→SLO→エラーバジェットの三層モデル) / [[ユーザー中心オブザーバビリティ]](検知順序の反転) / [[RED メソッド]] / [[USE メソッド]](技術指標駆動の補完メソドロジ) / [[サービストポロジ]](依存関係の可視化) - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]](質問駆動の SLI 設計方法論、少数計測による多数計測、複雑サービスでのジャンクション選択、SLI の平易な一文表現) - [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]](§9.1.3: SLI 採否を判定する 2 問のテスト、§9.2: コンポーネント境界への通過時間 SLI 割り当て)