DMMプラットフォームに ゼロベースでSLO導入している取り組み 適切なSLI模索の軌跡

ゼロベースでSLOの存在意義はなにか？適切なSLIはどうやって決めるのか？を考察・調査し、まずはプラットフォームの一部のチームでSLOを策定しました。それまでの苦労を含めてSLOがなぜ必要か、またSLIをどのように決めたのか等お話します。
Cloud Operator Days Tokyo 2023で使用したスライドです。

Transcript

1. DMMプラットフォームに
   ゼロベースでSLO導入している取り組み
   適切なSLI模索の軌跡
   Jun Kudo ( @j_nk71 )
   Cloud Operator Days Tokyo 2023
   

   View Slide

2. Jun Kudo @j_nk71
   東京大学大学院工学系研究科修了後、合同会社DMM.comに
   新卒入社(2021)。プラットフォーム事業本部にてSREとして
   各開発チームに向けたコンテナプラットフォームの提供や
   開発効率の向上施策を進めている。
   2
   

   View Slide

3. DMMプラットフォームの利用時全体像 3
   動画配信
   サービス
   End User
   電子書籍
   サービス
   End User
   API
   Gateway
   認証系
   サービス
   会員系
   サービス
   DMM プラットフォーム
   DMM.comのサービス
   主にプラットフォーム的機能を管轄する
   バックエンドサーバーが含まれる
   ex.ログインや退会など
   

   View Slide

4. DMMプラットフォームの状態 4
   Login API
   認証 API
   認証系
   サービス
   API
   Gateway
   会員系
   サービス
   SREチーム
   会員
   チーム
   認証
   チーム
   クラスタや
   各種オペレータを管理
   ex.会員チームはクラスタ内でログイン
   といった機能を持つAPIサーバーを管理
   

   View Slide

5. DMMプラットフォームの状態 5
   クラスタを運用するSREと、クラスタにサービスを乗せる
   各チームのマイクロサービス構成である。
   クラスタ利用者は自チームのアプリケーションにオーナーシップをもつ。
   Kubernetesクラスタ（GKE,EKS）
   Kubernetesクラスタ上のオペレータ
   （Argo CD, Datadog Agentなど）
   コンテナイメージの配置場所
   Kubernetesマニフェストを管理するモノレポ
   …
   アプリケーションコード
   アプリケーションのコンテナイメージ
   自チームのKubernetesマニフェスト
   （マニフェストは基本自由に変更可能）
   アプリケーションで利用するDBやS3
   …
   SREチームの管理物
   SREチーム以外
   クラスタ利用者の管理物
   

   View Slide

6. おさらい①
   User Journey: ユーザーがサービスと行う一連の対話・体験

   ex. 商品を購入するためにカート内商品の購入を確定する
   SLI: サービスの信頼性を測るための指標
   ex. 購入時のAPIについて5xx以外のHTTPコードのレスポンス数 / 全体のリクエスト数
   SLO: SLIに対してどの程度の値を目指すかを定義したもの
   ex. 過去28日間で5xx以外のレスポンス数の割合が99.5%
   6
   SLIを考える前段となる。実質 SLIを自
   然言語で表したものに近い
   

   View Slide

7. おさらい②
   Error Budget: SLOを元に算出される損失可能な信頼性の量
   ex. 50件 (全体のリクエスト件数が10000件でSLOが99.5%の場合)
   Burn Rate: 特定の期間でError Budgetを消費する速度
   ex. 1時間でError Budgetを2%消費する
   Error Budget Policy: Error Budgetの消費状態に対して
   どう対応するか取り決めたもの
   ex. Error Budgetを使い切ったら、30%に回復するまでリリースを停止する。
   7
   これをモニターで監視することで
   エラーバジェットを消費し切る前に
   対応を実施する、といったことができる
   

   View Slide

8. SLOへの理解度が足りないので
   調査しゼロから考えた
   SLOは何のためにあるのだろうか？
   適切なSLIはどう設計するのか？
   Error Budgetはどう運用するべきか？
   8
   

   View Slide

9. SLOの役割 9
   サービスの信頼性について「何をどの程度目指すのか」
   という線引きを明確にすることで意思決定をサポートする。
   

   View Slide

10. SLOはなぜ必要？ - 過剰要求からの防衛 10
    過剰な要求から自チームの持つサービスを守れる。
    昨晩、利用しているAPIで
    エラーが増加したんですが
    調査or対応してもらえますか？
    他チーム向けAPIを
    提供するチーム
    提供されているAPIを
    利用しているチーム
    増加とはどれぐらいですか？
    100件程度の増加であれば
    SLOとして問題ない範囲です。
    

    View Slide

