LuupにおけるSLOの物語

by gr1m0h

Slide 1

Slide 1 text

Wataru Tsuda (@gr1m0h) 2023年5月16日 SLOconf Tokyo 2023 LuupにおけるSLOの物語

Slide 2

Slide 2 text

2 自己紹介 whoami Wataru Tsuda / gr1m0h SRE @Luup, inc. SRE Lounge / SRE NEXT 運営メンバー Platform Engineering Meetup 運営メンバー SRE NEXT 2023 Chair

Slide 3

Slide 3 text

3 伝えたいこと ● IoTデバイスを扱うサービスでのSLIの考え方 ● スタートアップでのSLO運用の始め方

Slide 4

Slide 4 text

4 Agenda ● Luup SREチーム ○ どんなことしてるか ○ どんなチームとコラボレーションしてるか ● LUUPにおけるSLO ○ CUJ、CMC ○ SLO ● LuupにおけるSLO運用 ○ SLO定期見直し ○ SLO違反対応 ○ BurnRateAlert対応 ○ Luup Case Study ○ Enabling SRE活動 ● Luup SREチームの今後

Slide 5

Slide 5 text

5 用語 ● LUUP ○ サービス名  ○ 電動マイクロモビリティのシェアリングサービス  ● Luup  ○ 会社名  ○ 株式会社Luup

Slide 6

Slide 6 text

6 街じゅうの電動マイクロモビリティに、どこからでも乗れて好きな場所に返せるシェアリングサービス LUUPとは https://luup.sc/

Slide 7

Slide 7 text

7 SLOについて ● SLI ○ サービス動作の指標 ○ 「ユーザーがサービスを期待通りに使えているか」が反映された指標であるべき ● SLO ○ SLIに対する具体的な目標値 ● Error Budget ○ ”SLIによって計測されるソフトウェアのエラー”に対する予算 ○ SLOに基づいて算出される “許容できるエラーの割合” ● Burn Rate ○ SLOに対してErrorBudgetをどれだけの速度で消費しているかの傾き

Slide 8

Slide 8 text

8 Agenda ● Luup SREチーム ○ どんなことしてるか ○ どんなチームとコラボレーションしてるか ● LUUPにおけるSLO ○ CUJ、CMC ○ SLO ● LuupにおけるSLO運用 ○ SLO定期見直し ○ SLO違反対応 ○ BurnRateAlert対応 ○ Luup Case Study ○ Enabling SRE活動 ● Luup SREチームの今後

Slide 9

Slide 9 text

9 LuupのSREチーム紹介 LuupのSREチームについてチーム構成：11人(正社員: 3人) 役割：LUUPを提供するためのインフラ品質や信頼性を高めること  担当範囲：  ● サービスの可用性や信頼性の向上・担保  ● 開発や運用の効率性を担保するための自動化  ● 変更管理  ● モニタリング  ● 緊急対応とオンコール体制の構築  ● キャパシティプランニング

Slide 10

Slide 10 text

10 SREチームの「ご近所さん」 LuupのSREチームについて Hardware チーム IoT チーム SRE チーム Server チーム Android チーム iOS チーム CTO PdM

Slide 11

Slide 11 text

11 ざっくり構成図 LUUPの現状構成

Slide 12

Slide 12 text

12 ざっくり構成図 LUUPの現状構成 Hardwareチーム Serverチーム IoTチーム iOS/Androidチーム

Slide 13

Slide 13 text

13 Agenda ● Luup SREチーム ○ どんなことしてるか ○ どんなチームとコラボレーションしてるか ● LUUPにおけるSLO ○ CUJ、CMC ○ SLO ● LuupにおけるSLO運用 ○ SLO定期見直し ○ SLO違反対応 ○ BurnRateAlert対応 ○ Luup Case Study ○ Enabling SRE活動 ● Luup SREチームの今後

Slide 14

Slide 14 text

