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

信頼性の育て方 / mackerel-meetup-15

rrreeeyyy
December 19, 2023

信頼性の育て方 / mackerel-meetup-15

Mackerel Meetup #15 ( https://mackerelio.connpass.com/event/302254/ ) で「信頼性の育て方」というタイトルで発表させて頂きました

rrreeeyyy

December 19, 2023
Tweet

More Decks by rrreeeyyy

Other Decks in Technology

Transcript

  1. 「信頼性」の育て方
    Ryota Yoshikawa ( @rrreeeyyy )
    1
    1
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  2. Me
    株式会社 Topotal CTO/SRE
    (2021/06 〜)
    SRE as a Service®
    Waroom®
    趣味
    #game
    最近は SO2R をクリアしま
    した
    最近はもっぱら e スポーツ
    観戦・ストリーマー鑑賞
    #seiyu
    最近ハマっているアーティ
    ストはスリーズブーケです
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) 2
    2

    View full-size slide

  3. SRE as a Service ( #PR )
    https://topotal.com/services/sre-as-a-service
    いろいろな会社さんの SRE のお手伝いをさせてもらっています
    SRE の導入支援
    これから説明する「信頼性」の話など
    アプリケーションや Terraform の CI/CD の改善
    障害対応の支援
    原因調査〜恒久対応まで幅広くやらせてもらいました
    Mackerel のダッシュボードの権限を頂いてメトリクスから調査
    Terraform のコードに対して PR を出して暫定対応・恒久対応
    3
    3
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  4. Waroom ( #PR )
    https://waroom.com/
    インシデントレスポンスを改善するための SaaS を作っています
    インシデント対応チームの設定と自動招集
    インシデント発生時に対応手順を表示
    インシデントステートドキュメントの自動生成
    ポストモーテムの自動生成
    蓄積したインシデント情報の可視化
    4
    4
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  5. Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) 5
    5

    View full-size slide

  6. 今日のために Mackerel
    Integration を作りました!!
    https://docs.waroom.com/auto_trigger_integration/ma
    ckerel
    6
    6
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  7. Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) 7
    7

    View full-size slide

  8. Mackerel Meetup #15 のテーマ
    「チームとコミュニティで監視を育てる」
    https://mackerelio.connpass.com/event/302254/
    第15回目の今回は「チームとコミュニティで監視を育てる」をテーマに、監視を育てるスタート
    地点でもあり、考え方でもある「SRE」の概念やその導入方法、具体的な実装について、
    Mackerelユーザー、Mackerel開発者みんなで深掘りできる場にしたいと考えています。 ぜ
    ひ、ここでの知見をチームに持ち帰り、明日から自分たちの監視を、ひいてはシステムを育てる
    ヒントにしていただけたらと思います。
    8
    8
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  9. SRE (Site Reliability Engineering)
    オペレーションをソフトウェアの問題であるかのように扱うときに得られるもの
    https://sre.google/
    2003 年に Google で始まった取り組み
    2014 年に SRECon, 2016 年に SRE 本が出版されたことで広まった
    https://www.usenix.org/conference/srecon14/
    https://sre.google/sre-book/table-of-contents/
    https://sre.google/resources/book-update/
    代表的なプラクティス
    Service Level Objectives ( SLO )
    SRE の中でも特にコアとなるプラクティスと言われている
    Embracing Risk
    Eliminating Toil
    9
    9
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  10. まず Reliability ってなんだっけ
    JIS-Z8115:2000 での「信頼性」/「信頼度」の定義
    https://www.jisc.go.jp/app/jis/general/GnrJISNumberNameSearchList?
    show&jisStdNo=Z8115
    自分が携わっているサービスの「信頼性」ってどうだっけ?
    自分のサービスの「要求されている機能」は何だっけ?
    今どれくらいの信頼度で、どれくらいの信頼度を目指せばいいんだっけ?
    信頼性:
    アイテムが与えられた条件で規定の期間中, 要求された機能を果たすことができる性質
    信頼度:
    アイテムが与えられた条件で規定の期間中, 要求された機能を果たす確率
    10
    10
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  11. SLI/SLO/Error Budget
    SRE のプラクティスで「信頼性」を計測するための指標と目標値
    Service Level Indicator (SLI)
    サービスの信頼性を計測するための指標
    例: 成功した HTTP リクエストの数/全ての HTTP リクエストの数
    例: 0.5秒以内にレスポンスを返したリクエストの数/全てのリクエストの数
    Service Level Objective (SLO)
    サービスの信頼性の目的値 / SLI が目指すべき値
    例: 99.9% のリクエストが成功する
    例: 99.9% のリクエストが 0.5 秒以内にレスポンスを返す
    Error Budget
    SLO から計算される「信頼性の余裕」
    例: 30 日間で SLO が 99.9% の場合、30 日間で 0.1% の失敗は許容
    SRE は SLI/SLO を用いてサービスの信頼性を計測し意思決定を行う
    11
    11
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  12. SLI/SLO はどのように使えるか
    SRE チームの意思決定
    日々のタスク
    例: どのようなアクションが SLI を低下させているかを調査する
    SLI を特に低下させるようなアクションがあれば改善を行う
    例: リリースによってよく SLI が低下している
    リリース・ロールバックサイクルの改善・カナリアリリースの検討
    例: サービス A は信頼性を満たしているのでサービス B の信頼性を改善する
    監視
    例: 短期間に SLI が急速に低下したらアラートを出して即時対応する
    プロダクトチーム・プロダクトオーナーの意思決定
    SLO を十分に満たしているのでリリースサイクルや機能開発を加速する
    SLO を満たせなかったら機能開発を緩めて信頼性の改善に取り組む
    12
    12
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  13. SLI/SLO の定め方 - SLI
    SLI: 「良いイベント/有効なイベント」を使い割合になるように設定する
    リクエスト・レスポンス: 2XX+3XX+4XX を返したリクエスト/ 全リクエスト
    レイテンシー: 0.5 秒以内にレスポンスを返したリクエスト/全リクエスト」
    平均レイテンシーではなくパーセンタイルで計測する
    「重要なユーザージャーニー」をターゲットにすると良い
    例:「ユーザが商品を検索できるか」「ユーザが商品を購入できるか」
    例: 検索・エンドポイントのリクエスト成功率などが SLI になる
    例: /search
    エンドポイントに対する 2xx+3xx+4xx / 全リクエスト
    例: 外形監視で測定する /search
    の正しいレスポンス / リクエスト数
    障害モードも網羅できると良い
    単にリクエスト成功率をログから算出した値のみを SLI にする
    リクエストがロードバランサに到達していない場合は計測できない
    外形監視での SLI を組み合わせることもある
    13
    13
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  14. SLI/SLO の定め方 - SLO
    SLO: 現状の SLI の値とユーザの期待値から設定する
    高すぎる信頼性目標は相応に高いコストを払う必要がある
    100% の信頼性目標を目指すには無限のコストが必要(≒不可能)
    現状の SLI の値でユーザの期待値を満たせているかを確認する
    ユーザは現状の SLI を「暗黙に期待している」可能性がある
    現状の SLI が 99.5% でもユーザからのクレームが多い場合はより高い SLO が必要
    なケースもある
    信頼性目標が高すぎると挑戦・失敗・学習する機会を奪ってしまう可能性もある
    結果として機能開発が遅れたり長期的に見ると信頼性が低下する可能性もある
    メンテナンスウィンドウや依存するコンポーネントの信頼性も考える必要がある
    高すぎる信頼性を設定するとメンテナンスウィンドウが取れない
    そもそも利用するコンポーネントの信頼性より高い信頼性は設定できない
    14
    14
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  15. SLI/SLO の定め方 - 運用
    SLO を違反したときにどのようなアクションを取るか合意を取る
    例: SRE チームがアプリケーションコードを確認して問題を改善する
    例: 開発チームが機能開発を止めて 問題の機能のリファクタリングを行う
    1 イテレーション分は機能開発のスピードを落として信頼性を改善する
    合意を取ったアクションについてはドキュメントに残して公開するようにする
    SLI/SLO を改善するフィードバックループを決める
    例: 開発チームのイテレーションミーティングで SLO を確認する
    現状の SLO が高すぎないか?開発チームに負担がかかっていないか?を確認
    ユーザサポートのチケットを確認して SLI/SLO が上手く機能しているか確認
    例: SRE チームのイテレーションミーティングで SLO を確認する
    特に SLI を低下させるようなアクションがないか?あれば改善できないか?
    15
    15
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  16. 「信頼性は会話である」
    SLI/SLO はシステムの信頼性のニーズを論理的に判断するのに役に立つツール
    単に設定して眺めているだけでは特に何も得られない
    業務を進めるための指針として活用するように組織に導入していく必要がある
    開発チーム・プロダクトオーナー等と合意を取って信頼性をコントロールする
    リスクを取った素早いリリースとユーザが満足する信頼性を実現できる
    SRE チーム内から始まり、組織全体に SLI/SLO の文化を浸透させていけると良い
    自分は SRE チーム内で単純に使う分にも有用なツールだと思っている
    ステークホルダーと自分たちの仕事の交渉をする際にも便利
    SLI/SLO のようなツールを持っていないと雰囲気で交渉をすることになる
    「最近アラートが多いので開発を一旦止めて信頼性を改善してほしい」
    「XX のようなユーザジャーニーでこれまでより 30 日間でエラー数が m だけ増
    えて信頼性がこれまでより n % 低下してしまっています」
    16
    16
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  17. 「完璧である必要はない」
    とはいえはじめて SLI/SLO を定めるときに完璧である必要はない
    重要なのは始めて改善していけるような素早いフィードバックループを行うこと
    むしろ最初のうちは少ない SLI/SLO から小さく始めていく方が良いと思う
    例:「サービスにとって重要なユーザージャーニー」が正しいか分からない
    「正しさ」は恐らく無い(そして変化していく)ので始めてみて改善するのが大事
    例: SLI をちゃんと計測するために複雑なアーキテクチャを作りそうになる
    エンジニアリング作業が最小になるように始める ログがあるならログを使うなど
    例: 開発チームのステークホルダーとの合意が取れていない
    もちろん取れていることがベターだけど SRE チーム内だけの意思決定にも使える
    SRE チーム内でドッグフーディングして上手く行った姿を見せることでステークホルダ
    ーとの合意を取りやすくすることもできる
    17
    17
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  18. SLO Document
    ここまでの内容を踏まえて、SLO Document のようなものを用意すると良い
    以下のような内容を含んだドキュメントを公開し振り返り・改善で随時利用する
    サービスの名前・SLO の定義
    ダッシュボードへのリンク・ドキュメントの作成者・更新日など
    サービスの概要
    SLO を設定している対象のサービスが何を行うサービスなのか
    SLI / SLO
    実際に対象となっている SLI とその SLO
    見直しのスケジュール
    SLI / SLO をどのタイミングでどのように見直すか
    エラーバジェットポリシー
    エラーバジェットが消費されたときにどのようなアクションを取るか
    O'Reilly Japan - SLO サービスレベル目標 にテンプレートがある
    18
    18
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  19. 「監視」との関係を考える
    「入門 監視」のデザインパターンにも 「ユーザ視点での監視」 がある
    SLI/SLO に対して Burn rate alert を設定することでユーザ視点での監視を実現
    自分がもし新規サービスを出すならまず SLI/SLO/Burn rate alert の設定をする
    単純にエラー数などのアラートを利用するより柔軟で納得感がある(と思う)
    既存のサービスでも「ユーザ視点での監視が足りていない」と感じた場合は同様
    もちろん旧来の「監視」を必ずしも全て捨てたりする必要はないと思っている
    「小さく始める」「振り返りながら進める」のが大事
    一方「ユーザ影響が無いアラートを人間にページするべきか?」は考え直す
    アラートが鳴って毎回「本当にユーザ影響があるのか?」を考えるのは厳しい
    アラート対応は負担が大きく「アラート疲労」を起こす可能性がある
    「まず監視を追加すべきなのはユーザがアプリケーションとやりとりする所」
    19
    19
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  20. Burn rate alert
    Error Budget が消費されるレートに対してアラートを掛けるもの
    (期間あたりに観測されたエラーの数) / (期間あたりに許容されるエラーの数)
    1 より大きいとエラーバジェットを消費していることになる
    エラーバジェットの消費のされ方には大きく分けて 2 種類がある
    稼働が停止して全てのリクエストにエラーを返せる(Fast Burn)
    エラーバジェットの消費が早いので早めの対応が必要
    数多く断続的にエラーが発生するが殆どのリクエストは返せる(Slow Burn)
    エラーバジェットの消費は緩やかだが長期的に見ると問題になる
    これらの消費のされ方に対して適切にアラートを設定する
    例: 1 時間で 2 % エラーバジェットを消費したらアラートをページする
    例: 3 日間で 10% エラーバジェットを消費したらチケットを起票する
    20
    20
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  21. SLI/SLO/Burn rate alert の例
    SLI は次のように定める
    /search
    エンドポイントに対する 2xx+3xx+4xx リクエスト / 全リクエスト
    /search
    エンドポイントの 99 パーセンタイルレイテンシー / 全リクエスト
    SLO は次のように定める
    30 日間で 99.9% のリクエストが成功する
    30 日間で 99.9% のリクエストが 0.1 秒以内にレスポンスを返す
    Burn rate alert は次のように定める
    1 時間で 2 % エラーバジェットを消費したらアラートをページする
    30 * 24 * 0.02 = 14.4 がバーンレートになる
    3 日間で 10% エラーバジェットを消費したらチケットを起票する
    このようにしてアラート・チケット起票を設定して対応を行う
    21
    21
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  22. 閾値ベースのアラートとの違い(私見)
    これまでよく使われていた閾値ベースのアラートとの違い
    閾値ベースのアラートは固定値を使うことが多い
    ビジネスや環境の変化に追従しづらいことが多い
    ただ最近だと比率や線形回帰でのアラートも増えてきてはいる気がする
    複雑なシステムだとどこにアラートを仕掛けてよいか難しい
    結果いろいろなところにエラー数のアラートがあったりすることがある
    Burn rate alert は SLI/SLO の上に成り立っている
    より「ユーザ目線」に立ったアラートが設定される
    明確に見直しされるタイミングが定まっている
    開発チームやステークホルダーに理解してもらいやすい・説明しやすい
    SRE 本や SLO 本などさまざまなプラクティスを参照しやすい
    22
    22
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  23. まとめ
    SRE の概要とコアとなるプラクティスである SLI/SLO の説明をしました
    SLI/SLO の簡単な使い方について説明をしました
    SLI/SLO を定める際のポイントについて説明をしました
    SLI/SLO の運用について説明をしました
    SLI/SLO と監視の関係について説明をしました
    Burn Rate Alert について説明をしました
    閾値ベースのアラートとの違いについて説明をしました
    個人的には SLI/SLO のプラクティスはまさに「監視を育てる」だと思っています
    23
    23
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide

  24. Resources
    O'Reilly Japan - SRE サイトリライアビリティエンジニアリング
    Google SRE Book Updates, by Topic
    O'Reilly Japan - SLO サービスレベル目標
    O'Reilly Japan - サイトリライアビリティワークブック
    O'Reilly Japan - SREの探求
    O'Reilly Japan - 入門 監視
    SRE Classroom: The Art of SLOs - Google
    SRE の導入: SLO の設計プロセスを標準化する | Google Cloud 公式ブログ
    Service Level Calculator
    24
    24
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
    Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )

    View full-size slide