SRE Lounge #13 Service Level at Ubie

だいたい3ヶ月でサービスレベルを運用に乗せて「ちゃんとした」Webサービスにした話
https://sre-lounge.connpass.com/event/227250/ の発表資料です。

Transcript

1. だいたい3ヶ月でサービスレベルを運用に乗せて 「ちゃんとした」Webサービスにした話 2021-11-19 @itkq SRE Lounge #13
2. 2 - ID: itkq - 経歴：Cookpad → Ubie Discovery - 最近の業務領域：SRE業80%、その他20% (情シスorセキュリティ) - 興味：Load testing, Test in production About me 2
3. 3 - 話すこと - 短期間でサービスレベルを導入し運用するまでの事例 - 話さないこと - SRE、SLI/SLO自体 - チューニングなど技術的詳細。後日ブログに書く（予定） 発表内容 3
4. 4 目次 １．UbieとAI受診相談 ２．エイヤでサービスレベル ３．サービスレベル達成に向けた取り組み ４．そして運用へ ５．学びと今後 4
5. 5 About us (https://ubie.life)
6. 6 Ubieのサービス 6 生活者向け 医療機関向け 今日のテーマ
7. 7 ユビーAI受診相談 https://ubie.app 7
8. 8 300M+ MAU 8 https://prtimes.jp/main/html/rd/p/000000025.000048083.html 今日の話
9. 9 ホラクラシー組織 9 4 SREs 19 SWEs
10. 10 - 四半期毎にOKRをつくり、アライン。途中で変更もありうる OKR 10
11. 11 - Infra: Fastly, GKE, Istio - Frontend: Next.js - BFF: DGS (Kotlin, GraphQL) - APIs: Python, etc. AI受診相談のアーキテクチャ 11
12. 12 目次 １．UbieとAI受診相談 ２．エイヤでサービスレベル ３．サービスレベル達成に向けた取り組み ４．そして運用へ ５．学びと今後 12
13. 13 - これまで：ミッション達成のための1サービス - これから：ユビーが目指す世界の起点 - 1. リーチが拡大した（MAU急増、アプリリリースも） - 2. クリニックや製薬企業との提携 AI受診相談の転換 13
14. 14 - 信頼性観点では「ベストエフォート」 - toBに注力していたため - 今後も機能開発しながら信頼性を保ちスケールしなければならない - プロダクト基盤OKRに組み込まれる（全社OKRにも”SLO”が登場） - 社内外で、定性的に「遅い」「エラーが頻発」という声が上がる - 優先度を変更 当時のAI受診相談 14
15. 15 - エラーレートやレイテンシを定量的に算出してみる - Sentry荒野、本当の「エラーレート」がわからない、特定の画面が遅い - それを踏まえて「守らなければならない価値は何か?」 - SREsとプロダクトチームでディスカッション - 現状の認識と、あるべき姿が見えてきた - 同時にプロダクトチームの熱量も上がった AI受診相談を”診断” 15
16. 16 - 現状に対してどこまで改善するかの基準が必要 - 1. 症状チェック完走率99.5%（当時最低で98.2%） - 2. LP表示成功率99.9%（当時最低で99.2%） - 3. 症状チェック結果画面のレイテンシp90<=3s（当時最悪で15s） 議論をもとにエイヤで目標値を決める 16
17. 17 - 週次の全社共有会にて、現状やばいからなんとかするぜ！とやっていき宣言 - 「サービスレベルロール」が爆誕、SREsも参加 - 専用のSlackチャンネルを作成して関係者を突っ込み、臨戦態勢 やれることはすぐやる 17 New!!
18. 18 目次 １．UbieとAI受診相談 ２．エイヤでサービスレベル ３．サービスレベル達成に向けた取り組み ４．そして運用へ ５．学びと今後 18
19. 19 - プロダクトチーム - エラービューにログを仕込んで計測 - SREs - GraphQLサーバのオペレーションレベルでの観測 - レイテンシ分析 - Tracingを実用段階に 計測からはじめよ 19
20. 20 - イベントログと同様に計測 - Pub/Sub経由でBigQueryに投入 エラービューのログ 20
21. 21 計測！ 21
22. 22 計測！計測！計測！ 22
23. 23 - 数が多いエラーから原因究明して直したり、無視すべきエラーを分類 - トレース、ログ、メトリクスを見ながらレイテンシ悪化の原因を探る - 根本原因：graphql-javaのDataLoaderの使い方とDNS解決 - 改善されたらみんなで喜ぶ 🙌 あとは気合でがんばる 23
24. 24 結果、2ヶ月で達成 24 可用性：99.2% → 99.9% p90レイテンシ：15s → 2s
25. 25 目次 １．UbieとAI受診相談 ２．エイヤでサービスレベル ３．サービスレベル達成に向けた取り組み ４．そして運用へ ５．学びと今後 25
26. 26 - これまで出てきた「サービスレベル」!= SLI/SLO - 計測ウインドウや行動指針など含めきちんと定義し直す - BigQueryへのクエリだとリアルタイム性に乏しい - 扱いやすくするため、Prometheusメトリクスに 運用のためのSLI/SLO 26
27. 27 - 可用性：1ヶ月のウィンドウで`1 - (error_view / page_view)` >= 99.9% - レイテンシ：1ヶ月のウィンドウでバックエンドのp99 <= 1s - アラート：SRE本に基づく複数バーンレートアラートでSlack通知 - エラーバジェットが尽きた場合：信頼性向上アクション（開発は止めない） - サービスレベルロールでトリアージ シン・SLI/SLO 27
28. 28 Grafana dashboard powered by Sloth (sloth.dev) 28
29. 29 - 平日Slackにグラフを投稿 - ホラクラシーの定期MTGでチェック - Redashでエラー分析 - SLI/SLOの定期レビューは今後 定期的にSLI/SLOを確認する仕組み 29
30. 30 - 各環境リリース時にお手製E2Eテストで主導線チェック - 追加で保証したい導線はmablで実装 E2Eテストでリグレッション検知 30
31. 31 目次 １．UbieとAI受診相談 ２．エイヤでサービスレベル ３．サービスレベル達成に向けた取り組み ４．そして運用へ ５．学びと今後 31
32. 32 これまでのタイムライン 32 8月 10月 9月 OKR決定 目標値達成 SLO運用開始 優先度変更 8月 7月 プロジェクト 発足
33. 33 - 現状の分析結果をチームが自分ごととして問題意識、優先度の引き上げ - 専門ロールをつくり、SREsから2人がプロダクトチーム軸足に - ホラクラシー、OKRの移動、スクラムへの半参加 - そもそも、全員が全社観点を持ちサービスレベルの必要性を理解していた - 採用要件、PMFガイド、オンボーディングの効果 - 優先度やリソース割当の変更がスムーズ なぜ短期間でできたのか? 33
34. 34 - エラー・レイテンシへの疲弊が下がった - プロダクトチームが自分たちのサービスの信頼性を知れる状態に - 好例を示すことで他のサービスへの導入機運も高まった 導入の効果 34
35. 35 - 機能単位でのSLI/SLO・リトライを考慮したSLI - インシデントハンドリングフローの整備 w/ incident.io - 開発生産性の可視化と向上 - Production readiness checklist的な何か - 継続的な負荷試験 今後やりたいこと 35
36. 36 We are hiring! 36 recruit.ubie.life twitter.com/itkq or Thank you!