Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
モニタリングのよさ
Search
Toshiaki Baba
January 20, 2021
Technology
1.7k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
モニタリングのよさ
iCARE Dev Meetup #17 2021-01-20 でLTしました
Toshiaki Baba
January 20, 2021
More Decks by Toshiaki Baba
See All by Toshiaki Baba
AIがコードを書く時代、人間は何を保証するのか———馬場さんと考える、開発者に求められる新しい責任と価値 - TECH PLAY
netmarkjp
0
1.8k
【ベテランCTOからのメッセージ】AIとか組織とかキャリアとか気になることはあるけどさ、個人の技術力から目を背けないでやっていきましょうよ
netmarkjp
2
5.8k
Forkewell Library 103 『バックエンドエンジニアのためのインフラ・クラウド大全』を通じたエンジニアとしての地力獲得活動のススメ
netmarkjp
9
45k
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
1k
著者による『バックエンドエンジニアのためのインフラ・クラウド大全』120%活用術
netmarkjp
1
2.1k
SREsのためのSRE定着ガイド
netmarkjp
12
10k
SREこのへんで苦戦しがちじゃないですか?
netmarkjp
13
7.5k
技術書を活用してほしい!
netmarkjp
0
710
しつこくじわじわパフォーマンスチューニング
netmarkjp
1
1.8k
Other Decks in Technology
See All in Technology
Screen Lens - 今見てる画面を翻訳する
komagata
0
220
The Agent Builder Loop from Daily Work to OSS
minorun365
PRO
3
120
AI-DLCって実際どう? 〜聞きたいこと全部聞いてみる〜
news_it_enj
0
250
こんなアーキテクチャ図は嫌だ BEYOND THE TIME: 半年後の自分へ贈る15のメッセージ / 15 of Anti-pattern in AWS Architecture Diagrams
naospon
3
300
AIで開発は速くなったのに、なぜ現場は楽にならないのか 〜あなたの組織のボトルネックを突き止めるワークショップ〜
jacopen
1
310
Multica × 長期記憶:40個のミニプロジェクト管理
eiei114
1
230
プロダクト思考 × 基盤思考を AIで実現する Compound Engineering
tkc66buzz
1
310
SQL文一行も書けない人事がCortexもろもろを使って人事業務を楽にしてみる
ponponmikankan
1
210
20260912_スクラムにジェネラリストは必要か
ryugen04
0
300
生成AIのテナント制御とシャドーMCP対策 | AIを"止めずに"、情報を守る
yukun
0
140
AIに丸投げしないトイル削減 / Eliminating Toil Without Leaving It All to AI
kohbis
4
1.1k
AI時代だからこそ、スケールしないことをやろう
yutashigemura
1
130
Featured
See All Featured
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.6k
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
520
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
56
3.5k
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.6k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.8k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
520
So, you think you're a good person
axbom
PRO
2
2.1k
Accessibility Awareness
sabderemane
1
210
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
Navigating Weather and Climate Data
rabernat
0
510
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.2k
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