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

July Tech Festa 2021 winter E2セッションの資料です

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

Transcript

1. 監視とは何か ～監視エンジニアのスキルと成長～
2. 自己紹介 ▪ 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. セッションの目的 3
4. セッションの目的 ▪ 監視ツール、監視SaaSなどITシステム監視に関する ツールや仕組みについては多くのドキュメントがあります。 しかしそもそもITシステム監視そのものについてはあまり語ら れる事がありません。 ▪ 特定の監視ツールや監視サービスについてではなく ITシステム監視そのものの定義や意義、監視サービスのあるべ き未来やオブザーバビリティーについて考察します。 ▪ マイクロサービスやSREといった変化のなかで次世代MSPや モニタリングエンジニアの生存戦略ついて考えます。 4
5. セッションの概要 ▪ ITシステム監視とは何か ▪ 監視エンジニアの未来 ▪ 監視エンジニアのトレーニング ▪ 次世代MSPの役割 5
6. ITシステム監視とは 6
7. ITシステム監視とは ▪ プロセス監視 ▪ 機器監視 ▪ アプリケーション性能監視 ▪ リアルユーザーモニタリング ▪ ログ監視 ▪ オブザーバビリティー 7
8. ITシステム監視とは ▪ システム監視の目的はシステムの安定稼働 ▪ システム稼働効率の最適化 ▪ アプリケーションの改善 8
9. 監視システムの5要素 9
10. 監視システムの5要素 ▪ 収集 ▪ 判定 ▪ 通知 ▪ 分析 ▪ オブザーバビリティー 10
11. 収集 ▪ 対象システムやセンサー、ネットワーク機器等からデータを集 める。 ▪ CPU使用率やメモリ使用率、ディスク情報やネットワーク負荷 ログ情報や環境データの収集を行う。 11
12. 収集 ▪ 標準的なプロトコルやAPIにより監視ツールなどにデータ提供 を行う対象システム ▪ 監視システム独自Agentによって対象システムからデータ収集 を行う ▪ 対象システム自身の状態確認コマンド、統計コマンドにより出 力される情報をスクリプトやAgent等により収集する場合もあ る。 12
13. 判定 ▪ 収集により集められたデータに対して、正常・障害/ノーマ ル・アラートなどの判定を行う。 ▪ 判定では、「イコール/ノットイコール」や「含む/含まない」、 「以上/以下（超過/未満）」 などにより、数値判定、文字列判定を行う。 ▪ 近似計算による将来値予測を行いこの予測値に対する判定を行 うシステムも登場している。 ▪ 複数の条件やAIの利用など判定の高度化も行われている 13
14. 通知 ▪ 通知先は人間とは限らない ▪ システムに通知する＝自動復旧・自律制御 ▪ 何のために通知するのか＝通知するけど静観は意味が無い ▪ 通知した後のフローを意識して通知条件を設計する ▪ 通知を受けた人物が「決断」「操作」する必要がある場合に 通知する ▪ アリバイとしての通知をしない。 14
15. 分析 ▪ ソース – 収集されたデータ – 判定の頻度 ▪ 目的 – 現状把握 – 将来予測 ▪ 効果 – ボトルネックの判断 – ボトルネックの移動予測 – コスト最適化 15
16. 分析 ▪ 分析は立案である ▪ 監視は終端ではなく先端 ▪ 分析に必要な能力は勘ではなく知識 16
17. オブザーバビリティー ▪ 現象ではなく、その原因を探る ▪ 収集対象を増やし分析をリアルタイムにより深化させる。 ▪ 監視：異常検知 ▪ オブザーバビリティー：原因究明 17
18. オブザーバビリティー ▪ 現象ではなく、その原因を探る ▪ 収集対象を増やし分析をリアルタイムに より深化させる。 ▪ 監視：異常検知 ▪ オブザーバビリティー：原因究明 18 ! ! ! 問題症状 問題症状 問題症状 根本原因 根本原因 問 題 ! ! 問題症状 根本原因 根本原因
19. オブザーバビリティー ▪ オブザーバビリティーを得るためには、もっと全体的な可視化 が必要 ▪ RUM、APM ▪ Prometheus連携やAPM連携など 19
20. なぜ可視化するのか 20
21. なぜ可視化するのか ▪ 監視対象データは時系列データ ▪ 瞬間値ではなく、値の推移が意味を持つ ▪ 数値表を眺めるのではなくグラフ化することで変曲点が把握で きる。 ▪ ボトルネック分析やシステム負荷ではデータ同士の相関やス ケール変更が重要 ▪ データアナリストやデータサイエンティストに繋がる経験 21
22. 監視エンジニアトレーニング Zabbix IoTと気象観測 22
23. 可視化の意味を体得する ▪ 一番良いのは実際に壊せる環境 ▪ 壊せる環境が難しければ気象観測をしてみよう 23 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb
24. 周期性を見つける ▪ 時間と値の関連性を見つける 24 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb
25. 外れパターンを見つける ▪ 曇っていた？ 25 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb
26. 関連する複数のデータを比較する ▪ 日なたと日陰の気温を比べれば晴れか曇りかが特定できる 26 https://qiita.com/qryuu/items/c119f5ec8f6c9dc787cb
27. 異なる指標の関連を推測する 気温と気圧から台風の通過 を知る 27
28. MSPという業態 28
29. MSPという業態 ▪ MSP（Managed Service Provider） ▪ MSP（Monitoring Service Provider） ▪ MSPは本来運用サービスを提供するものであるが、実体として は監視サービスを提供し、サービス運用についてはエンドユー ザの指示に従うような業態となっている。 29
30. MSPという業態 ▪ AWSがMSPパートナープログラムとして、「Next Generation MSP」としてパートナー要件を定義 ▪ MSPに高度なナレッジ、システムの自動化、DevOpsの実現な どが求められた。 30
31. MSPという業態 ▪ DevOps＝開発・SIer機能 ▪ ナレッジ提供＝コンサルティング機能 ▪ 24-365＝カスタマーサポート機能 31
32. SREの役割 32
33. SREの役割 ▪ SRE（Site Reliability Engineering） ▪ 運用のためのコードを書く ▪ 開発者が運用を行うという思想 ▪ SREとはITサービス企業自身の役割でありMSPのようなアウト ソーサーとして提供する事に向いたロールでは無い。 ▪ 少なくとも業態や関係性を変える必要がある 33
34. 監視の役割は開発ではない 34
35. 監視エンジニアとしての価値 ▪ SREが登場した当時DevOpsの文脈が強くOpsやSREも開発を 行うという総員コーダーのような雰囲気が強くなった。 ▪ OpsやSREの本領はパフォーマンスの分析でありそこで求めら れる能力は統計やログ解析、アプリケーション解析である。 ▪ 大規模SaaSではSREとソフトウェアデペロッパーは別のチー ム ▪ SREやOpsに求められる役割は根拠となるデータを示し、設計 フェイズに対してフィードバックを行う事 35
36. 知識と技術 36
37. 知識と技術 論理 センス 知識 技術 学者 職人 コンピュータサイエンス プログラミング Opsの特性 Devの特性 37
38. 知識と技術 ▪ どちらが優れているではなく人類が進歩するために必要な両輪 ▪ 天才的とされる人材は1人で両方のスキルを兼ね備える場合も あるが、組織設計においては本来両方が補完関係にあるべき 38
39. 設計と監視 Opsサンドイッチ 39
40. 設計と監視 Opsサンドイッチ 40
41. MSPやSREを活かす開発体制 ▪ 分析に基づくフィードバックを適切 にソフトウェアの実装に反映する開 発体制が必要 ▪ フィードバックを反映しその効果を 確認するまでの期間は1週間以内長 くとも1ヶ月以内が理想的 ▪ ショートウォーターフォール、ア ジャイルモデル ▪ MSPが作業オペレーターでは無く次 世代MSPとなるためにはユーザー企 業やSIを巻き込んだより密な連携が できる契約が必要 41 Sier (Dev) エンド ユーザー MSP (Ops) 運用サービス の提供 設計・開発フェーズへの フィードバック 日本市場型 DevOps 体制 システム開発 の提供
42. 設計と監視 Opsサンドイッチ ▪ インフラモニタリング – →スレッドプログラミングの偏り・メモリリーク検知 ▪ ミドルウェアモニタリング – コネクションプーリング実装の不備検知 ▪ アプリケーションパフォーマンスモニタリング – 非効率な再帰呼び出し実装検知 – cache実装の不備検知 ▪ 値から意味を読み取り設計へとフィードバックすることがこれ からのMSP事業者やSREに求められる 42
43. MSPがこの先生きのこるためには 43
44. MSPがこの先生きのこるためには ▪ MSP事業者やSREは読影能力や設計能力を高める事が重 要である。 ▪ 読影能力＝分析 ▪ 分析で必要となるのはコンピュータサイエンスの知識 44
45. MSPがこの先生きのこるためには ▪ 1台いくらのビジネスモデルの限界 ▪ システム全体をより深く（オブザーバビリティー） ▪ そもそもサーバーレスは台数単位で見られない ▪ New Relicの価格モデル – データ量課金 – ユーザー（分析者）課金 – AI（イベント数）課金 ▪ MSPもシステム単位で分析（有識者）としてお金を貰う 45
46. 次世代MSPのエンジニア像 ▪ システムを深く分析し、コンピューターサイエンス、データサ イエンスに基づいて助言を行う ▪ 統計学やコンピュータサイエンスの知識 ▪ 分析の時間を作るためにもオペレーションは自動化 ▪ より高度な分析者としてのスキルを ▪ 分析ツールやAIを使いこなして ▪ オペレーターではなくアナリストへ 46
47. Zabbixの底力 タイムシフト＆アグリゲー ション 47
48. Zabbixの底力 タイムシフト＆アグリゲー ション 48
49. MSPやSREを活かす開発体制 ▪ 分析に基づくフィードバックを適切にソフトウェアの実装に反 映する開発体制が必要 ▪ フィードバックを反映しその効果を確認するまでの期間は1週 間以内長くとも1ヶ月以内が理想的 ▪ ショートウォーターフォール、アジャイルモデル 49
50. MSPは終端ではなく”先端” ▪ 根拠となるデータを示し、設計 フェイズに対してフィードバッ クを行う ▪ SIer、事業会社、MSPが密に連 携をして協業を行う 日本型DevOpsの鍵はMSP 50 Sier (Dev) エンド ユーザー MSP (Ops) 運用サービス の提供 設計・開発フェーズへの フィードバック 日本市場型 DevOps 体制 システム開発 の提供