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
Qryuu
January 24, 2021
Technology
8
8.2k
監視とは何か ~監視エンジニアのスキルと成長~
July Tech Festa 2021 winter E2セッションの資料です
ITシステム監視とは何か
監視エンジニアの未来
監視エンジニアのトレーニング
次世代MSPの役割
Qryuu
January 24, 2021
Tweet
Share
More Decks by Qryuu
See All by Qryuu
監視論Ⅳ ~監視からオブザーバビリティーへの招待~
qryuu
0
270
人体モニタリングによる運動療法継続
qryuu
0
120
オブザーバビリティで理解するコンピュータサイエンス
qryuu
1
1.3k
監視論 ~SREと次世代MSP~
qryuu
10
4.7k
Other Decks in Technology
See All in Technology
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide
takaking22
14
5.3k
SREのキャリア、 あるいは生態 / #ya8
cohalz
10
1k
[AWS Expert Online for JAWS-UG]AWS SAW を使ったトラブルシューティング効率化のススメ
furuton
0
170
小さく始めるAnsible
stopendy
0
210
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
soudai
20
5k
本気でプロダクトに向き合うCTOになるために必要な事 (技育祭2024春)
mosa_siru
33
12k
SwiftUIのpropertyWrapperをふんわり理解する
jambo_develop_team
0
110
『QAという人』が必要ではなく、『QAという技術』が必要
sadonosake
2
270
Feature Flag Deep Dive
biwashi
20
5.1k
SSMエージェントはIAMロールの夢を見るか/ Do SSM Agents Dream Of IAM Roles?
yukihirochiba
0
1.4k
Beginner's Guide to Partitioning vs. Sharding in Postgres | Claire Giordano | Nordic PGDay 2024
clairegiordano
0
210
スクラムマスター不在でスクラムをやるのは(とても辛いので)やめておけ! #scrumfukuoka
nulabinc
PRO
4
900
Featured
See All Featured
Embracing the Ebb and Flow
colly
78
4.1k
Mobile First: as difficult as doing things right
swwweet
215
8.5k
The World Runs on Bad Software
bkeepers
PRO
60
6.6k
Unsuck your backbone
ammeep
660
56k
Code Reviewing Like a Champion
maltzj
512
39k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
240
1.2M
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
28
5.9k
How to name files
jennybc
62
91k
For a Future-Friendly Web
brad_frost
170
8.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
19
1.6k
5 minutes of I Can Smell Your CMS
philhawksworth
199
19k
Keith and Marios Guide to Fast Websites
keithpitt
407
22k
Transcript
監視とは何か ~監視エンジニアのスキルと成長~
自己紹介 ▪ PN:九龍真乙 ▪ Twitter: @qryuu ▪ SlideShre: https://www.slideshare.net/qryuu ▪
GitHub: https://github.com/qryuu ▪ クックパッド: https://cookpad.com/kitchen/4142562 ▪ Youtube: https://www.youtube.com/channel/UCcPidyLCfGp49pmF4Zb761Q ▪ 専門:New Relic, Zabbix, テクニカルサポート, クラウドアーキテクト ▪ 所属:OpsJAWSコアメンバー、New Relic株式会社、Zabbixユーザー会 2
セッションの目的 3
セッションの目的 ▪ 監視ツール、監視SaaSなどITシステム監視に関する ツールや仕組みについては多くのドキュメントがあります。 しかしそもそもITシステム監視そのものについてはあまり語ら れる事がありません。 ▪ 特定の監視ツールや監視サービスについてではなく ITシステム監視そのものの定義や意義、監視サービスのあるべ き未来やオブザーバビリティーについて考察します。
▪ マイクロサービスやSREといった変化のなかで次世代MSPや モニタリングエンジニアの生存戦略ついて考えます。 4
セッションの概要 ▪ ITシステム監視とは何か ▪ 監視エンジニアの未来 ▪ 監視エンジニアのトレーニング ▪ 次世代MSPの役割 5
ITシステム監視とは 6
ITシステム監視とは ▪ プロセス監視 ▪ 機器監視 ▪ アプリケーション性能監視 ▪ リアルユーザーモニタリング ▪
ログ監視 ▪ オブザーバビリティー 7
ITシステム監視とは ▪ システム監視の目的はシステムの安定稼働 ▪ システム稼働効率の最適化 ▪ アプリケーションの改善 8
監視システムの5要素 9
監視システムの5要素 ▪ 収集 ▪ 判定 ▪ 通知 ▪ 分析 ▪
オブザーバビリティー 10
収集 ▪ 対象システムやセンサー、ネットワーク機器等からデータを集 める。 ▪ CPU使用率やメモリ使用率、ディスク情報やネットワーク負荷 ログ情報や環境データの収集を行う。 11
収集 ▪ 標準的なプロトコルやAPIにより監視ツールなどにデータ提供 を行う対象システム ▪ 監視システム独自Agentによって対象システムからデータ収集 を行う ▪ 対象システム自身の状態確認コマンド、統計コマンドにより出 力される情報をスクリプトやAgent等により収集する場合もあ
る。 12
判定 ▪ 収集により集められたデータに対して、正常・障害/ノーマ ル・アラートなどの判定を行う。 ▪ 判定では、「イコール/ノットイコール」や「含む/含まない」、 「以上/以下(超過/未満)」 などにより、数値判定、文字列判定を行う。 ▪ 近似計算による将来値予測を行いこの予測値に対する判定を行
うシステムも登場している。 ▪ 複数の条件やAIの利用など判定の高度化も行われている 13
通知 ▪ 通知先は人間とは限らない ▪ システムに通知する=自動復旧・自律制御 ▪ 何のために通知するのか=通知するけど静観は意味が無い ▪ 通知した後のフローを意識して通知条件を設計する ▪
通知を受けた人物が「決断」「操作」する必要がある場合に 通知する ▪ アリバイとしての通知をしない。 14
分析 ▪ ソース – 収集されたデータ – 判定の頻度 ▪ 目的 –
現状把握 – 将来予測 ▪ 効果 – ボトルネックの判断 – ボトルネックの移動予測 – コスト最適化 15
分析 ▪ 分析は立案である ▪ 監視は終端ではなく先端 ▪ 分析に必要な能力は勘ではなく知識 16
オブザーバビリティー ▪ 現象ではなく、その原因を探る ▪ 収集対象を増やし分析をリアルタイムにより深化させる。 ▪ 監視:異常検知 ▪ オブザーバビリティー:原因究明 17
オブザーバビリティー ▪ 現象ではなく、その原因を探る ▪ 収集対象を増やし分析をリアルタイムに より深化させる。 ▪ 監視:異常検知 ▪ オブザーバビリティー:原因究明
18 ! ! ! 問題症状 問題症状 問題症状 根本原因 根本原因 問 題 ! ! 問題症状 根本原因 根本原因
オブザーバビリティー ▪ オブザーバビリティーを得るためには、もっと全体的な可視化 が必要 ▪ RUM、APM ▪ Prometheus連携やAPM連携など 19
なぜ可視化するのか 20
なぜ可視化するのか ▪ 監視対象データは時系列データ ▪ 瞬間値ではなく、値の推移が意味を持つ ▪ 数値表を眺めるのではなくグラフ化することで変曲点が把握で きる。 ▪ ボトルネック分析やシステム負荷ではデータ同士の相関やス
ケール変更が重要 ▪ データアナリストやデータサイエンティストに繋がる経験 21
監視エンジニアトレーニング Zabbix IoTと気象観測 22
可視化の意味を体得する ▪ 一番良いのは実際に壊せる環境 ▪ 壊せる環境が難しければ気象観測をしてみよう 23 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb
周期性を見つける ▪ 時間と値の関連性を見つける 24 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb
外れパターンを見つける ▪ 曇っていた? 25 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb
関連する複数のデータを比較する ▪ 日なたと日陰の気温を比べれば晴れか曇りかが特定できる 26 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb
異なる指標の関連を推測する 気温と気圧から台風の通過 を知る 27
MSPという業態 28
MSPという業態 ▪ MSP(Managed Service Provider) ▪ MSP(Monitoring Service Provider) ▪
MSPは本来運用サービスを提供するものであるが、実体として は監視サービスを提供し、サービス運用についてはエンドユー ザの指示に従うような業態となっている。 29
MSPという業態 ▪ AWSがMSPパートナープログラムとして、「Next Generation MSP」としてパートナー要件を定義 ▪ MSPに高度なナレッジ、システムの自動化、DevOpsの実現な どが求められた。 30
MSPという業態 ▪ DevOps=開発・SIer機能 ▪ ナレッジ提供=コンサルティング機能 ▪ 24-365=カスタマーサポート機能 31
SREの役割 32
SREの役割 ▪ SRE(Site Reliability Engineering) ▪ 運用のためのコードを書く ▪ 開発者が運用を行うという思想 ▪
SREとはITサービス企業自身の役割でありMSPのようなアウト ソーサーとして提供する事に向いたロールでは無い。 ▪ 少なくとも業態や関係性を変える必要がある 33
監視の役割は開発ではない 34
監視エンジニアとしての価値 ▪ SREが登場した当時DevOpsの文脈が強くOpsやSREも開発を 行うという総員コーダーのような雰囲気が強くなった。 ▪ OpsやSREの本領はパフォーマンスの分析でありそこで求めら れる能力は統計やログ解析、アプリケーション解析である。 ▪ 大規模SaaSではSREとソフトウェアデペロッパーは別のチー ム
▪ SREやOpsに求められる役割は根拠となるデータを示し、設計 フェイズに対してフィードバックを行う事 35
知識と技術 36
知識と技術 論理 センス 知識 技術 学者 職人 コンピュータサイエンス プログラミング Opsの特性
Devの特性 37
知識と技術 ▪ どちらが優れているではなく人類が進歩するために必要な両輪 ▪ 天才的とされる人材は1人で両方のスキルを兼ね備える場合も あるが、組織設計においては本来両方が補完関係にあるべき 38
設計と監視 Opsサンドイッチ 39
設計と監視 Opsサンドイッチ 40
MSPやSREを活かす開発体制 ▪ 分析に基づくフィードバックを適切 にソフトウェアの実装に反映する開 発体制が必要 ▪ フィードバックを反映しその効果を 確認するまでの期間は1週間以内長 くとも1ヶ月以内が理想的 ▪
ショートウォーターフォール、ア ジャイルモデル ▪ MSPが作業オペレーターでは無く次 世代MSPとなるためにはユーザー企 業やSIを巻き込んだより密な連携が できる契約が必要 41 Sier (Dev) エンド ユーザー MSP (Ops) 運用サービス の提供 設計・開発フェーズへの フィードバック 日本市場型 DevOps 体制 システム開発 の提供
設計と監視 Opsサンドイッチ ▪ インフラモニタリング – →スレッドプログラミングの偏り・メモリリーク検知 ▪ ミドルウェアモニタリング – コネクションプーリング実装の不備検知
▪ アプリケーションパフォーマンスモニタリング – 非効率な再帰呼び出し実装検知 – cache実装の不備検知 ▪ 値から意味を読み取り設計へとフィードバックすることがこれ からのMSP事業者やSREに求められる 42
MSPがこの先生きのこるためには 43
MSPがこの先生きのこるためには ▪ MSP事業者やSREは読影能力や設計能力を高める事が重 要である。 ▪ 読影能力=分析 ▪ 分析で必要となるのはコンピュータサイエンスの知識 44
MSPがこの先生きのこるためには ▪ 1台いくらのビジネスモデルの限界 ▪ システム全体をより深く(オブザーバビリティー) ▪ そもそもサーバーレスは台数単位で見られない ▪ New Relicの価格モデル
– データ量課金 – ユーザー(分析者)課金 – AI(イベント数)課金 ▪ MSPもシステム単位で分析(有識者)としてお金を貰う 45
次世代MSPのエンジニア像 ▪ システムを深く分析し、コンピューターサイエンス、データサ イエンスに基づいて助言を行う ▪ 統計学やコンピュータサイエンスの知識 ▪ 分析の時間を作るためにもオペレーションは自動化 ▪ より高度な分析者としてのスキルを
▪ 分析ツールやAIを使いこなして ▪ オペレーターではなくアナリストへ 46
Zabbixの底力 タイムシフト&アグリゲー ション 47
Zabbixの底力 タイムシフト&アグリゲー ション 48
MSPやSREを活かす開発体制 ▪ 分析に基づくフィードバックを適切にソフトウェアの実装に反 映する開発体制が必要 ▪ フィードバックを反映しその効果を確認するまでの期間は1週 間以内長くとも1ヶ月以内が理想的 ▪ ショートウォーターフォール、アジャイルモデル 49
MSPは終端ではなく”先端” ▪ 根拠となるデータを示し、設計 フェイズに対してフィードバッ クを行う ▪ SIer、事業会社、MSPが密に連 携をして協業を行う 日本型DevOpsの鍵はMSP 50
Sier (Dev) エンド ユーザー MSP (Ops) 運用サービス の提供 設計・開発フェーズへの フィードバック 日本市場型 DevOps 体制 システム開発 の提供