FlutterアプリにおけるSLI/SLOを用いたユーザー体験の可視化と計測基盤構築

概要SLI/SLOはSREでよく使われる概念ですが、モバイルアプリ開発にはまだ馴染みが薄いかもしれません。
私たちのプロダクトでは障害発生率が高く、早期の検知と解消が求められていました。
そこで、SLI/SLOの概念をモバイルアプリに適用し、ユーザー体験の低下を即時に検知する仕組みを構築しました。この仕組みにより、以下の指標をリアルタイムで監視し、即時に対応可能となりました：
•失敗率：一定以上のユーザーが機能利用時にエラーが発生したケース
•キャンセル率：一定以上のユーザーが機能利用時に何らかの理由でキャンセルしたケース
•中断率：一定以上のユーザーが機能利用時にアプリを強制終了したケース

現在、この監視システムは40以上の機能に適用されています。このセッションでは以下の内容について詳しく解説します：
1.SLI/SLOの基本概念
2.一般的なSLI/SLOとユーザー体験を検知するSLI/SLOの違い
3.ユーザー行動の計測方法
4.計測基盤の構築：工夫と課題
•時系列データのログ計測
•高オブザーバビリティの実現オプション
5.アラート基盤の構築：工夫と課題
•ノイズ最小化の方法
•チームにアラートを定着させる方法

想定視聴者
•Flutterアプリ内でのDartを用いた計測基盤構築に興味がある方

Transcript

