Monitoring and SLI/SLO driven development @Merpay

Transcript

1. Merpay SRE @komattaka Monitoring -SLI/SLO Driven-
2. 2 自己紹介 Copyright © Merpay, Inc. All Rights Reserved. @komattaka SRE Team at Merpay
3. 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
4. Basic Information
5. Architecture Clients Merpay API Gateway API - 2 Service - 1 Service - 2 Service - 3 API - 1 CDN
6. 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. 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
8. Monitoring
9. Concept Monitoring
10. Concept of Monitoring
11. Monitoring Chaos Map Infrastructure Monitoring ※ 順不同 スタック毎に得手不得手があるので 1つのツールで全てを担当することは正解ではない Application Performance Monitoring Application Bug Tracking Analyzation External Monitoring Notification/Call
12. Application Performance Monitoring Monitoring Chaos Map Analyzation External Monitoring Infrastructure Monitoring Application Bug Tracking Notification/Call ※ 順不同 弊社での活用例(検証中含む)
13. Metrics Driven Development Monitoring
14. 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に影響が出る
15. Metrics Driven Development 3つの指標には相関関係がある 全てのモノ・人のEventはメトリクスに反映されるため、 常にモニタリングし改善を続けていくことが大事
16. SLI / SLO Monitoring
17. 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%以下である
18. SLIを決める - 1 "監視できるものは監視する"のではなく、 　SLIをUX / Customer Journeyから考える。 UX / Customer Journeyに責務を持つPMが主になって考え、エンジニアはそれを満 たすSLIを割り出していき、時には計測不能なSLIを計測するためのツールの選定も行 う。 SLIはCustomer Journeyに対して最大3つ程度が良い。 https://www.blastam.com/customer-journey
19. 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 以内に返る 認識齟齬が起こらないように、簡潔に定義する
20. 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以内である
21. 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を再定義することが良い。
22. 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が責任を持って管理する → 守りやすい指標だけが定義されずお客さま視点の開発が進む
23. Postmortem Monitoring
24. Postmortem SLI/SLOをベースにしたMonitoringの結果から得たインシデントを元に次に繋げ るための振り返りを行いますが、これをPost mortemと呼んでいる。 一般的な障害報告書とは異なり、内部の社員を対象にしており、PMにも必ず 出席してもらいエンジニアと共にインシデントから学びを得る。 「◦◦さんが」という批判・糾弾は行わないようにする。 (そもそも、そうならないような仕組みが必要です。例: 他者によるレビューが実 施されないと適用されない仕組み etc.)
25. 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に)インフラやツール等あったら嬉しい機能があればリクエストをもらう
26. Postmortem tool PagerDuty / Report
27. Postmortem tool PagerDuty / Postmortems PagerDutyでのIncidentとSlackでの会話を繋げたTimelineを 画面で作れるので、振り返りがしやすい　→
28. Error Budget Monitoring
29. 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
30. Merpayでは、PMが何をいつリリースするかを承認する権限を持っているため、 Error Budgetを使い果たした際には新規機能のリリースをブロックする権限も 持っている。 • 今このタイミングでリリースして良いか？ • テストに時間を割くべきか？ • 冗長化などの信頼性を高める実装に時間を割くべきか？ • … Error Budget
31. まとめ Monitoring
32. Merpayでは、1つのProductに対して縦軸・横軸に組織を展開し、様々な視点で Monitoringすることでユーザ体験を高めています。 まとめ 「Error Budgetの中でこのチャレンジ なDeployをさせてください」 というエンジニアの要望にNoが言え なくなった時が、組織として健全な SLI/SLOが設定できている証拠だと 思います。