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

by kaita

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

新しい 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

Slide 4

Slide 4 text

TROCCO と SLO について 4

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

1 回⽬ 10

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

2 回⽬ 14

Slide 15

Slide 15 text

SLO 違反 15

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

3 回⽬ 18

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

まとめ 22

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Thank you!