1. FlutterKaigi 2024 長田 卓 馬 株式会社サイバーエージェント Flutterエンジニア Flutterアプリにおける SLI/SLOを 用 いたユーザー体験の可視化と 計測基盤構築
2. FlutterKaigi 2024 2 自 己 紹介 長田 卓 馬 (おさたく) 株式会社サイバーエージェント 21年度新卒 入 社 最近はWebを書いてます 趣味はワンピースカードです • GitHub ID: ostk 0 0 6 9 • X ID: ostk 0 0 6 9
3. FlutterKaigi 2024 3 本 日 のゴール ユーザー体験を可視化するSLI/SLOを理解し、 Flutterアプリで計測可能なモニタリングの世界を広げる 💪
4. FlutterKaigi 2024 4 AGENDA 1. ユーザー体験を可視化するSLI/SLOとは 2. なぜユーザー体験を可視化するSLI/SLOを作ったのか 3. ユーザー体験を可視化するSLI/SLOの事前準備 4. ユーザー体験を計測 ・ 監視基盤を構築する 5. ユーザー体験を可視化するSLI/SLOの運 用 と効果
5. FlutterKaigi 2024 5 AGENDA 本 日 140Pを超える資料を作成しております🔥
6. FlutterKaigi 2024 6 1. ユーザー体験を可視化する SLI/SLOとは 1. 一 般的なSLI/SLOとは 2. ユーザー体験を可視化するSLI/SLOとは
7. FlutterKaigi 2024 7 1.1. 一 般的なSLI/SLOとは 「SLI/SLO」という単語を聞いたことが ある 方 はいらっしゃいますか？ 🙋
8. FlutterKaigi 2024 8 1.1. 一 般的なSLI/SLOとは SLI（Service Level Indicator） 定量的に測定可能なユーザーの満 足 度の指標。 レスポンスタイム、エラーレート、ダウンタイムなどが例に挙げられる。 https://cloud.google.com/architecture/framework/reliability/slo-components
9. FlutterKaigi 2024 9 1.1. 一 般的なSLI/SLOとは SLI（Service Level Indicator） 定量的に測定可能なユーザーの満 足 度の指標。 レスポンスタイム、エラーレート、ダウンタイムなどが例に挙げられる。 SLO（Service Level Objectives） SLIが達成すべき 目 標。 例えば「99.9%のアップタイム」や「平均レスポンスタイムは◦ミリ秒以下」 などと設定される。 https://cloud.google.com/architecture/framework/reliability/slo-components
10. FlutterKaigi 2024 1 0 1.1. 一 般的なSLI/SLOとは SLI 定量的に測定可能なユーザーの満 足 度の指標。 レスポンスタイム、エラーレート、ダウンタイムなどが例に挙げられる。 SLO SLIが達成すべき 目 標。 例えば「99.9%のアップタイム」や「平均レスポンスタイムは◦ミリ秒以下」 などと設定される。 https://cloud.google.com/architecture/framework/reliability/slo-components?hl=ja わかるようなわからないような😅
11. FlutterKaigi 2024 1 1 1.1. 一 般的なSLI/SLOとは SLI 定量的に測定可能なユーザーの満 足 度の指標。 レスポンスタイム、エラーレート、ダウンタイムなどが例に挙げられる。 SLO SLIが達成すべき 目 標。 例えば「99.9%のアップタイム」や「平均レスポンスタイムは◦ミリ秒以下」 などと設定される。 https://cloud.google.com/architecture/framework/reliability/slo-components?hl=ja Flutter開発で馴染み深いものを 例に考えていきます💨
12. FlutterKaigi 2024 1 2 1.1. 一 般的なSLI/SLOとは クラッシュフリーユーザー率を 例に考える
13. FlutterKaigi 2024 1 3 1.1. 一 般的なSLI/SLOとは クラッシュフリーユーザー率 とある期間でクラッシュに遭遇しなかったユーザーの割合。 セッションで割ったものはクラッシュフリーセッション率も存在する。 https://docs.newrelic.com/docs/mobile-monitoring/mobile-monitoring-ui/mobile-app-pages/release-versions-page/#drill-down
14. FlutterKaigi 2024 1 4 1.1. 一 般的なSLI/SLOとは SLI 定量的に測定可能なユーザーの満 足 度の指標。 レスポンスタイム、エラーレート、ダウンタイムなどが例に挙げられる。 SLO SLIが達成すべき 目 標。 例えば「99.9%のアップタイム」や「平均レスポンスタイムは◦ミリ秒以下」 などと設定される。 https://cloud.google.com/architecture/framework/reliability/slo-components
15. FlutterKaigi 2024 1 5 1.1. 一 般的なSLI/SLOとは SLI 定量的に測定可能なユーザーの満 足 度の指標。 レスポンスタイム、エラーレート、ダウンタイムなどが例に挙げられる。 SLO SLIが達成すべき 目 標。 例えば「99.9%のアップタイム」や「平均レスポンスタイムは◦ミリ秒以下」 などと設定される。 https://cloud.google.com/architecture/framework/reliability/slo-components クラッシュフリーユーザー率
16. FlutterKaigi 2024 1 6 1.1. 一 般的なSLI/SLOとは SLI 定量的に測定可能なユーザーの満 足 度の指標。 レスポンスタイム、エラーレート、ダウンタイムなどが例に挙げられる。 SLO SLIが達成すべき 目 標。 例えば「99.9%のアップタイム」や「平均レスポンスタイムは◦ミリ秒以下」 などと設定される。 https://cloud.google.com/architecture/framework/reliability/slo-components クラッシュフリーユーザー率 24時間単位で99%を維持する
17. FlutterKaigi 2024 1 7 1.1. 一 般的なSLI/SLOとは SLI 定量的に測定可能なユーザーの満 足 度の指標。 レスポンスタイム、エラーレート、ダウンタイムなどが例に挙げられる。 SLO SLIが達成すべき 目 標。 例えば「99.9%のアップタイム」や「平均レスポンスタイムは◦ミリ秒以下」 などと設定される。 https://cloud.google.com/architecture/framework/reliability/slo-components クラッシュフリーユーザー率 24時間単位で99%を維持する 目 標値はチームや事業がどこまで維持したいかで調整可能
18. FlutterKaigi 2024 1 8 1.1. 一 般的なSLI/SLOとは SLIはどうやって決めるのか？
19. FlutterKaigi 2024 1 9 1.1. 一 般的なSLI/SLOとは ↓ CUJ SLIはどうやって決めるのか？
20. FlutterKaigi 2024 2 0 1.1. 一 般的なSLI/SLOとは CUJ（クリティカルユーザージャーニー） ユーザージャーニーとは、 人 々が 目 標を達成するために 行 う 一 連のタスクを指す。 対して、CUJは、多くの 目 標を達成するために共通するタスクや、 非 常に重要な 目 標を達成するために 行 う 一 連の流れを指す。 https://sre.google/workbook/implementing-slos/#modeling-user-journeys
21. FlutterKaigi 2024 2 1 1.1. 一 般的なSLI/SLOとは CUJ（クリティカルユーザージャーニー） ユーザージャーニーとは、 人 々が 目 標を達成するために 行 う 一 連のタスクを指す。 対して、CUJは、多くの 目 標を達成するために共通するタスクや、 非 常に重要な 目 標を達成するために 行 う 一 連の流れを指す。 ECを例に挙げると 製品を探す、カートに商品を追加する、購 入 を完了する あたりがCUJとして挙げられる可能性が 高 い。 https://sre.google/workbook/implementing-slos/#modeling-user-journeys
22. FlutterKaigi 2024 2 2 1.1. 一 般的なSLI/SLOとは CUJ（クリティカルユーザージャーニー） ユーザージャーニーとは、 人 々が 目 標を達成するために 行 う 一 連のタスクを指す。 対して、CUJは、多くの 目 標を達成するために共通するタスクや、 非 常に重要な 目 標を達成するために 行 う 一 連の流れを指す。 ECを例に挙げると 製品を探す、カートに商品を追加する、購 入 を完了する あたりがCUJとして挙げられる可能性が 高 い。 https://sre.google/workbook/implementing-slos/#modeling-user-journeys 最終的に SLO はユーザー体験を向上させることに重点を置く必要がある。 したがって、ユーザー中 心 のアクションの観点から SLO を作成する。
23. FlutterKaigi 2024 2 3 1.2. ユーザー体験を可視化するSLI/SLOとは 一 般的なSLI/SLOと「ユーザー体験を可視化するSLI/SLO」 の違いを 見 ていく👀
24. FlutterKaigi 2024 2 4 1.2. ユーザー体験を可視化するSLI/SLOとは SLI/SLOについて調べるとAPIリクエスト単位で計測しているものばかり。 自 分が調べた限りでは明確な背景がわからなかったが、 以下が理由であると推測。 • SRE領域がバックエンドやインフラから 生 まれた技術である • ユーザーの利 用 プラットフォームに関係なく、網羅的に計測可能である
25. FlutterKaigi 2024 2 5 1.2. ユーザー体験を可視化するSLI/SLOとは ユーザー体験を可視化するSLI/SLOとは 「機能の開始から完了までの 一 連のフロー」 を計測対象とすることである
26. FlutterKaigi 2024 2 6 1.2. ユーザー体験を可視化するSLI/SLOとは ※ これは開発環境で機能を利 用 したものです WINTICKETのSMSログイン機能を例に考える → → →
27. FlutterKaigi 2024 → → → 2 7 1.2. ユーザー体験を可視化するSLI/SLOとは ボタンタップ時に計測開始 ログイン完了時に計測終了 「成功」として計測する WINTICKETのSMSログイン機能を例に考える ※ これは開発環境で機能を利 用 したものです
28. FlutterKaigi 2024 2 8 1.2. ユーザー体験を可視化するSLI/SLOとは ※ これは開発環境で機能を利 用 したものです システム起因、ユーザー起因問わずで エラーが発 生 した場合は「エラー」として計測 WINTICKETのSMSログイン機能を例に考える → →
29. FlutterKaigi 2024 2 9 1.2. ユーザー体験を可視化するSLI/SLOとは 機能の利 用 をキャンセルする場合は 「キャンセル」として計測 ※ アプリキルの場合は「中断」として計測 ※ これは開発環境で機能を利 用 したものです WINTICKETのSMSログイン機能を例に考える → →
30. FlutterKaigi 2024 3 0 メリット • キャンセルや中断率など計測する ユーザー体験の範囲を拡張可能 • Flutterの場合はワンソースで 計測処理をiOS/Androidに適 用 できる 1.2. ユーザー体験を可視化するSLI/SLOとは
31. FlutterKaigi 2024 3 1 メリット デメリット • 計測の範囲が広がることで考慮する ケースが増え、複雑になる • ユーザー起因のノイズが発 生 する 1.2. ユーザー体験を可視化するSLI/SLOとは • キャンセルや中断率など計測する ユーザー体験の範囲を拡張可能 • Flutterの場合はワンソースで 計測処理をiOS/Androidに適 用 できる
32. FlutterKaigi 2024 3 2 1.2. ユーザー体験を可視化するSLI/SLOとは 測定対象 システム起因のエラーを測定対象とするか ユーザー起因のエラーを測定対象とするか ユーザー体験を可視化する SLI/SLO SLI/SLO ❌ ✅ APIのリクエスト 機能の 一 連のフロー ✅ ✅ 領域 バックエンド クライアント 計測の埋め込みの容易さ ✅ ❌ まとめるとそれぞれにメリデメがあることがわかる
33. FlutterKaigi 2024 3 3 2. なぜユーザー体験を可視化する SLI/SLOを作ったのか 1. 可 用 性の向上を 目 指す 2. 平均復旧時間の改善を 目 指す
34. FlutterKaigi 2024 3 4 2.1. 可 用 性の向上を 目 指す 可 用 性
35. FlutterKaigi 2024 3 5 2.1. 可 用 性の向上を 目 指す 可 用 性とは... 可 用 性 (%) = 稼働時間 / (停 止 時間 + 稼働時間) 停 止 時間 (h) = 平均修復時間* x 3 6 5 日 x 2 4 時間 / 平均故障間隔* 平均修復時間 = 停 止 時間の合計 / 失敗の回数 平均故障間隔 = 稼働時間の合計 / 失敗の回数
36. FlutterKaigi 2024 3 6 2.1. 可 用 性の向上を 目 指す ユーザー体験において、以下の事象は体験を損ねている ・ 実装時のデグレ ・ 連携サービスの不具合(Firebase、決済サービス、銀 行 連携など) ・ キャンペーンなどの誤った情報の 入 稿ミス
37. FlutterKaigi 2024 3 7 2.1. 可 用 性の向上を 目 指す 2022 年の状況 • 変更障害率: 7.5 % （3/40） • 平均停 止 時間: 4.0 日 • 可 用 性: 96.8 %
38. FlutterKaigi 2024 3 8 2.1. 可 用 性の向上を 目 指す 2022 年の状況 • 変更障害率: 7.5 % （3/40） • 平均停 止 時間: 4.0 日 • 可 用 性: 96.8 % 2023 年以降の 目 標 • 変更障害率: 5 % • 平均停 止 時間: 3.0 日 • 可 用 性: 98.4 % →
39. FlutterKaigi 2024 3 9 2.1. 可 用 性の向上を 目 指す 目 標を達成するために
40. FlutterKaigi 2024 目 標を達成するために 4 0 2.1. 可 用 性の向上を 目 指す 📈 平均障害率を下げる • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する
41. FlutterKaigi 2024 4 1 2.1. 可 用 性の向上を 目 指す 目 標を達成するために 📈 平均障害率を下げる 🕐 平均修復時間を下げる • リリース後に不具合を早期に検知したい • 既存のモニタリング体制の 見 直しを実施する • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する
42. FlutterKaigi 2024 4 2 2.1. 可 用 性の向上を 目 指す 目 標を達成するために 📈 平均障害率を下げる 🕐 平均修復時間を下げる • リリース後に不具合を早期に検知したい • 既存のモニタリング体制の 見 直しを実施する • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する 本セッションではこちらはスキップ
43. FlutterKaigi 2024 4 3 2.1. 可 用 性の向上を 目 指す 目 標を達成するために 📈 平均障害率を下げる 🕐 平均修復時間を下げる • リリース後に不具合を早期に検知したい • 既存のモニタリング体制の 見 直しを実施する • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する 本セッションではこちらはスキップ FlutterKaigi 2 0 2 3 での登壇が YouTubeにアップロードされています https://www.youtube.com/watch?v=VHhZlTDfwIQ&ab_channel=FlutterKaigi
44. FlutterKaigi 2024 4 4 2.1. 可 用 性の向上を 目 指す 目 標を達成するために 📈 平均障害率を下げる 🕐 平均修復時間を下げる • リリース後に不具合を早期に検知したい • 既存のモニタリング体制の 見 直しを実施する • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する 本セッションではこちらはスキップ WINTICKETのアプリチームの技術戦略やこれまでに興味がある 方 は ぜひこちらも視聴いただけると嬉しいです https://www.youtube.com/watch?v=mzxKTsNmSBc&ab_channel=CyberAgentDevelopers
45. FlutterKaigi 2024 4 5 2.2. 平均復旧時間の改善を 目 指す 私のチームでデグレに気づく 手 段は以下になります • エラー監視ツールによる検知（エラー、クラッシュ、ANR） • ユーザーからの問い合わせ • メンバーからの連絡 • SNSでのエゴサーチ
46. FlutterKaigi 2024 それぞれの検知 方 法の特性 4 6 2.2. 平均復旧時間の改善を 目 指す 検知速度 検知範囲 エスカレーション 検知領域 ユーザーの問い合わせ Sentry メンバーからの連絡 エゴサーチ 既知の未知 速い 遅い ~ 中 中 すべて 遅い 遅い 中 小 小 ✅ △ ✅ ❌ すべて すべて
47. FlutterKaigi 2024 それぞれの検知 方 法の特性 4 7 2.2. 平均復旧時間の改善を 目 指す 検知速度 検知範囲 エスカレーション 検知領域 速い 中 すべて 中 ✅ ✅ ❌ すべて すべて Sentryだと検知が速いが、 「既知の未知」の領域しか拾うことができない ユーザーの問い合わせ Sentry メンバーからの連絡 エゴサーチ 既知の未知 遅い ~ 中 遅い 遅い 小 小 △
48. FlutterKaigi 2024 それぞれの検知 方 法の特性 4 8 2.2. 平均復旧時間の改善を 目 指す 検知速度 検知範囲 エスカレーション 検知領域 速い 中 すべて 中 ✅ ✅ ❌ すべて すべて 他の3つは未知の未知にも気づくことができるが、 検知速度が 十 分ではなく、平均修復時間が伸びしてしまう ユーザーの問い合わせ Sentry メンバーからの連絡 エゴサーチ 既知の未知 遅い ~ 中 遅い 遅い 小 小 △
49. FlutterKaigi 2024 4 9 2.2. 平均復旧時間の改善を 目 指す SLI/SLOはこれを検知可能にするのでは🧐
50. FlutterKaigi 2024 5 0 2.2. 平均復旧時間の改善を 目 指す 実際にFlutterアプリでSentryで検知できなかった障害の 一 覧( 一 部抜粋) • ライブ映像が読み込まれず、エラーになってしまう • Android 1 4 でWebView利 用 時にバックグラウンドから復帰すると真っ 白 になる • クレジットカード決済で 一 部のユーザーがエラーになってしまう • SMS認証で 一 部のユーザーがフリーズしてしまう
51. FlutterKaigi 2024 5 1 2.2. 平均復旧時間の改善を 目 指す すべてではないが、SLI/SLOによってこれらの 障害は検知することが可能になる。 実際にFlutterアプリでSentryで検知できなかった障害の 一 覧( 一 部抜粋) • ライブ映像が読み込まれず、エラーになってしまう • Android 1 4 でWebView利 用 時にバックグラウンドから復帰すると真っ 白 になる • クレジットカード決済で 一 部のユーザーがエラーになってしまう • SMS認証で 一 部のユーザーがフリーズしてしまう
52. FlutterKaigi 2024 それぞれの検知 方 法の特性 5 2 2.2. 平均復旧時間の改善を 目 指す 検知速度 検知範囲 エスカレーション 検知領域 ユーザーの問い合わせ Sentry メンバーからの連絡 既知の未知 速い 遅い ~ 中 中 すべて 遅い 遅い 中 小 小 ✅ ✅ ❌ すべて すべて SLI/SLO 速い 中 ✅ すべて ※機能のフロー中に限る SLI/SLOは計測対象の中であれば未知の未知 の問題も検知可能。アラート機能を作成すれば エスカレーションも 自 動で可能になる。 エゴサーチ △
53. FlutterKaigi 2024 5 3 2.2. 平均復旧時間の改善を 目 指す 2つのアプローチで平均修復時間を削減する
54. FlutterKaigi 2024 5 4 🚨アラート機能 2.2. 平均復旧時間の改善を 目 指す • アラート機能を作成することで 平均検出時間(MTTD)を削減する • 最新バージョンに絞ったアラートを作成し、 リリースによるデグレを検知する 2つのアプローチで平均修復時間を削減する
55. FlutterKaigi 2024 5 5 2.2. 平均復旧時間の改善を 目 指す 🚨アラート機能 • アラート機能を作成することで 平均検出時間(MTTD)を削減する • 最新バージョンに絞ったアラートを作成し、 リリースによるデグレを検知する 2つのアプローチで平均修復時間を削減する ⛰ 高 いオブザーバビリティ • 原因分析につながる情報を多く付与することで 平均調査時間(MTTI)を削減する
56. FlutterKaigi 2024 5 6 2.2. 平均復旧時間の改善を 目 指す 具体的な導 入方 法を説明していく🚀
57. FlutterKaigi 2024 5 7 3. ユーザー体験を可視化するSLI/SLO の事前準備 1. 知識のインプットをする 2 . CUJを定義し、ビジネスチームとすり合わせる 3. ツールを選定を 行 う
58. FlutterKaigi 2024 5 8 3.1. 知識のインプットをする 自 分もチームもSLI/SLOには詳しくありませんでした。 そのために調査と並 行 して輪読会の実施を 行 いました。 https://www.oreilly.com/library/view/observability-engineering/ 9 7 8 1 4 9 2 0 7 6 4 3 8 /
59. FlutterKaigi 2024 5 9 3.1. 知識のインプットをする 自 分もチームもSLI/SLOには詳しくありませんでした。 そのために調査と並 行 して輪読会の実施を 行 いました。 結果的に輪読会を 行 う上で、知識をつけるいい機会になったのはも ちろんなんですが、「この本に書いてあったアレだよね」「あの本 に書いてあった〇〇はいいんだっけ？」みたいなコミュニケーショ ンが取れたのが 非 常に良かったです。 https://www.oreilly.com/library/view/observability-engineering/ 9 7 8 1 4 9 2 0 7 6 4 3 8 /
60. FlutterKaigi 2024 6 0 3 . 2 . CUJを定義し、ビジネスチームとすり合わせる CUJをビジネスチームと確認し、その中でも優先度を付ける 👤認証 🚴投票 🏦 精算 💰チャージ 🎬 動画 🎬 ライブ映像 📈 分析 🎉 キャンペーン 🎉 予想閲覧 ✉ メッセージ 🔧 設定 📄 履歴確認 🔍 検索 📅 スケジュール
61. FlutterKaigi 2024 6 1 3 . 2 . CUJを定義し、ビジネスチームとすり合わせる CUJをビジネスチームと確認し、その中でも優先度を付ける ユーザーがサービスを利 用 する 目 的は「競輪 ・ オートレースに投票してギャンブルを楽しむこと」であるこ とから以下の機能に絞りました。 👤認証 📅 スケジュール 🚴投票 🏦 精算 💰チャージ 🎬 動画 🎬 ライブ映像 📈 分析 🎉 キャンペーン 🎉 予想閲覧 ✉ メッセージ 🔧 設定 📄 履歴確認 🔍 検索
62. FlutterKaigi 2024 6 2 3.3. ツールを選定を 行 う 🧠 Sentry etc … Big Query New Relic DataDog SLI/SLOを計測 ・ アラートするツールはたくさん存在する
63. FlutterKaigi 2024 6 3 🧠 Sentry etc … Big Query New Relic DataDog 私のチームではSentryを採 用 SLI/SLOを計測 ・ アラートするツールはたくさん存在する 3.3. ツールを選定を 行 う
64. FlutterKaigi 2024 6 4 Sentryを採 用 した理由 ✅ すでにエラーの監視にSentryを利 用 していたので扱いに慣れている ✅ エラーの監視とSLI/SLOの計測を1ツールで完結できる ✅ SDKの開発が 非 常に活発で今後も 高 いメンテナンスが期待できる 3.3. ツールを選定を 行 う
65. FlutterKaigi 2024 6 5 Sentryを採 用 した理由 ✅ すでにエラーの監視にSentryを利 用 していたので扱いに慣れている ✅ エラーの監視とSLI/SLOの計測を1ツールで完結できる ✅ SDKの開発が 非 常に活発で今後も 高 いメンテナンスが期待できる 満たせていない要件 ❌ アラート機能がカスタマイズ性が今回の要件では不 十 分 3.3. ツールを選定を 行 う
66. FlutterKaigi 2024 6 6 Sentryを採 用 した理由 ✅ すでにエラーの監視にSentryを利 用 していたので扱いに慣れている ✅ エラーの監視とSLI/SLOの計測を1ツールで完結できる ✅ SDKの開発が 非 常に活発で今後も 高 いメンテナンスが期待できる 満たせていない要件 ❌ アラート機能がカスタマイズ性が今回の要件では不 十 分 → 自 作する 3.3. ツールを選定を 行 う
67. FlutterKaigi 2024 6 7 計測ツールが決まったら 計測したい箇所への埋め込みが必要⛏ 3.3. ツールを選定を 行 う
68. FlutterKaigi 2024 6 8 4. ユーザー体験を計測 ・ 監視基盤を 構築する 1. 計測基盤の全体像 2. 計測基盤を作る上で 工 夫した点 3 . SREのアラートのベストプラクティスの紹介 4. 作成したアラート基盤の全体像
69. FlutterKaigi 2024 6 9 アプリケーション 計測開始タイミングを送信 計測終了タイミングを送信 まずは満たすべき仕様を紹介していきます 4.1. 計測基盤の全体像
70. FlutterKaigi 2024 7 0 計測開始タイミングを送信 計測終了タイミングを送信 まずは満たすべき仕様を紹介していきます 通常のログとは異なり、開始タイミングと終了タイミング の 二 つのログ(=トランザクション)が揃っている必要がある 4.1. 計測基盤の全体像 アプリケーション
71. FlutterKaigi 2024 7 1 アプリケーション 端末の情報を送信したい 様々な追加要件を紹介していきます 画 面 遷移時に付随したログを付与したい ※ ユーザーのプライバシーを侵害しないもの APIリクエストに付随したログを付与したい ローカルデータに付随したログを付与したい etc … 開始終了だけでなく、分析をしやすくするために、 計測途中で様々な付随データを送りたい 4.1. 計測基盤の全体像 アプリケーション
72. FlutterKaigi 2024 7 2 計測開始タイミングを送信 計測終了タイミングを送信 アプリケーション 様々な追加要件を紹介していきます UI State UseCase Data 様々なアーキテクチャレイヤーから送信処理を 行 う 送信タイミングはボタンのonPressedの場合もあれば、 APIのリクエストを受け取ったタイミングなど様々 4.1. 計測基盤の全体像
73. FlutterKaigi 2024 7 3 計測開始タイミングを送信 アプリケーション 様々な追加要件を紹介していきます UI State UseCase Data 計測開始したにも関わらず、計測開始が実 行 された場合 も前のトランザクションをを終了させて計測を開始する eg: 開始タイミングでのダブルタップなど ❌ 4.1. 計測基盤の全体像
74. FlutterKaigi 2024 7 4 アプリケーション 様々な追加要件を紹介していきます 計測はユーザー体験を損ねないように 行 いたい 送信時にasync/awaitをつけずに実 行 したい ❌ async/await 4.1. 計測基盤の全体像
75. FlutterKaigi 2024 7 5 まとめると • 開始 ~ 終了を時系列を維持して送信したい • 途中で付随した情報も送れるようにしたい • 送信処理の周辺には機能の実 行 コードがあるのでasync/awaitは使わない 4.1. 計測基盤の全体像
76. FlutterKaigi 2024 7 6 中継するObserverを 用 意し、時系列を担保する 計測開始タイミングを送信 計測終了タイミングを送信 追加で送りたい情報を送信(複数) 4.1. 計測基盤の全体像 アプリケーション
77. FlutterKaigi 2024 7 7 中継するObserverを 用 意し、時系列を担保する await startEvent() await endEvent() await addOption() 4.1. 計測基盤の全体像 アプリケーション
78. FlutterKaigi 2024 7 8 アプリケーション 中継するObserverを 用 意し、時系列を担保する Stream Controller AsyncMap startEvent() addOption() endOption() await startEvent() await addOption() await endOption() ↓ ↓ 4.1. 計測基盤の全体像
79. FlutterKaigi 2024 7 9 付随するデータを埋め込む • APIリクエスト • 画 面 遷移 • Preferenceの追加/編集/消去イベント 4.1. 計測基盤の全体像
80. FlutterKaigi 2024 8 0 付随するデータを埋め込む - APIリクエスト Dioを通信処理を実 行 するpackage として採 用 しており、 Interceptorsを使い、onRequest、 onResponse、onErrorを購読可能に https://pub.dev/packages/dio#interceptors 4.1. 計測基盤の全体像
81. FlutterKaigi 2024 8 1 付随するデータを埋め込む - 画 面 遷移 auto_route を画 面 遷移のpackage として採 用 しており、 Observerを使い、 didPush購読可能に https://pub.dev/packages/auto_route#navigation-observers 4.1. 計測基盤の全体像
82. FlutterKaigi 2024 8 2 最終的にSentry上で計測結果を確認する 4.1. 計測基盤の全体像
83. FlutterKaigi 2024 8 3 https://docs.sentry.io/product/performance/ 4.1. 計測基盤の全体像 ※ これは開発環境で機能を利 用 したものです
84. FlutterKaigi 2024 8 4 https://docs.sentry.io/product/performance/ 画 面 遷移を可視化 4.1. 計測基盤の全体像 ※ これは開発環境で機能を利 用 したものです
85. FlutterKaigi 2024 8 5 https://docs.sentry.io/product/performance/ APIリクエストを可視化 4.1. 計測基盤の全体像 ※ これは開発環境で機能を利 用 したものです
86. FlutterKaigi 2024 8 6 https://docs.sentry.io/product/performance/ Preferenceの更新イベントを可視化 4.1. 計測基盤の全体像 ※ これは開発環境で機能を利 用 したものです
87. FlutterKaigi 2024 8 7 サンプルレポジトリを公開しています 4.1. 計測基盤の全体像
88. FlutterKaigi 2024 8 8 計測基盤を作る上で 工 夫した点
89. FlutterKaigi 2024 8 9 4.2. 計測基盤を作る上で 工 夫した点 以下の3つを紹介します 1. 高 いオブザーバビリティを実現する 2. 中断率を計測する 3. サンプリングを 行 う
90. FlutterKaigi 2024 9 0 4.2. 計測基盤を作る上で 工 夫した点 高 いオブザーバビリティを実現する
91. FlutterKaigi 2024 9 1 3.5. 高 いオブザーバビリティを実現する アラートを検知した後、偽陽性かどうか含め、状況把握できるように プライバシーポリシーに違反しない形で追加する • ユーザーの端末やOS • 端末の性能(High, Medium, Low) • アプリバージョン • 最後どこの画 面 を表 示 していたか • 通信状態 • etc …
92. FlutterKaigi 2024 9 2 4.2. 計測基盤を作る上で 工 夫した点 中断率の計測の仕組みを実現する
93. FlutterKaigi 2024 9 3 4.2. 計測基盤を作る上で 工 夫した点 中断率 … ユーザーが機能を利 用 途中でアプリのクラッシュやアプリキルを 実施した件数の割合 ユーザーが機能を利 用 し始めた段階でLocal Databaseに値を保存して、 機能を利 用 した段階で破棄する。 アプリ起動時に破棄されていないものが存在した場合、 それは中断したものと判定する。
94. FlutterKaigi 2024 9 4 懸念点 • アプリを再度 立 ち上げずに離脱したユーザーのデータが送られない • LocalDatabaseではなく、Preferenceだとダメなのか 4.2. 計測基盤を作る上で 工 夫した点
95. FlutterKaigi 2024 9 5 懸念点 • アプリを再度 立 ち上げずに離脱したユーザーのデータが送られない • LocalDatabaseではなく、Preferenceだとダメなのか → 障害を検知できれば全てのユーザーのデータを計測する必要はないため、 送信できることが保証できる今回の 方 針で 行 くこととした → Shared PreferenceやSecure Preferenceは単 一 テーブルなので 機能側でもローカルデータを更新したい場合、 コンフリクトが起きる可能性がある 4.2. 計測基盤を作る上で 工 夫した点
96. FlutterKaigi 2024 9 6 4.2. 計測基盤を作る上で 工 夫した点 サンプリングを 行 う
97. FlutterKaigi 2024 9 7 4.2. 計測基盤を作る上で 工 夫した点 Sentryのperformance機能を利 用 して計測をしています。 計測するイベント数に応じて料 金 が発 生 するため、本番環境では注意が必要です。 https://docs.sentry.io/product/performance/
98. FlutterKaigi 2024 9 8 4.2. 計測基盤を作る上で 工 夫した点 Sentryはサンプリング機能を提供しています。 以下のように全てのPerformance計測に対してサンプリングをすることができます。 https://docs.sentry.io/platforms/ fl utter/con fi guration/sampling/
99. FlutterKaigi 2024 9 9 4.2. 計測基盤を作る上で 工 夫した点 以下のようにcallback内で分岐をさせる ことで機能別にサンプリングレートを 調整することが可能です。 私のチームではこれを機能単位で リモート管理しています。 https://docs.sentry.io/platforms/ fl utter/con fi guration/sampling/
100. FlutterKaigi 2024 1 0 0 SREのアラートの ベストプラクティスの紹介
101. FlutterKaigi 2024 1 0 1 SLI/SLOで利 用 するアラートは主に2つあります • エラーバジェットアラート • バーンレートアラート 4 . 3 . SREのアラートのベストプラクティスの紹介
102. FlutterKaigi 2024 1 0 2 エラーバジェットアラート https://docs.datadoghq.com/ja/service_management/service_level_objectives/error_budget/ エラーバジェットアラートは閾値に基づき、SLO のエラーバジェットの 一 定の割合が 消費されたときに通知する。たとえば、対象とする期間でエラーバジェットの 75% が消費されたらアラート、50% が消費されたら警告のように設定する。 4 . 3 . SREのアラートのベストプラクティスの紹介
103. FlutterKaigi 2024 4 . 3 . SREのアラートのベストプラクティスの紹介 1 0 3 エラーバジェットアラート https://docs.datadoghq.com/ja/service_management/service_level_objectives/error_budget/ エラーバジェットアラートは閾値に基づき、SLO のエラーバジェットの 一 定の割合が 消費されなかったときに通知する。たとえば、対象とする期間でエラーバジェットの 75% が消費されたらアラート、50% が消費されたら警告のように設定する。 エラーバジェット？
104. FlutterKaigi 2024 1 0 4 エラーバジェット https://docs.datadoghq.com/ja/service_management/service_level_objectives/error_budget/ サービスの信頼性がどの程度損なわれても許容できるかを 示 す指標。 サービスレベル 目 標（SLO）が「99.99%」のリクエスト応答率を維持することである場合、 エラーバジェットは、エラー応答率を「0.01%」以下に抑えることになる。 4 . 3 . SREのアラートのベストプラクティスの紹介
105. FlutterKaigi 2024 1 0 5 バーンレートアラート https://docs.datadoghq.com/ja/service_management/service_level_objectives/burn_rate/ エラーバジェットの消費率が指定した閾値を超え、それが特定の期間継続した場合に 通知される。たとえば、SLO の 7 日 間 目 標に対して、過去 5 分間で過去 1 時間に 16.8 以上のバーンレートが測定された場合にアラートを設定できる。 4 . 3 . SREのアラートのベストプラクティスの紹介
106. FlutterKaigi 2024 1 0 6 バーンレートアラート https://docs.datadoghq.com/ja/service_management/service_level_objectives/burn_rate/ エラーバジェットの消費率が指定した閾値を超え、それが特定の期間継続した場合に 通知される。たとえば、SLO の 7 日 間 目 標に対して、過去 5 分間で過去 1 時間に 16.8 以上のバーンレートが測定された場合にアラートを設定できる。 = 1時間*100% 7 日 *24時間*10%消費したエラーバジェット = 7 * 2 4 * 0 . 1 1 1 6 . 8 4 . 3 . SREのアラートのベストプラクティスの紹介
107. FlutterKaigi 2024 1 0 7 バーンレートアラート https://docs.datadoghq.com/ja/service_management/service_level_objectives/burn_rate/ エラーバジェットの消費率が指定した閾値を超え、それが特定の期間継続した場合に 通知される。たとえば、SLO の 7 日 間 目 標に対して、過去 5 分間で過去 1 時間に 16.8 以上のバーンレートが測定された場合にアラートを設定できる。 = 1時間*100% 7 日 *24時間*10%消費したエラーバジェット = 7 * 2 4 * 0 . 1 1 1 6 . 8 4 . 3 . SREのアラートのベストプラクティスの紹介 難しいので詳細は省きます 詳しく聞きたい 方 は ask the speakerまで
108. FlutterKaigi 2024 1 0 8 バーンレートアラート https://docs.datadoghq.com/ja/service_management/service_level_objectives/burn_rate/ バーンレートアラートによって多くのデグレに気付けることが可能。 しかし、ユーザー体験を可視化するSLI/SLOにおいては以下の問題がある。 ❌ ユーザー起因のエラーやキャンセルはタイミングによってブレが 大 きい ❌ 深夜や早朝などセッションが下がるタイミングで 一人 のユーザーの 行 動が アラートに 大 きく影響する 4 . 3 . SREのアラートのベストプラクティスの紹介
109. FlutterKaigi 2024 1 0 9 4.4. 作成したアラート基盤の全体像 アラート基盤の構成です 実装コストの観点からDartではなく、Cloud Functionsを 用 いてNode.js開発しています。
110. FlutterKaigi 2024 1 1 0 アラートのステータスは3つあり、2分おきのcron jobが現在時刻のデータと2分前のデータを元に品質の 低下を検知することでアラートするかどうかを判断します 4.4. 作成したアラート基盤の全体像
111. FlutterKaigi 2024 1 1 1 アラートのステータスは3つあり、2分おきのcron jobが現在時刻のデータと2分前のデータを元に品質の 低下を検知することでアラートするかどうかを判断します 定義したレートを上回るとエラー判定される シンプルな仕組み 4.4. 作成したアラート基盤の全体像
112. FlutterKaigi 2024 1 1 2 アラートのステータスは3つあり、2分おきのcron jobが現在時刻のデータと2分前のデータを元に品質の 低下を検知することでアラートするかどうかを判断します レートだけだとそもそもユーザーが頻繁に機能を 利 用 しない、利 用 者が少ない時間帯だと 偽陽性のアラートが発 生 する。 問題に気付けないリスクも伴うが、 アラートを鳴らすための最低件数を定義 定義したレートを上回るとエラー判定される シンプルな仕組み 4.4. 作成したアラート基盤の全体像
113. FlutterKaigi 2024 1 1 3 作成したアラート https://docs.datadoghq.com/ja/service_management/service_level_objectives/burn_rate/ 機能名 1時間単位で20%、30% 超えたら ※ Sentryに備わっているアラート機能ではなく、Sentryの計測データをもとに 自 作したもの Warningのアラートは10件、 Criticalのアラートは15件以上必要 4.4. 作成したアラート基盤の全体像
114. FlutterKaigi 2024 1 1 4 4.4. 作成したアラート基盤の全体像 SLI/SLOでは400系エラーをアラートの計測対象に含めないことが 一 般的です。 しかし、ユーザー体験を可視化する上で、400系のエラーや、 そもそもエラーになる前に機能の利 用 をやめたケースを計測してこそ、 価値があるものになります。
115. FlutterKaigi 2024 1 1 5 4.4. 作成したアラート基盤の全体像 SLI/SLOでは400系エラーをアラートの計測対象に含めないことが 一 般的です。 しかし、ユーザー体験を可視化する上で、400系のエラーや、 そもそもエラーになる前に機能の利 用 をやめたケースを計測してこそ、 価値があるものになります。 バーンレートアラートだとそこを前提に設計されていないことから、 ユーザー体験を可視化するSLI/SLOだと偽陽性、偽陰性のアラートが 多く発 生 してしまうリスクがあります。
116. FlutterKaigi 2024 1 . SLI/SLOをチーム ・ 事業に定着させる 2 . SLI/SLOを別の形で活 用 する 3. 平均復旧時間はどのくらい改善したのか 4. これから 5. 所感 1 1 6 5. ユーザー体験を可視化するSLI/SLO の運 用 と効果
117. FlutterKaigi 2024 1 1 7 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる サービス品質は事業全体にとっても 非 常に 大 事なこと
118. FlutterKaigi 2024 1 1 8 エンジニアが品質に取り組んでいることを 事業全体に知ってほしい 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
119. FlutterKaigi 2024 1 1 9 SLI/SLOの仕組みを使ってもっと事業全体で 品質に向き合うことはできないか？ 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
120. FlutterKaigi 2024 1 2 0 DASHBOARD機能の作成 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
121. FlutterKaigi 2024 1 2 1 DASHBOARD機能 • 目 的: 障害をいつでも誰でも確認できる • 手 段: 身 近にアクセス可能なダッシュボード機能 • 改善軸: 障害の状況把握はまずはここから 始められるようにする 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
122. FlutterKaigi 2024 1 2 2 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
123. FlutterKaigi 2024 1 2 3 機能名 時間別の機能の成功率 機能毎の正常を表す、 目 標値 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
124. FlutterKaigi 2024 1 2 4 3.4. アラートを作成する 緑が成功した成功率、グレーが途中でやめたキャンセル率、 赤 がユーザー体験として理想状態ではない、失敗率を表す
125. FlutterKaigi 2024 1 2 5 3.4. アラートを作成する 📊 ダッシュボード機能 それぞれが10分毎のデータになっている。 25件のうち、24件が成功、1件が失敗している。
126. FlutterKaigi 2024 1 2 6 3.4. アラートを作成する それぞれが10分毎のデータになっている。 こんな感じでエラーが増えていると障害が確認できる
127. FlutterKaigi 2024 1 2 7 📊 ダッシュボード機能 最新バージョンのユーザーで起きている障害かも
128. FlutterKaigi 2024 1 2 8 👍 提供すること ✅ 障害の全体像を把握し、 解消までの初速を上げる ✅ 障害時のダブルチェックのため の情報源になる ✅ 障害の解消を確認する 🙅 提供しないこと 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
129. FlutterKaigi 2024 1 2 9 👍 提供すること ✅ 障害の全体像を把握し、 解消までの初速を上げる ✅ 障害時のダブルチェックのため の情報源になる ✅ 障害の解消を確認する 🙅 提供しないこと ❌ これ 一 つで完全に障害解消までできる ❌ この情報だけを100%信 用 して ビジネス判断をする ❌ ユーザー単位やバージョン単位などの 詳細なデータ 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
130. FlutterKaigi 2024 1 3 0 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
131. FlutterKaigi 2024 1 3 1 ビジネスメンバーを中 心 にインシデントの 連絡が来た時に即座にユーザー影響を確認する ツールとして定着！ 5 . 1 . SLI/SLOをチーム ・ 事業に定着させる
132. FlutterKaigi 2024 1 3 2 5 . 2 . SLI/SLOを別の形で活 用 する アラート ・ ダッシュボード以外でいい感じ活 用 できないか🤔
133. FlutterKaigi 2024 1 3 3 5 . 2 . SLI/SLOを別の形で活 用 する 段階リリース中のアプリの品質評価に利 用 しています。 iOS/Android開発において、段階リリースは以下の仕様になっています。 iOS • 1 日 目 に1%、2 日 目 に2%、3 日目 に5%と、公開されていき、7 日目 に100%になります。 割合は変更できません。途中で100%に変更することは可能です。 Android • Google Play Consoleで 自 由に公開率を設定可能。 自 動で更新することはなく、 手 動またはAPI経由での更新が必要です。
134. FlutterKaigi 2024 1 3 4 5 . 2 . SLI/SLOを別の形で活 用 する SLI/SLOデータはもちろん、セッション数、クラッシュフリーレート、 そのversionで発 生 した新規issueを取得し、サマリーレポートを作成します 全てSentryのAPIを 使って実装してます！
135. FlutterKaigi 2024 1 3 5 5 . 2 . SLI/SLOを別の形で活 用 する 段階リリースしてから閾値が貯まり次第、最速で安全性の判断を可能にする。 Slack通知し、その場で100%公開もしくは、リリースを取り下げるかを選択する。
136. FlutterKaigi 2024 1 3 6 5.3. 平均復旧時間はどのくらい改善したのか 障害には以下のパターンが存在する • 内部コードによるデグレ • 連携している外部サービス(Firebase、決済系 ・ 銀 行 サービス) の障害やメンテナンス
137. FlutterKaigi 2024 1 3 7 平均復旧時間はどのくらい改善したのか
138. FlutterKaigi 2024 1 3 8 5.3. 平均復旧時間はどのくらい改善したのか 障害には以下のパターンが存在する • 内部コードによるデグレ • 連携している外部サービス(Firebase、決済系 ・ 銀 行 サービス) の障害やメンテナンス
139. FlutterKaigi 2024 1 3 9 検知できた 検知できていない 合計 外部連携による障害 内部実装による障害 2件 12件 0 / 2件 2 / 12件 2 / 2件 1 0 / 12件 5.3. 平均復旧時間はどのくらい改善したのか
140. FlutterKaigi 2024 1 4 0 検知できた 検知できていない 合計 外部連携による障害 内部実装による障害 2件 12件 0 / 2件 2 / 12件 2 / 2件 1 0 / 12件 5.3. 平均復旧時間はどのくらい改善したのか 内部実装は検知することが できている
141. FlutterKaigi 2024 1 4 1 検知できた 検知できていない 合計 外部連携による障害 内部実装による障害 2件 12件 0 / 2件 2 / 12件 2 / 2件 1 0 / 12件 5.3. 平均復旧時間はどのくらい改善したのか 内部実装は検知することが できている 一 部のユーザーで発 生 したケース。 サンプリングレートの調整/ 見 直しが必要
142. FlutterKaigi 2024 1 4 2 障害のケースが多種多様なため、単純に平均復旧時間を減ったかどうかを 計測するのが難しく、数値での共有は誤解が 生 まれそうで控えます。 ただ、体感値としてコミュニケーションがスムーズになったり、 事実確認がしやすいことで平均復旧時間に寄与している感覚が チームメンバー内外であります。 ※このツールの導 入 によっての改善ももちろんあるが、障害対応への熟練度が 上がったことによる、速度が上がったなどの要因もあります。 5.3. 平均復旧時間はどのくらい改善したのか
143. FlutterKaigi 2024 1 4 3 まだまだ改善ポイントはあります ・ アラートの偽陽性を減らす ・ 動画など計測範囲を広げる ・ Webでも計測可能にする ・ バックエンドのSLI/SLOとの連携強化 ・ 現状は障害復旧を 目 的とした利 用 のみなので、 中 長 期でのユーザー体験の低下の防 止 や向上に使う 5.4. これから
144. FlutterKaigi 2024 1 4 4 いかがたったでしょうか。SLI/SLOは 非 常に専 門 知識が求められ、 今回時間の都合上、説明を省略した箇所も多く存在します。 自 分もSLI/SLOについてまだまだわからないことも多く、引き続き学んでいきます。 興味を持たれた 方 はぜひ、後ほどお話しできれると嬉しいです。 5.5. 所感
145. FlutterKaigi 2024 1 4 5 ご清聴ありがとうございました 🙌