新しい SLO が良い感じにハマっている話

新しい SLO が良い感じにハマっている話もう⼀度考えるSRE #1

⾃⼰紹介 • Kaita Nakamura (@z63d_) • 株式会社primeNumber • SRE •
好きな技術: コンテナ、Kubernetes • Raycast Community Japan • Raycast Ambassador 2

新しい SLO が良い感じに機能しているのでその話この SLO を定義するまでの過程は “SRE Kaigi 2026 延⻑戦”
で話しました（資料‧アーカイブあり） https://speakerdeck.com/z63d/slo-duo-yang-naqi-dai-zhi-toxiang-kihe-tutemita https://sre-connect.connpass.com/event/381108/ 3

TROCCO と SLO について 4

TROCCO について • ETL の SaaS • ETL: データ分析基盤構築で⾏われるプロセス •
◦ Extract: データソースからデータを抽出 ◦ Transform: データを変換‧加⼯ ◦ Load: DWH にロード ETL ジョブを事前にスケジュールした時間や UI 上のボタンなどから実⾏可能 https://primenumber.com/trocco/features/etl 5

TROCCO のスケジュール機能について指定した時間に ETL ジョブを実⾏できる機能（コア機能） 6

どんな SLI / SLO？ • SLI ◦ スケジュールしたジョブの実⾏遅延時間 ▪ ◦
• （正確には遅延時間そのものではなく、これに関連する指標） CUJ 的な SLO ◦ 例: p90 の xx % が xx 秒以下 7

良い感じにハマっている 8

信頼性の維持‧向上以下のサイクルが回っている 1. サービス劣化の検知（burn rate が⾼い or SLO 違反） 2.
対応 3. 改善約半年間で3回ほど⼤きめのサービス劣化を検知 ※ burn rate という SRE ⼀般⽤語を使っているが、社内で burn rate という⽤語は使ってない & burn rate は計算していない 9

1 回⽬ 10

burn rate が⾼いリリース起因 11

対応 • 原因 Ruby on Rails の conﬁg 変更が原因 ◦
• 対応 ◦ conﬁg 変更の PR の revert 12

結果 • サービス劣化にすぐに気づくことができた • 対応により元の⽔準に戻った 13

2 回⽬ 14

SLO 違反 15

対応 • 原因 ◦ 既知の問題が影響していそう ◦ トリガーとなった PR がありそうだが、⻑期的にみると劣化傾向にあった
• 対応 ◦ 根本的な DB への負荷対策などを実施 ▪ SQL クエリの改善 ▪ 関連するテーブルにインデックスを作成 ▪ ... など 16

結果 • なんかめちゃくちゃ改善 • CPU‧memory 使⽤率も下がった 17

3 回⽬ 18

burn rate が⾼いスケジュール機能に関連する変更が怪しい 19

対応 • 原因スケジュール機能に関連する変更（と推測） ◦ • 対応 ◦ SQL クエリの改善
◦ 関連するテーブルにインデックスを作成 20

結果 • スケジュール機能に関連する変更は関係なかった ◦ • 別の原因が存在した可能性が⾼かった根本的な対応をしたことによりパフォーマンスが改善 21

まとめ 22

導⼊を振り返って • 2026/02 から約半年間運⽤ ◦ • SLO の⾒直しをした（2‧3回⽬の間）（結果的に）以前から認識されていたが優先度が上がらず対応していなかった問題に
SLO という強制⼒により対応できた • 信頼性の維持‧向上に繋がっている 23

今後について次のアクションを考えても良いかも？例: burn rate アラートを導⼊ 24

Thank you!

新しい SLO が良い感じにハマっている話

新しい SLO が良い感じにハマっている話

kaita

More Decks by kaita

Other Decks in Technology

Featured

Transcript