監視とは何か～監視エンジニアのスキルと成長～

by Qryuu

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 ▪ 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

Slide 3

Slide 3 text

セッションの目的 3

Slide 4

Slide 4 text

セッションの目的 ▪ 監視ツール、監視SaaSなどITシステム監視に関するツールや仕組みについては多くのドキュメントがあります。しかしそもそもITシステム監視そのものについてはあまり語られる事がありません。 ▪ 特定の監視ツールや監視サービスについてではなく ITシステム監視そのものの定義や意義、監視サービスのあるべき未来やオブザーバビリティーについて考察します。 ▪ マイクロサービスやSREといった変化のなかで次世代MSPやモニタリングエンジニアの生存戦略ついて考えます。 4

Slide 5

Slide 5 text

セッションの概要 ▪ ITシステム監視とは何か ▪ 監視エンジニアの未来 ▪ 監視エンジニアのトレーニング ▪ 次世代MSPの役割 5

Slide 6

Slide 6 text

ITシステム監視とは 6

Slide 7

Slide 7 text

ITシステム監視とは ▪ プロセス監視 ▪ 機器監視 ▪ アプリケーション性能監視 ▪ リアルユーザーモニタリング ▪ ログ監視 ▪ オブザーバビリティー 7

Slide 8

Slide 8 text

ITシステム監視とは ▪ システム監視の目的はシステムの安定稼働 ▪ システム稼働効率の最適化 ▪ アプリケーションの改善 8

Slide 9

Slide 9 text

監視システムの5要素 9

Slide 10

Slide 10 text

監視システムの5要素 ▪ 収集 ▪ 判定 ▪ 通知 ▪ 分析 ▪ オブザーバビリティー 10

Slide 11

Slide 11 text

収集 ▪ 対象システムやセンサー、ネットワーク機器等からデータを集める。 ▪ CPU使用率やメモリ使用率、ディスク情報やネットワーク負荷ログ情報や環境データの収集を行う。 11

Slide 12

Slide 12 text

収集 ▪ 標準的なプロトコルやAPIにより監視ツールなどにデータ提供を行う対象システム ▪ 監視システム独自Agentによって対象システムからデータ収集を行う ▪ 対象システム自身の状態確認コマンド、統計コマンドにより出力される情報をスクリプトやAgent等により収集する場合もある。 12

Slide 13

Slide 13 text

判定 ▪ 収集により集められたデータに対して、正常・障害/ノーマル・アラートなどの判定を行う。 ▪ 判定では、「イコール/ノットイコール」や「含む/含まない」、「以上/以下（超過/未満）」などにより、数値判定、文字列判定を行う。 ▪ 近似計算による将来値予測を行いこの予測値に対する判定を行うシステムも登場している。 ▪ 複数の条件やAIの利用など判定の高度化も行われている 13

Slide 14

Slide 14 text

通知 ▪ 通知先は人間とは限らない ▪ システムに通知する＝自動復旧・自律制御 ▪ 何のために通知するのか＝通知するけど静観は意味が無い ▪ 通知した後のフローを意識して通知条件を設計する ▪ 通知を受けた人物が「決断」「操作」する必要がある場合に通知する ▪ アリバイとしての通知をしない。 14

Slide 15

Slide 15 text

分析 ▪ ソース – 収集されたデータ – 判定の頻度 ▪ 目的 – 現状把握 – 将来予測 ▪ 効果 – ボトルネックの判断 – ボトルネックの移動予測 – コスト最適化 15

Slide 16

Slide 16 text

分析 ▪ 分析は立案である ▪ 監視は終端ではなく先端 ▪ 分析に必要な能力は勘ではなく知識 16

Slide 17

Slide 17 text

オブザーバビリティー ▪ 現象ではなく、その原因を探る ▪ 収集対象を増やし分析をリアルタイムにより深化させる。 ▪ 監視：異常検知 ▪ オブザーバビリティー：原因究明 17

Slide 18

