Merpay SRE @komattaka Monitoring -SLI/SLO Driven-

2 自己紹介 Copyright © Merpay, Inc. All Rights Reserved. @komattaka SRE Team at Merpay

3 Basic Information 01 今日の目次 02 Monitoring ● Concept of Monitoring ● Metrics Driven ● SLI / SLO ● Postmortem ● Error Budget Copyright © Merpay, Inc. All Rights Reserved. ● Architecture ● Product Manager

Basic Information

Architecture Clients Merpay API Gateway API - 2 Service - 1 Service - 2 Service - 3 API - 1 CDN

6 Confidential - Do Not Share Product D Product C Product B Product A Product Engineering PM PM PM PM TL ... TL ... TL EM EM EM EM TL Architect Backend 1 Backend 2 iOS, Android Frontend EM SRE EM Solution EM Merpay Organizational structure

7 Confidential - Do Not Share Product D Product C Product B Product A Product Engineering PM PM PM PM TL ... TL ... TL EM EM EM EM TL Architect Backend 1 Backend 2 iOS, Android Frontend EM SRE EM Solution EM Merpay Organizational structure Product Manager(PM)? ● Drive product planning, designing, managing development and operation for Mercari ● Create new business models tor grow specific categories like Fashion, Entertainment and so on ● keep an eye on current trends and the needs of users in order to propose, develop, and implement new features or plans. ● Create specifications for realizing new business, new functions with engineer, designer and customer services ● Own responsibility for product delivery and drive product development

Monitoring

Concept Monitoring

Concept of Monitoring

Monitoring Chaos Map Infrastructure Monitoring ※ 順不同 スタック毎に得手不得手があるので 1つのツールで全てを担当することは正解ではない Application Performance Monitoring Application Bug Tracking Analyzation External Monitoring Notification/Call

Application Performance Monitoring Monitoring Chaos Map Analyzation External Monitoring Infrastructure Monitoring Application Bug Tracking Notification/Call ※ 順不同 弊社での活用例(検証中含む)

Metrics Driven Development Monitoring

Metrics Driven Development 適切なモニタリングを行うために、あらゆる事象を特徴の異なる3つの指標にグルーピングすること を推奨している 種類 例 特徴 Work Metrics ● Throughput ● Success ● Error ● Performance お客さまに一番分かりやすく、 CVなどに影響 → 閲覧が…できる/できない → 表示までの速度が…速い/遅い これが悪化したらすぐに直さないといけない Resource Metrics ● Utilization ● Saturation ● (Internal) Error ● Availability これが悪化するとWork Metricsに影響が出るもの の、すぐに影響する訳ではない これが悪化したらいつか直さないといけない Events ● CI/CDジョブの実行 ● CM、広告 Work / Resource両方のMetricsに影響が出る

Metrics Driven Development 3つの指標には相関関係がある 全てのモノ・人のEventはメトリクスに反映されるため、 常にモニタリングし改善を続けていくことが大事

SLI / SLO Monitoring

SLI / SLO (SLA) 何をMonitoringすべきかはSLI/SLO(SLA)を定義することでハッキリする 　(アンチパターン「 監視できるものは全部監視する」を防ぐ) ● SLI(Service Level Indicator): サービスレベル指標 ● SLO(Service Level Objective): サービスレベル目標 = SLI + 目標 ● SLA(Service Level Agreement): サービスレベル契約 = SLO + 罰金 弊社でのSLI/SLOの例: 1. Availability: 1時間測定し99.99%のリクエストが正常な結果(Status: 200, 300系, 400系) を返す 2. Latency: 1時間測定してBackendへの99%のリクエストが 150msec以内に返る 3. Quality: APMで10分測定して、想定外のエラー率が 0.1%以下である

SLIを決める - 1 "監視できるものは監視する"のではなく、 　SLIをUX / Customer Journeyから考える。 UX / Customer Journeyに責務を持つPMが主になって考え、エンジニアはそれを満 たすSLIを割り出していき、時には計測不能なSLIを計測するためのツールの選定も行 う。 SLIはCustomer Journeyに対して最大3つ程度が良い。 https://www.blastam.com/customer-journey

SLIを決める - 2 例: PM < 買い物ページが出来るだけ正しく素早く見られるようにしたい 1. 買い物ページ = ○○ APIと□□ APIが肝 2. 正しく = APIのレスポンスがHTTP Status 200 a. どこで測れるか？ = Load Balancerで測れる 3. 素早く = UXとしてギリギリ許容できるのは500ms a. どこで測れるか？ = Load Balancerで測れる 1. Availability: Load Balancerで計測して、○○ APIと□□ APIへのリクエストが正常な結 果(Status: 200, 300系, 400系) を返す 2. Latency: Load Balancerで計測して、○○ APIと□□APIがリクエストされてから 500ms 以内に返る 認識齟齬が起こらないように、簡潔に定義する