11. SLOはなぜ必要？ - 信頼性への投資検討 11
    自チームとして信頼性にどの程度投資するかが明確にできる。
    ■ SLOを99.99%に引き上げると、どの程度機会損失額が減るのか？
    その場合どの程度の開発・運用工数がかかるのか？
    それらをふまえて、これに投資するべきか？
    ■ 機能追加をすることでセキュリティ性は向上するが
    レイテンシが20ms悪化する。これは許容していいのだろうか？
    

    View Slide

12. SLOはなぜ必要？ - 挑戦的な施策 12
    エラーバジェットがあることで保守的な運用だと
    実施しづらい挑戦的な施策を検討できる。
    ■ ダウンタイムを伴うメンテナンスを実施したい。
    ■ カオスエンジニアリングを実施したい。
    ■ 特定オペレーションを自動化し人間のレビューを不要にしたい。
    

    View Slide

13. SLO設計の大前提 13
    運用してみないと分からない側面:
    ■ SLIに使おうとしたメトリクスが実は不安定だった
    ■ SLIでは拾いきれないシナリオが実は存在した
    ■ …
    コンテキストの変化の側面:
    ■ ビジネス要件が変化した
    ■ アーキテクチャの変更があった
    ■ チームの人員が増減して割ける工数が変化した
    ■ …
    運用し続ける前提で考える。最初から完璧なSLOは作れないし
    加えてコンテキストの変化に合わせて調整・運用し続ける必要がある
    

    View Slide

14. 今回の話 14
    Login API
    認証 API
    認証系
    サービス
    API
    Gateway
    会員系
    サービス
    SREチーム
    会員
    チーム
    認証
    チーム
    クラスタや
    各種オペレータを管理
    今回はSREチームの提供する
    クラスタ周りのSLOを決めた話
    

    View Slide

15. 15
    User Journeyの設定
    SLIの設計
    SLOの設定
    Error Budget Policyの設定
    Burn Rate Alertの設定
    Burn Rate Alertの設定
    SLO Documentの作成
    SLO構築の流れ
    

    View Slide

16. User Journeyの設定①
    ユーザーをKubernetes Clusterを利用する
    DMMプラットフォーム内の各チームと定義した。
    16
    動画配信
    サービス
    電子書籍
    サービス
    API
    Gateway
    認証系
    サービス
    会員系
    サービス
    DMMプラットフォームを
    利用する事業部
    End User
    クラスタ運用側として一番距離の近い
    クラスタを利用する各チームを今回のユーザーとした
    クラスタ
    利用チーム
    

    View Slide

17. User Journeyの設定②
    「クラスタ上にデプロイしてあるサービスが
    他サービスと通信したりバッチ処理を行う。」をUser Journeyとした。
    17
    動画配信
    サービス
    電子書籍
    サービス
    API
    Gateway
    認証系
    サービス
    会員系
    サービス
    DMMプラットフォームを
    利用する事業部
    End User
    クラスタ
    利用チーム
    

    View Slide

18. SLIの設計
    ユーザージャーニーをSLIに落とし込むように設計した。
    （これが一番むずかしい）
    18
    おおまかな設計方針
    ■ 理解しやすい程度にはシンプルであること
    ■ メトリクスとしてノイズが少ないこと
    ■ 可能な限りユーザー体験を直接表現していること
    ■ あまりSLIの数が多くなりすぎないこと
    （運用できない＋意思決定に使いづらくなる）
    

    View Slide

19. 設計したSLI
    クラスタ運用側として、マニフェストやコンテナがちゃんとしてれば
    サービスがしっかり動くことを保証するために以下を設定した。
    アプリケーション自体の挙動は追わない。
    19
    ■ クラスタ内のPendingである状態のPodが N 個以下である時間長
    例えばCluster Autoscalerが壊れていてノードがスケールしない
    といったケースが拾える
    ■ 各ReplicasetがDesired Podの個数通りに動作している時間長
    例えばネットワークや認証情報が壊れてコンテナイメージを配置場所
    からPullできないといったケースが拾える
    

    

    View Slide

20. SLIに採用しなかった例 20
    ■ クラスタ内のアプリケーションのログが正常に保存されている割合
    そもそもUser Journeyとは異なってしまう。本来はサポートする
    べきかもしれないが別のUser Journeyで考えるべき。
    ■ クラスタ上でPodがErrorの状態である時間長
    実績的にPodがエラーになるかどうかはクラスタ自身以外の
    原因がほとんどだったので対象外とした。
    ex.) Podの通信先がダウンしていることによってPodが終了
    マニフェストの設定ミスによってうまく起動せずエラー
    ※今後クラスタのネットワーク起因でのエラーなどが

    　起こる場合には検討する

    

    View Slide

