Slide 1

Slide 1 text

モニタリング のよさ iCARE Dev Meetup #17 2021-01-20 Toshiaki Baba

Slide 2

Slide 2 text

今日、話したいこと ● ばばさんが思う「モニタリングのよさ」を共有します ○ × :(テクノロジスタックとしての)インフラ ○ ○ :(サービス・システムのための)インフラ : ≒プラットフォーム ● 今日でも後日でもリアクションいただけると嬉しいです ○ 共感した ○ 共感しかなかった ○ ... 2

Slide 3

Slide 3 text

自己紹介 馬場俊彰(ばばとしあき): @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

Slide 4

Slide 4 text

近著:Software Design 2021年2月号 第2特集 「何からやるか,どこからやるか」がわかる システム監視の始め方・続け方 第1章:システム監視の魅力・価値・意義 高まる監視の必要性,その背景とは? …… 馬場 俊彰 第2章:監視システム導入の悩みどころと解決策 認識をそろえ,優先事項を絞り込む …… 馬場 俊彰 第3章:Datadogで実践するSaaS監視 SaaSでどこまで監視できる? …… 近藤 健司 4

Slide 5

Slide 5 text

大前提:システムにまつわる残念な事実 ● 『Webエンジニアのための監視システム実装ガイド』より システムは何もしないと壊れる ● システムはよくわからない状態になる ⇒状況を把握するためにモニタリングが必要 ● 平常時の各種計数を観測・記録 ● 現状の各種計数を観測・記録 5

Slide 6

Slide 6 text

サービス・システムの存在意義(使命) 6

Slide 7

Slide 7 text

サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 7 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA :

Slide 8

Slide 8 text

サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 8 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA : 評価・検証 定量 定性

Slide 9

Slide 9 text

定量評価 1. 指標を決める :計測項目・計測方法を決定 2. 計測する :対象を観測し特定の基準のもとで数値化 3. 値を解釈する :データから相関や因果を推定・発見する ユーザの期待値と達成状況を観測・記録 9

Slide 10

Slide 10 text

定量評価 1. 指標を決める :計測項目・計測方法を決定 2. 計測する :対象を観測し特定の基準のもとで数値化 3. 値を解釈する :データから相関や因果を推定・発見する ユーザの期待値と達成状況を観測・記録 10 まずコレがムズい!

Slide 11

Slide 11 text

サービス・システムの創出価値を計測する指標 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

Slide 12

Slide 12 text

サービス・システムの創出価値を計測する指標 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 サービス・システムがユーザと共有している価値観に基 づくので、サービス・システムごとに異なるのが自然

Slide 13

Slide 13 text

サービス・システムがユーザと共有している価値観 「価値」は個人的・相対的なもの →特性1 :ユーザの体験に基づいてのみ発生し得る →特性2 :とある基準で全ユーザを対象に計測するのは芯を外す可能性。 :ボンヤリした、無難で汎用的で交換可能な指標に行き着きがち :(典型的には、お金か時間) 13

Slide 14

Slide 14 text

サービス・システムがユーザと共有している価値観 「価値」は個人的・相対的なもの →特性1 :ユーザの体験に基づいてのみ発生し得る →特性2 :とある基準で全ユーザを対象に計測するのは芯を外す可能性。 :ボンヤリした、無難で汎用的で交換可能な指標に行き着きがち :(典型的には、お金か時間) 14 結論:ムズい!

Slide 15

Slide 15 text

ちなみにSRE(Site Reliability Engineering) 代表的なプラクティス ● ソフトウェアエンジニアリング ● SLI策定(と更新) ● Error Budget策定(と更新) ● Toil削減(常時50%以下を死守) 15 SREは、複雑で大規模なコンピュータシステムを運用するときにシステムの成長・拡大に比例して運用系エンジニア数が どんどん増えてしまうのをなんとかしたいというモチベーションのもと、複雑で大規模なコンピュータシステムの運用を ソフトウェアエンジニアリングとしてあるべき姿にすること、組織構造的な対立をなくすことを基本的なコンセプトとし ています。 オペレーションエンジニアを全廃しソフトウェアエンジニアが運用フェーズでやらねばならぬことをやるためにソフトウ ェアエンジニアによる伝統的オペレーションの破壊・再定義・置換を行うこと、伝統的オペレーションを排するために会 社がSREを支持・支援することをコアプラクティスとしています。 Webエンジニアのための監視システム実装ガイド p.12

