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

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

Jun Kudo
September 15, 2023

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

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

Jun Kudo

September 15, 2023
Tweet

More Decks by Jun Kudo

Other Decks in Technology

Transcript

  1. DMMプラットフォームの利用時全体像 3 動画配信 サービス End User 電子書籍 サービス End User

    API Gateway 認証系 サービス 会員系 サービス DMM プラットフォーム DMM.comのサービス 主にプラットフォーム的機能を管轄する バックエンドサーバーが含まれる ex.ログインや退会など
  2. DMMプラットフォームの状態 4 Login API 認証 API 認証系 サービス API Gateway

    会員系 サービス SREチーム 会員 チーム 認証 チーム クラスタや 各種オペレータを管理 ex.会員チームはクラスタ内でログイン といった機能を持つAPIサーバーを管理
  3. DMMプラットフォームの状態 5 クラスタを運用するSREと、クラスタにサービスを乗せる 各チームのマイクロサービス構成である。 クラスタ利用者は自チームのアプリケーションにオーナーシップをもつ。 Kubernetesクラスタ(GKE,EKS) Kubernetesクラスタ上のオペレータ (Argo CD, Datadog

    Agentなど) コンテナイメージの配置場所 Kubernetesマニフェストを管理するモノレポ … アプリケーションコード アプリケーションのコンテナイメージ 自チームのKubernetesマニフェスト (マニフェストは基本自由に変更可能) アプリケーションで利用するDBやS3 … SREチームの管理物 SREチーム以外 クラスタ利用者の管理物
  4. おさらい① User Journey: ユーザーがサービスと行う一連の対話・体験
 ex. 商品を購入するためにカート内商品の購入を確定する SLI: サービスの信頼性を測るための指標 ex. 購入時のAPIについて5xx以外のHTTPコードのレスポンス数

    / 全体のリクエスト数 SLO: SLIに対してどの程度の値を目指すかを定義したもの ex. 過去28日間で5xx以外のレスポンス数の割合が99.5% 6 SLIを考える前段となる。実質 SLIを自 然言語で表したものに近い
  5. おさらい② 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 これをモニターで監視することで エラーバジェットを消費し切る前に 対応を実施する、といったことができる
  6. SLO設計の大前提 13 運用してみないと分からない側面: ▪ SLIに使おうとしたメトリクスが実は不安定だった ▪ SLIでは拾いきれないシナリオが実は存在した ▪ … コンテキストの変化の側面:

    ▪ ビジネス要件が変化した ▪ アーキテクチャの変更があった ▪ チームの人員が増減して割ける工数が変化した ▪ … 運用し続ける前提で考える。最初から完璧なSLOは作れないし 加えてコンテキストの変化に合わせて調整・運用し続ける必要がある
  7. 今回の話 14 Login API 認証 API 認証系 サービス API Gateway

    会員系 サービス SREチーム 会員 チーム 認証 チーム クラスタや 各種オペレータを管理 今回はSREチームの提供する クラスタ周りのSLOを決めた話
  8. 15 User Journeyの設定 SLIの設計 SLOの設定 Error Budget Policyの設定 Burn Rate

    Alertの設定 Burn Rate Alertの設定 SLO Documentの作成 SLO構築の流れ
  9. User Journeyの設定① ユーザーをKubernetes Clusterを利用する DMMプラットフォーム内の各チームと定義した。 16 動画配信 サービス 電子書籍 サービス

    API Gateway 認証系 サービス 会員系 サービス DMMプラットフォームを 利用する事業部 End User クラスタ運用側として一番距離の近い クラスタを利用する各チームを今回のユーザーとした クラスタ 利用チーム
  10. SLIの設計 ユーザージャーニーをSLIに落とし込むように設計した。 (これが一番むずかしい) 18 おおまかな設計方針 ▪ 理解しやすい程度にはシンプルであること ▪ メトリクスとしてノイズが少ないこと ▪

    可能な限りユーザー体験を直接表現していること ▪ あまりSLIの数が多くなりすぎないこと (運用できない+意思決定に使いづらくなる)
  11. 設計したSLI クラスタ運用側として、マニフェストやコンテナがちゃんとしてれば サービスがしっかり動くことを保証するために以下を設定した。 アプリケーション自体の挙動は追わない。 19 ▪ クラスタ内のPendingである状態のPodが N 個以下である時間長 例えばCluster

    Autoscalerが壊れていてノードがスケールしない といったケースが拾える ▪ 各ReplicasetがDesired Podの個数通りに動作している時間長 例えばネットワークや認証情報が壊れてコンテナイメージを配置場所 からPullできないといったケースが拾える 

  12. SLIに採用しなかった例 20 ▪ クラスタ内のアプリケーションのログが正常に保存されている割合 そもそもUser Journeyとは異なってしまう。本来はサポートする べきかもしれないが別のUser Journeyで考えるべき。 ▪ クラスタ上でPodがErrorの状態である時間長

    実績的にPodがエラーになるかどうかはクラスタ自身以外の 原因がほとんどだったので対象外とした。 ex.) Podの通信先がダウンしていることによってPodが終了 マニフェストの設定ミスによってうまく起動せずエラー ※今後クラスタのネットワーク起因でのエラーなどが
  起こる場合には検討する

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


    障害発生時、現実的に対応完了までにかかる時間は? 現時点ではオンコールを受けて調査開始までに現実的に5分以上かかる よって少なくとも99.99%のSLOは達成できない(28日間の0.01%は4.032分) 問題を検知する→ 人間がオンコールを受ける → 調査する → 対応する
  14. Error Budget Policyの設定 22 達成不可能な強い制約はかけず議論の出発点としての 機会を用意するようにして柔軟なポリシーを設定している。 条件 対応 エラーバジェットが
 50%を切った場合


    チームでMTGを実施し対応可否に加え
 対応内容を検討する。
 エラーバジェットを完全に 使い切った場合
 チームの少なくとも1人を最優先で信頼性向上の
 タスクにアサインする。対応完了後に利用チームに
 対応結果を共有する。

  15. アプリケーション運用チームへの展開 25 Login API 認証 API API Gateway 会員系 サービス

    SREチーム 会員 チーム 認証 チーム 認証系 サービス 今後は他チームへもSLO導入の流れを展開をする予定である。 SREチームだけではアプリケーションに対するSLOの運用知見は貯まらないので 一部クラスタ利用チームに依頼して先行的に導入を進めている。 基本はAPI別で エラー率・レイテンシの SLI/SLOを用意している
  16. User Journey 多すぎ問題 そもそもサポートすべき機能が多すぎてユーザージャーニーが大量に…。 27 ユーザージャーニーの実例 ▪ クラスタ上にデプロイしてあるサービスが他サービスと通信したり バッチ処理を行う。 ▪

    クラスタにデプロイしているサービスをDatadogで監視する。 ▪ k8sリソースの設定をモノレポのマニフェストを変更してリリースする。 ▪ kubectlを叩いてリソースの操作をする。 ▪ … 今はSLO導入初期なことから運用負荷を軽減すべく、まずはできる限り ユーザージャーニーをまとめる+重要度の高いものに絞って運用している。
  17. ユーザー体験に対するSLIの距離問題 ユーザー体験にSLIを寄せすぎると逆にノイズが増えて機能しないケースがあり 必ずしもユーザー体験に近いほど良いというものでもない。 28 SLIのユーザー体験との距離 ユ ー ザ ー 体

    験 の 表 現 度 ノ イ ズ の 混 じ り に く さ (近い) (遠い) 適度にノイズが混じらない程度にユーザー体験を 表現する落とし所を見つける必要がある…。 ▪ ex. ユーザーのブラウザ上のページの描画時間 (Webフロントページを提供するサービスのSLIとして) 体験としては近いが、マシンスペックに影響される。 おそらくロードバランサから取れるレスポンスタイム等を 計測したほうがノイズが少ないのでは?
  18. ユーザー体験に対するSLIの距離問題 - 対応策 対応策は色々あるが、現実的に割ける工数を考え 現状は仕方なくユーザーの不備起因のものは手動で除外している。 29 1. CIなどを作り込んでそもそもクライアント起因の問題が起きないようにする → クライアントの失敗を運用側の責務に取り込む。工数がかかる。

    2. 代わりのSLIを用意する → 理想はこれだが現実問題見つからない 3. ユーザーの不備によるエラーバジェット消費はSLO計算から手動で除外する → 現状は手動オペレーションは月1,2回程度、Datadogの機能でできる。   発生頻度が高すぎる場合はSLI見直す必要がある。   今は基本この方針で対応している。
  19. SLIで依存をどこまで取り込むか問題 - 例 32 API Gateway Service A Service B

    Service C API Gatewayを運用するチームが SLOを決めたいケース 後続のサービスは、別々のチームが管轄し エラー率もレイテンシも サービスによって全然異なる ユーザーをAPI Gatewayを 叩くクライアントとする ユーザー
  20. 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
  21. 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の後続にサービスが増えるほど発火する機会も増える 正常に稼働しているが エラー率が高くなる エラー率が 高くなる
  22. SLIで依存をどこまで取り込むか問題 - 対策 35 API Gateway Service A Service B

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