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

もう一度考えるSRE #1
https://topotal.connpass.com/event/399194/

Transcript

1. 新しい SLO が良い感じにハマっている話 もう⼀度考えるSRE #1
2. ⾃⼰紹介 • Kaita Nakamura (@z63d_) • 株式会社primeNumber • SRE • 好きな技術: コンテナ、Kubernetes • Raycast Community Japan • Raycast Ambassador 2
3. 新しい 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
4. TROCCO と SLO について 4
5. TROCCO について • ETL の SaaS • ETL: データ分析基盤構築で⾏われるプロセス • ◦ Extract: データソースからデータを抽出 ◦ Transform: データを変換‧加⼯ ◦ Load: DWH にロード ETL ジョブを 事前にスケジュールした時間や UI 上のボタンなどから実⾏可能 https://primenumber.com/trocco/features/etl 5
6. TROCCO のスケジュール機能について 指定した時間に ETL ジョブを実⾏できる機能（コア機能） 6
7. どんな SLI / SLO？ • SLI ◦ スケジュールしたジョブの実⾏遅延時間 ▪ ◦ • （正確には遅延時間そのものではなく、これに関連する指標） CUJ 的な SLO ◦ 例: p90 の xx % が xx 秒以下 7
8. 良い感じにハマっている 8
9. 信頼性の維持‧向上 以下のサイクルが回っている 1. サービス劣化の検知（burn rate が⾼い or SLO 違反） 2. 対応 3. 改善 約半年間で3回ほど⼤きめのサービス劣化を検知 ※ burn rate という SRE ⼀般⽤語を使っているが、社内で burn rate という⽤語は使ってない & burn rate は計算していない 9
10. 1 回⽬ 10
11. burn rate が⾼い リリース起因 11
12. 対応 • 原因 Ruby on Rails の config 変更が原因 ◦ • 対応 ◦ config 変更の PR の revert 12
13. 結果 • サービス劣化にすぐに気づくことができた • 対応により元の⽔準に戻った 13
14. 2 回⽬ 14
15. SLO 違反 15
16. 対応 • 原因 ◦ 既知の問題が影響していそう ◦ トリガーとなった PR がありそうだが、 ⻑期的にみると劣化傾向にあった • 対応 ◦ 根本的な DB への負荷対策などを実施 ▪ SQL クエリの改善 ▪ 関連するテーブルにインデックスを作成 ▪ ... など 16
17. 結果 • なんかめちゃくちゃ改善 • CPU‧memory 使⽤率も下がった 17
18. 3 回⽬ 18
19. burn rate が⾼い スケジュール機能に関連する変更が怪しい 19
20. 対応 • 原因 スケジュール機能に関連する変更（と推測） ◦ • 対応 ◦ SQL クエリの改善 ◦ 関連するテーブルにインデックスを作成 20
21. 結果 • スケジュール機能に関連する変更は関係なかった ◦ • 別の原因が存在した可能性が⾼かった 根本的な対応をしたことによりパフォーマンスが改善 21
22. まとめ 22
23. 導⼊を振り返って • 2026/02 から約半年間運⽤ ◦ • SLO の⾒直しをした（2‧3回⽬の間） （結果的に）以前から認識されていたが優先度が上がらず対応していな かった問題に SLO という強制⼒により対応できた • 信頼性の維持‧向上に繋がっている 23
24. 今後について 次のアクションを考えても良いかも？ 例: burn rate アラートを導⼊ 24
25. Thank you!