Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Shota Suzuki
June 28, 2022
560

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

Shota Suzuki

June 28, 2022
Tweet

Transcript

  1. ❏ 鈴木 祥太  @sshota0809 ❏ 所属 ❏ 株式会社ユーザベース SRE ❏ B2B

    向け SaaS プロダクトを横串で担当 ❏ 最近 ❏ Rust の勉強をしています ❏ 自己紹介
  2. z 社名:株式会社ユーザベース / Uzabase, Inc. 創業:2008年4月1日 事業内容:企業活動の意思決定を支える情報インフラの提供 上場市場:東証マザーズ(3966) COMPANY OVERVIEW

    提供サービス (一部紹介) 経済情報 プラットフォーム スタートアップ情報 プラットフォーム B2Bマーケティング プラットフォーム -7-
  3. ❏ SLA / SLI / SLO に関する細かい定義について ❏ SLO の運用に関する詳細なプラクティス

    ❏ エラーバジェットやバーンレートといった事柄に関する詳しい説明 ➢ 本日はサービスの信頼性を決めるまでのプロセスにフォーカスしてお話します ❏ 今日話さないこと
  4. ❏ ある日、Elastic Search クラスタ全体が不安定になりレスポンスを返せず サービスのコア機能に障害が発生 ❏ Elastic Search 周りのオブザーバビリティを当初は十分に確保できていなかったのも あり原因調査が難航

    ❏ 結局、数日後に障害対応を一旦クローズしてしまう ❏ 数ヶ月後、同様の障害が発生し短期間の間で繰り返しユーザーに ご迷惑をかけてしまった ❏ 組織内で話し合った結果、明らかにユーザーに提供すべきサービス品質を十分に 満たしていないという意見が一致し、他タスクを一度停止して本障害調査/解決に フルコミットすることに ❏ 前回の反省からオブザーバビリティの改善もしていた結果、 原因もわかり対応することができた ❏ アクションを起こす際の曖昧な判断軸
  5. ❏ 今一度、SLA / SLI / SLO などについてインプットをし直し ❏ 参考書や Web

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

    HTTP だったため 2 つの SLI を定義 ❏ リクエストの成功率 ❏ リクエストのレイテンシ ❏ 結果的に 2 つを定めることができた ❏ 99.9% の確率で正常にレスポンスを返すことができる(正常 = 200) ❏ 99% が 3 秒以内にレスポンスを返すことができる ❏ ちいさくはじめる A B C E D ・・・ サービス Application SLI / SLO の定義
  7. ❏ エラーバジェットのアラートチューニングなど難しい点がありながらも SLO の運用をチームで開始して運用を継続できた ❏ 2 つを意識 ❏ エラーバジェットに対するアラートが発報されたら SRE

    が手動しつつ SWE と一緒に対応し組織全体の文化として根付かせる意識をする ❏ 週 1 でチームで SLO の確認や見直し等を議論する定例を開催 ❏ SLO をベースにパフォーマンス改善の判断も適切にすることができた ❏ ちいさくはじめる しかし同時に課題も見えてきた
  8. ❏ このままマイクロサービスごとに SLI / SLO を設定していき運用していけるのか ❏ マイクロサービスは無数にある ❏ 現在のチームの規模だと問題なく

    SLI / SLO を設定したマイクロサービスを スケールしていけるイメージができなかった ❏ 決めた SLI / SLOが結局ユーザーにとってどういう価値になるのか直感的でなかった ❏ それがサービスとしてユーザーにどういう価値になるのかシンプルに 理解できるような形でなかった ❏ 99.9% の確率で正常にレスポンスを返すことができる(正常 = 200) ❏ 99% が 3 秒以内にレスポンスを返すことができる ❏ ユーザーに届けるべきサービスの信頼性を定義したはずが、本当にユーザー目線で 考えられていたのか疑問を持ってしまった ❏ 見えてきた課題感
  9. ❏ 経験値を一定積んだ状態でもう一度インプットをし直し ❏ 特に Google が公開している The Art of SLOs

    を参考にした ❏ https://docs.google.com/presentation/d/1qcQ6alG_qUg3qWf733ZsDnTggwzqe4PZICrFXZ1zQZs/ ❏ サービスにおけるクリティカルユーザージャーニー(CUJ)を最初に洗い出す ❏ ユーザーがサービスで行う目標を達成するために必要な一連のやり取り ❏ EC サイトであれば「カートに商品を入れる」「商品を見る」など ❏ Input #2 マイクロサービス単位ではなくサービス単位で思考し CUJ を皆で考えて、それをベースに SLI / SLO を設定する というユーザー目線でとにかく考えることに (結果的にThe Art of SLOsなぞるような形でやることに)
  10. ❏ CUJ から SLI への落とし込み ❏ 誰が見てもひと目で意味が理解でき、それ(SLI)を共通言語として すべてのステークホルダーと会話をしていきたかった ❏ 「ユーザーは

    XXXX できる」というフォーマットに則って CUJ から 具体的なセンテンスに落とし込んだ ❏ サービス単位で考える
  11. ❏ SLI の実装(SLI をどうトラッキングするか)での意識 ❏ ここでもマイクロサービスではなくサービス単位で考えユーザーとの境界に目を向けた ❏ 複数のマイクロサービスが複雑に連携しあって最終的にユーザーにレスポンスを 返しているが、SLI の実装に対する議論においてマイクロサービス同士の依存に

    目を向けはじめると論点がずれてしまうと考えた ❏ やはり一番大切なのは、「ユーザーにとって何(What)がどう(How)なのか」 ❏ サービス単位で考える User BFF API#1 API#2 e.g. ・・・ 議論の際はこれよりも後ろのレイヤーは意識しない トラッキングはユーザーから見た時に一番近いレイヤーのログやメトリクスを利用 ※.SLO 検討時はクラウド基盤や外部 API などシステム が依存している外部サービスのSLAを考慮する必要が あるのでそのフェーズでは依存関係を一定意識した
  12. ❏ CUJ からブレイクダウンしサービス単位で SLI / SLO を決めた結果 ❏ ユーザーが主語となったセンテンスでわかりやすい形となった ❏

    サービス単位なので追う目標とその数もシンプルになった ❏ あるサービスの実際の SLI / SLO ❏ ユーザーは 99.9% の確率でマイページを確認することができる ❏ ユーザーは 1 秒以内にマイページの情報を確認することができる ❏ etc... ❏ サービス単位で考える
  13. ❏ 今までの運用では、本当に「ユーザーを意識できているのか」課題感があり、 目指すべきサービスの信頼性を定義することにした ❏ マイクロサービス単位で SLI / SLO を定義したが、 やはり「ユーザーを意識できているのか」という部分に疑問が残ってしまった

    ❏ また、運用のスケールにも不安があった ❏ ユーザーのジャーニーに意識を向けサービス単位でそれに基づく形の SLI / SLO を 定義したところ、ユーザーを意識でき且つ誰が見てもわかりやすくシンプルな 指標を定めることができた ❏ まとめ