ユーザーの理想からはじめるサービスの信頼性定義

Transcript

1. ユーザーの理想からはじめる サービスの信頼性定義 株式会社ユーザベース 鈴木 祥太
2. ❏ 鈴木 祥太　　@sshota0809 ❏ 所属 ❏ 株式会社ユーザベース SRE ❏ B2B 向け SaaS プロダクトを横串で担当 ❏ 最近 ❏ Rust の勉強をしています ❏ 自己紹介
3. z 社名：株式会社ユーザベース / Uzabase, Inc. 創業：2008年4月1日 事業内容：企業活動の意思決定を支える情報インフラの提供 上場市場：東証マザーズ（3966） COMPANY OVERVIEW 提供サービス （一部紹介） 経済情報 プラットフォーム スタートアップ情報 プラットフォーム B2Bマーケティング プラットフォーム -7-
4. ❏ サービスの信頼性（SLO）の本格導入に至った経緯 ❏ それまでの運用の課題 ❏ 「小さくはじめて」わかった課題感 ❏ いかにしてユーザーに寄り添ったサービスの信頼性を定義したのか ❏ 今日話すこと
5. ❏ SLA / SLI / SLO に関する細かい定義について ❏ SLO の運用に関する詳細なプラクティス ❏ エラーバジェットやバーンレートといった事柄に関する詳しい説明 ➢ 本日はサービスの信頼性を決めるまでのプロセスにフォーカスしてお話します ❏ 今日話さないこと
6. ❏ ユーザーを意識しきれていなかった運用
7. ❏ ある日、Elastic Search クラスタ全体が不安定になりレスポンスを返せず サービスのコア機能に障害が発生 ❏ Elastic Search 周りのオブザーバビリティを当初は十分に確保できていなかったのも あり原因調査が難航 ❏ 結局、数日後に障害対応を一旦クローズしてしまう ❏ 数ヶ月後、同様の障害が発生し短期間の間で繰り返しユーザーに ご迷惑をかけてしまった ❏ 組織内で話し合った結果、明らかにユーザーに提供すべきサービス品質を十分に 満たしていないという意見が一致し、他タスクを一度停止して本障害調査/解決に フルコミットすることに ❏ 前回の反省からオブザーバビリティの改善もしていた結果、 原因もわかり対応することができた ❏ アクションを起こす際の曖昧な判断軸
8. 我々はベストを尽くせたのだろうか？ ❏ 適切なタイミングで適切な判断ができていたのか？ ❏ 「ユーザーに提供すべきサービス品質を十分に満たしていないという意見が一致」 ❏ それぞれ個人の中に存在するが曖昧な基準 ❏ 十分なサービス品質とは何なのか？ Quality 十分は品質だよね ギリギリ許せる あと一息では？ 全く許容できない
9. ❏ 一部のアラートが発報されるが無視されてそのまま自然と復旧報が出る という状態になってしまっていた ❏ アラートが鳴るとはとてもストレスフル、そもそも対応する必要のないアラートを 上げることによって無駄な精神的負荷を生み出してしまうし単純にノイジー ❏ アラートを全面的な見直しをして整理を行った ❏ 形骸化するアラート
10. そもそもなぜアラートを上げるのか？ ❏ 「問題を知りたい」がためにアラートを上げているが「問題」とは？ ❏ 普段と違う変化や異変を知りたい ❏ その先にあるものはユーザー影響なのでは（アラートの属性によっては例外はある） ❏ それをアラートでプロアクティブに検知する ❏ ユーザーにビジネス価値をちゃんと届けられているのか ❏ 「ちゃんと」とは何なのか？ CPU 使用率が 高騰する 処理が詰まる ユーザーに 応答が返らない e.g.
11. ❏ アクションを起こす際の曖昧な判断軸 ❏ 個人の中でそれぞれ存在する曖昧なサービス品質の基準 ❏ 形骸化するアラート ❏ ユーザーにビジネス価値を「ちゃんと」届けられている状態とは？ ❏ ユーザーを意識しきれていなかった運用 やはり、目指すべきサービスの信頼性を定義し 明確化することで運用の健全化ができると確信
12. ❏ サービスの信頼性定義に向けて
13. ❏ 今一度、SLA / SLI / SLO などについてインプットをし直し ❏ 参考書や Web で参照可能な記事を回遊し多くの事柄を吸収し直す ❏ SLO に対するエラーバジェットやバーンレートの概念 / その運用 ❏ 定義した目標が未達だった時のアクション ❏ 信頼性とユーザー満足度の曲線を意識して SLO を決める ❏ etc... ❏ Input 小さくはじめて小さく失敗したかった 契約上の約束となる SLA はファーストステップとして ハードルが高かったので、SLO をあるマイクロサービスに導入することに
14. ❏ 直接的な外部露出はないがサービスの画面表示に影響のある内部 API （マイクロサービス）で SLI / SLO を定義 ❏ プロトコルは HTTP だったため 2 つの SLI を定義 ❏ リクエストの成功率 ❏ リクエストのレイテンシ ❏ 結果的に 2 つを定めることができた ❏ 99.9% の確率で正常にレスポンスを返すことができる（正常 = 200） ❏ 99% が 3 秒以内にレスポンスを返すことができる ❏ ちいさくはじめる A B C E D ･･･ サービス Application SLI / SLO の定義
15. ❏ エラーバジェットのアラートチューニングなど難しい点がありながらも SLO の運用をチームで開始して運用を継続できた ❏ 2 つを意識 ❏ エラーバジェットに対するアラートが発報されたら SRE が手動しつつ SWE と一緒に対応し組織全体の文化として根付かせる意識をする ❏ 週 1 でチームで SLO の確認や見直し等を議論する定例を開催 ❏ SLO をベースにパフォーマンス改善の判断も適切にすることができた ❏ ちいさくはじめる しかし同時に課題も見えてきた
16. ❏ このままマイクロサービスごとに SLI / SLO を設定していき運用していけるのか ❏ マイクロサービスは無数にある ❏ 現在のチームの規模だと問題なく SLI / SLO を設定したマイクロサービスを スケールしていけるイメージができなかった ❏ 決めた SLI / SLOが結局ユーザーにとってどういう価値になるのか直感的でなかった ❏ それがサービスとしてユーザーにどういう価値になるのかシンプルに 理解できるような形でなかった ❏ 99.9% の確率で正常にレスポンスを返すことができる（正常 = 200） ❏ 99% が 3 秒以内にレスポンスを返すことができる ❏ ユーザーに届けるべきサービスの信頼性を定義したはずが、本当にユーザー目線で 考えられていたのか疑問を持ってしまった ❏ 見えてきた課題感
17. ❏ 経験値を一定積んだ状態でもう一度インプットをし直し ❏ 特に Google が公開している The Art of SLOs を参考にした ❏ https://docs.google.com/presentation/d/1qcQ6alG_qUg3qWf733ZsDnTggwzqe4PZICrFXZ1zQZs/ ❏ サービスにおけるクリティカルユーザージャーニー（CUJ）を最初に洗い出す ❏ ユーザーがサービスで行う目標を達成するために必要な一連のやり取り ❏ EC サイトであれば「カートに商品を入れる」「商品を見る」など ❏ Input #2 マイクロサービス単位ではなくサービス単位で思考し CUJ を皆で考えて、それをベースに SLI / SLO を設定する というユーザー目線でとにかく考えることに （結果的にThe Art of SLOsなぞるような形でやることに）
18. ❏ ユーザーの理想からはじめる信頼性定義
19. ❏ CUJ から SLI への落とし込み ❏ 誰が見てもひと目で意味が理解でき、それ（SLI）を共通言語として すべてのステークホルダーと会話をしていきたかった ❏ 「ユーザーは XXXX できる」というフォーマットに則って CUJ から 具体的なセンテンスに落とし込んだ ❏ サービス単位で考える
20. ❏ SLI の実装（SLI をどうトラッキングするか）での意識 ❏ ここでもマイクロサービスではなくサービス単位で考えユーザーとの境界に目を向けた ❏ 複数のマイクロサービスが複雑に連携しあって最終的にユーザーにレスポンスを 返しているが、SLI の実装に対する議論においてマイクロサービス同士の依存に 目を向けはじめると論点がずれてしまうと考えた ❏ やはり一番大切なのは、「ユーザーにとって何（What）がどう（How）なのか」 ❏ サービス単位で考える User BFF API#1 API#2 e.g. ･･･ 議論の際はこれよりも後ろのレイヤーは意識しない トラッキングはユーザーから見た時に一番近いレイヤーのログやメトリクスを利用 ※.SLO 検討時はクラウド基盤や外部 API などシステム が依存している外部サービスのSLAを考慮する必要が あるのでそのフェーズでは依存関係を一定意識した
21. ❏ CUJ からブレイクダウンしサービス単位で SLI / SLO を決めた結果 ❏ ユーザーが主語となったセンテンスでわかりやすい形となった ❏ サービス単位なので追う目標とその数もシンプルになった ❏ あるサービスの実際の SLI / SLO ❏ ユーザーは 99.9% の確率でマイページを確認することができる ❏ ユーザーは 1 秒以内にマイページの情報を確認することができる ❏ etc... ❏ サービス単位で考える
22. ❏ 気づき / 学び ❏ （当然ではあるが）いざエラーバジェットの消費が進んだ時にそれを調査するには やはりオブザーバビリティの確保が必須だと改めて認識 ❏ 複雑に連携し合うマイクロサービスの中でボトルネックを見つける必要がある ❏ SLO の有無に関わらずサービス運用するうえで当然重要ではあるが 改めてその大切さを伝えたい ❏ etc... ❏ サービス単位で考える
23. ❏ まとめ
24. ❏ 今までの運用では、本当に「ユーザーを意識できているのか」課題感があり、 目指すべきサービスの信頼性を定義することにした ❏ マイクロサービス単位で SLI / SLO を定義したが、 やはり「ユーザーを意識できているのか」という部分に疑問が残ってしまった ❏ また、運用のスケールにも不安があった ❏ ユーザーのジャーニーに意識を向けサービス単位でそれに基づく形の SLI / SLO を 定義したところ、ユーザーを意識でき且つ誰が見てもわかりやすくシンプルな 指標を定めることができた ❏ まとめ
25. ソフトウェアエンジニア テストエンジニア データサイエンティスト SRE(s) 株式会社ユーザベース 積極採用中です