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
2. Jun Kudo @j_nk71 東京大学大学院工学系研究科修了後、合同会社DMM.comに 新卒入社(2021)。プラットフォーム事業本部にてSREとして 各開発チームに向けたコンテナプラットフォームの提供や 開発効率の向上施策を進めている。 2
3. DMMプラットフォームの利用時全体像 3 動画配信 サービス End User 電子書籍 サービス End User API Gateway 認証系 サービス 会員系 サービス DMM プラットフォーム DMM.comのサービス 主にプラットフォーム的機能を管轄する バックエンドサーバーが含まれる ex.ログインや退会など
4. DMMプラットフォームの状態 4 Login API 認証 API 認証系 サービス API Gateway 会員系 サービス SREチーム 会員 チーム 認証 チーム クラスタや 各種オペレータを管理 ex.会員チームはクラスタ内でログイン といった機能を持つAPIサーバーを管理
5. DMMプラットフォームの状態 5 クラスタを運用するSREと、クラスタにサービスを乗せる 各チームのマイクロサービス構成である。 クラスタ利用者は自チームのアプリケーションにオーナーシップをもつ。 Kubernetesクラスタ（GKE,EKS） Kubernetesクラスタ上のオペレータ （Argo CD, Datadog Agentなど） コンテナイメージの配置場所 Kubernetesマニフェストを管理するモノレポ … アプリケーションコード アプリケーションのコンテナイメージ 自チームのKubernetesマニフェスト （マニフェストは基本自由に変更可能） アプリケーションで利用するDBやS3 … SREチームの管理物 SREチーム以外 クラスタ利用者の管理物
6. おさらい① User Journey: ユーザーがサービスと行う一連の対話・体験
 ex. 商品を購入するためにカート内商品の購入を確定する SLI: サービスの信頼性を測るための指標 ex. 購入時のAPIについて5xx以外のHTTPコードのレスポンス数 / 全体のリクエスト数 SLO: SLIに対してどの程度の値を目指すかを定義したもの ex. 過去28日間で5xx以外のレスポンス数の割合が99.5% 6 SLIを考える前段となる。実質 SLIを自 然言語で表したものに近い
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 これをモニターで監視することで エラーバジェットを消費し切る前に 対応を実施する、といったことができる
8. SLOへの理解度が足りないので 調査しゼロから考えた SLOは何のためにあるのだろうか？ 適切なSLIはどう設計するのか？ Error Budgetはどう運用するべきか？ 8
9. SLOの役割 9 サービスの信頼性について「何をどの程度目指すのか」 という線引きを明確にすることで意思決定をサポートする。
10. SLOはなぜ必要？ - 過剰要求からの防衛 10 過剰な要求から自チームの持つサービスを守れる。 昨晩、利用しているAPIで エラーが増加したんですが 調査or対応してもらえますか？ 他チーム向けAPIを 提供するチーム 提供されているAPIを 利用しているチーム 増加とはどれぐらいですか？ 100件程度の増加であれば SLOとして問題ない範囲です。
11. SLOはなぜ必要？ - 信頼性への投資検討 11 自チームとして信頼性にどの程度投資するかが明確にできる。 ▪ SLOを99.99%に引き上げると、どの程度機会損失額が減るのか？ その場合どの程度の開発・運用工数がかかるのか？ それらをふまえて、これに投資するべきか？ ▪ 機能追加をすることでセキュリティ性は向上するが レイテンシが20ms悪化する。これは許容していいのだろうか？
12. SLOはなぜ必要？ - 挑戦的な施策 12 エラーバジェットがあることで保守的な運用だと 実施しづらい挑戦的な施策を検討できる。 ▪ ダウンタイムを伴うメンテナンスを実施したい。 ▪ カオスエンジニアリングを実施したい。 ▪ 特定オペレーションを自動化し人間のレビューを不要にしたい。
13. SLO設計の大前提 13 運用してみないと分からない側面: ▪ SLIに使おうとしたメトリクスが実は不安定だった ▪ SLIでは拾いきれないシナリオが実は存在した ▪ … コンテキストの変化の側面: ▪ ビジネス要件が変化した ▪ アーキテクチャの変更があった ▪ チームの人員が増減して割ける工数が変化した ▪ … 運用し続ける前提で考える。最初から完璧なSLOは作れないし 加えてコンテキストの変化に合わせて調整・運用し続ける必要がある
14. 今回の話 14 Login API 認証 API 認証系 サービス API Gateway 会員系 サービス SREチーム 会員 チーム 認証 チーム クラスタや 各種オペレータを管理 今回はSREチームの提供する クラスタ周りのSLOを決めた話
15. 15 User Journeyの設定 SLIの設計 SLOの設定 Error Budget Policyの設定 Burn Rate Alertの設定 Burn Rate Alertの設定 SLO Documentの作成 SLO構築の流れ
16. User Journeyの設定① ユーザーをKubernetes Clusterを利用する DMMプラットフォーム内の各チームと定義した。 16 動画配信 サービス 電子書籍 サービス API Gateway 認証系 サービス 会員系 サービス DMMプラットフォームを 利用する事業部 End User クラスタ運用側として一番距離の近い クラスタを利用する各チームを今回のユーザーとした クラスタ 利用チーム
17. User Journeyの設定② 「クラスタ上にデプロイしてあるサービスが 他サービスと通信したりバッチ処理を行う。」をUser Journeyとした。 17 動画配信 サービス 電子書籍 サービス API Gateway 認証系 サービス 会員系 サービス DMMプラットフォームを 利用する事業部 End User クラスタ 利用チーム
18. SLIの設計 ユーザージャーニーをSLIに落とし込むように設計した。 （これが一番むずかしい） 18 おおまかな設計方針 ▪ 理解しやすい程度にはシンプルであること ▪ メトリクスとしてノイズが少ないこと ▪ 可能な限りユーザー体験を直接表現していること ▪ あまりSLIの数が多くなりすぎないこと （運用できない＋意思決定に使いづらくなる）
19. 設計したSLI クラスタ運用側として、マニフェストやコンテナがちゃんとしてれば サービスがしっかり動くことを保証するために以下を設定した。 アプリケーション自体の挙動は追わない。 19 ▪ クラスタ内のPendingである状態のPodが N 個以下である時間長 例えばCluster Autoscalerが壊れていてノードがスケールしない といったケースが拾える ▪ 各ReplicasetがDesired Podの個数通りに動作している時間長 例えばネットワークや認証情報が壊れてコンテナイメージを配置場所 からPullできないといったケースが拾える 

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