14 CUJ（Critical User Journey） https://sre.google/workbook/table-of-contents/ LUUPにおけるSLO 究極的にはSLOの主眼は顧客体験の改善であるべきです。  したがって、SLOはユーザーを中心に置くアクションについて書かれるべきです。  顧客の体験を補足するには、クリティカルユーザージャーニーを利用できます。  クリティカルユーザージャーニーは、あるユーザーの体験の中核部分となるタスクの並びで、サービスのきわめて重要な側面です。  サイトリライアビリティワークブックより  ● ユーザーが目的を達成するために行うサービス操作をCUJとする ● CUJに紐づく操作を計測したSLIはユーザー体験を反映したSLIとなる

Slide 15

Slide 15 text

15 CMC（Critical Machine Communication） LUUPにおけるSLO IoTにおけるSLIで計測するべきなのは、”マシンが期待通りに動作できる状態であるか” であるその計測対象をCMC：Critical Machine Communicationと定義した ※CMCは一般用語ではなく、Luup内でCUJと区別するため作成された用語です ● CMCとは、IoTデバイスが動作するために必要なステータス群 ○ e.g. バッテリーが切れていないか、サーバーと接続されているか、... ○ プロトコルとしては、MQTTやLwM2M等 ● CMCに紐づくメトリクスを観測することで、マシンが期待通りに動作している状態であることを指標化できる ● ハードウェアの異常は影響あるユーザは少ないが、顧客体験への影響がソフトウェアの異常よりも大きくなる懸念がある

Slide 16

Slide 16 text

16 CMC（Critical Machine Communication） https://speakerdeck.com/0gm/jie-ziyuuwo-yi-qian-hua-surudian-dong-maikuromobiriteifalsesieasabisu-luup-falseiottosre LUUPにおけるSLO CMCやIoTxSREについては、 SRE NEXT 2022 でのセッションに詳しく記載されています！

Slide 17

Slide 17 text

17 LUUP ライドを行う際の一連のアクティビティ LUUPにおけるSLO

Slide 18

Slide 18 text

18 LUUP ライドを行う際の一連のアクティビティ LUUPにおけるSLO

Slide 19

Slide 19 text

19 LUUP ライドを行う際の処理の流れ LUUPにおけるSLO

Slide 20

Slide 20 text

20 LUUP ライドを行う際の処理の流れ LUUPにおけるSLO

Slide 21

Slide 21 text

21 LUUP SLO LUUPにおけるSLO SLO ● Availability SLO: 99% ○ HTTP/MQTT Success Rate ● Latency SLO: 99% ○ HTTP Response time (99%ile > 20s) 対象のアクティビティ（CUJ） ● RideStart（ライドを開始する） ● Lock（ライドを一時停止する） ● Unlock（ライドを再開する）

Slide 22

Slide 22 text

22 Agenda ● Luup SREチーム ○ どんなことしてるか ○ どんなチームとコラボレーションしてるか ● LUUPにおけるSLO ○ CUJ、CMC ○ SLO ● LuupにおけるSLO運用 ○ SLO定期見直し ○ SLO違反対応 ○ BurnRateAlert対応 ○ Luup Case Study ○ Enabling SRE活動 ● Luup SREチームの今後 ○ SLO Roadmap

Slide 23

Slide 23 text

23 SLOまわりの構成図 LuupにおけるSLO運用通知 SLO Monitor作成 ︙ メトリクス/ログ送信

Slide 24

Slide 24 text

24 Datadog SLO Dashboard LuupにおけるSLO運用 12345 12345 12345 12345

Slide 25

Slide 25 text

25 Datadog SLO:Terraform LuupにおけるSLO運用

Slide 26

Slide 26 text

