Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

74948d1118cd84528f7861a3069dd8d9?s=47 Qryuu
January 24, 2021

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

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

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

74948d1118cd84528f7861a3069dd8d9?s=128

Qryuu

January 24, 2021
Tweet

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 体制 システム開発 の提供