[SRE NEXT] 複雑なシステムにおけるUser Journey SLOの導入

2025/07/11のSRE NEXT 2025 当日の登壇資料です。

Transcript

1. 1 複雑なシステムにおける User Journey SLOの導入 土屋健司
2. 2 ・SIerで大規模システムの性能問題を多数解決 
 ・2024年メルカリ入社 
 ・Platform SRE 
 　・新規サービスの立ち上げ支援 
 　・メルカリのモニタリング 
 ・最近Platform Networkに異動 
 土屋健司 @yakenji 

3. 3 　　 2013年2月1日 会社設立日 東京、福岡、大阪 Palo Alto、Bangalore オフィス 2,190名（連結） 従業員数 3 株式会社メルカリ　概要
4. 4 　　 •サービス開始：2013年7月 •対応OS：Android、iOS ※Webブラウザからも利用可能 •利用料：無料 ※売れたときの手数料：販売価格の10% •対応地域・言語：日本・日本語基本仕様 •累計出品数：40億品を突破 (2024年9月) でなくなったモノが必要とする人に渡る喜びを感じ、また購入 者は豊富な出品数から「宝探し」感覚で魅力的な商品を見つけ ることを楽しんでいます。 さらに「メルカリ」は物の売買だけではなく出品者と購入者の コミュニケーションも重視し、チャットや絵文字、「いい ね！」機能の拡充などお客さまがより快適に取引を楽しめるた めの機能改善にも取り組んでいます。 「メルカリ」は、個人間での不要品の売買を簡単に行えるフリ マアプリです。エスクロー決済を活用した安心・安全な取引環 境の整備や、簡単かつ手頃な価格の配送オプションなど差別化 されたユニークなお客さま体験を提供しています。 現在、「メルカリ」では1秒間に7.9個の商品が売れています。 売れやすい環境が整う中、多くの出品者は、自分にとって必要 4 メルカリとは
5. 5 　　 5 CtoCの基盤を活用した事業成長
6. 6 User Journey SLOとは？
7. 7 User Journey SLO ＝ お客さま目線の SLO
8. 8 従来のSLOとの違い 開発目線の SLO 単一のサービスに閉じた目標・監視 サービスにフォーカス User Journey SLO 複数のサービスに跨った目標・監視 お客さまにフォーカス
9. 9 User Journey SLOの背景と動機
10. 10 メルカリでは各サービスチームが障害対応を実施 ・各チームがそれぞれ 
 　・SLO設定 
 　・モニタリング 
 　・オンコール対応 

11. 11 SREはインシデント対応の改善と最後の砦の役割 SRE
 SREはサービス全体の 
 信頼性向上に注力 
 最後の砦としてオンコール対応もする 
 
 各サービスの障害対応・改善は 
 あくまで各開発チームの責務！ 

12. 12 各User Journeyは複数のサービスに依存 複数の
 - エンドポイント 
 - サービス
 
 例えば …
 発送の場合： 
 - Shipping 
 - Item
 - User
 - Transaction 

13. 13 一つのサービスの障害の影響範囲はわかりにくい どのAPIがどこで 
 リクエストされるかの 
 把握は困難 
 お客さまは何ができなくなった？ 
 ＝ 何ならできる？ 

14. 14 障害が発生しても重大度が不明 # incident-channel # incident-channel As Is To Be 障害発生時に 
 影響範囲が 
 具体的にはわからない 
 
 さらに …
 各サービスのSLOでは 
 お客さま目線の 
 サービスレベルは不明 

15. 15 ユーザージャーニー に沿ったSLOが必要！
16. 16 1. SLIの設定 2. Critical User Journey (CUJ)の定義 3. クリティカルな APIの探索 やったこと
17. 17 1 User Journey, 1 single SLO 1 User Journeyに 
 サービスの数だけ 
 SLOがあっても 
 使いこなせない 
 
 多少の誤差は許容 
 あっても1つのSLOに 
 なるように 

18. 18 計測可能なメトリクスから SLIを決定 Availability: SCUJ = SA × SB Latency : ACUJ = min(AA, AB) クリティカルAPI 
 (= 障害発生でUJがAvailableで はなくなるもの) 
 のメトリクスを用いて 
 SLIを定義 
 
 トライ＆エラーが大事 
 コード化で後から 
 チューニングできるように 
 クリティカルAPI A・Bの 　Availability: SA, SB エラー率 　Latency : AA, AB 目標応答時間の達成率
19. 19 40のCUJを定義 ・画面操作 + 画面遷移 
 ・Availableな状態を定義 
 ・コア機能にフォーカス 
 例）
 ・商品検索 
 ・出品・購入・発送 

20. 20 障害注入によりクリティカル APIを探索 各CUJで使用される 
 APIを探索 
 
 各APIに障害を 
 擬似発生させてアプリの挙動 
 を判定
 
 AvailableではなくなるAPI 
 => クリティカルなAPI 

21. 21 既存のテストフレームワークを流用して探索を自動化 アプリは日々変化する 
 → クリティカルAPIも 
 変化する
 
 探索を自動化して 
 常に最新の状態を 
 維持する必要 

22. 22 Lookerで結果の可視化 +Terraformでモニタリング反映 クリティカルAPIの 
 可視化とAPMへの反映も 
 半自動化
 
 工数を削減しつつ 
 統一的なモニタリングを 
 実施

23. 23 障害発生後、即座に影響範囲を特定 影響CUJとともにアラート通知 
 Slack botで影響範囲を一覧化 

24. 24 ダッシュボードから原因サービスに最短でコンタクト ダッシュボードで 
 クリティカルAPIの 
 メトリクスを可視化 
 
 ・ 障害時の一次ソース 
 ・ SLOが悪化した際の分析 
 コンタクトポイント情報
25. 25 今後の取り組み
26. 26 自動化を進めたが、テストシナリオのメンテナンスは必要 QAのフレームワーク 
 により小さな変更なら 
 影響なし
 
 大きな変更には 
 対応できない 
 （画面ごと置き換わる等） 

27. 27 AI Agent等によってテスト保守も自動化を目指す => Cursor / Claud CodeなどLLMにメンテナンスを 
 実施させる取り組みをトライ中 
 
 => QAサイクルへの組み込みも考えたい 

28. 28 まとめ
29. 29 • Critical User Journey SLO を導入して障害対応・サービス品質の 可視化を行った ◦ お客さまが実際に感じる品質を数値化 ◦ お客さまが障害時に何ができて何ができないのかを即時把握 ◦ わかりやすいSLIの定義が重要 • アプリの変化に追従して陳腐化しない仕組みの整備を行った ◦ アプリは常にアップデートされるので自動でSLOもアップデート ◦ SLOと現実が乖離すると意味なし！アップデートし続けるのが重要 ◦ これからもメンテナンスとの闘いは続く。。。 まとめ
30. 30 We are hiring!
31. 31 クラウドネットワークエンジニアを探しています！ https://apply.workable.com/mercari/j/08F0B7531B/