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.1k
モニタリングのよさ
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
SREsのためのSRE定着ガイド
netmarkjp
12
8.4k
SREこのへんで苦戦しがちじゃないですか?
netmarkjp
13
6.4k
技術書を活用してほしい!
netmarkjp
0
510
しつこくじわじわパフォーマンスチューニング
netmarkjp
1
1.2k
現場がさき、 プラクティスがあと、 原則はだいじに
netmarkjp
4
2.9k
ばばさんは、なぜ本を書くの?という話
netmarkjp
0
800
SRE≠インフラなんだけどもう誤解されちゃってる から、DevOps新実装として Site Production Engineering はいかがでしょう?
netmarkjp
2
2.1k
非ITの事業会社にSREと言わずにSREを持ち込んだ
netmarkjp
16
30k
変化の激しいWebの世界でコンスタントに局面局面で勝つ方法論「OODAループ」
netmarkjp
0
2k
Other Decks in Technology
See All in Technology
PHPで印刷所に入稿できる名札データを作る / Generating Print-Ready Name Tag Data with PHP
tomzoh
0
180
人はなぜISUCONに夢中になるのか
kakehashi
PRO
6
1.8k
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
7
2.5k
Raycast AI APIを使ってちょっと便利な拡張機能を作ってみた / created-a-handy-extension-using-the-raycast-ai-api
kawamataryo
0
190
RayでPHPのデバッグをちょっと快適にする
muno92
PRO
0
140
役員・マネージャー・著者・エンジニアそれぞれの立場から見たAWS認定資格
nrinetcom
PRO
1
3.2k
IAMポリシーのAllow/Denyについて、改めて理解する
smt7174
2
180
Goで作って学ぶWebSocket
ryuichi1208
3
2.5k
Apache Iceberg Case Study in LY Corporation
lycorptech_jp
PRO
0
260
エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜 / product discovery accelerated by engineers
rince
4
540
日経のデータベース事業とElasticsearch
hinatades
PRO
0
200
Exadata Database Service on Cloud@Customer セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
2
1.5k
Featured
See All Featured
For a Future-Friendly Web
brad_frost
176
9.6k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Raft: Consensus for Rubyists
vanstee
137
6.8k
BBQ
matthewcrist
87
9.5k
Java REST API Framework Comparison - PWX 2021
mraible
29
8.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Code Review Best Practice
trishagee
67
18k
Building Your Own Lightsaber
phodgson
104
6.2k
GitHub's CSS Performance
jonrohan
1030
460k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
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