Slide 18 text

オブザーバビリティー ▪ 現象ではなく、その原因を探る ▪ 収集対象を増やし分析をリアルタイムにより深化させる。 ▪ 監視：異常検知 ▪ オブザーバビリティー：原因究明 18 ! ! ! 問題症状問題症状問題症状根本原因根本原因問題 ! ! 問題症状根本原因根本原因

Slide 19

Slide 19 text

オブザーバビリティー ▪ オブザーバビリティーを得るためには、もっと全体的な可視化が必要 ▪ RUM、APM ▪ Prometheus連携やAPM連携など 19

Slide 20

Slide 20 text

なぜ可視化するのか 20

Slide 21

Slide 21 text

なぜ可視化するのか ▪ 監視対象データは時系列データ ▪ 瞬間値ではなく、値の推移が意味を持つ ▪ 数値表を眺めるのではなくグラフ化することで変曲点が把握できる。 ▪ ボトルネック分析やシステム負荷ではデータ同士の相関やスケール変更が重要 ▪ データアナリストやデータサイエンティストに繋がる経験 21

Slide 22

Slide 22 text

監視エンジニアトレーニング Zabbix IoTと気象観測 22

Slide 23

Slide 23 text

可視化の意味を体得する ▪ 一番良いのは実際に壊せる環境 ▪ 壊せる環境が難しければ気象観測をしてみよう 23 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb

Slide 24

Slide 24 text

周期性を見つける ▪ 時間と値の関連性を見つける 24 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb

Slide 25

Slide 25 text

外れパターンを見つける ▪ 曇っていた？ 25 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb

Slide 26

Slide 26 text

関連する複数のデータを比較する ▪ 日なたと日陰の気温を比べれば晴れか曇りかが特定できる 26 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb

Slide 27

Slide 27 text

異なる指標の関連を推測する気温と気圧から台風の通過を知る 27

Slide 28

Slide 28 text

MSPという業態 28

Slide 29

Slide 29 text

MSPという業態 ▪ MSP（Managed Service Provider） ▪ MSP（Monitoring Service Provider） ▪ MSPは本来運用サービスを提供するものであるが、実体としては監視サービスを提供し、サービス運用についてはエンドユーザの指示に従うような業態となっている。 29

Slide 30

Slide 30 text

MSPという業態 ▪ AWSがMSPパートナープログラムとして、「Next Generation MSP」としてパートナー要件を定義 ▪ MSPに高度なナレッジ、システムの自動化、DevOpsの実現などが求められた。 30

Slide 31

Slide 31 text

MSPという業態 ▪ DevOps＝開発・SIer機能 ▪ ナレッジ提供＝コンサルティング機能 ▪ 24-365＝カスタマーサポート機能 31

Slide 32

Slide 32 text

SREの役割 32

Slide 33

Slide 33 text

SREの役割 ▪ SRE（Site Reliability Engineering） ▪ 運用のためのコードを書く ▪ 開発者が運用を行うという思想 ▪ SREとはITサービス企業自身の役割でありMSPのようなアウトソーサーとして提供する事に向いたロールでは無い。 ▪ 少なくとも業態や関係性を変える必要がある 33

Slide 34

Slide 34 text

監視の役割は開発ではない 34

Slide 35

Slide 35 text

監視エンジニアとしての価値 ▪ SREが登場した当時DevOpsの文脈が強くOpsやSREも開発を行うという総員コーダーのような雰囲気が強くなった。 ▪ OpsやSREの本領はパフォーマンスの分析でありそこで求められる能力は統計やログ解析、アプリケーション解析である。 ▪ 大規模SaaSではSREとソフトウェアデペロッパーは別のチーム ▪ SREやOpsに求められる役割は根拠となるデータを示し、設計フェイズに対してフィードバックを行う事 35

Slide 36

Slide 36 text

知識と技術 36

Slide 37

Slide 37 text