26 SLOが「運用されている状態」ってどんな状態？ LuupにおけるSLO運用 1. SLO違反になった時、SLO Burn Rate Alertが鳴った時のアクションアイテム、フローが決まっており、継続的に実施がなされている状態 2. 形骸化を防ぐために定期的な見直しが実施されている状態 3. SLO違反対応、SLO Burn Rate Alertの対応、SLO定期見直しについてSREメンバーなら誰でも主導して解決に持っていける状態（属人化の排除） 4. SLOが開発計画に対する意思決定に使用されている状態 5. SLOが社内に浸透している状態

Slide 27

Slide 27 text

27 SLOが「運用されている状態」ってどんな状態？ LuupにおけるSLO運用 1. SLO違反になった時、SLO Burn Rate Alertが鳴った時のアクションアイテム、フローが決まっており、継続的に実施がなされている状態 2. 形骸化を防ぐために定期的な見直しが実施されている状態 3. SLO違反対応、SLO Burn Rate Alertの対応、SLO定期見直しについてSREメンバーなら誰でも主導して解決に持っていける状態（属人化の排除） 4. SLOが開発計画に対する意思決定に使用されている状態 5. SLOが社内に浸透している状態 SLO違反対応、SLO BurnRate Alert対応、SLO定期見直しの３つのイベントに対して対応が必要 Enabling SREという活動が必要

Slide 28

Slide 28 text

28 SLOが「運用されている状態」ってどんな状態？ LuupにおけるSLO運用 1. SLO違反になった時、SLO Burn Rate Alertが鳴った時のアクションアイテム、フローが決まっており、継続的に実施がなされている状態 2. 形骸化を防ぐために定期的な見直しが実施されている状態 3. SLO違反対応、SLO Burn Rate Alertの対応、SLO定期見直しについてSREメンバーなら誰でも主導して解決に持っていける状態（属人化の排除） 4. SLOが開発計画に対する意思決定に使用されている状態 5. SLOが社内に浸透している状態 SLO違反対応、SLO BurnRate Alert対応、SLO定期見直しの３つのイベントに対して対応が必要 Enabling SREという活動が必要

Slide 29

Slide 29 text

29 SLO運用の３つのイベント LuupにおけるSLO運用３つのイベント 1. SLO定期見直し • SLOの形骸化を防ぐために定期的な見直しを実施 2. SLO違反対応 • SLO違反が発生している = 明確に品質低下が起きている • 品質低下を改善するために新機能開発を止めて品質改善を行うべきか判断し対応を行う 3. SLO BurnRateAlert対応 • Burn Rate Alertが発火した = Error Budgetが枯渇しそうな状態 • ErrorBudget枯渇へ向かう勢いが強いので緊急度が高い対応となる

Slide 30

Slide 30 text

30 SLO定期見直し LuupにおけるSLO運用大きく２つのことを行います 1. 定期見直し会議実施 • ２Qごとに定期的に実施 • メンバー：CTO、SRE、Dev、Approver（PdM、HW） 2. SLO、BurnRateAlert閾値変更対応実施 • Terraformで変更しPR

Slide 31

Slide 31 text

31 SLO違反対応 LuupにおけるSLO運用大きく２つのことを行います 1. SLO違反対策検討会議実施 • メンバー：CTO、SRE、Dev、Approver（PdM、HW） 2. SLO違反対応実施 • SLO違反会議で出たアクションアイテムの実施

Slide 32

Slide 32 text

32 SLO BurnRateAlert対応 LuupにおけるSLO運用大きく３つのことを行います 1. 止血/緩和対応実施 2. 他チームとコミュニケーション • 止血/緩和できなかった場合はエスカレーション • 対応検討を行う 3. 対応実施

Slide 33

Slide 33 text

33 Luup Case Study: Unlock Availability SLO違反 LuupにおけるSLO運用 12345 12345 12345 12345

Slide 34

Slide 34 text

