【SLO】”多様な期待値” と向き合ってみた SRE Kaigi 2026 延⻑戦 

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

3 3 話すこと / 話さないこと 話すこと ● SLO を設定する中で直⾯した課題とそれに対するアクション ○ 弊社の TROCCO という SaaS のスケジュール機能に関する SLO 話さないこと ● SLI/SLO の概念について ● 具体的な SLO の数値 

4 4 アジェンダ ● TROCCO とそのスケジュール機能について ● TROCCO アーキテクチャ ● スケジュール実⾏ジョブの処理フロー ● TROCCO の SLI/SLO ● 学び / 今後について 

5 TROCCO とそのスケジュール機能について 

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

7 7 TROCCO のスケジュール機能について 指定した時間に ETL ジョブを実⾏できる機能 https://documents.trocco.io/docs/schedule-settings 

8 TROCCO アーキテクチャ スケジュール機能 version 

9 9 TROCCO アーキテクチャ ⼤事なこと 💡 ● スケジュール機能にフォーカスしています ● スケジュール設定されたジョブは⼤きく分けて3段階で実⾏される 

10 10 TROCCO アーキテクチャ概要 まずは TROCCO を構成するコンポーネントについて（詳細は後述） ● DB: ユーザーが設定したジョブのスケジュール設定が⼊っている ● K8s (EKS): ジョブ実⾏基盤 ● message queue (SQS): ジョブ queue ● Scheduler (K8s Deployment): ジョブのスケジューリング（SQS へ message を送る） ● Manager (K8s Deployment): ジョブの実⾏（SQS から message を受け取る） 

11 11 TROCCO アーキテクチャ スケジュール設定されたジョブは⼤きく分けて3段階で実⾏される (1) Scheduler → (2) Manager → (3) Job 起動 

12 12 TROCCO アーキテクチャ (1) Scheduler: 定期的に DB をチェックして、スケジュール対象をリストアップ → スケジュール時間になったものは queue へ enqueue 

13 13 TROCCO アーキテクチャ (2) Manager: queue から dequeue して K8s API を叩いて Job を作成 

14 14 TROCCO アーキテクチャ (3) Job 起動: Pod（≒ コンテナ）Running → アプリケーション起動 → 処理開始 （リソースが⾜りない場合は Node がスケールアウト） 

15 スケジュール実⾏ジョブの処理フロー 

16 16 (1) Scheduler → (2) Manager → (3) Job 起動 それぞれの過程で何が処理時間に影響するか？ スケジュール実⾏ジョブの処理フロー scheduled_time スケジュール予定時間 queued_up_at queue に追加 started_at ジョブ実⾏開始時 setting_up_at K8s Job 作成時 （= K8s API 呼び出し） (1) Scheduler ‧Scheduler の性能 (2) Manager ‧Manager の性能 (3) Job 起動 ‧Node のスケールアウト ‧アプリケーション起動速度 

17 17 Scheduler: DB を⾒て、定期的にスケジュール対象をリストアップ → スケジュール時間になったものは queue へ enqueue スケジュール実⾏ジョブの処理フロー (1) scheduled_time スケジュール予定時間 queued_up_at queue に追加 started_at ジョブ実⾏開始時 setting_up_at K8s Job 作成時 （= K8s API 呼び出し） (1) Scheduler ‧Scheduler の性能 (2) Manager ‧Manager の性能 (3) Job 起動 ‧Node のスケールアウト ‧アプリケーション起動速度 

18 18 Manager: queue から dequeue して K8s API を叩いて Job を作成 スケジュール実⾏ジョブの処理フロー (2) scheduled_time スケジュール予定時間 queued_up_at queue に追加 started_at ジョブ実⾏開始時 setting_up_at K8s Job 作成時 （= K8s API 呼び出し） (1) Scheduler ‧Scheduler の性能 (2) Manager ‧Manager の性能 (3) Job 起動 ‧Node のスケールアウト ‧アプリケーション起動速度 

19 19 Job 起動: Pod（≒ コンテナ）Running → アプリケーション起動 → 処理開始 （リソースが⾜りない場合は Node がスケールアウト） スケジュール実⾏ジョブの処理フロー (3) scheduled_time スケジュール予定時間 queued_up_at queue に追加 started_at ジョブ実⾏開始時 setting_up_at K8s Job 作成時 （= K8s API 呼び出し） (1) Scheduler ‧Scheduler の性能 (2) Manager ‧Manager の性能 (3) Job 起動 ‧Node のスケールアウト ‧アプリケーション起動速度 