SLOを決める - 1 例: PM < 買い物ページが出来るだけ正しく素早く見られるようにしたい 1. 買い物ページ = ○○ APIと□□ APIが肝 2. 正しく = APIのレスポンスがHTTP Status 200 a. どこで測れるか？ = Load Balancerで測れる b. どれくらいの時間と割合か？ i. ○○ API = 1時間中99.9%が成功する ii. □□ API = 1時間中99.9%が成功する 3. 素早く = UXとしてギリギリ許容できるのは500ms a. どこで測れるか？ = Load Balancerで測れる b. どれくらいの時間と割合か？ i. ○○ API = 1時間中の平均200ms以内である ii. □□ API = 1時間中の平均300ms以内である

SLOを決める - 2 例: PM < 買い物ページが出来るだけ正しく素早く見られるようにしたい 1. 買い物ページ = ○○ APIと□□ APIが肝 2. 正しく = APIのレスポンスがHTTP Status 200 a. どこで測れるか？ = Load Balancerで測れる b. どれくらいの時間と割合か？ i. ○○ API = 1時間中99.9%が成功する ii. □□ API = 1時間中99.9%が成功する 3. 素早く = UXとしてギリギリ許容できるのは500ms a. どこで測れるか？ = Load Balancerで測れる b. どれくらいの時間と割合か？ i. ○○ API = 1時間中の平均200ms以内である ii. □□ API = 1時間中の平均300ms以内である 100%が理想ですが、100%を達成するためには膨大なお金と苦労が比例してかかります。(全コ ンポーネントの多重化、マルチクラウド対応、アラート即時対応のための24/365体制、…) 始めは99%のように小さくても良いので、取り敢えず定義してみて、振り返り(Post Mortem)の度 にSLI/SLOを再定義することが良い。

SLIとSLOを決める 1. Availability: 1時間、Load Balancerで計測して、○○ APIまたは□□ APIへのリクエ ストの内99.99%以上が正常な結果(Status: 200, 300系, 400系) を返す 2. Latency - 1: 1時間、Load Balancerで計測して、○○ APIがリクエストされてから平均 200ms 以内に返る 3. Latency - 2: 1時間、Load Balancerで計測して、□□ APIがリクエストされてから平均 300ms 以内に返る 買い物ページが出来るだけ正しく素早く見られるようにする 定義したSLI/SLOはPMが責任を持って管理する → 守りやすい指標だけが定義されずお客さま視点の開発が進む

Postmortem Monitoring

Postmortem SLI/SLOをベースにしたMonitoringの結果から得たインシデントを元に次に繋げ るための振り返りを行いますが、これをPost mortemと呼んでいる。 一般的な障害報告書とは異なり、内部の社員を対象にしており、PMにも必ず 出席してもらいエンジニアと共にインシデントから学びを得る。 「○○さんが」という批判・糾弾は行わないようにする。 (そもそも、そうならないような仕組みが必要です。例: 他者によるレビューが実 施されないと適用されない仕組み etc.)

Postmortem template SLI/SLO SLI/SLOを再掲して再認識してもらう Overview 1ヶ月間に起きたインシデントのサマリ What happened どういった事象が起きたか Resolution 解決または再発防止策をいつまでに実施するか Root causes 根本的な原因 User / Business Impact どのようなUXになってしまったか または離脱などによるBusiness Impactについて microservice Impact 別MicroserviceへのImpactについて Review SLI/SLO SLI/SLOを再考する Action Items (SREから)Monitoringの改善案などを提案する Any request to SRE? (SREに)インフラやツール等あったら嬉しい機能があればリクエストをもらう

Postmortem tool PagerDuty / Report

Postmortem tool PagerDuty / Postmortems PagerDutyでのIncidentとSlackでの会話を繋げたTimelineを 画面で作れるので、振り返りがしやすい　→

Error Budget Monitoring

Error Budget Error Budget(エラー予算)とはSLOとは逆の意味で「許容可能なエラー率」であ り、以下の式で計算される。 1 - uptime = error budget 例: SLO 99.9% 99.99% 99.999% Error Budget 0.1% 0.01% 0.001% Month 43.2 min 4.3 min 25.9 sec Quota 2.16 hour 13.0 min 77.8 sec

Merpayでは、PMが何をいつリリースするかを承認する権限を持っているため、 Error Budgetを使い果たした際には新規機能のリリースをブロックする権限も 持っている。 ● 今このタイミングでリリースして良いか？ ● テストに時間を割くべきか？ ● 冗長化などの信頼性を高める実装に時間を割くべきか？ ● … Error Budget

まとめ Monitoring

Merpayでは、1つのProductに対して縦軸・横軸に組織を展開し、様々な視点で Monitoringすることでユーザ体験を高めています。 まとめ 「Error Budgetの中でこのチャレンジ なDeployをさせてください」 というエンジニアの要望にNoが言え なくなった時が、組織として健全な SLI/SLOが設定できている証拠だと 思います。