CUJ（Critical User Journey）ベースのSLI/SLOを活用したProgressive Deliveryでリリース時の信頼性を最大化させる、ペアーズのデリバリー戦略

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy
CUJ（Critical User Journey）ベースの SLI/SLOを活用したProgressive Deliveryでリリース時の信頼性を最大化させるペアーズのデリバリー戦略 2023/11/20 CloudNative Days Tokyo 2023プレイベント

About Me Yukako Ishikawa (@__yucatty) • 株式会社エウレカ ◦ 2022年に入社 ◦ SRE & Data Management Teamに所属 ▪ インフラ構築〜監視運用 ▪ データ基盤の信頼性強化 ◦ 休日は時々山にいます

日本で最も使われている恋活・婚活マッチングアプリ Pairsについて出典：MMD研究所「2023年マッチングサービス・アプリの利用実態調査」2023年10月時点 3

本セッションについて（前提） • ペアーズでは直近2年間でCUJベースのSLI/SLOの安定運用ができていた • EKS移行後はProgressive Deliveryによる自動ロールバックを導入し、安全にリリースする仕組みを構築した（今日お話しすること） • 開発者が運用するCUJ毎のSLI/SLOをProgressive Deliveryに活用し、リリース時の信頼性向上を目指した話ペアーズの SLI/SLO改善と信頼性向上の歩み

本セッションの対象者 • EKSでインフラを構築している方 • Argo Rolloutsを既に導入している方・導入に興味がある方 • CUJベースのSLI/SLOを運用している方 • SLI/SLOをデリバリーに活用するプロセスに興味のある方

Agenda(本日の流れ）ペアーズの Progressive Delivery について CUJベースの SLI/SLOをデリバリープロセスに活用するまとめペアーズのSLI/SLO運用について１. ペアーズのSLI/SLO運用について 2. ペアーズのProgressive Deliveryについて 3. CUJベースのSLI/SLOをデリバリープロセスに活用する 4. まとめ • SLI/SLO・CUJとは • ペアーズのSLI/SLO • 開発者がオーナーシップを持って SLI/SLOを運用している話 • Progressive Delivery とは • ペアーズの全体構成 • Istio/Argo Rolloutsを用いたペアーズの Progressive Delivery • 課題感 • 開発者が運用しているSLI/SLOを Progressive Delivery の分析指標に活用する仕組み

ペアーズのSLI/SLO運用についてペアーズの Progressive Delivery について CUJベースの SLI/SLOをデリバリープロセスに活用するまとめペアーズのSLI/SLO運用について

SLI/SLO（おさらい） • SLI（サービスレベル指標） ◦ サービスレベルのある側面について測定した定量的な指標 • SLO（サービスレベル目標） ◦ SLI によって測定されるサービス・レベルの目標値

CUJ • CUJ（Critical User Journey） ◦ ユーザーの体験の中核をなす一連のタスク（サイトリライアビリティワークブックより） ▪ ECサイトの例 • 商品を探す • 商品をカートに入れる • 購入を完了させる ◦ 顧客体験を向上させることを中心に考えたSLOを設定すべき ▪ = CUJに紐付く操作を束ねた指標をSLIとする

ペアーズのSLI/SLO • SLOを形成するSLI ◦ サービスにおけるユーザーの重要操作の成功率＝CUJ（Critical User journey) をベースにした指標 ◦ 指標の悪化がサービス満足度に影響しやすいもの ◦ サービス停止時に影響が計上される • SRE/Backend双方が重要だと判断するものであり、共同で改善作業をすることに合意形成ができているもの

ペアーズのSLI/SLO • ペアーズにおけるCUJの例 ◦ 新規登録 ◦ ログイン ◦ 課金関連 ◦ など約10種類の重要操作

Availability SLI/SLO • Datadog にアプリケーションから送信している Trace（サンプリングレート 1%）を使用 ◦ Good Events = API ごとに http status code 5XX 以外の件数を datadog の trace.http.request.hit からクエリし、それをユーザー操作単位で合計した件数 ◦ Total Events = API ごとのリクエスト件数を datadog の trace.http.request.hit からクエリし、それをユーザー操作単位で合計した件数 • SLOは99.95% (window 1ヶ月)

Latency SLI/SLO • Datadog にアプリケーションから送信している Trace（サンプリングレート 1%）を用いているので、Datadog のメトリクスで表現することができる ◦ Good Events = API ごとに閾値より早く返せたメトリクスを datadog の trace.http.request からクエリし、それをユーザー操作単位で合計した件数 ◦ Total Events = API ごとにメトリクスを datadog の trace.http.request からクエリし、それをユーザー操作単位で合計した件数 • 閾値・SLOはメトリクスを見てAPI毎に個別に設定(window 1ヶ月)

開発者がオーナーシップを持って運用 • 隔週でBackend × SREで定例ミーティングを実施し、その中で SLOを割っているものがないか確認＆アクションを決定 • アクションを決定できるフローチャートを作成