Slide 16

Slide 16 text

Pick Up:Error Budget ざっくり言うと、SLIの目標範囲 結果としてのSLIには、ちょうどいい塩梅がある ● SLIが低すぎる =ユーザに価値を与えられていない ● SLIが高すぎる =過剰品質やチャレンジ不足の可能性 =ユーザに与えられるはずだった価値を目減りさせているのでは!? (競合にわざわざ付け入る隙を与えている可能性も...) 16

Slide 17

Slide 17 text

話を戻します 17

Slide 18

Slide 18 text

サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 18 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA :

Slide 19

Slide 19 text

サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 19 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA : モニタリングを押さえる すなわち サービス・システムの存在意義の 根幹を押さえる

Slide 20

Slide 20 text

サービス・システムの存在意義(使命) 価値を創出しユーザに届ける 継続的に価値を創出するために、変化し続ける 20 戦略レベル施策 戦術レベル施策 評価・検証 PDCA OODA : モニタリングを押さえる すなわち サービス・システムの存在意義の 根幹を押さえる 世界で一番、適切な 判断ができる可能性

Slide 21

Slide 21 text

モニタリングを修めた者 だけが司令塔になれる 21

Slide 22

Slide 22 text

モニタリングを修めた司令塔なら SLIに基づいて適切(と考えられる)な判断軸を持てる ● やることの優先順位を決められる ● やらないことのラインを決められる →判断根拠、主体性、心の安定、自信が得られる 例: ● アラートAとアラートBが同時に発報したけど、AよりBのほうがSLIインパク ト(≒ユーザ体験への影響)が大きいので、AはさておいてまずはBを全力で やる ● このサーバがこうダウンしてもSLI(≒ユーザ体験)にはこの程度しか影響が ないから通知しない 22

Slide 23

Slide 23 text

例:ISUCON 23 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避

Slide 24

Slide 24 text

例:ISUCON 24 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい

Slide 25

Slide 25 text

例:ISUCON 25 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい ここができる=地味

Slide 26

Slide 26 text

例:ISUCON 26 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい ここができる=地味 でも、ここができるからこそ、 対策が当たる可能性がある

Slide 27

Slide 27 text

例:ISUCON 27 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい ここができる=地味 でも、ここができるからこそ、 対策が当たる可能性がある モニタリングができるようになると、総当 たりやあてずっぽう以外の方法でチューニ ングできるようになる

Slide 28

Slide 28 text

例:ISUCON 28 計測 ボトルネック箇所を特定 対策実施 解決 緩和 回避 ここができる=強い=カッコいい ここができる=地味 でも、ここができるからこそ、 対策が当たる可能性がある モニタリングができるようになると、総当 たりやあてずっぽう以外の方法でチューニ ングできるようになる モニタリングができるようになると、 ISUCON決勝進出の可能性が出てくる

Slide 29

Slide 29 text

How to be ... 29 Webエンジニアのための 監視システム実装ガイド (わたしが書きました) https://amzn.to/2yDn8zc モニタリングについての本。 歴史、トレンド、仕組み、 目的、意義、構成例などを 詰め込みました。 Webエンジニアが知っておきたい インフラの基本 (わたしが書きました) https://amzn.to/2UFnm0a 本講の内容をより深く知る ならこの本が最適。 Webシステム運用において 知らないことが激減すると 思います。

Slide 30

Slide 30 text

モニタリングを押さえれば システムの根幹を 掌握したも同然 30