ネットワークが創生する価値 再考②：脚光を浴び始めたTelemetry とは - 前編 -

• 
• 

ビジネス推進本部応用技術部
コアネットワークチーム
井上 勝晴
ハディ ザケル

前回のコラムでは、ネットワークインフラの構築・運用おける新たな潮流として注目される「Hyper Scale Data Center Architecture」の概要と、そこで生まれた新たなテクノロジーである「Telemetry」の概要を其々説明しました。連載テーマの第2弾として「脚光を浴び始めたTelemetry とは」というテーマを2回に分けてご紹介します。
前編となる今回のコラムでは、「Telemetry」の実体解説をし、後編では弊社ネットワンシステムズが構築した「Telemetry PoC」を紹介したいと思います。

連載インデックス
ネットワークが創生する価値 再考①：Hyper Scale DC Architectureとその手法 ネットワークが創生する価値 再考②：脚光を浴び始めたTelemetry とは – 前編 – ネットワークが創生する価値 再考②：脚光を浴び始めたTelemetry とは – 後編 – 番外編：OSSツールで作る、Telemetry初めの一歩 – 前編 – 番外編：OSSツールで作る、Telemetry初めの一歩 – 後編 – ネットワークが創生する価値 再考③：Data Platform のビジネス利用 ネットワークが創生する価値 再考④：Workflow エンジンによる管理の自律化

Telemetry 登場の背景

Telemetry は古くから使われている用語であり、Tele = Remote (遠隔)と Metry = Measure（はかる）から成る造語になります。そういった意味において SNMP や xFlow も Telemetry の1つと呼ぶことが出来ますが、これから本コラムで紹介する "Telemetry" は、次世代版 SNMP と理解して頂くと解り易いかもしれません。

SNMPの課題

ネットワークの状態可視化には、古くより SNMP が使用されてきました。SNMPv1 の登場が1988年、SNMPv3 の登場が1999年であり、レガシーな（古い）プロトコルであると言えます。

レガシーな SNMP を Hyper Scale 環境に適用した場合、パフォーマンスにおいて課題があり、（ネットワーク機器側へ多くのリソースを要求するため）Polling 間隔を狭めることや複数 Poller が存在した場合、機器側で処理がスタックし、リアルタイム性が損なわれてしまう結果に繋がります。また、柔軟性と言う観点においても制限があり、昨今様々な用途で用いられ主流になりつつある新 Data モデル（ YANG 等）の適用も不可である点や、Transport プロトコルも UDP のみであり gRPC のような新たな Transport プロトコルにも未対応であるといった点からも、SNMP は現在及び今後の Network 運用に適しているとは言い難い状況にあります。

SNMP の場合 OID 経由の統計情報のやり取りはリクエストベースとなるため、デバイス側ではリクエスト処理に負荷がかかります。リクエストがある度にデバイス側では同じ辞書式順序で情報の取り出しが行われ、返答処理がおこなれます。イメージ的には、SNMP は電話通信（コールがかかれば応答、コールが完了していない状態で新規コールは受け付けできず保留状態）に相当します。

一方で、これから Telemetry の詳細を見ていきますが、SNMP との違いとしてリクエスト・レスポンス形式ではなく、Subscription（購読宣言）ベースになっています。特定の統計情報に対して、Subscriber（購読者）が複数いても情報が必要となったときにコールがかかるという形式ではなく、デバイスは購読者に対して定期的に統計情報を配信します。

Telemetry 解説

この様な背景もあり SNMP に代わる新たな手段として、Telemetry と呼ばれる概念が生まれました。開発の中心である Google は、Telemetry の Framework Requirement として以下を挙げています。
✓ Network 機器は Collector へ Data をストリーム形式で送信する（ Push モデル）
✓ Publish/Subscribe モデルであり任意の Data を選択し Subscribe（購読）を宣言する
✓ Data モデルは Vendor neutral、もしくは Open-config（後述）
✓ 向こう10年のデータ増加に耐え得るテクノロジーを利用可能である事（後述）
✓ Telemetry Data 種別
➣ 定期送信型：「例」10秒毎に全ての Interface 情報を送信
➣ イベントトリガー型：「例」特定 LSP が Down となった時にその状態を送信
➣ オペレータリクエスト型：「例」オペレータ側の任意のリクエストを契機に送信

では、上述 Requirement を満たす上で重要となる技術要素を、幾つか見て行きたいと思います。

gRPC（Google Remote Procedure Call）
gRPC はマルチプラットフォームに対応した RPC Framework であり、特徴は以下となります。
✓ ロードバランス、アプリレベルのフロー制御、Call キャンセリング機能
✓ 双方向ストリーム及びサーバプッシュ型に対応
✓ マルチプラットフォーム（複数言語に対応）
✓ ストリームコネクションの多重化
✓ オープンソース

これらの機能から、（gRPC を使用する事で）HTTP/2 をあたかも独立して動作する Transport Layer かのように活用する事が出来、その上で RPC（Remote Procedure Call）による情報取得が可能となります。また、元々は分散コンピュティング環境におけるコンポーネント同士のやり取りの効率化を目的としたプロトコルであったため、プロトコルとしての軽量化、レスポンスの迅速性が重視されています。
※ Micro-Service が注目されている昨今では、コンポーネント間の迅速なやり取りが非常に重要視されています。

