Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大きな組織にSLOを導入し 運用するということ、その難しさ / SRE NEXT 2024
Search
Jun Kudo
August 04, 2024
Technology
6
2.4k
大きな組織にSLOを導入し 運用するということ、その難しさ / SRE NEXT 2024
SRE NEXT 2024の登壇資料になります。
Jun Kudo
August 04, 2024
Tweet
Share
More Decks by Jun Kudo
See All by Jun Kudo
DMMプラットフォームに ゼロベースでSLO導入している取り組み 適切なSLI模索の軌跡
junjunjunk
9
2.2k
Other Decks in Technology
See All in Technology
日経電子版におけるリアルタイムレコメンドシステム開発の事例紹介/nikkei-realtime-recommender-system
yng87
1
500
なんで、私がAWS Heroに!? 〜社外の広い世界に一歩踏み出そう〜
minorun365
PRO
6
1.1k
CyberAgent 生成AI Deep Dive with Amazon Web Services / genai-aws
cyberagentdevelopers
PRO
1
480
VPC間の接続方法を整理してみた #自治体クラウド勉強会
non97
1
850
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.6k
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
160
Fargateを使った研修の話
takesection
0
120
WINTICKETアプリで実現した高可用性と高速リリースを支えるエコシステム / winticket-eco-system
cyberagentdevelopers
PRO
1
190
顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed
soudai
24
6.8k
プロダクトチームへのSystem Risk Records導入・運用事例の紹介/Introduction and Case Studies on Implementing and Operating System Risk Records for Product Teams
taddy_919
1
170
新R25、乃木坂46 Mobileなどのファンビジネスを支えるマルチテナンシーなプラットフォームの全体像 / cam-multi-cloud
cyberagentdevelopers
PRO
1
130
AIを駆使したゲーム開発戦略: 新設AI組織の取り組み / sge-ai-strategy
cyberagentdevelopers
PRO
1
130
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
38
7k
The Cost Of JavaScript in 2023
addyosmani
45
6.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
It's Worth the Effort
3n
183
27k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Gamification - CAS2011
davidbonilla
80
5k
Bash Introduction
62gerente
608
210k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Music & Morning Musume
bryan
46
6.1k
Code Review Best Practice
trishagee
64
17k
Transcript
大きな組織にSLOを導入し 運用するということ、その難しさ SRE NEXT 2024 工藤 純
自己紹介 Jun Kudo @j_nk71 合同会社DMM.com所属。 プラットフォーム開発本部のSREとして 各チームへのSLI/SLOの導入推進や 可用性向上の施策等に取り組んでいる。
今回の話 1. DMMの開発組織の話 2. 実際のSLO導入・運用のためにやったこと 3. 現時点で見えている課題・やっていきたいこと
DMMのプラットフォーム開発本部 決済基盤 動画配信事業部 クーポン基盤 会員基盤 電子書籍事業部 … … DMMのPF開発本部 (今回はココの話)
DMMの各事業部(60+)
DMMのプラットフォーム開発本部の規模 在籍メンバー チーム数 マイクロサービス 約 120 人 約 30
チーム 約 30 個 決済基盤 クーポン基盤 会員基盤 … DMMのPF開発本部 主に今回のSLO導入推進先はこの組織
プラットフォーム開発本部のSREチーム PF開発本部にはサービス信頼性向上を目指す専任のSREチームがある ◆信頼性にフルコミットする珍しいチーム ◆障害対応フローやポストモーテム文化の推進、SLI/SLOの導入などを実施 ◆プラットフォームエンジニアリング的なことをするチームとは別立て ◆SREチームに信頼性向上のための知見の集約し、効率よく他チームに展開
DMMのマイクロサービスプラットフォーム PF開発本部のマイクロサービス基盤はマルチテナントKubernetes Clusterを ベースに構成されており、マイクロサービスを各チームが開発運用している API Gateway 認証基盤 マイクロ サービスA マイクロ
サービスB マイクロ サービスC … API Gatewayを通してPFの提供機能が使える!
過去のSLO運用状態 組織として形式上SLOはあったがエラーバジェットの概念もなかった 組織としてのSLO文化はほぼない状態から導入をすすめた
導入・運用のために実施したこと 1. 導入の流れ 2. サポートについて 3. レビュー例の紹介 4. Doc整備内容の紹介 5.
バーンレートアラートの調整
SLO導入時の流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget
Policy 設計・設定 Burn Rate Alert 設計・設定 同時並行で SLO Documentの作成
SLO導入時の流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget
Policy 設計・設定 Burn Rate Alert 設計・設定 リテラシーのない状態では”問題”を”問題”として認識できない 問題をキャッチしに行く姿勢でサポートする必要がある じゃあ各チームこの通りやってください! …とは行かない
実際のSLO導入でのサポートと流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget
Policy 設計・設定 Burn Rate Alert 設計・設定 ヒアリング+ キックオフ MTG レビュー レビュー レビュー レビュー+ 見直しMTG+ 運用サポート 細かく口頭でのサポートやレビューを行い ある程度妥当な設定での導入や運用ができるようしている
サポートにかかる工数 ヒアリング+ キックオフ MTG レビュー レビュー レビュー レビュー+ 見直しMTG+ 運用サポート
45min 30min 45min 45min 30min+ 仮に1チーム1サービスに導入する際は 短めに概算して、レビュー側は 3.5時間 程度は持っていかれる PF開発本部はおおよそ30チームなので 各チームへの初回導入だけでも累計 105時間 かける必要がある
レビュー例: SLOの設定値の決め方 SLIやSLOの値を考えるときに”どうしたら検知できるか”を 考えてしまっている
レビュー例: 達成可能ではないSLO 達成不可能なのにとりあえずSLOとして99%を選んでしまう (特にリクエスト数の少ないエンドポイントで起こる)
知見を展開するためのDoc整備 最低限の下地としてDoc周りは充実させて展開している 単純な設定方針の考え方も含めDocにまとめている 文字で書いてあるだけでは 伝わらない… このDocだと約17000文字程度
Docへのフィードバック サポート結果を逆にDocに反映させて継続的に改善し FAQに落としている
導入だけでもかなりのリテラシーを求められるが 導入後の運用もそれ以上にサポートが必要
運用中の壁: Burn Rate Alertの修正 初期導入時などによくあるアラートの偽陽性発火時の修正には 多くの変数から妥当なものを選択できるリテラシーが必要 ◆ バーンレート値 ◆
SLO自体の高さ(エラーバジェット) ◆ SLIの閾値やクエリ ◆ SLIの評価ウィンドウや集計関数 (※Budgetを時間量で計算するSLOの場合) 変更候補となる値
Burn Rate Alertの修正の簡略化 誤発火への対応方針が属人化しないようにチャートを作成・展開した ex.) SLOの値が妥当か確認してから バーンレート値の引き下げを考える
フローチャートの全体像
Burn Rate値の調整 特にBurn Rate値は直感的には理解しづらいし調整も難しい SLOの値や期間が変わった際はBurn Rate値も管理する必要がある 1hourに2%の設定したいだけなのに14.4 やら 16.6やら良くわからない…
バーンレート値のカタログ 特に時間量をエラーバジェットとするSLOについては 機械的に閾値を緩める事ができるようにカタログを用意した バーンレート値の計算のコストがなくなる以外のメリットもある なおカタログを用意する都合上、カタログの値に縛られるリスクは懸念点
ちなみに… 実際にSLO導入してどう?
Error Budgetの活用① 全チームとは行かないが徐々に意思決定に エラーバジェットが活用される場面もでてきている
Error Budgetの活用② 自サービス外の依存先で キャッシュが壊れていた例
一方で… 運用の中で課題もたくさん見えている
運用して見えてきた難しい課題 運用中には下記の課題が見えており対応していく必要がある ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる
運用して見えてきた難しい課題 ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる ➡ レビューフローの整備
①-A: SLOの値の最適化 最初は実績をもとに達成可能なSLOを設定してもらって 運用で調整をつづけていく方針にしているが、そもそも調整が難しい 最終的に SLO運用側が現実的に達成できる値 & ユーザーが満足する設定値 になっていればOK
①-B: 達成可能な値なのか 達成可能な値かどうかの判断は SLO運用側のSLO見直しで自然と調整されていくので問題ない 達成不可能な値だった場合はSLOが割れるか ものすごい勢いでエラーバジェットが削れるので そもそも達成できない設定をしていることに気づく
①-C: ユーザーの満足度を表しているか どの値だと満足ラインなのか判断できないのに加えて 最適化のための方針が立てづらい 問題1: まずSLO運用側としてはSLOを引き上げるモチベーションが発生しない 問題2: 問題1を認識した上で、SLO運用側が頑張って際限なくSLOを 引き上げるのも過度な信頼性担保につながる
➡ エラーバジェットが減ってしまうので開発にかけられる時間も減る ➡ ユーザーは十分にそれで満足しているのに高いコストを払って 信頼性を引き上げ続けるリスクがある ex. 目標は高く99.9999%目指すぞ!➡ユーザーは99%でも十分でした
①-D: 今後の対応 - レビューフローの整備検討 SLOがSLO運用チームの独りよがりにならないような仕組みを作る必要があるが 今回は社内にユーザーがいるのでSLO変更時はユーザーの承認フローを整備したい 些細な変更等含めすべてに承認を求めていたらコミュニケーションコストが肥大化 ◆PF開発本部にとってのユーザーの事業部は60以上存在しており、かつ増減する ◆ PF開発本部はマイクロサービス+クラウドネイティブな環境なので
しばしばSLOの変更機会がある ex.) 自チームの部長レイヤでの承認でOKにする(部長会議ですり合わせもらう) どこかの事業部を基準としてそこがOKをだせばOKとする
運用して見えてきた難しい課題 ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる ➡ レビューフローの整備 ➡
よりユーザージャーニーを表現したSLO
②−A: 今後の対応 - 新たなSLOへの移行or導入 各マイクロサービス単体に対して定義する。 現在SLOの導入では運用や責務設計の 難易度の低さからこちらを採用。 現在はマイクロサービス単体のSLO(マイクロサービスSLO)形式で導入をしているが 最終的にはユーザージャーニーをより表したSLO=プラットフォームSLOを定義したい マイクロサービス
SLO プラットフォーム SLO 事業部の体験により近い形式でSLOを定義する。 マイクロサービス単体以外の要素を取り込むので 難易度が高くなる。
②-B: マイクロサービスSLO API Gateway 認証基盤 決済基盤 サービス 会員基盤 サービス …
運用や責務設計の難易度の低さからマイクロサービスSLOを運用しているが 事業部の体験を厳密には定量化できていない 例えばAPI Gatewayが止まってしまったら…?
②-C: マイクロサービスSLOの補足 API Gateway 認証基盤 決済基盤 サービス 外部決済代行 サービス …
ちなみに各マイクロサービスのSLOは 依存先(自サービスより後段)の影響を取り込むようにSLO設計をしてもらっている ex. 決済基盤サービスにおけるレイテンシの SLOは外部決済代行サービスのレイテンシを 含めた400msを基準に計測・定義する 100ms 300ms
②−D: プラットフォームSLO マイクロサービス単体では無く、他の部分も取り込むことで よりユーザー(事業部)の体験を適切に表現できるSLOにする API Gateway 決済基盤 サービス … マイクロサービスまでの到達経路として
API Gateway上などのレイテンシを含めた SLOを定義する
②−E: 最終的に目指したい形式 各事業部に、PF開発本部の提供する各機能のSLOを提示できる世界にしたい API Gateway 決済基盤 サービス … 会員基盤 サービス
決済機能のSLOは 決済基盤サービスのチームが運用 会員機能のSLOは 会員基盤サービスの チームが運用 API Gatewayとしての単体性能は API Gatewayの運用チームが SLOとして担保する
運用して見えてきた難しい課題 ① SLOの値の調整の最適化が難しい ② 現行のSLOではユーザージャーニーを表現しきれていない ③ SLOの定義・運用にはリテラシーとコストがかかる ➡ レビューフローの整備 ➡
よりユーザージャーニーを表現したSLO ➡ SLO as CodeによるSLOの管理
③-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を生成する! 簡略化したイメージ この定義から… これによって運用負荷や要求リテラシーの 高さ問題にアプローチできる
③-B: SLO as Code のうまみ① 設定の共通化・抽象化による導入・運用コストの低減が見込める { target: 99.9 type:
"availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] }, … ◆ レビューができる ◆ リソースの生成コストが下がる サービスによっては エンドポイントが150個ある。 1個1個GUI上で生成するのにも限界がある。
③-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*"] }, …
③-D: SLO as Code のうまみ③ さまざまなValidationが適用できるようになる =ガードレールが作れる! ex.) マイクロサービス同士の依存関係を管理し 依存先のマイクロサービスよりも
高いSLOを設定しないようにしたい Code化されていることで 依存先マイクロサービスより高い信頼性を 設定していないかといったValidationができる でも人間が 管理するのは厳しい { target: 99.9 type: "availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] }, …
③-E: SLO as Codeのうまみ - まとめ ① SLOのセットアップや管理が手軽になる (レビューができる、記述の共通化ができる) ②
SLO Docなどの整合性担保をしなくてよくなる (SLO関連のエコシステムを作りやすくなる) ③ SLO設定のガードレールが作れる (マイクロサービス間の依存関係によるSLOの関係性など)
まとめ ◆ SLO導入は思った以上に運用負荷があり、リテラシーが求められる。 大きな組織に広めていくにあたっては多大なサポートの工数がかかると感じた。 ◆ただ単にSLOのプラクティスに沿うだけではなく、 SLOは組織そのものと向き合ってサポート+仕組みづくりの必要がある。 ◆ まだまだサポートは十分だと思っていない。より運用しやすい形式で
各チームがSLOを活用していけるようなエコシステムや風土を整えていきたい。