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

by Jun Kudo

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 Jun Kudo @j_nk71 合同会社DMM.com所属。プラットフォーム開発本部のSREとして各チームへのSLI/SLOの導入推進や可用性向上の施策等に取り組んでいる。

Slide 3

Slide 3 text

今回の話 1. DMMの開発組織の話 2. 実際のSLO導入・運用のためにやったこと 3. 現時点で見えている課題・やっていきたいこと

Slide 4

Slide 4 text

DMMのプラットフォーム開発本部決済基盤動画配信事業部クーポン基盤会員基盤電子書籍事業部 … … DMMのPF開発本部（今回はココの話） DMMの各事業部(60+)

Slide 5

Slide 5 text

DMMのプラットフォーム開発本部の規模在籍メンバーチーム数　マイクロサービス約 120 人約 30 チーム約 30 個決済基盤クーポン基盤会員基盤 … DMMのPF開発本部主に今回のSLO導入推進先はこの組織

Slide 6

Slide 6 text

プラットフォーム開発本部のSREチーム PF開発本部にはサービス信頼性向上を目指す専任のSREチームがある ◆信頼性にフルコミットする珍しいチーム ◆障害対応フローやポストモーテム文化の推進、SLI/SLOの導入などを実施 ◆プラットフォームエンジニアリング的なことをするチームとは別立て ◆SREチームに信頼性向上のための知見の集約し、効率よく他チームに展開

Slide 7

Slide 7 text

DMMのマイクロサービスプラットフォーム PF開発本部のマイクロサービス基盤はマルチテナントKubernetes Clusterをベースに構成されており、マイクロサービスを各チームが開発運用している API Gateway 認証基盤マイクロサービスA マイクロサービスB マイクロサービスC … API Gatewayを通してPFの提供機能が使える！

Slide 8

Slide 8 text

過去のSLO運用状態組織として形式上SLOはあったがエラーバジェットの概念もなかった組織としてのSLO文化はほぼない状態から導入をすすめた

Slide 9

Slide 9 text

導入・運用のために実施したこと 1. 導入の流れ 2. サポートについて 3. レビュー例の紹介 4. Doc整備内容の紹介 5. バーンレートアラートの調整

Slide 10

Slide 10 text

SLO導入時の流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget Policy 設計・設定 Burn Rate Alert 設計・設定同時並行で SLO Documentの作成

Slide 11

Slide 11 text

SLO導入時の流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget Policy 設計・設定 Burn Rate Alert 設計・設定リテラシーのない状態では”問題”を”問題”として認識できない問題をキャッチしに行く姿勢でサポートする必要があるじゃあ各チームこの通りやってください！　　　　　　　　　　　　　　…とは行かない

Slide 12

Slide 12 text

実際のSLO導入でのサポートと流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget Policy 設計・設定 Burn Rate Alert 設計・設定ヒアリング＋キックオフ MTG レビューレビューレビューレビュー＋見直しMTG＋運用サポート細かく口頭でのサポートやレビューを行いある程度妥当な設定での導入や運用ができるようしている

Slide 13

Slide 13 text

サポートにかかる工数ヒアリング＋キックオフ MTG レビューレビューレビューレビュー＋見直しMTG＋運用サポート 45min 30min 45min 45min 30min+ 仮に1チーム1サービスに導入する際は短めに概算して、レビュー側は 3.5時間程度は持っていかれる PF開発本部はおおよそ30チームなので各チームへの初回導入だけでも累計 105時間かける必要がある

Slide 14

Slide 14 text

レビュー例: SLOの設定値の決め方 SLIやSLOの値を考えるときに”どうしたら検知できるか”を考えてしまっている

Slide 15

Slide 15 text

レビュー例: 達成可能ではないSLO 達成不可能なのにとりあえずSLOとして99%を選んでしまう（特にリクエスト数の少ないエンドポイントで起こる）

Slide 16

Slide 16 text

知見を展開するためのDoc整備最低限の下地としてDoc周りは充実させて展開している単純な設定方針の考え方も含めDocにまとめている文字で書いてあるだけでは伝わらない… このDocだと約17000文字程度

Slide 17

Slide 17 text

Docへのフィードバックサポート結果を逆にDocに反映させて継続的に改善し FAQに落としている

Slide 18

Slide 18 text