20 20 ⼀連の処理の合計時間 = スケジュール予定からのジョブ実⾏遅延時間 = ユーザー視点での遅延時間（UI から遅延時間が分かる） スケジュール実⾏ジョブの処理フロー scheduled_time スケジュール予定時間 queued_up_at queue に追加 started_at ジョブ実⾏開始時 setting_up_at K8s Job 作成時 （= K8s API 呼び出し） (1) Scheduler ‧Scheduler の性能 (2) Manager ‧Manager の性能 (3) Job 起動 ‧Node のスケールアウト ‧アプリケーション起動速度 ユーザー視点での遅延時間 

21 TROCCO の SLI/SLO 

22 22 既存のジョブ関連の SLO ● Job 起動の遅延（setting_up_at ~ started_at）に関する SLO があった ● スケジュール以外の UI 上から実⾏するジョブにも関連する 既存の SLO scheduled_time スケジュール予定時間 queued_up_at queue に追加 started_at ジョブ実⾏開始時 setting_up_at K8s Job 作成時 （= K8s API 呼び出し） (1) Scheduler ‧Scheduler の性能 (2) Manager ‧Manager の性能 (3) Job 起動 ‧Node のスケールアウト ‧アプリケーション起動速度 ユーザー視点での遅延時間 （過去に K8s control plane 起因で Node のスケーリングに問題が発⽣した経緯があり設定） 

23 23 スケジュール機能の SLO ● TROCCO の重要な機能の1つであるスケジュール機能の SLO が無かった ● ユーザー視点での遅延時間 を測定したい 既存の SLO scheduled_time スケジュール予定時間 queued_up_at queue に追加 started_at ジョブ実⾏開始時 setting_up_at K8s Job 作成時 （= K8s API 呼び出し） (1) Scheduler ‧Scheduler の性能 (2) Manager ‧Manager の性能 (3) Job 起動 ‧Node のスケールアウト ‧アプリケーション起動速度 ユーザー視点での遅延時間 スケジュール SLO 

24 24 いくつか課題が... 

25 25 2つの課題 1. TROCCO スケジュール機能の特性 a. スケジュール頻度によって期待値が異なる b. スケジュール時間帯による遅延の差 c. ユーザーによって期待値が異なる 2. SLI 測定の難度が⾼い a. スケジュール頻度ごとの測定 b. ジョブの同時実⾏数の制限 

26 26 1. TROCCO スケジュール機能の特性 スケジュールの遅延1つとっても... スケジュール頻度によって期待値が異なる ● 毎時（hourly）/ 毎⽇（daily）/ 毎週（weekly）/ 毎⽉（monthly） ● 例: monthly は1, 2⽇遅延しても問題ない可能性がある（極端ですが） ● 例: hourly は10分以内に実⾏されて欲しい ○ 1時間遅延すると次のスケジュールと被る ○ monthly よりは明らかに期待値が⾼い 

27 27 1. TROCCO スケジュール機能の特性 スケジュールの遅延1つとっても... スケジュール時間帯による遅延の差 ● 毎時0‧30分付近はジョブが集中するため、 各コンポーネントの負荷が⾼く、処理の遅延が⼤きい https://documents.trocco.io/docs/schedule-settings 

28 28 1. TROCCO スケジュール機能の特性 スケジュールの遅延1つとっても... ユーザーによって期待値が異なる ● 例: リアルタイムに近いデータを求めているため、 スケジュール後、直ぐに処理後のデータが欲しい 

29 29 2. SLI 測定の難度が⾼い スケジュール頻度によって期待値が異なるので スケジュール頻度ごとの測定をしたいが... 頻度ごとの測定ができない ● DB のデータを使って測定したかったが、DB の設計上、測定ができなかった ● 関連するテレメトリーデータがない（observability...） 

