Slide 1

Slide 1 text

ユーザーの理想からはじめる サービスの信頼性定義 株式会社ユーザベース 鈴木 祥太

Slide 2

Slide 2 text

❏ 鈴木 祥太  @sshota0809 ❏ 所属 ❏ 株式会社ユーザベース SRE ❏ B2B 向け SaaS プロダクトを横串で担当 ❏ 最近 ❏ Rust の勉強をしています ❏ 自己紹介

Slide 3

Slide 3 text

z 社名:株式会社ユーザベース / Uzabase, Inc. 創業:2008年4月1日 事業内容:企業活動の意思決定を支える情報インフラの提供 上場市場:東証マザーズ(3966) COMPANY OVERVIEW 提供サービス (一部紹介) 経済情報 プラットフォーム スタートアップ情報 プラットフォーム B2Bマーケティング プラットフォーム -7-

Slide 4

Slide 4 text

❏ サービスの信頼性(SLO)の本格導入に至った経緯 ❏ それまでの運用の課題 ❏ 「小さくはじめて」わかった課題感 ❏ いかにしてユーザーに寄り添ったサービスの信頼性を定義したのか ❏ 今日話すこと

Slide 5

Slide 5 text

❏ SLA / SLI / SLO に関する細かい定義について ❏ SLO の運用に関する詳細なプラクティス ❏ エラーバジェットやバーンレートといった事柄に関する詳しい説明 ➢ 本日はサービスの信頼性を決めるまでのプロセスにフォーカスしてお話します ❏ 今日話さないこと

Slide 6

Slide 6 text

❏ ユーザーを意識しきれていなかった運用

Slide 7

Slide 7 text

❏ ある日、Elastic Search クラスタ全体が不安定になりレスポンスを返せず サービスのコア機能に障害が発生 ❏ Elastic Search 周りのオブザーバビリティを当初は十分に確保できていなかったのも あり原因調査が難航 ❏ 結局、数日後に障害対応を一旦クローズしてしまう ❏ 数ヶ月後、同様の障害が発生し短期間の間で繰り返しユーザーに ご迷惑をかけてしまった ❏ 組織内で話し合った結果、明らかにユーザーに提供すべきサービス品質を十分に 満たしていないという意見が一致し、他タスクを一度停止して本障害調査/解決に フルコミットすることに ❏ 前回の反省からオブザーバビリティの改善もしていた結果、 原因もわかり対応することができた ❏ アクションを起こす際の曖昧な判断軸

Slide 8

Slide 8 text

我々はベストを尽くせたのだろうか? ❏ 適切なタイミングで適切な判断ができていたのか? ❏ 「ユーザーに提供すべきサービス品質を十分に満たしていないという意見が一致」 ❏ それぞれ個人の中に存在するが曖昧な基準 ❏ 十分なサービス品質とは何なのか? Quality 十分は品質だよね ギリギリ許せる あと一息では? 全く許容できない

Slide 9

Slide 9 text

❏ 一部のアラートが発報されるが無視されてそのまま自然と復旧報が出る という状態になってしまっていた ❏ アラートが鳴るとはとてもストレスフル、そもそも対応する必要のないアラートを 上げることによって無駄な精神的負荷を生み出してしまうし単純にノイジー ❏ アラートを全面的な見直しをして整理を行った ❏ 形骸化するアラート

Slide 10

Slide 10 text

そもそもなぜアラートを上げるのか? ❏ 「問題を知りたい」がためにアラートを上げているが「問題」とは? ❏ 普段と違う変化や異変を知りたい ❏ その先にあるものはユーザー影響なのでは(アラートの属性によっては例外はある) ❏ それをアラートでプロアクティブに検知する ❏ ユーザーにビジネス価値をちゃんと届けられているのか ❏ 「ちゃんと」とは何なのか? CPU 使用率が 高騰する 処理が詰まる ユーザーに 応答が返らない e.g.

Slide 11

Slide 11 text

❏ アクションを起こす際の曖昧な判断軸 ❏ 個人の中でそれぞれ存在する曖昧なサービス品質の基準 ❏ 形骸化するアラート ❏ ユーザーにビジネス価値を「ちゃんと」届けられている状態とは? ❏ ユーザーを意識しきれていなかった運用 やはり、目指すべきサービスの信頼性を定義し 明確化することで運用の健全化ができると確信

Slide 12

Slide 12 text

❏ サービスの信頼性定義に向けて

Slide 13

Slide 13 text

❏ 今一度、SLA / SLI / SLO などについてインプットをし直し ❏ 参考書や Web で参照可能な記事を回遊し多くの事柄を吸収し直す ❏ SLO に対するエラーバジェットやバーンレートの概念 / その運用 ❏ 定義した目標が未達だった時のアクション ❏ 信頼性とユーザー満足度の曲線を意識して SLO を決める ❏ etc... ❏ Input 小さくはじめて小さく失敗したかった 契約上の約束となる SLA はファーストステップとして ハードルが高かったので、SLO をあるマイクロサービスに導入することに

Slide 14

Slide 14 text

❏ 直接的な外部露出はないがサービスの画面表示に影響のある内部 API (マイクロサービス)で SLI / SLO を定義 ❏ プロトコルは HTTP だったため 2 つの SLI を定義 ❏ リクエストの成功率 ❏ リクエストのレイテンシ ❏ 結果的に 2 つを定めることができた ❏ 99.9% の確率で正常にレスポンスを返すことができる(正常 = 200) ❏ 99% が 3 秒以内にレスポンスを返すことができる ❏ ちいさくはじめる A B C E D ・・・ サービス Application SLI / SLO の定義

