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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

おさらい② 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 これをモニターで監視することでエラーバジェットを消費し切る前に対応を実施する、といったことができる

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

SLOの設計過去に達成できている&現実的に達成可能な値をベースに決定した。現時点ではそれぞれのSLIは99.9%を目標としている。   21 ex.) 時間ベースのSLO（28 days window）の場合…   障害発生時、現実的に対応完了までにかかる時間は？現時点ではオンコールを受けて調査開始までに現実的に5分以上かかるよって少なくとも99.99%のSLOは達成できない(28日間の0.01%は4.032分) 問題を検知する→ 人間がオンコールを受ける → 調査する → 対応する

Slide 22

Slide 22 text

Error Budget Policyの設定 22 達成不可能な強い制約はかけず議論の出発点としての機会を用意するようにして柔軟なポリシーを設定している。条件対応エラーバジェットが  50%を切った場合  チームでMTGを実施し対応可否に加え  対応内容を検討する。  エラーバジェットを完全に使い切った場合  チームの少なくとも１人を最優先で信頼性向上の  タスクにアサインする。対応完了後に利用チームに  対応結果を共有する。 

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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の後続にサービスが増えるほど発火する機会も増える正常に稼働しているがエラー率が高くなるエラー率が高くなる

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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