30 30 2. SLI 測定の難度が⾼い ジョブの同時実⾏数の制限 ● アカウント内で同時に実⾏できるジョブの数に制限がある（プランによって数は異なる） ● この制御は Manager で⾏っている ○ 同時実⾏数の制限にかかったジョブは遅延する ○ 同時実⾏数の制限にかかったジョブは遅延とはみなしたくない。（仕様のため） ○ 測定対象から除外したいが、関連するテレメトリーデータがないため除外対象を特定できない scheduled_time スケジュール予定時間 queued_up_at queue に追加 started_at ジョブ実⾏開始時 setting_up_at K8s Job 作成時 （= K8s API 呼び出し） (1) Scheduler ‧Scheduler の性能 (2) Manager ‧Manager の性能 ‧同時実⾏数の制限 (3) Job 起動 ‧Node のスケールアウト ‧アプリケーション起動速度 

31 31 どうしたか 

32 32 理想とする SLI の測定 測定するには実装コストがかかる ● スケジュール頻度ごとの測定 ○ アプリケーションロジックの変更‧DB の table 追加 / observability ● ジョブの同時実⾏数の制限 ○ observability 実装に⾒合うリターンがあるか？ 例: SLO 導⼊ → 運⽤がうまくいかない → SLO 廃⽌ → 実装が無駄になる （前提として observability が重要ということはあったりするが） → 少ない⼯数で SLO 導⼊を⽬指すことにした 

33 33 実際に設定したスケジュール機能の SLO スケジュール頻度による期待値の差分 ● 毎時（hourly）において、ユーザーの期待値を満たすための SLO を設定した ● 毎⽇（daily）/ 毎週（weekly）/ 毎⽉（monthly）で⾒ると厳しめの SLO 

34 34 実際に設定したスケジュール機能の SLO SLI として処理全体を測定せずに、Scheduler 処理だけを測定することにした ● scheduled_time ~ queued_up_at ● UI から⾒えるものではないため、ユーザー視点に基づいた SLO ではない ● 少ない⼯数で SLO 導⼊を⾏ったが、課題は多く残った スケジュール SLO scheduled_time スケジュール予定時間 queued_up_at queue に追加 started_at ジョブ実⾏開始時 setting_up_at K8s Job 作成時 （= K8s API 呼び出し） (1) Scheduler ‧Scheduler の性能 (2) Manager ‧Manager の性能 ‧同時実⾏数の制限 (3) Job 起動 ‧Node のスケールアウト ‧アプリケーション起動速度 既存の SLO 

35 学び / 今後について 

36 36 学び‧収穫 ● ユーザーに近い⼈たちの意⾒を聞ける ○ スケジュール遅延はユーザーからどう⾒えているか？課題になっているのか？ ● 判断の指標ができた ○ 以前からスケジュール遅延は何となくは測定していた。遅延を改善しても良いのでは？という意 ⾒が時々 SRE 内で出ていたが、改善すべきかの判断材料がなかった。 ○ > SLO は、どのエンジニアリング作業を優先するかの決定を助けるツールです。 （サイトリライアビリティワークブック） 

37 37 学び‧収穫 SLI で Scheduler のパフォーマンス劣化を検知 & 改善アクションができた ● SLI でパフォーマンス劣化を検知 → リリース後に スケジュールに関連する クエリ実⾏時間が ⻑くなっていた → 開発チームへ連携 ● 運⽤開始から1ヶ⽉ほどで 早速役に⽴った 

38 38 気をつけたいこと 期待値のコントロール ● 異なる期待値をひとつの SLO で管理 ● ジョブによっては（スケジュール頻度‧時間帯など） 相対的に⾼い SLO が設定されてしまっている ● Scheduler の改善が⼀部ジョブでは過剰な改善になり、 ユーザーの期待値が⾼くなりすぎる可能性がある ● 例: SLO 違反が起きても、スケジュール頻度が hourly では ユーザー体験に問題があり、monthly では問題がない可能性がある。 

39 39 今後について SLI/SLO の改善 ● 異なる期待値をひとつの SLI/SLO で管理しているので... ● スケジュール頻度ごとの SLO を設定する ● ジョブ実⾏時間帯を考慮した SLO ○ 毎時0‧30分付近は低めの SLO にするなど ● ユーザー視点に基づいた SLO ○ 現状は内部的な指標になっている ● observability ○ 上記を達成するために必要 

40 ありがとうございました