そもそもTelemetryとは？
Push型でさまざまなデータを出力できるソリューションの総称の呼び名
よくネットワークで古くから使われてきているSNMPの後継とされる技術と言われるため、プロトコルなんじゃね？と思われがちだが、プロトコルの名前ではない。
Telemetry は古くから使われている用語であり、Tele = Remote (遠隔)と Metry = Measure（はかる）から成る造語になります。そういった意味において SNMP や xFlow も Telemetry の1つと呼ぶことが出来る。
Telemetryを構成する要素
Telemetryを構成する要素は大別して以下3要素
- ノード：データを送信する装置（NetworkElementの場合が多い?）
- コレクタ：ノードからのデータを受信・デコードし、データレイクに貯める装置
- データストア：コレクタから受信したデータを格納する領域
出典：NetOneより引用
- Telemetryはプロトコルではない”ソリューションの総称”
- Telemetryは”ノード”、”コレクタ”、”データストア”の３要素から成るソリューション※
SNMP的なプロトコルだと勘違いしがち。
構成要素は３要素と言ったけど、
実運用では図にあるように、
可視化ツールを加えたりアレンジがあるよ
SNMPとTelemetryの対比
SNMPとは
SNMPは前述したTelemetryに対してPull型ベースの動きをするプロトコルです。
コレクタ(SNMP サーバー)からの指示要求を受けて、要求に応じた返答をNE側が返す。
SNMPのアーキテクチャ
- SNMPマネージャー：エージェントに対してSNMPコマンド（GET/SET等)を送信
(OID:Object Identifier)を含む識別子でエージェントへ指示を出す - SNMPエージェント（NE）：マネージャーからの指示に従い自信が持つMIB（Management Information Base）いわゆる機器の管理情報データベースを参照し、該当情報を返答する。
ManageEngine OpManager サイト引用
SNMPとTelemetryの動作比較
SNMPは指示要求に対応して動作するのに対して、
Telemetryはあらかじめ指示された内容の解答を淡々と行う
Telemetryが優位なシチュエーション
SNMPとTelemetryでは前述した動作特性上、
「SNMP： Pull型」「Telemetry：Push型」のため、定型動作を淡々と行うような処理についてはTelemetryに軍配が上がる。
例えば、取得したい装置状態（CPU使用率や帯域等）を時間軸で確認したい等の需要に対しては、SNMPで毎度同じ指示を出すよりもTelemetryの方が優れている。
また昨今よく取り上げられるマイクロバーストのような動作をキャプチャするためには、平均化される前の極短期間での帯域情報を収集する必要があるため、取得頻度が細かいような動作はSNMPでは装置負荷観点から対応できない。
NetOneより引用
装置負荷：大
マネージャーからのOID指示を読み解き、都度その応答に応じた情報をMIBを参照して解答する
SNMP専用のマネージャーが必要
SNMPのみで情報収集が完結しない場合は別のプロトコル用のものを別途立てる必要あり。
NetOneより引用
装置負荷：軽
あらかじめ解答すべき内容が決まっているため、処理負荷が軽い
デコード負荷：小
コレクタへ渡すデータフォーマット(GPB,gRPC 後ほど紹介)も処理負担の小さい形式を採用できるため負担が少ない
Tememetryのまとめ
Telemetryは大規模なNW（管理するノードが大量）かつ、
定期的に定型処理をしたい事業者(キャリアやDataCenter等)
のシチュエーションにハマると効果が大そうだね！
この後出てくるけど、実際Telemetryの需要は
GAFAMの様なノード大量保持の事業者が
SNMPに限界を感じて標準化の動きを始めたのがきっかけだよ。
GoogleとかAmazonとかがWhitebox系の装置を
扱い始めてベンダー依存しないOpenConfigで
制御を始めたのも背景にありそうだね。
- Telemetryは高頻度で定型処理を継続するようなNW情報の収集に有利。
- SNMPは処理負荷の影響に限界がある。マイクロバーストの観測等には不利。
コメント