Slide 1

Slide 1 text

監視論 ~SREと次世代MSP~ OpsJaws

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システム監視とは何か ▪ 監視エンジニアの未来 ▪ SREとアウトソーシングの関係 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

監視システムの4要素 9

Slide 10

Slide 10 text

監視システムの4要素 ▪ 収集 ▪ 判定 ▪ 通知 ▪ 分析 ▪ 単一のソフトやサービスによって全てを実現する場合もあれば、 複数のソフトウェアやサービスを組み合わせて機能を満たす場 合もあります。 10

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

判定 ▪ 収集により集められたデータに対して、正常・障害/ノーマ ル・アラートなどの判定を行う。 ▪ 判定では、「イコール/ノットイコール」や「含む/含まない」、 「以上/以下(超過/未満)」 などにより、数値判定、文字列判定を行う。 ▪ 2015年ごろから、近似計算による将来値予測を行いこの予測 値に対する判定を行うシステムも登場している。 ▪ 複数の条件や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

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

Slide 20

Slide 20 text

MSPという業態 20

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

SREの役割 24

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

知識と技術 28

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

©2008–20 New Relic, Inc. All rights reserved Webinars in September Your Name Here September 2, 2020

Slide 38

Slide 38 text

©2008–20 New Relic, Inc. All rights reserved New Relic はじめの一歩 (概要編) 38 全世界で17,000社、日本国内でも既に数百社が導入・活用しているNew Relic。本ウェビナーでは、New Relic とはいったい何なのか?どのよう なことができるのか?といった全体像を理解できる初心者向けのセッ ションです。 New Relic は、モバイルやブラウザのエンドユーザーモニタリングや、 外形監視、バックエンドのアプリケーションとインフラモニタリング など、オンプレやクラウド、コンテナからサーバレスまであらゆるシ ステム環境での性能管理を実現するプラットフォームです。できるこ とが多種多様にわたるプラットフォームであるため、New Relic で何が できるのかその全体像をまずは理解したい方に最適です。 対象:New Relic で何ができるのかまずは理解したい方 9月17日 16:00 - 17:00 New Relic University 101 : Overview Walk-through ©2008–20 New Relic, Inc. All rights reserved このウェビナーに参加する

Slide 39

Slide 39 text

©2008–20 New Relic, Inc. All rights reserved New Relic はじめの一歩 (ハンズオン) 39 本ウェビナーは、New Relic の全体概要は理解しているが、実際に操作 することで理解を深めたい方向けのハンズオントレーニングです。 New Relic One のコアとなる Full stack Observability の中から中核昨日 となるAPM、Infrastructure、そして Alert と Dashboard 作成についてハ ンズオントレーニングで学びます。 New Relic のテクニカルサポートエンジニアやモデレーターが、初歩的 な質問から細かい質問まで答えられる限り回答して参りますので、ざ っくばらんにお問い合わせください。 対象:New Relic を理解しているがまだ触ったことのない方 9月24日 16:00 - 18:00 New Relic University 102 : Full Stack Observability Hands-On Training ©2008–20 New Relic, Inc. All rights reserved このウェビナーに参加する

Slide 40

Slide 40 text

©2008–20 New Relic, Inc. All rights reserved New Relic の Webinar 登録でもらえる 40 New Relic のウェビナーにご登録いただくと、参加の可否にかかわらず ウェビナー実施後に Nerd 御用達、ブラックでキメた New Relic Swag にご応募いただけます。在庫がなくなり次第の終了です。 Nerd Mask (限定300枚) Stay Home を IP アドレスとサブネットマスクで表現した Nerd なマス ク。そんじょそこらでは思いつかない Nerd なメッセージスタイルは、 わかる人にだけはわかるという、厄介なスタイルを表現しています。 データニャード Tシャツ (限定300枚) データナード (データ分析オタク)をもじってデータニャードと読み替え ることから生まれた New Relic 猫型データアナリスト。大量に生産され るもオフラインイベントの尽くのキャンセルで行き場を失い、そのデ ータを見通すシャープな眼差しは、飼い主を求めて虚空を見つめます 。 Nerd Mask & データニャード 注意 : 該当アイテムは予告なく変更される可能性がございます。