大きな組織にSLOを導入し 運用するということ、その難しさ / SRE NEXT 2024

SRE NEXT 2024の登壇資料になります。

Transcript

1. 大きな組織にSLOを導入し 運用するということ、その難しさ SRE NEXT 2024 工藤 純
2. 自己紹介 Jun Kudo @j_nk71 合同会社DMM.com所属。 プラットフォーム開発本部のSREとして 各チームへのSLI/SLOの導入推進や 可用性向上の施策等に取り組んでいる。
3. 今回の話 1. DMMの開発組織の話 2. 実際のSLO導入・運用のためにやったこと 3. 現時点で見えている課題・やっていきたいこと
4. DMMのプラットフォーム開発本部 決済基盤 動画配信事業部 クーポン基盤 会員基盤 電子書籍事業部 … … DMMのPF開発本部 （今回はココの話） DMMの各事業部(60+)
5. DMMのプラットフォーム開発本部の規模 在籍メンバー チーム数 　 マイクロサービス 約 120 人 約 30 チーム 約 30 個 決済基盤 クーポン基盤 会員基盤 … DMMのPF開発本部 主に今回のSLO導入推進先はこの組織
6. プラットフォーム開発本部のSREチーム PF開発本部にはサービス信頼性向上を目指す専任のSREチームがある ◆信頼性にフルコミットする珍しいチーム ◆障害対応フローやポストモーテム文化の推進、SLI/SLOの導入などを実施 ◆プラットフォームエンジニアリング的なことをするチームとは別立て ◆SREチームに信頼性向上のための知見の集約し、効率よく他チームに展開
7. DMMのマイクロサービスプラットフォーム PF開発本部のマイクロサービス基盤はマルチテナントKubernetes Clusterを ベースに構成されており、マイクロサービスを各チームが開発運用している API Gateway 認証基盤 マイクロ サービスA マイクロ サービスB マイクロ サービスC … API Gatewayを通してPFの提供機能が使える！
8. 過去のSLO運用状態 組織として形式上SLOはあったがエラーバジェットの概念もなかった 組織としてのSLO文化はほぼない状態から導入をすすめた
9. 導入・運用のために実施したこと 1. 導入の流れ 2. サポートについて 3. レビュー例の紹介 4. Doc整備内容の紹介 5. バーンレートアラートの調整
10. SLO導入時の流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget Policy 設計・設定 Burn Rate Alert 設計・設定 同時並行で SLO Documentの作成
11. SLO導入時の流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget Policy 設計・設定 Burn Rate Alert 設計・設定 リテラシーのない状態では”問題”を”問題”として認識できない 問題をキャッチしに行く姿勢でサポートする必要がある じゃあ各チームこの通りやってください！ 　　　　　　　　　　　　　　…とは行かない
12. 実際のSLO導入でのサポートと流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget Policy 設計・設定 Burn Rate Alert 設計・設定 ヒアリング＋ キックオフ MTG レビュー レビュー レビュー レビュー＋ 見直しMTG＋ 運用サポート 細かく口頭でのサポートやレビューを行い ある程度妥当な設定での導入や運用ができるようしている
13. サポートにかかる工数 ヒアリング＋ キックオフ MTG レビュー レビュー レビュー レビュー＋ 見直しMTG＋ 運用サポート 45min 30min 45min 45min 30min+ 仮に1チーム1サービスに導入する際は 短めに概算して、レビュー側は 3.5時間 程度は持っていかれる PF開発本部はおおよそ30チームなので 各チームへの初回導入だけでも累計 105時間 かける必要がある
14. レビュー例: SLOの設定値の決め方 SLIやSLOの値を考えるときに”どうしたら検知できるか”を 考えてしまっている
15. レビュー例: 達成可能ではないSLO 達成不可能なのにとりあえずSLOとして99%を選んでしまう （特にリクエスト数の少ないエンドポイントで起こる）
16. 知見を展開するためのDoc整備 最低限の下地としてDoc周りは充実させて展開している 単純な設定方針の考え方も含めDocにまとめている 文字で書いてあるだけでは 伝わらない… このDocだと約17000文字程度
17. Docへのフィードバック サポート結果を逆にDocに反映させて継続的に改善し FAQに落としている
18. 導入だけでもかなりのリテラシーを求められるが 導入後の運用もそれ以上にサポートが必要
19. 運用中の壁: Burn Rate Alertの修正 初期導入時などによくあるアラートの偽陽性発火時の修正には 多くの変数から妥当なものを選択できるリテラシーが必要 　 ◆ バーンレート値 ◆ SLO自体の高さ（エラーバジェット） ◆ SLIの閾値やクエリ ◆ SLIの評価ウィンドウや集計関数 （※Budgetを時間量で計算するSLOの場合） 変更候補となる値
20. Burn Rate Alertの修正の簡略化 誤発火への対応方針が属人化しないようにチャートを作成・展開した ex.) SLOの値が妥当か確認してから バーンレート値の引き下げを考える
21. フローチャートの全体像
22. Burn Rate値の調整 特にBurn Rate値は直感的には理解しづらいし調整も難しい SLOの値や期間が変わった際はBurn Rate値も管理する必要がある 1hourに2%の設定したいだけなのに14.4 やら 16.6やら良くわからない…
23. バーンレート値のカタログ 特に時間量をエラーバジェットとするSLOについては 機械的に閾値を緩める事ができるようにカタログを用意した バーンレート値の計算のコストがなくなる以外のメリットもある なおカタログを用意する都合上、カタログの値に縛られるリスクは懸念点
24. ちなみに… 実際にSLO導入してどう？
25. Error Budgetの活用① 全チームとは行かないが徐々に意思決定に エラーバジェットが活用される場面もでてきている
26. Error Budgetの活用② 自サービス外の依存先で キャッシュが壊れていた例
27. 一方で… 運用の中で課題もたくさん見えている
28. 運用して見えてきた難しい課題 運用中には下記の課題が見えており対応していく必要がある ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる
29. 運用して見えてきた難しい課題 ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる ➡ レビューフローの整備
30. ①-A: SLOの値の最適化 最初は実績をもとに達成可能なSLOを設定してもらって 運用で調整をつづけていく方針にしているが、そもそも調整が難しい 最終的に SLO運用側が現実的に達成できる値　　　　　 　　　　　　& ユーザーが満足する設定値 になっていればOK
31. ①-B: 達成可能な値なのか 達成可能な値かどうかの判断は SLO運用側のSLO見直しで自然と調整されていくので問題ない 達成不可能な値だった場合はSLOが割れるか ものすごい勢いでエラーバジェットが削れるので そもそも達成できない設定をしていることに気づく
32. ①-C: ユーザーの満足度を表しているか どの値だと満足ラインなのか判断できないのに加えて 最適化のための方針が立てづらい 問題1: まずSLO運用側としてはSLOを引き上げるモチベーションが発生しない 問題2: 問題1を認識した上で、SLO運用側が頑張って際限なくSLOを 　　　 引き上げるのも過度な信頼性担保につながる ➡ エラーバジェットが減ってしまうので開発にかけられる時間も減る ➡ ユーザーは十分にそれで満足しているのに高いコストを払って 　 信頼性を引き上げ続けるリスクがある ex. 目標は高く99.9999%目指すぞ！➡ユーザーは99%でも十分でした
33. ①-D: 今後の対応 - レビューフローの整備検討 SLOがSLO運用チームの独りよがりにならないような仕組みを作る必要があるが 今回は社内にユーザーがいるのでSLO変更時はユーザーの承認フローを整備したい 些細な変更等含めすべてに承認を求めていたらコミュニケーションコストが肥大化 ◆PF開発本部にとってのユーザーの事業部は60以上存在しており、かつ増減する ◆ PF開発本部はマイクロサービス＋クラウドネイティブな環境なので 　しばしばSLOの変更機会がある ex.) 自チームの部長レイヤでの承認でOKにする（部長会議ですり合わせもらう） どこかの事業部を基準としてそこがOKをだせばOKとする
34. 運用して見えてきた難しい課題 ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる ➡ レビューフローの整備 ➡ よりユーザージャーニーを表現したSLO
35. ②−A: 今後の対応 - 新たなSLOへの移行or導入 各マイクロサービス単体に対して定義する。 現在SLOの導入では運用や責務設計の 難易度の低さからこちらを採用。 現在はマイクロサービス単体のSLO（マイクロサービスSLO）形式で導入をしているが 最終的にはユーザージャーニーをより表したSLO＝プラットフォームSLOを定義したい マイクロサービス SLO プラットフォーム SLO 事業部の体験により近い形式でSLOを定義する。 マイクロサービス単体以外の要素を取り込むので 難易度が高くなる。
36. ②-B: マイクロサービスSLO API Gateway 認証基盤 決済基盤 サービス 会員基盤 サービス … 運用や責務設計の難易度の低さからマイクロサービスSLOを運用しているが 事業部の体験を厳密には定量化できていない 例えばAPI Gatewayが止まってしまったら…？
37. ②-C: マイクロサービスSLOの補足 API Gateway 認証基盤 決済基盤 サービス 外部決済代行 サービス … ちなみに各マイクロサービスのSLOは 依存先（自サービスより後段）の影響を取り込むようにSLO設計をしてもらっている ex. 決済基盤サービスにおけるレイテンシの SLOは外部決済代行サービスのレイテンシを 含めた400msを基準に計測・定義する 100ms 300ms
38. ②−D: プラットフォームSLO マイクロサービス単体では無く、他の部分も取り込むことで よりユーザー（事業部）の体験を適切に表現できるSLOにする API Gateway 決済基盤 サービス … マイクロサービスまでの到達経路として API Gateway上などのレイテンシを含めた SLOを定義する
39. ②−E: 最終的に目指したい形式 各事業部に、PF開発本部の提供する各機能のSLOを提示できる世界にしたい API Gateway 決済基盤 サービス … 会員基盤 サービス 決済機能のSLOは 決済基盤サービスのチームが運用 会員機能のSLOは 会員基盤サービスの チームが運用 API Gatewayとしての単体性能は API Gatewayの運用チームが SLOとして担保する
40. 運用して見えてきた難しい課題 ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる ➡ レビューフローの整備 ➡ よりユーザージャーニーを表現したSLO ➡ SLO as CodeによるSLOの管理
41. ③-A: SLO as Codeの導入 SLO定義がCodeで可能な仕組みを導入し SLO自体の運用負荷を下げつつ管理できる仕組みを構想中 { target: 99.9 type: "availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] } /v1/hoge, /v1/fugaに対して 5xx系を異常系として扱う AvailabilityのSLOを生成する！ 簡略化したイメージ この定義から… これによって運用負荷や要求リテラシーの 高さ問題にアプローチできる
42. ③-B: SLO as Code のうまみ① 設定の共通化・抽象化による導入・運用コストの低減が見込める { target: 99.9 type: "availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] }, … ◆ レビューができる ◆ リソースの生成コストが下がる サービスによっては エンドポイントが150個ある。 1個1個GUI上で生成するのにも限界がある。
43. ③-C: SLO as Code のうまみ② SLO Documentのドキュメントとの連携による二重管理コストの低減と 整合性担保が見込める SLO自体の実装とSLO Docの内容が一致するよう 管理しなければSLO DocがSSoTにならない SLOの実装もSLO DocもSLO as Codeから 生成してしまえば整合性が担保される！ { target: 99.9 type: "availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] }, …
44. ③-D: SLO as Code のうまみ③ さまざまなValidationが適用できるようになる ＝ガードレールが作れる！ ex.) マイクロサービス同士の依存関係を管理し 依存先のマイクロサービスよりも 高いSLOを設定しないようにしたい Code化されていることで 依存先マイクロサービスより高い信頼性を 設定していないかといったValidationができる でも人間が 管理するのは厳しい { target: 99.9 type: "availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] }, …
45. ③-E: SLO as Codeのうまみ - まとめ ① SLOのセットアップや管理が手軽になる 　（レビューができる、記述の共通化ができる） ② SLO Docなどの整合性担保をしなくてよくなる 　（SLO関連のエコシステムを作りやすくなる） ③ SLO設定のガードレールが作れる 　 (マイクロサービス間の依存関係によるSLOの関係性など）
46. まとめ ◆ SLO導入は思った以上に運用負荷があり、リテラシーが求められる。 　 大きな組織に広めていくにあたっては多大なサポートの工数がかかると感じた。 ◆ただ単にSLOのプラクティスに沿うだけではなく、 　SLOは組織そのものと向き合ってサポート＋仕組みづくりの必要がある。 ◆ まだまだサポートは十分だと思っていない。より運用しやすい形式で 　 各チームがSLOを活用していけるようなエコシステムや風土を整えていきたい。