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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy About Me Yukako Ishikawa (@__yucatty) ● 株式会社エウレカ ○ 2022年に入社 ○ SRE & Data Management Teamに所属 ■ インフラ構築〜監視運用 ■ データ基盤の信頼性強化 ○ 休日は時々山にいます 

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

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

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 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 の分析指標に活用す る仕組み 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy ペアーズのSLI/SLO運用について ペアーズの Progressive Delivery について CUJベースの SLI/SLOをデリバリー プロセスに活用する まとめ ペアーズのSLI/SLO運用 について 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy SLI/SLO（おさらい） ● SLI（サービスレベル指標） ○ サービスレベルのある側面について測定した定量的な指標 ● SLO（サービスレベル目標） ○ SLI によって測定されるサービス・レベルの目標値 

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

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy ペアーズのSLI/SLO ● ペアーズにおけるCUJの例 ○ 新規登録 ○ ログイン ○ 課金関連 ○ など約10種類の重要操作 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 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ヶ月) 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 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ヶ月) 

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

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

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy ペアーズのProgressive Deliveryについて ペアーズの Progressive Delivery について CUJベースの SLI/SLOをデリバリー プロセスに活用する まとめ ペアーズのSLI/SLO運用 について 

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy ペアーズの全体構成 

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 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%を閾値とする 

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 昨年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 

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

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy CUJベースのSLI/SLOをデリバリープロセスに活用する ペアーズの Progressive Delivery について CUJベースの SLI/SLOをデリバリー プロセスに活用する まとめ ペアーズのSLI/SLO運用 について 

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

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

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 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のメトリ クスを取得 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy Multiple Template ● Analysis Templateは複数設定することが可能 ● 各AnalysisはAND条件で評価される（1つでもPASSしてい なければ失敗とみなす） 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy Multiple Templateの利用 ● Analysisの結果は、GUIもしくはkubectl describe analysisrun -n で確認 

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

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

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

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

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy CUJごとのエンドポイントを管理する設定ファイルをCUE言語に変換 Terraformリポジトリ側は cue exportでtf.jsonに変換 

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

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 最終的な構成 CUJの SLI/SLOの 更新 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy まとめ 

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

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

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

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

No content