開発者がオーナーシップを持って運用 • SLI/SLO管理用の専用リポジトリを作成し、terraformでコード管理 • 閾値調整・SLO調整・新規CUJ追加の際に、開発者はSLI/SLO 対象のエンドポイントを管理する設定ファイルに追加・修正するだけで、SLO設定からダッシュボード・アラート構築を行えるようになっている query作成 terraform apply

ここまでのまとめ • ペアーズではCUJ毎にAvailability SLI/SLOとLatency SLI/SLOを運用している • 隔週の定例ミーティングでError budgetが割った場合のアクションを決定 • 開発者がオーナーシップを持ってSLI/SLOを運用し、terraformでコード管理したSLOダッシュボード・アラートをメンテナンスしている

ペアーズのProgressive Deliveryについてペアーズの Progressive Delivery について CUJベースの SLI/SLOをデリバリープロセスに活用するまとめペアーズのSLI/SLO運用について

Progressive Delivery • 新しいバージョンを徐々にリリースしつつ、リリースに伴う影響を最小限に抑えることを目的としたデリバリー方式 • Canary Releaseと組み合わせて、段階リリースしながらメトリクス分析を行い、一定の閾値ベースで自動ロールバックなどを行う手法が有名 • 導入のメリット ◦ 自動ロールバックにより、リリース後に問題があった時にできるだけ素早く切り戻すことができる ◦ リリースの影響範囲をできるだけ小さくすることができる

ペアーズの全体構成

ペアーズの全体構成 • EKS on EC2 ◦ マルチテナントクラスターとして複数のアプリケーションが1クラスターでホストされている • Istio Ingress Gatewayを利用したトラフィックコントロール ◦ Istio Ingress Gateway をNodePortで公開し、 TargetGroupBindingで全てのアプリケーション用 ALBのtargetGroupに紐付け • 各サービスのPodへはIstioのカスタムリソース（Gateway、VirtualService）を使用してHostBaseのルーティングを行っている

Progressive Deliveryの実装 • Progressive Delivery自体はArgo Rolloutsの機能を使用 ◦ Istio Ingress Gateway + VirtualServiceと連携 ◦ Canary serviceとStable serviceのweightを動的に更新することによってCanary Releaseを実現 • AnalysisTemplateを使用して、rollout中にバックグラウンドでAnalysisを実行 • Analysisのメトリクスは、DatadogのIstioのVirtualServiceのメトリクスを使用 ◦ Canary revisonに絞ったリクエストで、Availability SLOに合わせて99.95%を閾値とする

Delivery フロー 1. Canary Release(stableからcanaryへのパーセントリリース) で 25%リリース -> pending 5m -> 100%リリース a. その間、intervalに設定した間隔で自動でメトリクスアナライズが走る 2. 自動メトリクスアナライズで、canary revisionの5XX rate 0.05%超えが1回発生したらリリース失敗とみなす 3. メトリクスアナライズによりリリース失敗とみなされると自動でstable revisonへロールバックされる

昨年Tech Blogでも紹介しました https://medium.com/eureka-engineering/argo-rollouts%E3%81%A8pairs%E3%81%AE %E3%83%87%E3%83%AA%E3%83%90%E3%83%AA%E3%83%BC%E6%88%A6%E7%95 %A5-progressive-delivery%E3%81%B8%E3%81%AE%E7%A7%BB%E8%A1%8C-266cb2 af8d20