21. SLOの設計 過去に達成できている&現実的に達成可能な値をベースに決定した。 現時点ではそれぞれのSLIは99.9%を目標としている。 
 21 ex.) 時間ベースのSLO（28 days window）の場合… 
 障害発生時、現実的に対応完了までにかかる時間は？ 現時点ではオンコールを受けて調査開始までに現実的に5分以上かかる よって少なくとも99.99%のSLOは達成できない(28日間の0.01%は4.032分) 問題を検知する→ 人間がオンコールを受ける → 調査する → 対応する
22. Error Budget Policyの設定 22 達成不可能な強い制約はかけず議論の出発点としての 機会を用意するようにして柔軟なポリシーを設定している。 条件 対応 エラーバジェットが
 50%を切った場合
 チームでMTGを実施し対応可否に加え
 対応内容を検討する。
 エラーバジェットを完全に 使い切った場合
 チームの少なくとも１人を最優先で信頼性向上の
 タスクにアサインする。対応完了後に利用チームに
 対応結果を共有する。

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

24. SLOドキュメント 24 最終的には他チームや時チームの意思決定に使うという特性上 プラクティスに習い、Single Source of TruthとしてSLOドキュメントを用意 （現在はDatadog Dashboard上で管理できないか模索中) 実際のものを一部記載 実際のものを一部記載 目次
25. アプリケーション運用チームへの展開 25 Login API 認証 API API Gateway 会員系 サービス SREチーム 会員 チーム 認証 チーム 認証系 サービス 今後は他チームへもSLO導入の流れを展開をする予定である。 SREチームだけではアプリケーションに対するSLOの運用知見は貯まらないので 一部クラスタ利用チームに依頼して先行的に導入を進めている。 基本はAPI別で エラー率・レイテンシの SLI/SLOを用意している
26. SLOを作り込もうとしたとき これ難しいな…と思ったことを紹介します 26
27. User Journey 多すぎ問題 そもそもサポートすべき機能が多すぎてユーザージャーニーが大量に…。 27 ユーザージャーニーの実例 ▪ クラスタ上にデプロイしてあるサービスが他サービスと通信したり バッチ処理を行う。 ▪ クラスタにデプロイしているサービスをDatadogで監視する。 ▪ k8sリソースの設定をモノレポのマニフェストを変更してリリースする。 ▪ kubectlを叩いてリソースの操作をする。 ▪ … 今はSLO導入初期なことから運用負荷を軽減すべく、まずはできる限り ユーザージャーニーをまとめる＋重要度の高いものに絞って運用している。
28. ユーザー体験に対するSLIの距離問題 ユーザー体験にSLIを寄せすぎると逆にノイズが増えて機能しないケースがあり 必ずしもユーザー体験に近いほど良いというものでもない。 28 SLIのユーザー体験との距離 ユ ー ザ ー 体 験 の 表 現 度 ノ イ ズ の 混 じ り に く さ (近い) (遠い) 適度にノイズが混じらない程度にユーザー体験を 表現する落とし所を見つける必要がある…。 ▪ ex. ユーザーのブラウザ上のページの描画時間 （Webフロントページを提供するサービスのSLIとして） 体験としては近いが、マシンスペックに影響される。 おそらくロードバランサから取れるレスポンスタイム等を 計測したほうがノイズが少ないのでは？
29. ユーザー体験に対するSLIの距離問題 - 対応策 対応策は色々あるが、現実的に割ける工数を考え 現状は仕方なくユーザーの不備起因のものは手動で除外している。 29 1. CIなどを作り込んでそもそもクライアント起因の問題が起きないようにする → クライアントの失敗を運用側の責務に取り込む。工数がかかる。 2. 代わりのSLIを用意する → 理想はこれだが現実問題見つからない 3. ユーザーの不備によるエラーバジェット消費はSLO計算から手動で除外する → 現状は手動オペレーションは月1,2回程度、Datadogの機能でできる。 　 発生頻度が高すぎる場合はSLI見直す必要がある。 　 今は基本この方針で対応している。
30. ユーザー体験に対するSLIの距離問題 - 対策 ユーザー不備の計算除外はDatadogのCorrect Statusという機能で実施している。 30
31. SLIで依存をどこまで取り込むか問題 SLOは自チームで運用する信頼性の目標となる。 依存先（ex.SaaS,DB,他チームのサービス等)によって エラーバジェットが消費される状態は健全なのか…？ ユーザー体験視点のサービスの信頼性を正確に表すために依存は取り込みたい ex.依存先を自サービスの考慮項目として取り込める 自サービスの信頼性が依存先によって低下していると判断して依存先を変える 31 依存を取り込むと運用負荷が高くなるケースがある しかし…
32. SLIで依存をどこまで取り込むか問題 - 例 32 API Gateway Service A Service B Service C API Gatewayを運用するチームが SLOを決めたいケース 後続のサービスは、別々のチームが管轄し エラー率もレイテンシも サービスによって全然異なる ユーザーをAPI Gatewayを 叩くクライアントとする ユーザー
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
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の後続にサービスが増えるほど発火する機会も増える 正常に稼働しているが エラー率が高くなる エラー率が 高くなる
35. SLIで依存をどこまで取り込むか問題 - 対策 35 API Gateway Service A Service B Service C 現実的に後続のサービスを取り込むと運用しきれないので このようなケースは後続サービスの影響を除外するような方針にしている。 ただ影響を除外するのにも手間がかかる..。 ex. 後続サービスによるレイテンシ影響を減算、他サービス起因のエラーを除外 Latency 25ms Latency 80ms Latency 20ms Latency 50ms
36. まとめ ▪ Kubernetesクラスタを社内に提供しており 運用と見直しを前提としてスモールスタートでSLO運用を始めた。 ▪ SLOドキュメントまで作成後運用しており、知見・プラクティスを蓄積させている。 （並行でアプリケーションを運用している一部チームにも先行的にSLO導入を依頼） ▪ クラスタ運用側としては、SLIとして一般的なAPIのレイテンシやエラー率といった 一般的な指標がないのでなおさらSLI設計が難しい。 ▪ SLIを作り込むのはとても難しい。 依存を取り込むべきか、ユーザー起因のノイズ等に検討考え対応しているが キレイな解決方法は現状見つかっていない。 36