## 概要
Squarespace の Senior SRE である Arnaud Lawson が、Ceph Object Storage（COS）という新規ストレージサービスに SLO を実装した実践事例を報告した発表である。リクエスト駆動のRESTfulインターフェースと分散ストレージバックエンドの両側面を持つサービスに対し、可用性・レイテンシ・耐久性の三種の SLI を定義し、プローバーを用いた能動的計測から初期 SLO を設定するまでの過程を 6 ステップで示す。SREcon19 Americas（2019-03-25、Brooklyn）で発表。
## 主要メッセージ
- SLO を導入する動機：COS の利用拡大に伴い、ユーザーの幸福度を保証し、信頼性作業の優先順位付けを改善するために SLO が必要になった（p.8）
- 6 ステップのプロセス：SLI 種別決定 → SLI 定義 → 計測方法選択 → SLI 収集と初期 SLO 推定 → エラーバジェット導出 → SLO 公開（p.9）
- ストレージサービス固有の SLI：リクエスト駆動側の可用性・レイテンシ SLI に加え、ストレージバックエンド側に耐久性 SLI（書き込んだオブジェクトが障害後も無損傷で再読み取りできる割合）を定義した（p.11）
- 計測の多層化：ロードバランサーログ・S3 クライアントのインストルメンテーション・プローバーの三種を組み合わせた（p.12）
- SLO の実績値：可用性 99.9%、レイテンシ p90 < 300 ms・p99 < 2000 ms（4 週間窓）、耐久性 99.999999%（1 年窓）（p.16）
## 視覚的に重要な図表
**p.5 Ceph Object Storage アーキテクチャ図**
![[_attachments/2019__SREcon19Americas__Implementing-SLOs-for-a-New-Service/page-005.png]]
US-EAST と EU-WEST の 2 クラスターが Ceph Object Gateway（RGW）で双方向に接続し、それぞれの上位に Web Application + App Server を持つ地理分散構成を示す。
**p.9 SLO 実装 6 ステップ**
![[_attachments/2019__SREcon19Americas__Implementing-SLOs-for-a-New-Service/page-009.png]]
「SLI 種別決定 → SLI 定義 → 計測方法選択 → SLI 収集 → エラーバジェット導出 → SLO 公開」の 6 ステップを明示した全体プロセス図。
**p.14 Overall Object Store Latency グラフ（4 週間窓）**
![[_attachments/2019__SREcon19Americas__Implementing-SLOs-for-a-New-Service/page-014.png]]
2019 年 1〜2 月の 4 週間の実績を示す。p90 レイテンシ 0.188〜0.198 秒（橙線の SLO 目標 0.300 秒を常に下回る）、p99 レイテンシ 1.484〜1.856 秒（水色線の SLO 目標 2.000 秒内で推移）。
**p.15 リクエスト種別ごとのレイテンシダッシュボード**
![[_attachments/2019__SREcon19Americas__Implementing-SLOs-for-a-New-Service/page-015.png]]
Create Bucket・Upload 400KB Object・Delete Bucket・Download 400KB Object の 4 パネル。Create Bucket の p99 が一時的に 2.6 秒を超過しており、全体の latency SLO に最も悪影響を与えるリクエスト種別として特定できる構造を示す。
**p.16 確定した SLO 一覧**
![[_attachments/2019__SREcon19Americas__Implementing-SLOs-for-a-New-Service/page-016.png]]
Availability SLO: 99.9%（4 週間）、Latency SLO: p90 < 300 ms かつ p99 < 2000 ms（4 週間）、Durability SLO: 99.999999%（1 年）の三種を確定値として提示。
## 実装詳細
**SLI 定義の対応（p.10–11）**
| コンポーネント | SLI 種別 | 定義 |
|---|---|---|
| リクエスト駆動 HTTP サーバー | 可用性 | HTTP リクエストのうち失敗しない割合 |
| リクエスト駆動 HTTP サーバー | レイテンシ | HTTP リクエストのうち x ミリ秒以内に正常完了する割合 |
| 分散ストレージバックエンド | 耐久性 | COS に書き込まれたオブジェクトのうち障害後も無損傷で再読み取りできる割合 |
**プローバーのコード（p.13）**
Go 言語の `collectSlis()` 関数で、バケット作成・削除・オブジェクトアップロード・ダウンロードの各操作を実行し、`slicollector.PushCounter`（成功/失敗）と `slicollector.PushHistogram`（レイテンシ分布）でメトリクスを送出する構造。ファイル名は `ceph_object_store_slis.go`。
**エラーバジェットの計算（p.18）**
| SLO | エラーバジェット |
|---|---|
| 可用性 99.9%（4 週間） | 0.1% のリクエストが失敗してよい |
| レイテンシ p90 < 300 ms（4 週間） | 約 10% のリクエストが ≥ 300 ms でよい |
| レイテンシ p99 < 2000 ms（4 週間） | 約 1% のリクエストが ≥ 2000 ms でよい |
| 耐久性 99.999999%（1 年） | 約 0.000001% のオブジェクト損失が許容される |
**SLO 公開ドキュメントの要素（p.19）**
COS が行うこと・実際の使われ方・SLI 種別・SLI の定義（何を計測するか）・SLI に基づく SLO の定義・SLI/SLO を選んだ根拠の 6 要素。
## 教訓とガイドライン
**得られた恩恵（p.20）**
- SLI がキャパシティプランニングや信頼性プロジェクトの優先順位決定を支援
- SLI グラフがサービス問題の早期発見に役立つ
- ユーザーが SLO をもとに自サービスへの適合性を自己判断できる
- SLO 内にある間はオンコールをページしなくてよい（SLI ベースのモニタリング）
**学んだこと（p.21）**
- 強力なクエリ言語を持つメトリクス収集サービスを選ぶ
- ストレージシステムのデータ耐久性 SLO 実装は難しい
**SLO 定義・計測のヒント（p.22）**
- 100% の信頼性を目指さない
- システムのコンポーネントを理解する
- ユーザーがシステムとどう対話するかを把握する
- ユーザーにとって重要な側面を計測する SLI を選ぶ
- SLO 結果を信頼性エンジニアリングの優先順位付けに使う
## 概念・実体への接続
- 関連概念: [[サービスレベル目標]] / [[エラーバジェット]] / [[SLI-SLO段階的導入]]
- 登壇者: [[Arnaud Lawson]]（[[Squarespace]] Senior SRE）
## 限界・不確実点
- transcript なし（Whisper 失敗、YouTube 字幕フォールバックも未実行）。口頭説明・Q&A の内容は未取得。
- 「ストレージ耐久性 SLO 実装が難しい」と述べているが、具体的に何が難しいかはスライドに記載なく、transcript なしのため詳細不明。
- プローバーで使用しているメトリクス収集サービスの製品名はスライドに記載なし。