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
モニタリングのよさ
Search
Toshiaki Baba
January 20, 2021
Technology
0
1.4k
モニタリングのよさ
iCARE Dev Meetup #17 2021-01-20 でLTしました
Toshiaki Baba
January 20, 2021
Tweet
Share
More Decks by Toshiaki Baba
See All by Toshiaki Baba
Forkewell Library 103 『バックエンドエンジニアのためのインフラ・クラウド大全』を通じたエンジニアとしての地力獲得活動のススメ
netmarkjp
9
3.9k
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
530
著者による『バックエンドエンジニアのためのインフラ・クラウド大全』120%活用術
netmarkjp
1
1.2k
SREsのためのSRE定着ガイド
netmarkjp
12
9.6k
SREこのへんで苦戦しがちじゃないですか?
netmarkjp
13
6.9k
技術書を活用してほしい!
netmarkjp
0
630
しつこくじわじわパフォーマンスチューニング
netmarkjp
1
1.5k
現場がさき、 プラクティスがあと、 原則はだいじに
netmarkjp
4
3.4k
ばばさんは、なぜ本を書くの?という話
netmarkjp
0
1.1k
Other Decks in Technology
See All in Technology
それでは聞いてください「Impeller導入に失敗しました」 #FlutterKaigi #skia
tacck
PRO
0
140
LINEヤフー バックエンド組織・体制の紹介
lycorptech_jp
PRO
0
810
身近なCSVを活用する!AWSのデータ分析基盤アーキテクチャ
koosun
0
1.9k
なぜThrottleではなくDebounceだったのか? 700並列リクエストと戦うサーバーサイド実装のすべて
yoshiori
13
4.7k
ECS組み込みのBlue/Greenデプロイを動かしてELB側の動きを観察してみる
yuki_ink
1
130
現地速報!Microsoft Ignite 2025 M365 Copilotアップデートレポート
kasada
1
1.2k
ZOZOTOWNカート決済リプレイス ── モジュラモノリスという過渡期戦略
zozotech
PRO
0
460
AIでテストプロセスを自動化しよう251113.pdf
sakatakazunori
1
230
米軍Platform One / Black Pearlに学ぶ極限環境DevSecOps
jyoshise
2
490
Dart and Flutter MCP serverで実現する AI駆動E2Eテスト整備と自動操作
yukisakai1225
0
570
入社したばかりでもできる、 アクセシビリティ改善の第一歩
unachang113
2
310
AIと自動化がもたらす業務効率化の実例: 反社チェック等の調査・業務プロセス自動化
enpipi
0
670
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
186
22k
Code Review Best Practice
trishagee
72
19k
Why Our Code Smells
bkeepers
PRO
340
57k
Agile that works and the tools we love
rasmusluckow
331
21k
Git: the NoSQL Database
bkeepers
PRO
432
66k
Optimising Largest Contentful Paint
csswizardry
37
3.5k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
What's in a price? How to price your products and services
michaelherold
246
12k
Rails Girls Zürich Keynote
gr2m
95
14k
Product Roadmaps are Hard
iamctodd
PRO
55
12k
A better future with KSS
kneath
239
18k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
980
Transcript
モニタリング のよさ iCARE Dev Meetup #17 2021-01-20 Toshiaki Baba
今日、話したいこと • ばばさんが思う「モニタリングのよさ」を共有します ◦ × :(テクノロジスタックとしての)インフラ ◦ ◦ :(サービス・システムのための)インフラ :
≒プラットフォーム • 今日でも後日でもリアクションいただけると嬉しいです ◦ 共感した ◦ 共感しかなかった ◦ ... 2
自己紹介 馬場俊彰(ばばとしあき): @netmarkjp https://netmark.jp/ 株式会社X-Tech 5 取締役 CTO https://x- tech5.co.jp/
お仕事: ユーザ体験を軸にした、システム運用プラットフォームや体制・制度・チームの、 設計・構築・提供・伴走・コンサル 個人の主な守備範囲: Webシステムのインフラ・ミドルウェア全般、モニタリング、チューニング、プ ログラミング(Python、Go) 3 Amazon著者ページ https://www.amazon.co.jp/%E9%A6%AC%E5%A0%B4-%E4%BF%8A%E5%BD%B0/e/B004Y4SUBY
近著:Software Design 2021年2月号 第2特集 「何からやるか,どこからやるか」がわかる システム監視の始め方・続け方 第1章:システム監視の魅力・価値・意義 高まる監視の必要性,その背景とは? …… 馬場
俊彰 第2章:監視システム導入の悩みどころと解決策 認識をそろえ,優先事項を絞り込む …… 馬場 俊彰 第3章:Datadogで実践するSaaS監視 SaaSでどこまで監視できる? …… 近藤 健司 4
大前提:システムにまつわる残念な事実 • 『Webエンジニアのための監視システム実装ガイド』より システムは何もしないと壊れる • システムはよくわからない状態になる ⇒状況を把握するためにモニタリングが必要 • 平常時の各種計数を観測・記録 •
現状の各種計数を観測・記録 5
サービス・システムの存在意義(使命) 6
サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 7 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA :
サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 8 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA :
評価・検証 定量 定性
定量評価 1. 指標を決める :計測項目・計測方法を決定 2. 計測する :対象を観測し特定の基準のもとで数値化 3. 値を解釈する :データから相関や因果を推定・発見する
ユーザの期待値と達成状況を観測・記録 9
定量評価 1. 指標を決める :計測項目・計測方法を決定 2. 計測する :対象を観測し特定の基準のもとで数値化 3. 値を解釈する :データから相関や因果を推定・発見する
ユーザの期待値と達成状況を観測・記録 10 まずコレがムズい!
サービス・システムの創出価値を計測する指標 SRE(Site Reliability Engineering)のプラクティスではSLIと呼称 Service Level Indicator 未だ決定版はない • Time-based(uptime)
• Count-based(request) • Windowed user-uptime https://www.usenix.org/conference/nsdi20/presentation/hauer • ... 11
サービス・システムの創出価値を計測する指標 SRE(Site Reliability Engineering)のプラクティスではSLIと呼称 Service Level Indicator 未だ決定版はない • Time-based(uptime)
• Count-based(request) • Windowed user-uptime https://www.usenix.org/conference/nsdi20/presentation/hauer • ... 12 サービス・システムがユーザと共有している価値観に基 づくので、サービス・システムごとに異なるのが自然
サービス・システムがユーザと共有している価値観 「価値」は個人的・相対的なもの →特性1 :ユーザの体験に基づいてのみ発生し得る →特性2 :とある基準で全ユーザを対象に計測するのは芯を外す可能性。 :ボンヤリした、無難で汎用的で交換可能な指標に行き着きがち :(典型的には、お金か時間) 13
サービス・システムがユーザと共有している価値観 「価値」は個人的・相対的なもの →特性1 :ユーザの体験に基づいてのみ発生し得る →特性2 :とある基準で全ユーザを対象に計測するのは芯を外す可能性。 :ボンヤリした、無難で汎用的で交換可能な指標に行き着きがち :(典型的には、お金か時間) 14 結論:ムズい!
ちなみにSRE(Site Reliability Engineering) 代表的なプラクティス • ソフトウェアエンジニアリング • SLI策定(と更新) • Error
Budget策定(と更新) • Toil削減(常時50%以下を死守) 15 SREは、複雑で大規模なコンピュータシステムを運用するときにシステムの成長・拡大に比例して運用系エンジニア数が どんどん増えてしまうのをなんとかしたいというモチベーションのもと、複雑で大規模なコンピュータシステムの運用を ソフトウェアエンジニアリングとしてあるべき姿にすること、組織構造的な対立をなくすことを基本的なコンセプトとし ています。 オペレーションエンジニアを全廃しソフトウェアエンジニアが運用フェーズでやらねばならぬことをやるためにソフトウ ェアエンジニアによる伝統的オペレーションの破壊・再定義・置換を行うこと、伝統的オペレーションを排するために会 社がSREを支持・支援することをコアプラクティスとしています。 Webエンジニアのための監視システム実装ガイド p.12
Pick Up:Error Budget ざっくり言うと、SLIの目標範囲 結果としてのSLIには、ちょうどいい塩梅がある • SLIが低すぎる =ユーザに価値を与えられていない • SLIが高すぎる
=過剰品質やチャレンジ不足の可能性 =ユーザに与えられるはずだった価値を目減りさせているのでは!? (競合にわざわざ付け入る隙を与えている可能性も...) 16
話を戻します 17
サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 18 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA :
サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 19 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA :
モニタリングを押さえる すなわち サービス・システムの存在意義の 根幹を押さえる
サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 20 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA :
モニタリングを押さえる すなわち サービス・システムの存在意義の 根幹を押さえる 世界で一番、適切な 判断ができる可能性
モニタリングを修めた者 だけが司令塔になれる 21
モニタリングを修めた司令塔なら SLIに基づいて適切(と考えられる)な判断軸を持てる • やることの優先順位を決められる • やらないことのラインを決められる →判断根拠、主体性、心の安定、自信が得られる 例: • アラートAとアラートBが同時に発報したけど、AよりBのほうがSLIインパク
ト(≒ユーザ体験への影響)が大きいので、AはさておいてまずはBを全力で やる • このサーバがこうダウンしてもSLI(≒ユーザ体験)にはこの程度しか影響が ないから通知しない 22
例:ISUCON 23 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避
例:ISUCON 24 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい
例:ISUCON 25 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい ここができる=地味
例:ISUCON 26 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい ここができる=地味
でも、ここができるからこそ、 対策が当たる可能性がある
例:ISUCON 27 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい ここができる=地味
でも、ここができるからこそ、 対策が当たる可能性がある モニタリングができるようになると、総当 たりやあてずっぽう以外の方法でチューニ ングできるようになる
例:ISUCON 28 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい ここができる=地味
でも、ここができるからこそ、 対策が当たる可能性がある モニタリングができるようになると、総当 たりやあてずっぽう以外の方法でチューニ ングできるようになる モニタリングができるようになると、 ISUCON決勝進出の可能性が出てくる
How to be ... 29 Webエンジニアのための 監視システム実装ガイド (わたしが書きました) https://amzn.to/2yDn8zc モニタリングについての本。
歴史、トレンド、仕組み、 目的、意義、構成例などを 詰め込みました。 Webエンジニアが知っておきたい インフラの基本 (わたしが書きました) https://amzn.to/2UFnm0a 本講の内容をより深く知る ならこの本が最適。 Webシステム運用において 知らないことが激減すると 思います。
モニタリングを押さえれば システムの根幹を 掌握したも同然 30