導入だけでもかなりのリテラシーを求められるが導入後の運用もそれ以上にサポートが必要

Slide 19

Slide 19 text

運用中の壁: Burn Rate Alertの修正初期導入時などによくあるアラートの偽陽性発火時の修正には多くの変数から妥当なものを選択できるリテラシーが必要　 ◆ バーンレート値 ◆ SLO自体の高さ（エラーバジェット） ◆ SLIの閾値やクエリ ◆ SLIの評価ウィンドウや集計関数（※Budgetを時間量で計算するSLOの場合）変更候補となる値

Slide 20

Slide 20 text

Burn Rate Alertの修正の簡略化誤発火への対応方針が属人化しないようにチャートを作成・展開した ex.) SLOの値が妥当か確認してからバーンレート値の引き下げを考える

Slide 21

Slide 21 text

フローチャートの全体像

Slide 22

Slide 22 text

Burn Rate値の調整特にBurn Rate値は直感的には理解しづらいし調整も難しい SLOの値や期間が変わった際はBurn Rate値も管理する必要がある 1hourに2%の設定したいだけなのに14.4 やら 16.6やら良くわからない…

Slide 23

Slide 23 text

バーンレート値のカタログ特に時間量をエラーバジェットとするSLOについては機械的に閾値を緩める事ができるようにカタログを用意したバーンレート値の計算のコストがなくなる以外のメリットもあるなおカタログを用意する都合上、カタログの値に縛られるリスクは懸念点

Slide 24

Slide 24 text

ちなみに… 実際にSLO導入してどう？

Slide 25

Slide 25 text

Error Budgetの活用① 全チームとは行かないが徐々に意思決定にエラーバジェットが活用される場面もでてきている

Slide 26

Slide 26 text

Error Budgetの活用② 自サービス外の依存先でキャッシュが壊れていた例

Slide 27

Slide 27 text

一方で… 運用の中で課題もたくさん見えている

Slide 28

Slide 28 text

運用して見えてきた難しい課題運用中には下記の課題が見えており対応していく必要がある ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる

Slide 29

Slide 29 text

運用して見えてきた難しい課題 ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる ➡ レビューフローの整備

Slide 30

Slide 30 text

①-A: SLOの値の最適化最初は実績をもとに達成可能なSLOを設定してもらって運用で調整をつづけていく方針にしているが、そもそも調整が難しい最終的に SLO運用側が現実的に達成できる値　　　　　　　　　　　& ユーザーが満足する設定値になっていればOK

Slide 31

Slide 31 text

①-B: 達成可能な値なのか達成可能な値かどうかの判断は SLO運用側のSLO見直しで自然と調整されていくので問題ない達成不可能な値だった場合はSLOが割れるかものすごい勢いでエラーバジェットが削れるのでそもそも達成できない設定をしていることに気づく

Slide 32

Slide 32 text

①-C: ユーザーの満足度を表しているかどの値だと満足ラインなのか判断できないのに加えて最適化のための方針が立てづらい問題1: まずSLO運用側としてはSLOを引き上げるモチベーションが発生しない問題2: 問題1を認識した上で、SLO運用側が頑張って際限なくSLOを　　　引き上げるのも過度な信頼性担保につながる ➡ エラーバジェットが減ってしまうので開発にかけられる時間も減る ➡ ユーザーは十分にそれで満足しているのに高いコストを払って　信頼性を引き上げ続けるリスクがある ex. 目標は高く99.9999%目指すぞ！➡ユーザーは99%でも十分でした

Slide 33

Slide 33 text

①-D: 今後の対応 - レビューフローの整備検討 SLOがSLO運用チームの独りよがりにならないような仕組みを作る必要があるが今回は社内にユーザーがいるのでSLO変更時はユーザーの承認フローを整備したい些細な変更等含めすべてに承認を求めていたらコミュニケーションコストが肥大化 ◆PF開発本部にとってのユーザーの事業部は60以上存在しており、かつ増減する ◆ PF開発本部はマイクロサービス＋クラウドネイティブな環境なので　しばしばSLOの変更機会がある ex.) 自チームの部長レイヤでの承認でOKにする（部長会議ですり合わせもらう）どこかの事業部を基準としてそこがOKをだせばOKとする

Slide 34

Slide 34 text

運用して見えてきた難しい課題 ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる ➡ レビューフローの整備 ➡ よりユーザージャーニーを表現したSLO