GPB（Google Protocol Buffers）

GPB は Google が開発した構造データをシリアライズ（エンコーディング）するためのメカニズムになります（SNMP における ASN.1 BER 相当）。単純処理が得意な ASIC でも動作可能であり（勿論CPU によるシリアライズ･デシリアライズも可能）、SNMP が採用する ASN.1 BER と比べると処理負荷は軽減されています。言語非依存・プラットフォーム非依存で拡張性が高く、且つ、xml と比べてデータサイズが小さく、高速、シンプルである事も特徴になります。

OpenConfig

OpenConfig は複数の Network オペレータ（Apple, AT&T, BT, Comcast, Cox, Facebook, Google, Microsoft, Verizon, Yahoo等）で構成されるオープンソースプロジェクトであり、実運用をベースにしたベンダー非依存（Vendor Neutral）な「Configuration（設定）」と「Operational State（運用状態）」の共通データモデルの策定を活動目標としています。OpenConfig による共通データモデルにより、マルチベンダーで構成する Network に対しても、統一した設定及び運用が可能となります。Data モデリングのベースとして YANG を採用しており、成果物を Github で公開しています。Telemetry の側面では、機器ステータス（Interface Counter 等）取得時に、この OpenConfig で策定されたデータモデルを利用する事が出来ます。（Operational Stateとして取得）

これまで紹介した各技術のTelemetryにおける役割は以下になります。

上表にあるように、gRPC は Transport 技術として、GPB はエンコーディング技術として、OpenConfig は Data モデリングとして、Telemetry にて活用する事が出来ます。（表１では、紹介した技術以外の選択肢を黒字で記載しています。）

また、図3では Data モデルに OpenConfig、エンコーディングに GPB、Transport 技術に gRPC を其々採用した時の構成（図3上方）と、それ以外の技術を採用した際の構成（図3下方）を描いています。

Telemetry / SNMP 比較

それではここで改めて、Telemetry と SNMP の違いを見て行きたいと思います。（下表3参照）
SNMP では情報取得時に都度要求する Polling 方式を採用していますが、Telemetry では Subscription 方式を採用しています。Transport に関しては、SNMP は UDP のみの実装となりますが、Telemetry では UDP/TCP に加え gRPC も利用可能であり、フロー制御された Transport レイヤを使用する事が出来ます。SNMP ではエンコーディングに ASN.1 BER を使用していますが、Telemetry ではより動作の軽い GPB を使用する事が出来ます。また、データモデルにおいては OpenConfig を採用する事でベンダーに依存しない共通のデータモデルにて、機器から様々な情報を得る事が出来ます。

パフォーマンス面においても、SNMP と Telemetry の違いは顕著に存在します。下図は、ある環境下に存在するネットワーク機器に対し10秒間隔で情報取得を実施した時の、機器からの応答時間を縦軸、横軸を時間軸としたグラフになります。情報取得に SNMP を使用すると応答時間が長引く（機器側でスタックする）傾向があるのに対し、Telemetry を使用した場合は機器からの応答時間が一定である事が解ります。この図からも、Telemetry がリアルタイム性に優れている事が解ります 。

まとめ

前編となる今回は、対 SNMP との比較も含めて「Telemetry」の実体を中心に説明させていただきました。Telemetry は Hyper Scale 環境に於ける SNMP 採用の課題を解決するために考えられたため、リアルタイム可視化において非常に優れています。今後は Telemetry のこのリアルタイム性が必要とされるさまざまなシステムで導入や検討が進むのではと想定しています。
コラム後編では弊社ネットワンシステムズが構築した「Telemetry PoC」の詳細を紹介していきます。

関連記事

• ネットワン NFV の全貌と市場への挑戦①
• ネットワン NFV の全貌と市場への挑戦②
• ネットワン NFV の全貌と市場への挑戦③
• NFV動向： NFVとOpenStack①
• NFV動向： NFVとOpenStack②
• NFV動向： NFVとOpenStack③
• 仮想アプライアンスの提案で直面する致命的な課題とその対策 - 前編 –
• 仮想アプライアンスの提案で直面する致命的な課題とその対策 - 後編 –
• ネットワークが創生する価値 再考①：Hyper Scale DC Architectureとその手法

執筆者プロフィール

井上 勝晴

ネットワンシステムズ株式会社 ビジネス推進本部 応用技術部 コアネットワークチーム所属
エンタープライズ・サービスプロバイダのネットワーク提案・導入を支援する業務に、10年以上にわたり従事
現在はSDN・クラウドのエンジニアになるべく格闘中

• MCPC1級

ハディ ザケル

ネットワンシステムズ株式会社 ビジネス推進本部 応用技術部 コアネットワークチーム所属
主にハイエンドルータ製品の担当として、評価・検証および様々な案件サポートに従事
現在は、SP-SDN分野、コントローラ関連、標準化動向について調査及び連携検証を実施中

• 
• 

ナレッジセンターを検索する