Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
サービスレベル管理とは?〜計測すべき指標と活用について/What is Service Lev...
Search
New Relic
May 23, 2023
Technology
0
1.1k
サービスレベル管理とは?〜計測すべき指標と活用について/What is Service Level Management
2023/5/23開催「オブザーバビリティ最前線 〜 事例LTから学ぶ、オブザーバビリティの成熟度〜」
New Relic
May 23, 2023
Tweet
Share
More Decks by New Relic
See All by New Relic
監視からオブザーバビリティへ〜オブザーバビリティの成熟度/From Monitoring to Observability - Maturity of Observability
newrelic2023
9
8.1k
DevSecOpsへの展開〜全てのチームの能力を最大限に引き出す/Expanding to DevSecOps
newrelic2023
0
560
Other Decks in Technology
See All in Technology
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
180
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.9k
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
130
iOS/Androidで同じUI体験をネ イティブで作成する際に気をつ けたい落とし穴
fumiyasac0921
1
110
OCI Security サービス 概要
oracle4engineer
PRO
0
6.5k
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
430
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
130
FlutterアプリにおけるSLI/SLOを用いたユーザー体験の可視化と計測基盤構築
ostk0069
0
100
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1030
460k
What's in a price? How to price your products and services
michaelherold
243
12k
Facilitating Awesome Meetings
lara
50
6.1k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Gamification - CAS2011
davidbonilla
80
5k
A better future with KSS
kneath
238
17k
GraphQLとの向き合い方2022年版
quramy
43
13k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Transcript
© 2023 New Relic, Inc. All rights reserved サービスレベル管理 (SLM)
とは? - 計測すべき指標と活用について-
© 2022 New Relic, Inc. All rights reserved Observability成熟度モデル Data
Driven • データドリブンによる経営判断 • 素早い市場投入 • CSAT/Netスコアの改善 Predictive 予測的 Proactive 積極的 Reactive 受動的 • 顧客満足度 • SLOによる経営計画と判断 • 市場投入数 特徴 KPI Getting Started 4 2 3 0 1 • New Relicによる運用 • 顧客体験の改善 • ちょうどよいスケーリング • MTTD(Mean Time To Discover)の改善 • サービスレベルの計測 • デジタル顧客体験の策定 • MTTR(Mean Time To Repair)の改善 • アプリケーションパフォーマンスの気付き • 顧客に影響がある事象への対応の改善 • パフォーマンス計測 • スケールする製品の投入計画 • サービスレベルの維持 • 重大な障害率 • エラーバジェット消費率 • SLOに関連するアラート率 • ビジネスメトリックの改善率 • 平均MTTD • SLOが定義されているサービスの割合 • クリティカル・ケイパビリティの策定の割合 • 平均MTTR • パフォーマンス低下を伴う障害率 • サービス停止を伴う障害率 • New Relicでの監視率 • データの量 成熟度
© 2023 New Relic, Inc. All rights reserved SREの役割 “SREチームは、サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリン
グ、緊急対応、キャパシティプランニングに責任を負います。 ” 出典: SRE サイトリライアビリティエンジニアリング (Oreilly, 2017) 信頼性 イノベーション 3 常に新機能を追加しているサービスにとって、機能追加 (=変更)と信頼性はトレードオフ サイトリライアビリティエンジニアリングは、 信頼性におけるリスクとイノベーションの速度 および、サービス運用効率性というゴール とのバランスを取ることを目指すプラクティス
© 2023 New Relic, Inc. All rights reserved “信頼性”を計測・評価する イノベーションを推進するか否かを判断するためには、
サービスの信頼性の状態を計測し、その結果を評価する必要がある 信頼性 イノベーション vs 4 どちらを優先すべきか? 信頼性とは何か?
© 2023 New Relic, Inc. All rights reserved 評価可能な信頼性=SLO(サービスレベル目標) •
SLOとは、サービスの信頼性の目標レベル を示すものであり、 信頼性に関してデータを元に意思決定をする上で鍵となるもの • SLOを定めることによって、それに逸脱しないという 明確な基準を持って、 新機能のリリースを推進することができる • SLOは運用チーム、開発チーム、プロダクトチームの 共通言語として活用できる チーム種別 SLOを定めるメリット プロダクト 新機能の信頼性に対するコストをリアルタイムに知り、 優先順位付けができる 開発 エラーバジェットの範囲内でよりスピーディーに機能をリリース することができる 運用 闇雲にアラート対応している状態から、 データを元に信頼性を維持することができ、またそ の取組みを他チームと共有することができる 1つ1つのリリースを気にかけるのではなく、エラーバジェットをキープしながらより信頼性を 高める取り組みに専念することができる 5
© 2023 New Relic, Inc. All rights reserved SLA, SLO,
SLI • SLA(サービスレベルアグリーメント) • Service Level Agreement • サービスの信頼性に関する顧客との取り決め 6 • SLO(サービスレベル目標) • Service Level Objectives • SLAに抵触する前にサービスの信頼性に関する問題を検知するためのしきい値 • SLI(サービスレベル指標) • Service Level Indicator • SLOを満たすために計測すべき指標
© 2023 New Relic, Inc. All rights reserved SLIとSLOの関係 参考情報:
https://landing.google.com/sre/workbook/chapters/slo-document/ SLI ユーザーが満足しているか評価する尺度 例. LBのリクエスト処理の成功割合 (HTTPステータスが500-599以外のもの) SLO 個々のSLIに対する具体的な目標値 例. LBのリクエスト処理の成功割合が97% 7
© 2023 New Relic, Inc. All rights reserved SLI、SLOを定義して活用するステップ 1.
対象となるサービスの ユーザージャーニーを定義、 システム構成を確認 2. SLIメニュー等を参考に対 象サービスのSLIを定義 3. 定めたSLIに基づいて SLOを定義 4. SLIを計測して現状を リアルタイムに把握 5. エラーバジェットを活用し、 信頼性を高める 6. 定期的にSLI/SLO を見直す 8
© 2023 New Relic, Inc. All rights reserved 1. ユーザジャーニーと
アーキテクチャの確認 ユーザジャーニー ユーザーがサービスを利用する際の一連の動作 例. New Relicのユーザージャーニー (の一例) 1. ログイン画面を開く 2. ログインし、New Relicのページに行く 3. APMのメニューを開く 4. 詳細を確認したいアプリを選ぶ 5. ・・・ アーキテクチャ サービスを提供するシステムの構成要素 9
© 2023 New Relic, Inc. All rights reserved 2. SLIの定義
大前提: サービスを利用するユーザーが期待しているようなことを指標とする • 予測可能なものであることが望ましい(ユーザーの満足度とSLIが比例する) • 上の条件を満たすために、Valid Event(検査する総イベント)に対し、Good Event(総イベントのうち、“よい”と定義されたイベント)の割合で示す手法が一般 的 SLI = Valid Event(総イベント) Good Event(“良い”イベント) 10 例. サービスの応答時間が100ms以内だった割合
© 2023 New Relic, Inc. All rights reserved 2. SLIの定義
SLIの候補となる項目の一覧 (SLIメニュー) サービスの種類 SLIの種類 説明 Request/ Response 可用性(Availability) 正常に応答したリクエストの比率 どのリクエストを対象にするのか、 “正常”とは何かの定義が重要 ユーザージャーニーから離脱してしまうケースを想像し、正常を 0か1で評価できるものを選 択する 遅延(Latency) しきい値より早く応答したリクエストの比率 95%や99%で確認するのが一般的、ただし傾向を知るために 75%も見る場合も 品質(Quality) 特定の品質を満たしたリクエストの比率 過負荷や障害等でサービスがデグレする設計の場合、デグレしていないレスポンスを見る ためのもの、“degraded”というフラグを立てたりして計測 データ処理 新鮮さ(Freshness) ある特定の時間をしきい値にして、それより最近に更新されたデータの比率 正確性(Correctness) 正しい値の出力につながったデータ処理への入力レコードの比率 カバレッジ(Coverage) バッチ: ターゲット量以上のデータを処理したジョブの比率 ストリーム処理: ある時間ウィンドウ内に処理に成功した入力レコードの比率 ストレージ Durability(耐久性) 書き込まれたレコードのうち、正しく読み出せるものの比率 https://www.coursera.org/learn/site-reliability-engineering-slos/lecture/CST0V/the-sli-menu 11
© 2023 New Relic, Inc. All rights reserved 3. SLOの定義
定めたSLIに対して、目標値を設定する • 現状のサービスの状態が十分信頼性を満たしている場合は、 現状の値よりも悪化しないことを目標とした値を設定 • 現状のサービスが信頼性に欠けていると判断する場合は、 ユーザーが満足するであろう理想的な値を設定 12
© 2023 New Relic, Inc. All rights reserved 3. SLOの定義
高すぎる目標は高コスト 99.9% - 人が調査、修正、解決するのに十分な時間がある 99.99% - 自動化を実装して、停電を検出し、リダイレクトし、セルフヒーリングを実行する必要がある 99.999% - 分散システムのうち、ごく一部の機能だけが使えなくなる程度 Uptime Daily Weekly Monthly Yearly 99% 14 分 24 秒 1 時間 40 分 48 秒 7 時間 12 分 3 日 15 時間 36 分 99.9% 1 分 26 秒 10 分 5 秒 43 分 12 秒 8 時間 45 分 36 秒 99.99% 9 秒 1 分 4 分 19 秒 52 分 34 秒 99.999% 1 秒未満 6 秒 26 秒 5 分 15 秒 13
© 2023 New Relic, Inc. All rights reserved 4. SLIの計測
New Relicは幅広いデータソースを提供 一般的にはユーザに近い方が望ましいが、システム構成やみたい観点に応じて選択する New Relicの機能 メリット デメリット Log 柔軟な情報出力が可能 ロギングロジックを編集するためのコーディングの負荷 リアルタイム性の欠如(中長期的な分析に向く) APM (アプリケーションパ フォーマンス) 収集が容易 リアルタイムに観測が可能 複雑なユーザージャーニーとの関連付けが難しい Infrastructure (ロードバランサからの データ) 収集が容易 (クラウドプロバイダも提供している) ステートレスなデータしか収集できず、トラッキング不可 能 Synthetics(外形監視) ユーザージャーニーの把握が簡単 全てのユーザー体験を把握できるわけではない Browser / Mobile ユーザー体験を最も正確に知ることができる 不確定要素(ユーザーの利用環境等)のノイズが入る ユーザとの距離 近 遠 14
© 2023 New Relic, Inc. All rights reserved 5. エラーバジェットの活用
エラーバジェットとは • サービスの信頼性が損なわれることをどれくらい許容するかを示すメトリクス • 100% – SLO で導くことができる 例: あるユーザー操作のSLOが99%の成功率だとすると、1%がエラーバジェット 信頼性 イノベーション 15 エラーバジェットを設定することで、明確な指針を持って信頼性と 機能追加のどちらを優先するかを判断でき、関連するチームが 不必要な交渉をすることを防ぐことができる
© 2023 New Relic, Inc. All rights reserved 6. SLI/SLOの定期的な見直し
• SLOの変更 • 今設定しているSLOを満たしていてもユーザの満足度につながっていない場合 • SLO違反が発生してもユーザ影響が認められない場合 • SLIの実装の変更 • なるべくユーザの体験に近い方法に実装を変更する等 重要なのは、ユーザの声を可能な限り集めながら、それに沿ったSLI/SLOを検討し続けること 16
© 2023 New Relic, Inc. All rights reserved SREの中でのNew Relicの位置付け:
SLIの計測ツール 17 1. 対象となるサービスの ユーザージャーニーを定義、 システム構成を確認 2. SLIメニュー等を参考に対 象サービスのSLIを定義 3. 定めたSLIに基づいて SLOを定義 4. SLIを計測して現状を リアルタイムに把握 5. エラーバジェットを活用し、 信頼性を高める 6. 定期的にSLI/SLO を見直す
© 2023 New Relic, Inc. All rights reserved SLIの計測 -
SREを実践するうえでの根幹 SLIを計測することで初めて、現在 のサービスの信頼性を評価でき るようになる New Relicは簡単にSLIを計測で きるだけでなく、以下の点で最適 なツール • データのリアルタイム性 • 目的に応じた可視化 (SLOとの比較等) 18
© 2023 New Relic, Inc. All rights reserved New Relic
が提供する サービスレベル管理機能
© 2023 New Relic, Inc. All rights reserved サービス管理実現までの多くの決定すべき事項 -
悩むべき事項は山積みという現実 5 SLO違反の通知 違反があれば直ぐに把握できるのか? SLOを順守するためには、どのような体制を 準備しておけば良いのだろうか? 3 適切なSLOの設定 現状のサービスの状態はどうなっているの か? より品質を向上させるために適切な SLOはど こに設定するのが適切なのか? 1 サービス/システムとしてのあ るべき状態や品質の決定 サービスとしてあるべき状態や目標はどのよ うなものなのか?その状態や目標は、サー ビスやシステムの利用者にとって、期待に答 えているものなのか? 4 SLI/SLOの可視化 今どの様な状況なのか? 適切なメンバーと常に状況を気軽に把握で きる環境を用意できるのか? 2 計測施策の実現と 伴うSLIの決定 どうやって計測を行っていけばいいのか?ま た、どのデータを用いて、サービスの状態や 品質を計測していけば良いのか? 20
© 2023 New Relic, Inc. All rights reserved 21 サービス管理実現までの多くの決定すべき事項
- New Relicの活用 - 即座にサービス管理を開始する 5 SLO違反の通知 違反があれば直ぐに把握できるのか? SLOを順守するためには、どのような体制を 準備しておけば良いのだろうか? 3 適切なSLOの設定 現状のサービスの状態はどうなっているの か? より品質を向上させるために適切な SLOはど こに設定するのが適切なのか? 1 サービス/システムとしてのあ るべき状態や品質の決定 サービスとしてあるべき状態や目標はどのよ うなものなのか?その状態や目標は、サー ビスやシステムの利用者にとって、期待に答 えているものなのか? 4 SLI/SLOの可視化 今どの様な状況なのか? 適切なメンバーと常に状況を気軽に把握で きる環境を用意できるのか? 2 計測施策の実現と 伴うSLIの決定 どうやって計測を行っていけばいいのか?ま た、どのデータを用いて、サービスの状態や 品質を計測していけば良いのか? 豊富なベストプラクティス 迅速な運用を開始するためのプリ セットの提供 詳細なデータ計測を実現する様々 なエージェントと幅広いデータ連 携機能 専用ビューによるサービス状況の 解析と深い理解 強みや改善点の適切な把握 ダッシュボード機能による目的に 沿ったデータの可視化 指標に対する認識の共有 アラート機能による柔軟な通知機 能の実現 外部システムとの連携
© 2023 New Relic, Inc. All rights reserved サービス管理機能(Service levels)
直感的なUIで全体を簡単に把握
© 2023 New Relic, Inc. All rights reserved 個別のサービス品質状況を可視化 23
• 少しの設定作業で設定完了 • 設定に従って自動で可視化 • 可視化した情報を簡単にダッシュボードに追加可能
© 2023 New Relic, Inc. All rights reserved サービスレベルの設定はクリックだけで完了 24
設定のためにやること 1. [Add a service level indicator (SLI)] ボタンをクリック 2. Entity typeを選択 3. 利用したいプリセットSLIを選択 ※カスタムも可能、ハンズオンのoptionalを参照 4. 自動で計算される値を用いて SLIとSLOの閾値を設定 5. 管理用の名前を指定して設定を保存 24
© 2023 New Relic, Inc. All rights reserved プリセットSLI -
Browser/Synthetics/APM New Relic機能 Availability (Success) Latency Browser • 全ページビューリクエストに対する エラーフリーの総数 • Largest Contentful Paintがxx秒以内 • First Input Delayがxxミリ秒以内 • Cumulative Layout Shiftがxx以内 これら3つの値はCore Web Vitalsというユーザー 体験を代表する指標です Synthetics • 全チェックに対するチェック成功の総数 - APM • 全トランザクションに対する トランザクションエラーフリーの総数 • 全トランザクションに対して xx秒以内で処理 したものの割合がxx%以上 25
© 2023 New Relic, Inc. All rights reserved 補足: APM
UIからアプリのサービルレベルの参照 26 対象のアプリケーションに関連する Service Levelesだけが表示
© 2023 New Relic, Inc. All rights reserved. 参照:バーンレートやエラーバジェット、SLI達成に対する アラート設定が可能になりました
サービスレベルを元にした 3つのアラートを簡単設定 • 複雑なサービスレベルのアラート条 件を数クリックで設定できるようにな りました • ファストバーンレート、エラーバ ジェット消費、SLOコンプライアンス の3つのアラートタイプを選ぶことが できます アラートタイプを選ぶだけで、 ビジネスへの影響を考慮した アラート設定が可能! ファストバーンレート • エラーバジェットを1時間以内に 2%消費するとアラート • 消費量が突然大きく変化したこ とを検知する設定 エラーバジェット消費 • エラーバジェットの80%を 消費するとアラート通知 • エラーバジェットが無くなりそうな ことを検知する設定 SLOコンプライアンス • SLOを下回るとアラート 通知をする設定 • SLOを遵守できているか 知りたい場合に設定