21. SLOの設計
    過去に達成できている&現実的に達成可能な値をベースに決定した。
    現時点ではそれぞれのSLIは99.9%を目標としている。
    

    21
    ex.) 時間ベースのSLO（28 days window）の場合…
    

    障害発生時、現実的に対応完了までにかかる時間は？
    現時点ではオンコールを受けて調査開始までに現実的に5分以上かかる
    よって少なくとも99.99%のSLOは達成できない(28日間の0.01%は4.032分)
    問題を検知する→ 人間がオンコールを受ける → 調査する → 対応する
    

    View Slide

22. Error Budget Policyの設定 22
    達成不可能な強い制約はかけず議論の出発点としての
    機会を用意するようにして柔軟なポリシーを設定している。
    条件 対応
    エラーバジェットが

    50%を切った場合

    チームでMTGを実施し対応可否に加え

    対応内容を検討する。

    エラーバジェットを完全に
    使い切った場合

    チームの少なくとも１人を最優先で信頼性向上の

    タスクにアサインする。対応完了後に利用チームに

    対応結果を共有する。

    

    View Slide

23. Burn Rate Alertの設定 23
    最初は決め打ちでDatadog社やSRE本の推奨値を利用し
    課題感が出たら都度調整する運用にしている。
    SLO策定前にあった各種ユーザー体験を間接的に表現するモニターは
    （ex. ノードのCPU使用率が90%以上になっている）などは
    置き換え可能と判断したらこちらのアラートに乗り換えていく予定
    ウィンドウ
 消費量
 対応

    1時間
 2%
 オンコールで即時対応する。

    6時間
 5%
 オンコールで即時対応する。

    

    View Slide

24. SLOドキュメント 24
    最終的には他チームや時チームの意思決定に使うという特性上
    プラクティスに習い、Single Source of TruthとしてSLOドキュメントを用意
    （現在はDatadog Dashboard上で管理できないか模索中)
    実際のものを一部記載
    実際のものを一部記載
    目次
    

    View Slide

25. アプリケーション運用チームへの展開 25
    Login
    API
    認証
    API
    API
    Gateway
    会員系
    サービス
    SREチーム
    会員
    チーム
    認証
    チーム
    認証系
    サービス
    今後は他チームへもSLO導入の流れを展開をする予定である。
    SREチームだけではアプリケーションに対するSLOの運用知見は貯まらないので
    一部クラスタ利用チームに依頼して先行的に導入を進めている。
    基本はAPI別で
    エラー率・レイテンシの
    SLI/SLOを用意している
    

    View Slide

26. SLOを作り込もうとしたとき
    これ難しいな…と思ったことを紹介します
    26
    

    View Slide

27. User Journey 多すぎ問題
    そもそもサポートすべき機能が多すぎてユーザージャーニーが大量に…。
    27
    ユーザージャーニーの実例
    ■ クラスタ上にデプロイしてあるサービスが他サービスと通信したり
    バッチ処理を行う。
    ■ クラスタにデプロイしているサービスをDatadogで監視する。
    ■ k8sリソースの設定をモノレポのマニフェストを変更してリリースする。
    ■ kubectlを叩いてリソースの操作をする。
    ■ …
    今はSLO導入初期なことから運用負荷を軽減すべく、まずはできる限り
    ユーザージャーニーをまとめる＋重要度の高いものに絞って運用している。
    

    View Slide

28. ユーザー体験に対するSLIの距離問題
    ユーザー体験にSLIを寄せすぎると逆にノイズが増えて機能しないケースがあり
    必ずしもユーザー体験に近いほど良いというものでもない。
    28
    SLIのユーザー体験との距離
    ユ
    ー
    ザ
    ー
    体
    験
    の
    表
    現
    度
    ノ
    イ
    ズ
    の
    混
    じ
    り
    に
    く
    さ
    (近い) (遠い) 適度にノイズが混じらない程度にユーザー体験を
    表現する落とし所を見つける必要がある…。
    ■ ex. ユーザーのブラウザ上のページの描画時間
    （Webフロントページを提供するサービスのSLIとして）
    体験としては近いが、マシンスペックに影響される。
    おそらくロードバランサから取れるレスポンスタイム等を
    計測したほうがノイズが少ないのでは？
    

    View Slide

