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

by yakenji

Slide 1

Slide 1 text

1 複雑なシステムにおける User Journey SLOの導入土屋健司

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

3 　　 2013年2月1日会社設立日東京、福岡、大阪 Palo Alto、Bangalore オフィス 2,190名（連結）従業員数 3 株式会社メルカリ　概要

Slide 4

Slide 4 text

4 　　 ●サービス開始：2013年7月 ●対応OS：Android、iOS ※Webブラウザからも利用可能 ●利用料：無料 ※売れたときの手数料：販売価格の10% ●対応地域・言語：日本・日本語基本仕様 ●累計出品数：40億品を突破 (2024年9月) でなくなったモノが必要とする人に渡る喜びを感じ、また購入者は豊富な出品数から「宝探し」感覚で魅力的な商品を見つけることを楽しんでいます。さらに「メルカリ」は物の売買だけではなく出品者と購入者のコミュニケーションも重視し、チャットや絵文字、「いいね！」機能の拡充などお客さまがより快適に取引を楽しめるための機能改善にも取り組んでいます。「メルカリ」は、個人間での不要品の売買を簡単に行えるフリマアプリです。エスクロー決済を活用した安心・安全な取引環境の整備や、簡単かつ手頃な価格の配送オプションなど差別化されたユニークなお客さま体験を提供しています。現在、「メルカリ」では1秒間に7.9個の商品が売れています。売れやすい環境が整う中、多くの出品者は、自分にとって必要 4 メルカリとは

Slide 5

Slide 5 text

5 　　 5 CtoCの基盤を活用した事業成長

Slide 6

Slide 6 text

6 User Journey SLOとは？

Slide 7

Slide 7 text

7 User Journey SLO ＝お客さま目線の SLO

Slide 8

Slide 8 text

8 従来のSLOとの違い開発目線の SLO 単一のサービスに閉じた目標・監視サービスにフォーカス User Journey SLO 複数のサービスに跨った目標・監視お客さまにフォーカス

Slide 9

Slide 9 text

9 User Journey SLOの背景と動機

Slide 10

Slide 10 text

10 メルカリでは各サービスチームが障害対応を実施・各チームがそれぞれ   　・SLO設定   　・モニタリング   　・オンコール対応  

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

15 ユーザージャーニーに沿ったSLOが必要！

Slide 16

Slide 16 text

16 1. SLIの設定 2. Critical User Journey (CUJ)の定義 3. クリティカルな APIの探索やったこと

Slide 17

Slide 17 text

17 1 User Journey, 1 single SLO 1 User Journeyに   サービスの数だけ   SLOがあっても   使いこなせない     多少の誤差は許容   あっても1つのSLOに   なるように  

Slide 18

Slide 18 text

18 計測可能なメトリクスから SLIを決定 Availability: SCUJ = SA × SB Latency : ACUJ = min(AA, AB) クリティカルAPI   (= 障害発生でUJがAvailableではなくなるもの)   のメトリクスを用いて   SLIを定義     トライ＆エラーが大事   コード化で後から   チューニングできるように   クリティカルAPI A・Bの　Availability: SA, SB エラー率　Latency : AA, AB 目標応答時間の達成率

Slide 19

Slide 19 text

19 40のCUJを定義・画面操作 + 画面遷移   ・Availableな状態を定義   ・コア機能にフォーカス   例）  ・商品検索   ・出品・購入・発送  

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

24 ダッシュボードから原因サービスに最短でコンタクトダッシュボードで   クリティカルAPIの   メトリクスを可視化     ・障害時の一次ソース   ・ SLOが悪化した際の分析   コンタクトポイント情報

Slide 25

Slide 25 text

25 今後の取り組み

Slide 26

Slide 26 text

26 自動化を進めたが、テストシナリオのメンテナンスは必要 QAのフレームワーク   により小さな変更なら   影響なし    大きな変更には   対応できない   （画面ごと置き換わる等）  

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

28 まとめ

Slide 29

Slide 29 text

29 ● Critical User Journey SLO を導入して障害対応・サービス品質の可視化を行った ○ お客さまが実際に感じる品質を数値化 ○ お客さまが障害時に何ができて何ができないのかを即時把握 ○ わかりやすいSLIの定義が重要 ● アプリの変化に追従して陳腐化しない仕組みの整備を行った ○ アプリは常にアップデートされるので自動でSLOもアップデート ○ SLOと現実が乖離すると意味なし！アップデートし続けるのが重要 ○ これからもメンテナンスとの闘いは続く。。。まとめ

Slide 30

Slide 30 text

30 We are hiring!

Slide 31

Slide 31 text

31 クラウドネットワークエンジニアを探しています！ https://apply.workable.com/mercari/j/08F0B7531B/