Merpay Tech Fest 2021_メルペイにおけるSLOの活用事例 - 信頼性を定義しよう / Use case of SLOs in Merpay Let’s Define Reliability

Merpay Tech Fest 2021は5日間のオンライン技術カンファレンスです。

IT企業で働くソフトウェアエンジニアおよびメルペイの技術スタックに興味がある方々を対象に2021年7月26日（月）から7月30日（金）までの5日間、開催します。 Merpay Tech Festは事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りです。 セッションでは事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介予定です。お楽しみに！

■イベント関連情報
- 公式ウェブサイト：https://events.merpay.com/techfest-2021/
- 申し込みページ：https://mercari.connpass.com/event/215035/
- Twitterハッシュタグ： #MerpayTechFest

■リンク集
- メルカリ・メルペイイベント一覧：https://mercari.connpass.com/
- メルカリキャリアサイト：https://careers.mercari.com/
- メルカリエンジニアリングブログ：https://engineering.mercari.com/blog/
- メルカリエンジニア向けTwitterアカウント：https://twitter.com/mercaridevjp
- 株式会社メルペイ：https://jp.merpay.com/

Transcript

1. #MerpayTechFest Session Title メルペイにおけるSLOの活用事例 - 信頼性を定義しよう Kosuke Adachi Platform Engineering Div. SRE Team
2. #MerpayTechFest Platform Engineering Div. SRE Team Kosuke Adachi 2019年入社、サービスの品質を担保するための仕組みづくりや、 SLOを設定す るための基盤を開発。最近は SLOをベースにしたモニタリング周りの整備に取り 組んでいる。趣味はキーボードをつくること。
3. #MerpayTechFest 本日話すこと メルペイSREチーム SLI / SLO / Error Budget メルペイにおけるSLOの運用 活用事例: SLOアラート 02 03 04 01
4. #MerpayTechFest メルペイSREチーム
5. #MerpayTechFest メルペイSREチーム SRE = Site Reliability Engineering メルペイを安定して動かすために、インフラやマイクロサービス のリリースと運用などをエンジニアリングするチーム
6. #MerpayTechFest ミッション 当たり前のようにメルペイを使えるようにする メルペイを利用するお客さまにとって最も重要なことは「信頼性」 が高いこと メルペイは金融サービスなので高い信頼性が求められる → いつでも使えて当たり前 → お金が正しいのが当たり前
7. #MerpayTechFest メルペイに求められる信頼性とは いつでも使える高い可用性 素早いレスポンス性能 お金の計算の正確性 など
8. #MerpayTechFest サービス成長と信頼性のバランス サービス成長 信頼性 新機能、チャレンジ、変化 改善、対応、維持
9. #MerpayTechFest お客さまの期待値とサービスの信頼性 お客さま の体験 信頼性の目標 信頼性が低く 体験が悪い状態 参考: Shrinking the impact of production incidents using SRE principles—CRE Life Lessons 目標以上の信頼性を実現するに は高いコストと時間がかかる 信頼性 (&コスト) お客さまの期待値とコストとのバ ランスが取れている
10. #MerpayTechFest 信頼性の目標を決める SLO (Service Level Objective) 理想的なSLO = お客さまの期待値とコストとのバランスが 取れる目標 SLOを決める = 目指す信頼性を決めるだけでなく、 次のサービス成長へのチャンスを作る
11. #MerpayTechFest SLI / SLO / Error Budget
12. #MerpayTechFest SLI (Service Level Indicator) サービスの信頼性を測るための指標 お客さまの満足度を数値として計測可能なものを選ぶ 例: 可用性: 成功したリクエストの割合 レイテンシー: 100ms以内で完了したリクエストの割合
13. #MerpayTechFest SLI (Service Level Indicator) 可用性: 成功したリクエストの割合 Load Balancer Service A HTTP requests HTTP responses ログ収集 SLI = 200 OK リクエスト / リクエスト総数
14. #MerpayTechFest SLO (Service Level Objective) サービスの信頼性の目標値 SLIに対して期間と目標値(%)を設けたもの 例: 可用性: 成功したリクエストの割合が30日間で99.9% レイテンシー: 100ms以内で完了したリクエストの割合が7日間で99%
15. #MerpayTechFest SLO (Service Level Objective) Request-based SLO (Metric-based SLO) Window-based SLO (Monitor-based SLO) 参考 GCP: Concepts in service monitoring | Operations Suite Datadog: サービスレベル目標 成功したリクエストの割合が30日間で99.9% 100ms以内で完了したリクエストの割合が7日間で99% 正常に稼働している時間の割合が30日間で99.9% 99%ileが100ms以下である時間の割合が7日間で99%
16. #MerpayTechFest SLO (Service Level Objective) 可用性: 成功したリクエストの割合が30日間で99.9% SLI = 200 OK リクエスト / リクエスト総数 30日間計測 例: 100 rpsのエンドポイントの場合 リクエスト総数 = 100 * 60 * 60 * 24 * 30 = 259,200,000 SLO 99.9% = リクエスト総数 * 0.999 = 258,940,800 許容できる異常リクエスト = リクエスト総数 * (1-0.999) = 259,200
17. #MerpayTechFest Error Budget SLOに対して許容できる異常系の量 SLO: 成功したリクエストの割合が30日間で99.9% 100 rps のエンドポイントの場合 許容できる異常リクエスト = リクエスト総数 * (1-0.999) = 259,200 許容できる異常リクエスト = Error Budget = 259,200
18. #MerpayTechFest Error Budget SLO: 成功したリクエストの割合が30日間で99.9% どのぐらいで使い果たすか 100 rps のエンドポイントの場合 Error Budget = 259,200 例: デプロイミスでエラー率が100％になる → 2,592秒 = 43.2分 バグを仕込んでエラー率が1%になる → 259,200秒 = 3日
19. #MerpayTechFest メルペイにおける SLO の運用
20. #MerpayTechFest メルペイにおける SLO の運用の特徴 求められる高い信頼性に応える 50を超えるマイクロサービス 10を超えるプロダクト開発チーム これらを支えるSLO基盤とSLOダッシュボード
21. #MerpayTechFest Project GKE マイクロサービスアーキテクチャとSLO Load Balancer Google Kubernetes Engine API Gateway Authority API Service X API Service Y Service A Service B Service C Client
22. #MerpayTechFest Project GKE マイクロサービスアーキテクチャとSLO Load Balancer Google Kubernetes Engine API Gateway Authority API Service X API Service Y Service A Service B Service C Client Dev team A Dev team B Dev team C Dev team D
23. #MerpayTechFest Project GKE マイクロサービスアーキテクチャとSLO Load Balancer Google Kubernetes Engine API Gateway Authority API Service X API Service Y Service A Service B Service C Client Dev team A Dev team B Dev team C Dev team D 各開発チームが担当マイクロサービスのエン ドポイント毎にSLOを設定/運用している
24. #MerpayTechFest マイクロサービスとSLI Goアプリケーション内で独自のメトリクスを収集 Service A Service B gPRC grpc.UnaryInterceptor • go-microservices-kit.datadog.grpc.UnaryInterceptor Datadog custom metrics • mercari.grpc_server.handled.count • mercari.grpc_server.handled.duration SLIとして利用する情報を収集 ※ The Go gopher was designed by Renée French.
25. #MerpayTechFest マイクロサービスとSLO Service A serviceId: merpay-service-a teamName: merpay-dev-1 service_level: service_level_objectives: - definition: time_window: MONTHLY objective: "P99_99" request_availability: protocol: GRPC exclude_status_codes: - "not_found" - "invalid_argument" selector: - grpc_methods: 省略 - definition: time_window: MONTHLY objective: "P99_9" request_latency: protocol: HTTP threshold_ms: 200 percentile: "P99" selector: - http_services: 省略 Spec Microserviceに関する 情報をyamlで定義 成功したgPRCリクエストの 割合が30日間で99.99% HTTPリクエストの99%ileレ イテンシが200ms以下であ る時間の割合が30日間で 99.9%
26. #MerpayTechFest マイクロサービスとSLO SLI(Custom metrics) SLOダッシュボード 必要な監視用リソースを自動 で生成 Service A Spec
27. #MerpayTechFest SLOダッシュボード 信頼性が低下している = Error Budgetが低下していることが明 確にわかる 開発チームに限らず組織のメンバーが、サービス全体の信頼性の 低下に気づきやすくする ※ グラフは開発時のものです。実際のデータとは異なります サービス全体を確認するダッシュボード
28. #MerpayTechFest SLOダッシュボード 信頼性が低下している = Error Budgetが低下していることが明 確にわかる 開発チームに限らず組織のメンバーが、サービス全体の信頼性の 低下に気づきやすくする ※ グラフは開発時のものです。実際のデータとは異なります サービス単体を確認するダッシュボード
29. #MerpayTechFest SLOのメンテナンス 適切なSLOを設定することは難しい 定期的に見直して目標を調整することが重要 メルペイでは信頼性の定期チェック項目を用意 開発チームが定期的にSLOを見直す機会をつくっている
30. #MerpayTechFest メルペイにおける SLO の活用 SLO アラート
31. #MerpayTechFest 適切なアラートとはなにか お客さま影響のあるトラブルが発生した時にすぐ気付ける システム復旧や原因特定などのアクションがすぐ取れる O O トラブルが発生してからアラートまでの時間が長い 特にアクションする必要がないのにアラートが鳴っている X X
32. #MerpayTechFest アラートは鳴りすぎていないか あらゆるメトリクスに対してモニタリングしている CPU使用率 / メモリ使用率 / ネットワークI/O / LA etc… これらの数値を監視してアラートを鳴らす必要はあるか？ システムの状態を知るのに有力なメトリクスではあるが、必ずし もお客さまに影響が出るわけではない
33. #MerpayTechFest 不必要なアラートが多いとどうなるか オオカミ少年効果 / 割れ窓理論 アラート対応による疲弊 運用コストの増加 / 開発力の低下 お客さま影響がある場合のみアラートを鳴らして、不要な アラートを減らしたい
34. #MerpayTechFest SLOを基準としたアラート お客さま の体験 SLO SLOが達成できな いとお客さまの満足 度が下がる SLOが達成できるとお客さまの体 験が良い 信頼性 ここより下がる前にアラートを鳴ら して気付く必要がある 参考: Shrinking the impact of production incidents using SRE principles—CRE Life Lessons
35. #MerpayTechFest SLOを基準としたアラート お客さま の体験 SLO Error Budget が 枯渇している状態 Error Budgetが残っている状 態 信頼性 Error Budget が 0 の状態 参考: Shrinking the impact of production incidents using SRE principles—CRE Life Lessons
36. #MerpayTechFest SLOアラートの手法 Burn Rate に基づいたアラート SLO: 成功したリクエストの割合が30日間で99.9% Error Budgetの消費速度(Burn Rate)で考える 1時間でError Budgetの2％を消費したらアラート 例: 100 rps のエンドポイントの場合、Error Budget * 0.02 = 5,184 エラー を超えるとアラート
37. #MerpayTechFest SLOアラートの手法 Burn Rate に基づいたアラート 1時間でError Budgetの2％を消費したら(5,184エラーで)ア ラート エラー率100％の場合は、51.84秒でアラート エラー率1%の場合は、1時間で3,600エラーなのでアラートにはならない
38. #MerpayTechFest SLOアラートの手法 Multi-window, Multi-Burn-Rate アラート https://sre.google/workbook/alerting-on-slos/ 詳細はこちら 複数の計測期間、複数のBurn Rateを組み合わせた手法 単一のアラート設定の欠点を条件の異なる複数のアラート設定 を合わせることで補う
39. #MerpayTechFest SLOアラートの手法の選択 Terraform module で SLO アラートの手法を選択可能に Service A Spec Service B Spec slo-module monitor_type = { availability = { name= "multi-window-multi-burnrate" } }
40. #MerpayTechFest 低トラフィックに対するエラー率とアラート リクエストが少ないエンドポイントは1つのエラーでアラートが 鳴ってしまう場合がある SLO: 成功したリクエストの割合が30日間で99.9% SLOアラート: 5分間でError Budgetの2％を消費したらアラート 対象のエンドポイントの1分あたりのリクエスト数: 1 rpm Error Budget = 43.2 5分間で許容できるエラー数 = 43.2 * 2% = 0.864
41. #MerpayTechFest 低トラフィックに対するエラー率とアラート 低トラフィックなエンドポイントでも一定数のエラーが発生していたが、リ トライ処理などで自動復旧するためお客さま影響はなかった エラー率に関わらず、数件程度のエラーではアラートとしないように制 御した 深夜帯の不要なアラートがなくなり安眠できるようになった
42. #MerpayTechFest SLOアラートとPlaybook Playbook: 対象のエンドポイントに関する情報や一次対応方法などが示 されたドキュメント 影響範囲や対処方法を明確にして、復旧までの時間を短くする Service A Spec Playbook Dev teams/ Ops temas Playbook
43. #MerpayTechFest 本日話したこと メルペイにおけるSLOの活用事例 メルペイにおけるSLOの運用 / SLOアラート 信頼性を定義しよう 信頼性を可視化して改善のアクションをすぐ取れるように お客さま影響のあるインシデントが発生したらアラート