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
1.6k
0
Share
モニタリングのよさ
iCARE Dev Meetup #17 2021-01-20 でLTしました
Toshiaki Baba
January 20, 2021
More Decks by Toshiaki Baba
See All by Toshiaki Baba
【ベテランCTOからのメッセージ】AIとか組織とかキャリアとか気になることはあるけどさ、個人の技術力から目を背けないでやっていきましょうよ
netmarkjp
2
4.5k
Forkewell Library 103 『バックエンドエンジニアのためのインフラ・クラウド大全』を通じたエンジニアとしての地力獲得活動のススメ
netmarkjp
9
44k
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
840
著者による『バックエンドエンジニアのためのインフラ・クラウド大全』120%活用術
netmarkjp
1
1.9k
SREsのためのSRE定着ガイド
netmarkjp
12
10k
SREこのへんで苦戦しがちじゃないですか?
netmarkjp
13
7.3k
技術書を活用してほしい!
netmarkjp
0
690
しつこくじわじわパフォーマンスチューニング
netmarkjp
1
1.7k
現場がさき、 プラクティスがあと、 原則はだいじに
netmarkjp
4
3.7k
Other Decks in Technology
See All in Technology
Harnessing the Power of Mocks and Stubs in PHPUnit / #laravellivejp
asumikam
0
710
Don't Just Patch — MOTTAINAI! Learn Security from Laravel CVE Diffs
codmoninc
0
140
Claude Codeですべての日常業務を爆速化しよう!
minorun365
PRO
16
15k
個人AIからチームAIへ:開発における品質と生産性の再設計
moongift
PRO
0
250
大規模災害時でも高い信頼性を維持するアプリケーション基盤の実現/nikkei-tech-talk46
nikkei_engineer_recruiting
0
110
はじめてのDatadog
kairim0
0
140
Cloud Run のアップデート 触ってみる&紹介
gre212
0
180
OpenID Connectによるサービス間連携
takesection
0
130
Amazon Bedrock 経由の Claude Cowork を試してみよう・MCP にも繋いでみよう
sugimomoto
0
220
Gradle×GitHub_ActionsでCI時間を約50%短縮 ジョブ分割の設計と落とし穴 / Cutting CI Time by ~50% with Gradle and GitHub Actions: Job-Splitting Design and Pitfalls
takatty
0
460
速さだけじゃない! VoidZero ツールが移行先に選ばれる理由
mizdra
PRO
3
280
freee-mcpを Local→Remote で出してわかった MCP認可実装のリアル
terara
3
890
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.1k
How to build a perfect <img>
jonoalderson
1
5.5k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
1.5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
140
The Cult of Friendly URLs
andyhume
79
6.9k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
130
The SEO Collaboration Effect
kristinabergwall1
1
460
Measuring & Analyzing Core Web Vitals
bluesmoon
9
830
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
310
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
180
How Software Deployment tools have changed in the past 20 years
geshan
0
34k
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