29. ユーザー体験に対するSLIの距離問題 - 対応策
    対応策は色々あるが、現実的に割ける工数を考え
    現状は仕方なくユーザーの不備起因のものは手動で除外している。
    29
    1. CIなどを作り込んでそもそもクライアント起因の問題が起きないようにする
    → クライアントの失敗を運用側の責務に取り込む。工数がかかる。
    2. 代わりのSLIを用意する
    → 理想はこれだが現実問題見つからない
    3. ユーザーの不備によるエラーバジェット消費はSLO計算から手動で除外する
    → 現状は手動オペレーションは月1,2回程度、Datadogの機能でできる。
    　 発生頻度が高すぎる場合はSLI見直す必要がある。
    　 今は基本この方針で対応している。
    

    View Slide

30. ユーザー体験に対するSLIの距離問題 - 対策
    ユーザー不備の計算除外はDatadogのCorrect Statusという機能で実施している。
    30
    

    View Slide

31. SLIで依存をどこまで取り込むか問題
    SLOは自チームで運用する信頼性の目標となる。
    依存先（ex.SaaS,DB,他チームのサービス等)によって
    エラーバジェットが消費される状態は健全なのか…？
    ユーザー体験視点のサービスの信頼性を正確に表すために依存は取り込みたい
    ex.依存先を自サービスの考慮項目として取り込める
    自サービスの信頼性が依存先によって低下していると判断して依存先を変える
    31
    依存を取り込むと運用負荷が高くなるケースがある
    しかし…
    

    View Slide

32. SLIで依存をどこまで取り込むか問題 - 例 32
    API
    Gateway
    Service A
    Service B
    Service C
    API Gatewayを運用するチームが
    SLOを決めたいケース
    後続のサービスは、別々のチームが管轄し
    エラー率もレイテンシも
    サービスによって全然異なる
    ユーザーをAPI Gatewayを
    叩くクライアントとする
    ユーザー
    

    View Slide

33. SLIで依存をどこまで取り込むか問題 - 例 33
    API
    Gateway
    Service A
    Service B
    Service C
    ユーザー体験を表現するSLIを作ろうとして、
    後続サービスの状態を取り込むと、当然その後続サービスの信頼性にSLIが影響される
    Latency 80ms
    Latency 20ms
    Latency 50ms
    レイテンシは各サービスごとに違う。API Gateway自身がレイテンシの
    SLIを作るとき後続のサービスごとのレイテンシのSLIを用意するべきなのか？
    API Gatewayの後続にサービスが増えるほど、API GatewayのSLIも増える
    Latency 25ms
    合計 105ms
    

    View Slide

34. SLIで依存をどこまで取り込むか問題 - 例 34
    API
    Gateway
    Service A
    Service B
    Service C
    後続のサービスが障害を起こしたときはAPI Gateway自身の
    SLIの値も低下する（個別のServiceごとにSLIを作ってもこの問題は発生する)
    Service Aがダウンしたときユーザー体験をSLIは適切に表現しているが
    API Gateway自身に問題はなくてもAPI GatewayのBurn Rate Alertが発火する
    API Gatewayの後続にサービスが増えるほど発火する機会も増える
    正常に稼働しているが
    エラー率が高くなる
    エラー率が
    高くなる
    

    View Slide

35. SLIで依存をどこまで取り込むか問題 - 対策 35
    API
    Gateway
    Service A
    Service B
    Service C
    現実的に後続のサービスを取り込むと運用しきれないので
    このようなケースは後続サービスの影響を除外するような方針にしている。
    ただ影響を除外するのにも手間がかかる..。
    ex. 後続サービスによるレイテンシ影響を減算、他サービス起因のエラーを除外
    Latency 25ms
    Latency 80ms
    Latency 20ms
    Latency 50ms
    

    View Slide

36. まとめ
    ■ Kubernetesクラスタを社内に提供しており
    運用と見直しを前提としてスモールスタートでSLO運用を始めた。
    ■ SLOドキュメントまで作成後運用しており、知見・プラクティスを蓄積させている。
    （並行でアプリケーションを運用している一部チームにも先行的にSLO導入を依頼）
    ■ クラスタ運用側としては、SLIとして一般的なAPIのレイテンシやエラー率といった
    一般的な指標がないのでなおさらSLI設計が難しい。
    ■ SLIを作り込むのはとても難しい。
    依存を取り込むべきか、ユーザー起因のノイズ等に検討考え対応しているが
    キレイな解決方法は現状見つかっていない。
    36
    

    View Slide