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