Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Jun Kudo
August 04, 2024

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

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

Jun Kudo

August 04, 2024
Tweet

More Decks by Jun Kudo

Other Decks in Technology

Transcript

  1. DMMのプラットフォーム開発本部の規模 在籍メンバー チーム数   マイクロサービス 約 120 人 約 30

    チーム 約 30 個 決済基盤 クーポン基盤 会員基盤 … DMMのPF開発本部 主に今回のSLO導入推進先はこの組織
  2. SLO導入時の流れ User Journey 設定 SLI 設計 SLO 設計・設定 Error Budget

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

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

    Policy 設計・設定 Burn Rate Alert 設計・設定 ヒアリング+ キックオフ MTG レビュー レビュー レビュー レビュー+ 見直しMTG+ 運用サポート 細かく口頭でのサポートやレビューを行い ある程度妥当な設定での導入や運用ができるようしている
  5. サポートにかかる工数 ヒアリング+ キックオフ MTG レビュー レビュー レビュー レビュー+ 見直しMTG+ 運用サポート

    45min 30min 45min 45min 30min+ 仮に1チーム1サービスに導入する際は 短めに概算して、レビュー側は 3.5時間 程度は持っていかれる PF開発本部はおおよそ30チームなので 各チームへの初回導入だけでも累計 105時間 かける必要がある
  6. 運用中の壁: Burn Rate Alertの修正 初期導入時などによくあるアラートの偽陽性発火時の修正には 多くの変数から妥当なものを選択できるリテラシーが必要   ◆ バーンレート値 ◆

    SLO自体の高さ(エラーバジェット) ◆ SLIの閾値やクエリ ◆ SLIの評価ウィンドウや集計関数 (※Budgetを時間量で計算するSLOの場合) 変更候補となる値
  7. ①-C: ユーザーの満足度を表しているか どの値だと満足ラインなのか判断できないのに加えて 最適化のための方針が立てづらい 問題1: まずSLO運用側としてはSLOを引き上げるモチベーションが発生しない 問題2: 問題1を認識した上で、SLO運用側が頑張って際限なくSLOを     引き上げるのも過度な信頼性担保につながる

    ➡ エラーバジェットが減ってしまうので開発にかけられる時間も減る ➡ ユーザーは十分にそれで満足しているのに高いコストを払って   信頼性を引き上げ続けるリスクがある ex. 目標は高く99.9999%目指すぞ!➡ユーザーは99%でも十分でした
  8. ②-B: マイクロサービスSLO API Gateway 認証基盤 決済基盤 サービス 会員基盤 サービス …

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

    ちなみに各マイクロサービスのSLOは 依存先(自サービスより後段)の影響を取り込むようにSLO設計をしてもらっている ex. 決済基盤サービスにおけるレイテンシの SLOは外部決済代行サービスのレイテンシを 含めた400msを基準に計測・定義する 100ms 300ms
  10. ②−E: 最終的に目指したい形式 各事業部に、PF開発本部の提供する各機能のSLOを提示できる世界にしたい API Gateway 決済基盤 サービス … 会員基盤 サービス

    決済機能のSLOは 決済基盤サービスのチームが運用 会員機能のSLOは 会員基盤サービスの チームが運用 API Gatewayとしての単体性能は API Gatewayの運用チームが SLOとして担保する
  11. ③-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を生成する! 簡略化したイメージ この定義から… これによって運用負荷や要求リテラシーの 高さ問題にアプローチできる
  12. ③-B: SLO as Code のうまみ① 設定の共通化・抽象化による導入・運用コストの低減が見込める { target: 99.9 type:

    "availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] }, … ◆ レビューができる ◆ リソースの生成コストが下がる サービスによっては エンドポイントが150個ある。 1個1個GUI上で生成するのにも限界がある。
  13. ③-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*"] }, …
  14. ③-D: SLO as Code のうまみ③ さまざまなValidationが適用できるようになる =ガードレールが作れる! ex.) マイクロサービス同士の依存関係を管理し 依存先のマイクロサービスよりも

    高いSLOを設定しないようにしたい Code化されていることで 依存先マイクロサービスより高い信頼性を 設定していないかといったValidationができる でも人間が 管理するのは厳しい { target: 99.9 type: "availability" endpoint: ["/v1/hoge","/v1/fuga"] bad_events_code: ["5*"] }, …
  15. ③-E: SLO as Codeのうまみ - まとめ ① SLOのセットアップや管理が手軽になる  (レビューができる、記述の共通化ができる) ②

    SLO Docなどの整合性担保をしなくてよくなる  (SLO関連のエコシステムを作りやすくなる) ③ SLO設定のガードレールが作れる   (マイクロサービス間の依存関係によるSLOの関係性など)