34 Luup Case Study: Unlock Availability SLO違反 LuupにおけるSLO運用 ErrorBudgetに影響を及ぼしているのは以下の項目が考えられる 1. オペレーション用アプリが同じAPIを使用していること ○ アクションアイテム：オペレーション用アプリが使用するAPIを別にする ○ オペレーション用アプリに対してもSLOを設定すべき ■ 社内/社外のサービス運用者をユーザとしたときのSLOの計測は必要 2. 同じ車両のリトライによってエラー回数が増えていること ○ リトライはErrorではなく、Warningであるべき ○ リトライの影響はAvailability SLOではなくLatency SLOに影響があるべき ○ アクションアイテム：サーバー側での自動リトライの追加によるリトライの内包

Slide 35

Slide 35 text

35 Luup Case Study: Unlock Availability SLO違反 LuupにおけるSLO運用 12345 12345 12345 12345

Slide 36

Slide 36 text

36 Luup Case Study: Unlock Availability SLO違反 LuupにおけるSLO運用 12345 12345 12345 12345 12345 12345

Slide 37

Slide 37 text

37 SLOが「運用されている状態」ってどんな状態？ LuupにおけるSLO運用 1. SLO違反になった時、SLO Burn Rate Alertが鳴った時のアクションアイテム、フローが決まっており、継続的に実施がなされている状態 2. 形骸化を防ぐために定期的な見直しが実施されている状態 3. SLO違反対応、SLO Burn Rate Alertの対応、SLO定期見直しについてSREメンバーなら誰でも主導して解決に持っていける状態（属人化の排除） 4. SLOが開発計画に対する意思決定に使用されている状態 5. SLOが社内に浸透している状態 SLO違反対応、SLO BurnRate Alert対応、SLO定期見直しの３つイベントに対して対応が必要 Enabling SREという活動が必要

Slide 38

Slide 38 text

38 Enabling SRE活動 LuupにおけるSLO運用 Enabling SRE ● 開発チームにSREの文化/知識を浸透させて開発者自身がSRE Practiceを実践できるようにする活動 ● Luupでは、SLOの普及と活用を開発チームだけでなくビジネスサイドまでスコープを広げて適用することを進めています現状の具体的な活動 ● SLOのIaC化 ○ TerraformによってDatadog SLOを設定できる状態にした ○ → 開発者に設定してもらえるようにする ● SLO社内勉強会 ○ SLO運用を行うことによるSLOの普及、意識付け ○ → もっと広く認知してもらうために勉強会を行う

Slide 39

Slide 39 text

39 Agenda ● Luup SREチーム ○ どんなことしてるか ○ どんなチームとコラボレーションしてるか ● LUUPにおけるSLO ○ CUJ、CMC ○ SLO ● LuupにおけるSLO運用 ○ SLO定期見直し ○ SLO違反対応 ○ BurnRateAlert対応 ○ Luup Case Study ○ Enabling SRE活動 ● Luup SREチームの今後

Slide 40

Slide 40 text

40 SLOまわりで今後やっていくこと Luup SREチームの今後 SLOの対象を増やしていくこと ● CUJを対象とするSLOを更に増やしていく ● CMCを対象とするSLOを増やしていく SLO運用を根付かせること ● SLO運用を回していき改善していく ● SLO勉強会を開催する ● 開発チームとの積極的なコラボレーション

Slide 41

Slide 41 text

41 LUUPのSLO運用を通して... まとめ ● SLIはCUJとCMCから決めていく ○ WebサービスにおけるCUJ（Critical User Journey） ○ IoTデバイスにおけるCMC（Critical Machine Communication） ● SLO運用について３イベントについて準備する ○ SLO違反対応、SLO BurnRate Alert対応、SLO定期見直し ● Enabling SREを進める必要がある ○ SREチーム外の開発チームやビジネスサイドにSLOを普及するため ● IoTデバイス特有のSLO運用の難しさが多くある ○ IoTデバイスとシステムのコミュニケーション（CMC）があること ○ 移動するIoTデバイスであること

Slide 42

Slide 42 text

No content