Slide 35

Slide 35 text

②−A: 今後の対応 - 新たなSLOへの移行or導入各マイクロサービス単体に対して定義する。現在SLOの導入では運用や責務設計の難易度の低さからこちらを採用。現在はマイクロサービス単体のSLO（マイクロサービスSLO）形式で導入をしているが最終的にはユーザージャーニーをより表したSLO＝プラットフォームSLOを定義したいマイクロサービス SLO プラットフォーム SLO 事業部の体験により近い形式でSLOを定義する。マイクロサービス単体以外の要素を取り込むので難易度が高くなる。

Slide 36

Slide 36 text

②-B: マイクロサービスSLO API Gateway 認証基盤決済基盤サービス会員基盤サービス … 運用や責務設計の難易度の低さからマイクロサービスSLOを運用しているが事業部の体験を厳密には定量化できていない例えばAPI Gatewayが止まってしまったら…？

Slide 37

Slide 37 text

②-C: マイクロサービスSLOの補足 API Gateway 認証基盤決済基盤サービス外部決済代行サービス … ちなみに各マイクロサービスのSLOは依存先（自サービスより後段）の影響を取り込むようにSLO設計をしてもらっている ex. 決済基盤サービスにおけるレイテンシの SLOは外部決済代行サービスのレイテンシを含めた400msを基準に計測・定義する 100ms 300ms

Slide 38

Slide 38 text

②−D: プラットフォームSLO マイクロサービス単体では無く、他の部分も取り込むことでよりユーザー（事業部）の体験を適切に表現できるSLOにする API Gateway 決済基盤サービス … マイクロサービスまでの到達経路として API Gateway上などのレイテンシを含めた SLOを定義する

Slide 39

Slide 39 text

②−E: 最終的に目指したい形式各事業部に、PF開発本部の提供する各機能のSLOを提示できる世界にしたい API Gateway 決済基盤サービス … 会員基盤サービス決済機能のSLOは決済基盤サービスのチームが運用会員機能のSLOは会員基盤サービスのチームが運用 API Gatewayとしての単体性能は API Gatewayの運用チームが SLOとして担保する

Slide 40

Slide 40 text

運用して見えてきた難しい課題 ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる ➡ レビューフローの整備 ➡ よりユーザージャーニーを表現したSLO ➡ SLO as CodeによるSLOの管理

Slide 41

Slide 41 text

③-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を生成する！簡略化したイメージこの定義から… これによって運用負荷や要求リテラシーの高さ問題にアプローチできる

Slide 42

Slide 42 text

③-B: SLO as Code のうまみ① 設定の共通化・抽象化による導入・運用コストの低減が見込める { target: 99.9 type: "availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] }, … ◆ レビューができる ◆ リソースの生成コストが下がるサービスによってはエンドポイントが150個ある。 1個1個GUI上で生成するのにも限界がある。

Slide 43

Slide 43 text

③-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*"] }, …

Slide 44

Slide 44 text

③-D: SLO as Code のうまみ③ さまざまなValidationが適用できるようになる＝ガードレールが作れる！ ex.) マイクロサービス同士の依存関係を管理し依存先のマイクロサービスよりも高いSLOを設定しないようにしたい Code化されていることで依存先マイクロサービスより高い信頼性を設定していないかといったValidationができるでも人間が管理するのは厳しい { target: 99.9 type: "availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] }, …

Slide 45

Slide 45 text

③-E: SLO as Codeのうまみ - まとめ ① SLOのセットアップや管理が手軽になる　（レビューができる、記述の共通化ができる） ② SLO Docなどの整合性担保をしなくてよくなる　（SLO関連のエコシステムを作りやすくなる） ③ SLO設定のガードレールが作れる　 (マイクロサービス間の依存関係によるSLOの関係性など）

Slide 46

Slide 46 text

まとめ ◆ SLO導入は思った以上に運用負荷があり、リテラシーが求められる。　大きな組織に広めていくにあたっては多大なサポートの工数がかかると感じた。 ◆ただ単にSLOのプラクティスに沿うだけではなく、　SLOは組織そのものと向き合ってサポート＋仕組みづくりの必要がある。 ◆ まだまだサポートは十分だと思っていない。より運用しやすい形式で　各チームがSLOを活用していけるようなエコシステムや風土を整えていきたい。