Downloaded 25 times
Uploaded by真乙 九龍
監視論
OpsJaws ＃18 での資料です。 監視論 https://qiita.com/qryuu/items/c55b1e8c472eb716f616 および 監視論Ⅱ https://qiita.com/qryuu/items/94890340b958185cb8be の内容をまとめました。
![[Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日 放送](https://cdn.slidesharecdn.com/ss_thumbnails/dddddd-180906091548-thumbnail.jpg?width=640&height=640&fit=bounds)
監視論
- 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 ▪ 専門：Zabbix, テクニカルサポート, クラウドアーキテクト 2
- 3.
- 4.
- 5. セッションの目的 ▪ 監視ツール、監視SaaSなどITシステム監視に関する ツールや仕組みについては多くのドキュメントがあります。 しかしそもそもITシステム監視そのものについてはあまり語ら れる事がありません。 ▪ このセッションでは特定の監視ツールや監視サービスについて ではなく ITシステム監視そのものの定義や意義、監視サービスのあるべ き未来について考察します。 ▪さらにマイクロサービスやSREといった変化のなかでMSP事業者 やモニタリングエンジニアの生存戦略ついてかんがえます。 5
- 6. セッションの目的 ▪ ITシステム監視とは何か ▪ 監視エンジニアの未来 ▪SREとアウトソーシングの関係 6
- 7.
- 8. ITシステム監視とは ▪ プロセス監視 ▪ 機器監視 ▪アプリケーション監視 ▪ ログ監視 8
- 9.
- 10.
- 11. 監視システムの４要素 ▪ 収集 ▪ 判定 ▪通知 ▪ 分析 ▪ 単一のソフトやサービスによって全てを実現する場合もあれば、 複数のソフトウェアやサービスを組み合わせて機能を満たす場 合もあります。 11
- 12.
- 13. 収集 ▪ 標準的なプロトコルやAPIにより監視ツールなどにデータ提供を 行う対象システム ▪ 監視システム独自Agentによって対象システムからデータ収集を 行う ▪対象システム自身の状態確認コマンド、統計コマンドにより出 力される情報をスクリプトやAgent等により収集する場合もある。 13
- 14. 判定 ▪ 収集により集められたデータに対して、正常・障害/ノーマル・ アラートなどの判定を行う。 ▪ 判定では、「イコール/ノットイコール」や「含む/含まない」、 「以上/以下（超過/未満）」 などにより、数値判定、文字列判定を行う。 ▪2015年ごろから、近似計算による将来値予測を行いこの予測値 に対する判定を行うシステムも登場している。 ▪ 複数の条件やAIの利用など判定の高度化も行われている 14
- 15. 通知 ▪ 通知先は人間とは限らない ▪ システムに通知する＝自動復旧・自律制御 ▪何のために通知するのか＝通知するけど静観は意味が無い ▪ 通知した後のフローを意識して通知条件を設計する ▪ 通知を受けた人物が「決断」「操作」する必要がある場合に 通知する 15
- 16. 分析 ▪ ソース – 収集されたデータ –判定の頻度 ▪ 目的 – 現状把握 – 将来予測 ▪ 効果 – ボトルネックの判断 – ボトルネックの移動予測 – コスト最適化 16
- 17. 分析 ▪ 分析は立案である ▪ 監視は終端ではなく先端 ▪分析に必要な能力は勘ではなく知識 17
- 18.
- 19. なぜ可視化するのか ▪ 監視対象データは時系列データ ▪ 瞬間値ではなく、値の推移が意味を持つ ▪数値表を眺めるのではなくグラフ化することで変曲点が把握で きる。 ▪ ボトルネック分析やシステム負荷ではデータ同士の相関やス ケール変更が重要 ▪ データアナリストやデータサイエンティストに繋がる経験 19
- 20.
- 21. MSPという業態 ▪ MSP（Managed ServiceProvider） ▪ MSP（Monitoring Service Provider） ▪ MSPは本来運用サービスを提供するものであるが、実体として は監視サービスを提供し、サービス運用についてはエンドユー ザの指示に従うような業態となっている。 21
- 22. MSPという業態 ▪ AWSがMSPパートナープログラムとして、「Next Generation MSP」としてパートナー要件を定義 ▪MSPに高度なナレッジ、システムの自動化、DevOpsの実現など が求められた。 22
- 23. MSPという業態 ▪ DevOps＝開発・SIer機能 ▪ ナレッジ提供＝コンサルティング機能 ▪24-365＝カスタマーサポート機能 23
- 24.
- 25. SREの役割 ▪ SRE（Site ReliabilityEngineering） ▪ 運用のためのコードを書く ▪ 開発者が運用を行うという思想 ▪ SREとはITサービス企業自身の役割でありMSPのようなアウト ソーサーとして提供する事に向いたロールでは無い。 ▪ 少なくとも業態や関係性を変える必要がある 25
- 26.
- 27. 監視エンジニアとしての価値 ▪ SREが登場した当時DevOpsの文脈が強くOpsやSREも開発を行う という総員コーダーのような雰囲気が強くなった。 ▪ OpsやSREの本領はパフォーマンスの分析でありそこで求められ る能力は統計やログ解析、アプリケーション解析である。 ▪大規模SaaSではSREとソフトウェアデペロッパーは別のチーム ▪ SREやOpsに求められる役割は根拠となるデータを示し、設計 フェイズに対してフィードバックを行う事 27
- 28.
- 29. 知識と技術 論理 センス 知識 技術 学者職人 コンピュータサイエンス プログラミング 29
- 30.
- 31.
- 32.
- 33. 設計と監視 Opsサンドイッチ ▪ インフラモニタリング –→スレッドプログラミングの偏り・メモリリーク検知 ▪ ミドルウェアモニタリング – コネクションプーリング実装の不備検知 ▪ アプリケーションパフォーマンスモニタリング – 非効率な再帰呼び出し実装検知 – cache実装の不備検知 ▪ 値から意味を読み取り設計へとフィードバックすることがこれ からのMSP事業者やSREに求められる 33
- 34.
- 35. MSPがこの先生きのこるためには ▪ MSP事業者やSREは読影能力や設計能力を高める事が重要 である。 ▪ 読影能力＝分析 ▪分析で必要となるのはコンピュータサイエンスの知識 35
- 36.