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

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

Transcript

1. 「信頼性」の育て方 Ryota Yoshikawa ( @rrreeeyyy ) 1 1 Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
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
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 )
4. Waroom ( #PR ) https://waroom.com/ インシデントレスポンスを改善するための SaaS を作っています インシデント対応チームの設定と自動招集 インシデント発生時に対応手順を表示 インシデントステートドキュメントの自動生成 ポストモーテムの自動生成 蓄積したインシデント情報の可視化 4 4 Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
5. Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) 5 5
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 )
7. Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) 7 7
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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )
17. 「完璧である必要はない」 とはいえはじめて SLI/SLO を定めるときに完璧である必要はない 重要なのは始めて改善していけるような素早いフィードバックループを行うこと むしろ最初のうちは少ない SLI/SLO から小さく始めていく方が良いと思う 例:「サービスにとって重要なユーザージャーニー」が正しいか分からない 「正しさ」は恐らく無い（そして変化していく）ので始めてみて改善するのが大事 例: SLI をちゃんと計測するために複雑なアーキテクチャを作りそうになる エンジニアリング作業が最小になるように始める ログがあるならログを使うなど 例: 開発チームのステークホルダーとの合意が取れていない もちろん取れていることがベターだけど SRE チーム内だけの意思決定にも使える SRE チーム内でドッグフーディングして上手く行った姿を見せることでステークホルダ ーとの合意を取りやすくすることもできる 17 17 Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
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 )
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 )
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 )
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 )
22. 閾値ベースのアラートとの違い（私見） これまでよく使われていた閾値ベースのアラートとの違い 閾値ベースのアラートは固定値を使うことが多い ビジネスや環境の変化に追従しづらいことが多い ただ最近だと比率や線形回帰でのアラートも増えてきてはいる気がする 複雑なシステムだとどこにアラートを仕掛けてよいか難しい 結果いろいろなところにエラー数のアラートがあったりすることがある Burn rate alert は SLI/SLO の上に成り立っている より「ユーザ目線」に立ったアラートが設定される 明確に見直しされるタイミングが定まっている 開発チームやステークホルダーに理解してもらいやすい・説明しやすい SRE 本や SLO 本などさまざまなプラクティスを参照しやすい 22 22 Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy ) Mackerel Meetup #15 | Ryota Yoshikawa ( @rrreeeyyy )
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 )
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 )