知識と技術論理センス知識技術学者職人コンピュータサイエンスプログラミング Opsの特性 Devの特性 37

Slide 38

Slide 38 text

知識と技術 ▪ どちらが優れているではなく人類が進歩するために必要な両輪 ▪ 天才的とされる人材は1人で両方のスキルを兼ね備える場合もあるが、組織設計においては本来両方が補完関係にあるべき 38

Slide 39

Slide 39 text

設計と監視 Opsサンドイッチ 39

Slide 40

Slide 40 text

設計と監視 Opsサンドイッチ 40

Slide 41

Slide 41 text

MSPやSREを活かす開発体制 ▪ 分析に基づくフィードバックを適切にソフトウェアの実装に反映する開発体制が必要 ▪ フィードバックを反映しその効果を確認するまでの期間は1週間以内長くとも1ヶ月以内が理想的 ▪ ショートウォーターフォール、アジャイルモデル ▪ MSPが作業オペレーターでは無く次世代MSPとなるためにはユーザー企業やSIを巻き込んだより密な連携ができる契約が必要 41 Sier (Dev) エンドユーザー MSP (Ops) 運用サービスの提供設計・開発フェーズへのフィードバック日本市場型 DevOps 体制システム開発の提供

Slide 42

Slide 42 text

設計と監視 Opsサンドイッチ ▪ インフラモニタリング – →スレッドプログラミングの偏り・メモリリーク検知 ▪ ミドルウェアモニタリング – コネクションプーリング実装の不備検知 ▪ アプリケーションパフォーマンスモニタリング – 非効率な再帰呼び出し実装検知 – cache実装の不備検知 ▪ 値から意味を読み取り設計へとフィードバックすることがこれからのMSP事業者やSREに求められる 42

Slide 43

Slide 43 text

MSPがこの先生きのこるためには 43

Slide 44

Slide 44 text

MSPがこの先生きのこるためには ▪ MSP事業者やSREは読影能力や設計能力を高める事が重要である。 ▪ 読影能力＝分析 ▪ 分析で必要となるのはコンピュータサイエンスの知識 44

Slide 45

Slide 45 text

MSPがこの先生きのこるためには ▪ 1台いくらのビジネスモデルの限界 ▪ システム全体をより深く（オブザーバビリティー） ▪ そもそもサーバーレスは台数単位で見られない ▪ New Relicの価格モデル – データ量課金 – ユーザー（分析者）課金 – AI（イベント数）課金 ▪ MSPもシステム単位で分析（有識者）としてお金を貰う 45

Slide 46

Slide 46 text

次世代MSPのエンジニア像 ▪ システムを深く分析し、コンピューターサイエンス、データサイエンスに基づいて助言を行う ▪ 統計学やコンピュータサイエンスの知識 ▪ 分析の時間を作るためにもオペレーションは自動化 ▪ より高度な分析者としてのスキルを ▪ 分析ツールやAIを使いこなして ▪ オペレーターではなくアナリストへ 46

Slide 47

Slide 47 text

Zabbixの底力タイムシフト＆アグリゲーション 47

Slide 48

Slide 48 text

Zabbixの底力タイムシフト＆アグリゲーション 48

Slide 49

Slide 49 text

MSPやSREを活かす開発体制 ▪ 分析に基づくフィードバックを適切にソフトウェアの実装に反映する開発体制が必要 ▪ フィードバックを反映しその効果を確認するまでの期間は1週間以内長くとも1ヶ月以内が理想的 ▪ ショートウォーターフォール、アジャイルモデル 49

Slide 50

Slide 50 text

MSPは終端ではなく”先端” ▪ 根拠となるデータを示し、設計フェイズに対してフィードバックを行う ▪ SIer、事業会社、MSPが密に連携をして協業を行う日本型DevOpsの鍵はMSP 50 Sier (Dev) エンドユーザー MSP (Ops) 運用サービスの提供設計・開発フェーズへのフィードバック日本市場型 DevOps 体制システム開発の提供