運用してわかった課題 • 総リクエストのエラー率をAnalysisしていたため、総リクエストに対してリクエスト数の少ない、特定の操作(エンドポイント）でエラーが発生していたことを検知できなかった • リリース時にCUJの不具合を検知して自動ロールバックできるのが理想的普段運用している、CUJベースのAvailability SLI/SLOを Analysisの指標として活用できるのではないか？

ここまでのまとめ • ペアーズはIstio(Istio Ingress Gateway + VirtualService)とArgo Rolloutsを利用してProgressive Deliveryの自動ロールバック機能を実装している • メトリクス分析ではDatadogのIstioのVirtualServiceのメトリクスを使用 ◦ Canary revisonにおける総リクエストのエラー率を評価 • 全体のリクエストに対して、リクエスト数の少ないエンドポイントは不具合が検知できない課題があった

CUJベースのSLI/SLOをデリバリープロセスに活用するペアーズの Progressive Delivery について CUJベースの SLI/SLOをデリバリープロセスに活用するまとめペアーズのSLI/SLO運用について

やりたいこと • リリース時にCUJの不具合を検知して自動ロールバックできるようにしたい普段運用している、CUJベースのAvailability SLI/SLOを Analysisの指標として活用する

CUJベースのAvailability SLI/SLOをAnalysisの指標として活用するために 1. Analysis Runで複数のCUJごとにAnalysisできるようにする a. Canary revisionのリクエストをpathごとにAnalysisできるようにする b. Multiple Template 2. CUJベースのSLI/SLOの更新を、Analysis Templateに同期できるようにする

Canary revisionのリクエストをpath毎にAnalysisできるようにする • CUJ毎のAnalysisをするためにはエンドポイントのメタデータが必要 ◦ SLI/SLOと同様にDatadog の trace.http.request.hitを利用 • Canary revisionのメトリクスを利用するために、CanaryとStableで Datadog traceのメトリクスを区別する ◦ IstioのVirtualServiceのroute.destinationでCanaryのserviceの時にheader付与 ◦ アプリケーション側でheader取得 -> datadog traceでcanaryのメトリクスを取得

Multiple Template • Analysis Templateは複数設定することが可能 • 各AnalysisはAND条件で評価される（1つでもPASSしていなければ失敗とみなす）

Multiple Templateの利用 • Analysisの結果は、GUIもしくはkubectl describe analysisrun <analysis-run-name> -n <namespace>で確認

CUJベースのSLI/SLOをデリバリープロセスに活用するために 1. Analysis Runで複数のCUJを扱えるようにする a. Canary revisionのリクエストをpathごとにAnalysisできるようにする b. Multiple Template 2. CUJベースのSLI/SLOの更新を、Analysis Templateに同期できるようにする

DatadogメトリクスのQueryの二重メンテを避けたい • 一つのCUJに複数のエンドポイントが紐づくので、Analysis Templateのqueryが冗長になる • そもそもSLI/SLOを管理するterraformリポジトリでも類似したqueryを生成している

開発者が設定したSLI/SLOをAnaleysis Templateに同期する • 開発者が二重メンテナンスしなくていいように、CUJごとのエンドポイントを管理する設定ファイルを、SLI/SLOを管理する terraformのリポジトリと、k8sマニフェストを管理するリポジトリ間で、扱えるようにしたい SLO DashBoard構築 Alert管理 Analysis Template作成 query生成 query生成

CUJベースのSLI/SLOをデリバリープロセスに活用するために 1. Analysis Runで複数のCUJを扱えるようにする a. Canary revisionのリクエストをpathごとにAnalysisできるようにする b. Multiple Template 2. CUJベースのSLI/SLOの更新を、Analysis Templateに同期できるようにする →開発者のメンテナンス性を維持したまま同期できるようする

CUE言語の活用 • https://cuelang.org • 構成管理を目的とした言語 ◦ 構成ファイルのバリデーション、構成のマージ、設定のデフォルト値を持たせることができるのが特徴 • tfファイル(tf.json)と、k8sマニフェストファイル(yaml)の両方に対応しているので、今回やりたいことが達成できる • ペアーズのバッチ基盤（EKS）での利用実績や、勉強会の実施で開発組織に浸透しつつある #CUEでキュッと

CUJごとのエンドポイントを管理する設定ファイルをCUE言語に変換 Terraformリポジトリ側は cue exportでtf.jsonに変換

CUE言語でAnalysis Templateを生成する cuj.cue analysis_template.cue CUE言語のイテレート処理+ 独自サブコマンド(cue dump)で複数のAnalysis Templateを生成単一yamlファイルで複数 k8sリソースを定義できる独自サブコマンドを作成

最終的な構成 CUJの SLI/SLOの更新

まとめ

まとめ • そもそも、SLI/SLOを開発者がオーナーシップを持って継続的に運用できていることが大前提 ◦ 隔週ミーティングでSLOダッシュボードを一緒にみる ◦ 開発者がメンテナンスしやすい運用に整備する ◦ Error budgetが割った時のアクションを定義・実施 • リリース時の信頼性向上 ◦ 総リクエストのエラー率に加え、CUJベースのSLI/SLOの指標を利用することで、リリースによる、重要操作における不具合の影響を最小限にすることが可能となった • メンテナンス性の維持 ◦ CUJはアップデートされていくもの ▪ ビジネス判断により閉じられる機能や、新規機能の追随 ◦ 仕組みを構築して終わりではない ▪ CUE言語の活用で複雑なクエリを開発者が意識せずに、SLI/SLOの更新・Analysis Templateの更新を行えるようになった

さらなる信頼性向上に向けて • サーバーサイドのSLOが満たされていても、直接的にユーザーが利用できている状況と言うことができない • 改善系タスクの意思決定をする際にProduct Managerにとっても納得感のあるものにしたいユーザー操作に直結する信頼性を計測する = クライアント監視の重要性

そのほかにもまだまだやることがたくさん • クライアント監視の拡充 • データ基盤の信頼性・開発体験強化 • アプリケーションの開発体験向上

We’re hiring! ペアーズではエンジニアを積極採用中！  カジュアル面談もお待ちしております！  (X: @__yucatty) 

CUJ（Critical User Journey）ベースのSLI/SLOを活用したProgr...

CUJ（Critical User Journey）ベースのSLI/SLOを活用したProgressive Deliveryでリリース時の信頼性を最大化させる、ペアーズのデリバリー戦略

Featured

Transcript