Slide 15

Slide 15 text

❏ エラーバジェットのアラートチューニングなど難しい点がありながらも SLO の運用をチームで開始して運用を継続できた ❏ 2 つを意識 ❏ エラーバジェットに対するアラートが発報されたら SRE が手動しつつ SWE と一緒に対応し組織全体の文化として根付かせる意識をする ❏ 週 1 でチームで SLO の確認や見直し等を議論する定例を開催 ❏ SLO をベースにパフォーマンス改善の判断も適切にすることができた ❏ ちいさくはじめる しかし同時に課題も見えてきた

Slide 16

Slide 16 text

❏ このままマイクロサービスごとに SLI / SLO を設定していき運用していけるのか ❏ マイクロサービスは無数にある ❏ 現在のチームの規模だと問題なく SLI / SLO を設定したマイクロサービスを スケールしていけるイメージができなかった ❏ 決めた SLI / SLOが結局ユーザーにとってどういう価値になるのか直感的でなかった ❏ それがサービスとしてユーザーにどういう価値になるのかシンプルに 理解できるような形でなかった ❏ 99.9% の確率で正常にレスポンスを返すことができる(正常 = 200) ❏ 99% が 3 秒以内にレスポンスを返すことができる ❏ ユーザーに届けるべきサービスの信頼性を定義したはずが、本当にユーザー目線で 考えられていたのか疑問を持ってしまった ❏ 見えてきた課題感

Slide 17

Slide 17 text

❏ 経験値を一定積んだ状態でもう一度インプットをし直し ❏ 特に Google が公開している The Art of SLOs を参考にした ❏ https://docs.google.com/presentation/d/1qcQ6alG_qUg3qWf733ZsDnTggwzqe4PZICrFXZ1zQZs/ ❏ サービスにおけるクリティカルユーザージャーニー(CUJ)を最初に洗い出す ❏ ユーザーがサービスで行う目標を達成するために必要な一連のやり取り ❏ EC サイトであれば「カートに商品を入れる」「商品を見る」など ❏ Input #2 マイクロサービス単位ではなくサービス単位で思考し CUJ を皆で考えて、それをベースに SLI / SLO を設定する というユーザー目線でとにかく考えることに (結果的にThe Art of SLOsなぞるような形でやることに)

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

❏ CUJ から SLI への落とし込み ❏ 誰が見てもひと目で意味が理解でき、それ(SLI)を共通言語として すべてのステークホルダーと会話をしていきたかった ❏ 「ユーザーは XXXX できる」というフォーマットに則って CUJ から 具体的なセンテンスに落とし込んだ ❏ サービス単位で考える

Slide 20

Slide 20 text

❏ SLI の実装(SLI をどうトラッキングするか)での意識 ❏ ここでもマイクロサービスではなくサービス単位で考えユーザーとの境界に目を向けた ❏ 複数のマイクロサービスが複雑に連携しあって最終的にユーザーにレスポンスを 返しているが、SLI の実装に対する議論においてマイクロサービス同士の依存に 目を向けはじめると論点がずれてしまうと考えた ❏ やはり一番大切なのは、「ユーザーにとって何(What)がどう(How)なのか」 ❏ サービス単位で考える User BFF API#1 API#2 e.g. ・・・ 議論の際はこれよりも後ろのレイヤーは意識しない トラッキングはユーザーから見た時に一番近いレイヤーのログやメトリクスを利用 ※.SLO 検討時はクラウド基盤や外部 API などシステム が依存している外部サービスのSLAを考慮する必要が あるのでそのフェーズでは依存関係を一定意識した

Slide 21

Slide 21 text

❏ CUJ からブレイクダウンしサービス単位で SLI / SLO を決めた結果 ❏ ユーザーが主語となったセンテンスでわかりやすい形となった ❏ サービス単位なので追う目標とその数もシンプルになった ❏ あるサービスの実際の SLI / SLO ❏ ユーザーは 99.9% の確率でマイページを確認することができる ❏ ユーザーは 1 秒以内にマイページの情報を確認することができる ❏ etc... ❏ サービス単位で考える

Slide 22

Slide 22 text

❏ 気づき / 学び ❏ (当然ではあるが)いざエラーバジェットの消費が進んだ時にそれを調査するには やはりオブザーバビリティの確保が必須だと改めて認識 ❏ 複雑に連携し合うマイクロサービスの中でボトルネックを見つける必要がある ❏ SLO の有無に関わらずサービス運用するうえで当然重要ではあるが 改めてその大切さを伝えたい ❏ etc... ❏ サービス単位で考える

Slide 23

Slide 23 text

❏ まとめ

Slide 24

Slide 24 text

❏ 今までの運用では、本当に「ユーザーを意識できているのか」課題感があり、 目指すべきサービスの信頼性を定義することにした ❏ マイクロサービス単位で SLI / SLO を定義したが、 やはり「ユーザーを意識できているのか」という部分に疑問が残ってしまった ❏ また、運用のスケールにも不安があった ❏ ユーザーのジャーニーに意識を向けサービス単位でそれに基づく形の SLI / SLO を 定義したところ、ユーザーを意識でき且つ誰が見てもわかりやすくシンプルな 指標を定めることができた ❏ まとめ

Slide 25

Slide 25 text

ソフトウェアエンジニア テストエンジニア データサイエンティスト SRE(s) 株式会社ユーザベース 積極採用中です