モバイルアプリのSLI/SLOについて考える | DMM.swift #2

Transcript

1. Shunsuke Nakao モバイルアプリの SLI/SLOについて考える DMM.swift #2 - March 28th, 2024 @noa4021J
2. 中尾 俊介 合同会社 DMM.com プラットフォーム開発本部 第１開発部 DMM PointClubグループ iOS Team Leader Shunsuke Nakao 2021年に合同会社DMM.comに新卒入社し、ソフトウェアエンジニアとして 『DMMポイントクラブ』のiOSアプリ開発に従事。翌年からiOSテックリードとしてDMMポ イントクラブグループのモバイル開発をリードし、技術戦略や開発生産性の改善にコミッ ト。現在は同グループのiOS Team Leaderを務める。 About Me
3. Introduction 1 . SLI/SLOについて確認する 2 . モバイルアプリのサービスレベルを考える 3 . モバイルアプリの信頼性を追跡するために 4 . Q&A
4. SLI/SLOについて確認する 1.
5. 01 SLI/SLOについて確認する Q. SLI/SLOとは何か A. Googleが提唱する "Site Reliability Engineering (SRE)" の 概論の中で出てくる、サービスを正しく管理するための指標群 It’s impossible to manage a service correctly, let alone well, without understanding which behaviors really matter for that service and how to measure and evaluate those behaviors. To this end, we would like to define and deliver a given level of service to our users, whether they use an internal API or a public product. We use intuition, experience, and an understanding of what users want to define service level indicators (SLIs), objectives (SLOs), and agreements (SLAs). https://sre.google/sre-book/table-of-contents/
6. 01 SLI/SLOについて確認する Q. SLI/SLOとは何か A. Googleが提唱する "Site Reliability Engineering (SRE)" の 概論の中で出てくる、サービスを正しく管理するための指標群 It’s impossible to manage a service correctly, let alone well, without understanding which behaviors really matter for that service and how to measure and evaluate those behaviors. To this end, we would like to define and deliver a given level of service to our users, whether they use an internal API or a public product. We use intuition, experience, and an understanding of what users want to define service level indicators (SLIs), objectives (SLOs), and agreements (SLAs). https://sre.google/sre-book/table-of-content s/ "Site Reliability Engineering (SRE)" 🤔？
7. 01 SLI/SLOについて確認する Q. Site Reliability Engineeringとは？ DevOpsを実現するための、Googleが提唱した 具体的なプラクティス ※アジャイルにおけるスクラム、のような「方針・思想」と「その具体的な解決手段」の関係
8. 01 SLI/SLOについて確認する Q. Site Reliability Engineeringとは？ DevOpsを実現するための、Googleが提唱した 具体的なプラクティス ※アジャイルにおけるスクラム、のような「方針・思想」と「その具体的な解決手段」の関係 class SRE implements DevOps SREはDevOpsというinterfaceの実装である
9. DevOpsの概念が生まれた背景 01 SLI/SLOについて確認する Developers Operators 組 織 的 な 壁 「機能の提供」に責任をもつ 機能を速くリリースして製品のビジ ネス的価値の向上を加速させた い。 Developers 開発担当 「製品の安定性」に責任をもつ 製品が利用できない事態を避けシ ステムを安定して運用させたい。 Operators 運用担当 かつて企業は、ソフトウェアを運用するために、 開発者と運用者を分けるというアプローチをとってきた。 ソフトウェアを開発する開発者と、開発されたソフトウェアを載せて稼働させるハード（インフラ）を運用する運用者
10. 01 SLI/SLOについて確認する 「機能の提供」に責任をもつ 機能を速くリリースして製品のビジ ネス的価値の向上を加速させた い。 Developers 開発担当 「製品の安定性」に責任をもつ 製品が利用できない事態を避けシ ステムを安定して運用させたい。 Operators 運用担当 開発者(Dev)と運用者(Ops)を分けるアプローチは、 主に"本番環境への機能のデプロイ"をめぐって衝突。 組織間の摩擦を生んだ 早くリリースしたい！ そんな頻繁にリリースできない！ 🔥
11. 01 SLI/SLOについて確認する 価値の提供と信頼性の担保 どちらも同じミッションからブレイクダウンされたものであり、 目指す方向は同じはず。 価値の提供 信頼性の担保 機能を速くリリースして製品のビジネス的価 値の向上を加速させたい。 製品が利用できない事態を避けシステムを 安定して運用させたい。 Mission 製品のビジネス価値向上
12. 01 SLI/SLOについて確認する 価値の提供と信頼性の担保 どちらも同じミッションからブレイクダウンされたものであり、 目指す方向は同じはず。 価値の提供 信頼性の担保 機能を速くリリースして製品のビジネス的価値の向上 を加速させたい。 製品が利用できない事態を避けシステムを安定して 運用させたい。 Mission 製品のビジネス価値向上 信頼性の担保 機能を速くリリースして製品のビジネス的価 値の向上を加速させたい。 製品が利用できない事態を避けシステムを 安定して運用させたい。 Mission 製品のビジネス価値向上 🤝 DevOpsとは 組織間の摩擦・壁を減らし、協調を促すことで さらなる製品の価値向上を達成するための 概念・実践・文化 価値の提供
13. 01 SLI/SLOについて確認する モバイルアプリにおいてもこれらは同じ 価値の提供 信頼性の担保 機能を速くリリースして製品のビジネス的価値 の向上を加速させたい。 製品が利用できない事態を避けシステムを安 定して運用させたい。 Mission 製品のビジネス価値向上 だと思ってます。ソフトウェアの話なので。
14. 01 SLI/SLOについて確認する モバイルアプリにおいてもこれらは同じ。 価値の提供 信頼性の担保 機能を速くリリースして製品のビジネス的価値の向上 を加速させたい。 製品が利用できない事態を避けシステムを安定して 運用させたい。 Mission 製品のビジネス価値向上 ソフトウェアの話なので 開発しているアプリ、 開発速度は維持できていますか？ バグ修正・不具合対応に圧されて機能開発遅くなっていませんか？
15. 01 SLI/SLOについて確認する モバイルアプリにおいてもこれらは同じ。 価値の提供 信頼性の担保 機能を速くリリースして製品のビジネス的価値の向上 を加速させたい。 製品が利用できない事態を避けシステムを安定して 運用させたい。 Mission 製品のビジネス価値向上 ソフトウェアの話なので 開発しているアプリ、 品質は適切に管理できていますか？ 今リリースされているアプリの信頼性はモニタリングできていますか？
16. 02 SLI/SLOについて確認する GoogleのDevOpsの解釈 組織のサイロを削減する Reduce organizational silos エラー発生を普通と捉える Accept failure as normal 段階的変更を実施する Implement gradual change ツールと自動化を活用する Leverage tooling and automation すべてを測定する Measure everything SRE 所有権の共有 Share ownership エラーバジェットによる許容 SLOs & Blameless PMs カナリアリリース Reduce cost of failure 手作業の自動化 Automate common case 苦労と信頼性の計測 Measure toil and reliability DevOps
17. 02 SLI/SLOについて確認する GoogleのDevOpsの解釈 組織のサイロを削減する Reduce organizational silos エラー発生を普通と捉える Accept failure as normal 段階的変更を実施する Implement gradual change ツールと自動化を活用する Leverage tooling and automation すべてを測定する Measure everything SRE 所有権の共有 Share ownership エラーバジェットによる許容 SLOs & Blameless PMs カナリアリリース Reduce cost of failure 手作業の自動化 Automate common case 苦労と信頼性の計測 Measure toil and reliability DevOps
18. 02 SLI/SLOについて確認する GoogleのDevOpsの解釈 組織のサイロを削減する Reduce organizational silos エラー発生を普通と捉える Accept failure as normal 段階的変更を実施する Implement gradual change ツールと自動化を活用する Leverage tooling and automation すべてを測定する Measure everything SRE 所有権の共有 Share ownership エラーバジェットによる許容 SLOs & Blameless PMs カナリアリリース Reduce cost of failure 手作業の自動化 Automate common case 苦労と信頼性の計測 Measure toil and reliability DevOps DevOpsのエッセンス 迅速に価値をエンドユーザーに届けるために SREが定めた手段 どこまでなら失敗を許容できるか定めよう ＝ SLI/SLO （= Error Budget）
19. モバイルアプリのサービスレベルを考える 2.
20. SLI/SLO 02 SLI/SLOについて確認する SLI: Service Level Indicators ユーザーが、品質や体験などの "サービスに対して期待する側面" を定量的に示した具体的な指標。 e.g.) リクエストレイテンシ、エラー率など SLO: Service Level Objectives ユーザーが、品質や体験などの"サービスに対して期待する側面"において要求または期待される具体的な目標値。 e.g.) リクエストレイテンシが200ms以内、エラー率が99.9%以上 SLA: Service Level Agreements ユーザーが利用するサービスに期待するサービスレベルの水準(=SLO)を公約として規定し取り交わす契約。 遵守すべきサービスレベルを下回った時のペナルティや責任について記載される。 エラーバジェットによる許容 SLOs & Blameless PMs 苦労と信頼性の計測 Measure toil and reliability
21. Crash Free Rate モバイルアプリではしばしば 01 SLI/SLOについて確認する または "Crash Free Users" が用いられる
22. 01 SLI/SLOについて確認する SLI/SLOはどう決めればいいのか？ ユーザー向けかどうかに関係なく、すべてのサービスで個別の SLO を開発したくなることがあります。たとえば、2 つ以上の サービス（たとえば、フロントエンド サービスとバックエンド データストア）で、ユーザーが両方のサービスに依存しているが、 それらを区別できない場合に、個別に測定してしまうことがよくある間違いです。 よりよいアプローチは、プロダクト（サービスのコレクション）に基づいて SLO を開発し、ユーザーがこのプロダクトと行う最も 重要なインタラクションに焦点を合わせることです。 https://cloud.google.com/architecture/framework/reliability/defining-SLOs?hl=ja
23. 01 SLI/SLOについて確認する よりよいアプローチは、プロダクト（サービスのコレクション）に基づいて SLO を開発し、ユーザーがこのプロダクトと行う最も重要な インタラクションに焦点を合わせること クリティカル・ユーザージャーニー（CUJ） 効果的な SLO を開発するために、クリティカル ユーザー ジャーニー（CUJ）と呼ばれる、ユーザーとサービスとのインタラクションを理解することが理想 です。CUJ では、ユーザーの目的と、ユーザーがその目的の達成のためにサービスをどのように使用するかが考慮されます。 CUJ は、サービスの境 界線を考慮せずに顧客の視点で定義されます。 CUJ が満たされていれば顧客は満足であり、顧客の満足度がサービスの成功の重要な尺度になりま す。 https://cloud.google.com/architecture/framework/reliability/defining-SLOs?hl=ja
24. 例えばコード決済アプリのCUJ 01 SLI/SLOについて確認する 1.支払いのために アプリを開く 0. 商品をカゴに 入れる 2.QRコードをリーダーに スキャンする 3.支払いが完了する 正常系
25. 例えばコード決済アプリのCUJ 01 SLI/SLOについて確認する ❌ 1.支払いのために アプリを開く 0. 商品をカゴに 入れる 2.QRコードをリーダーに スキャンする 異常系① 2.QRコードが表示されない 異常系② 0. 商品をカゴに 入れる 1.支払いのために アプリを開く ❌ または ・アプリがクラッシュする ・QRコードの読み取りができない 3.支払いに失敗する または ・アプリがクラッシュする ・支払いが実行されたまま終わらない
26. 例えばコード決済アプリのCUJ 01 SLI/SLOについて確認する ❌ 1.支払いのために アプリを開く 0. 商品をカゴに 入れる 2.QRコードをリーダーに スキャンする 異常系① 2.QRコードが表示されない 異常系② 0. 商品をカゴに 入れる 1.支払いのために アプリを開く ❌ または ・アプリがクラッシュする ・QRコードの読み取りができない 3.支払いに失敗する または ・アプリがクラッシュする ・支払いが実行されたまま終わらない SLI/SLOではここを見る ※ユーザーがサービスに対して 最も信頼を失うリスクが高い、 CUJの達成を阻害するケース 2.QRコードが表示されない または ・アプリがクラッシュする ・QRコードの読み取りができない ❌ 3.支払いに失敗する または ・アプリがクラッシュする ・支払いが実行されたまま終わらない ❌
27. 01 SLI/SLOについて確認する CUJの担保を目標に置くと考えた時に… Crash Free Rateだけでは CUJが担保できていると言い切れない QRコードが表示されない ❌ または ・アプリがクラッシュする ・QRコードの読み取りができない ❌ 支払いに失敗する または ・アプリがクラッシュする ・支払いが実行されたまま終わらない クラッシュはCUJを阻害する要因の一つに過ぎない
28. 01 SLI/SLOについて確認する CUJの担保を目標に置くと考えた時に… Crash Free Rateだけでは CUJが担保できていると言い切れない 1. QRコードが表示されない ❌ または ・アプリがクラッシュする ・QRコードの読み取りができない ❌ 1. 支払いに失敗する または ・アプリがクラッシュする ・支払いが実行されたまま終わらない クラッシュはCUJを阻害する要因の一つに過ぎない 正常系 問題なくCUJを 達成したユーザー 異常系 何かしらの要因でCUJを 達成できなかったユーザー ❌ Firebase等の モニタリングツール CUJを追跡して ユーザーエクスペリエンスの異常 （＝サービスレベルの低下） を検知する
29. モバイルアプリの信頼性を追跡するために 3.
30. 02 DMMポイントクラブの事例 正常系 問題なくCUJを 達成したユーザー 異常系 何かしらの要因でCUJを 達成できなかったユーザー ❌
31. 02 DMMポイントクラブの事例 正常系 問題なくCUJを 達成したユーザー 異常系 何かしらの要因でCUJを 達成できなかったユーザー ❌ 1.Crash Free Rate (30days) 最優先で達成すべきSLO CUJに直結するか・SLIの下り幅でインシデントをトリアージ Crash Free Rateの次に優先して達成すべきSLO 2.Error Alert Free Rate (30days) DMMポイントクラブの事例 定義運用しているSLO
32. Conclusion 1. DevOpsの具体的なプラクティスがSRE。 SLI/SLOを用いた失敗の許容によって、開発速度と オペレーションを両立しよう 2. SLI/SLOではCUJを追跡可能な正確な指標を測って インシデントのトリアージをしよう 3. CUJを阻害する要因はクラッシュだけではないので、ユーザー がアプリに対して行う最も重要なインタラクションを考えて設計しよ う
33. Thank you for listening !