It is the top of the page

Link for moving within the page
To text (c)

このウェブサイトではサイトの利便性の向上のためにクッキーを利用します。サイトの閲覧を続行されるには、クッキーの使用にご同意いただきますようお願いします。
お客様のブラウザの設定によりクッキーの機能を無効にすることもできます。詳細はこちら

The main part starts here.

  1. ナレッジセンター
  2. 匠コラム

Telemetry活用に向けた課題と解決へのアプローチ(part 1)

匠コラム

ビジネス開発本部 第1応用技術部
第1チーム
片野 祐

はじめに

「ネットワーク創生する価値 再考」というタイトルでTelemetryについて数回に分けて紹介しており、再考④ではWorkflowエンジンによる管理の自動化について述べました。ネットワークの自動最適化を目指してTelemetryに注目し活用を検討してきましたが、再考④のまとめにある通り、まだ課題が残っていることも事実です。そこで今回は考えられる課題の解決に向けてどのようにアプローチし、弊社で構築してきたTelemetry収集基盤(TelemetryPoC)をどのように拡張していったのか紹介します。

※今回紹介する内容については検討中の内容も含まれており、今後も継続して検討を進めていく予定です。

【Telemetry収集基盤の全体像】

検討を進めて見えてきた課題

ネットワークの自立最適化についてTelemetryを使う際に、弊社内での検討や外部での紹介を通して見えてきた課題を少し挙げてみます。

  • Telemetryに対応していない環境はどうするのか
  • データの加工をどこでどのように行うか
  • 大量のデータをどのように捌くか
  • 膨大なデータの中から自分の欲しい情報をどのように見つけるか
  • Telemetryを「守り」に使うか、「攻め」に使うか
  • Telemetry収集基盤の安定性の向上させるにはどうするか
  • Telemetry収集基盤自身の監視をどのように行うか

ここで挙げた課題について、答えが決まっていないものもあると思いますが、これらについて検討した内容を共有していきたいと思います。part 1では前半の3つに注目し、あらためてTelemetryとは何か、データの取得と蓄積に至るまでを検討しています。

Telemetryに対応していない環境はどうするのか

そもそも「Telemetry」とは何でしょうか。今までの匠コラムで出てきたTelemetryは「Streaming Telemetry」が中心でした。ですが、Telemetryは遠隔を意味する「Tele」と測定を意味する「Metry」から成る造語であることからもわかるように、Streaming TelemetryだけがTelemetryではありません。今まで使われてきたSNMPも広義のTelemetryの一部と捉えられます。環境を構成するすべての機器(ルータやスイッチだけでなく、サーバやストレージを含めると特に)がStreaming Telemetryに対応していないため、完全にSNMPの置き換えとしてStreaming Telemetryを考えることはできません。現状ではネットワーク機器に限ってもすべてTelemetryに対応している機器で構成されていることは珍しいと思います。また、Streaming Telemetryでリアルタイムに現在の事象を把握できていても、その事象の原因が何であるかは別の手法で探す必要があります。

そこで弊社のTelemetry収集基盤はより多くの情報を集められるように、広義のTelemetryに対応するべくコンポーネントの追加を行ってきました。例えばある障害が発生したときに、ネットワークが原因なのか、サーバが原因なのか切り分けるのに必要なデータを収集するにしても、サーバからStreaming Telemetryで情報収集することはできません。そのため、サーバからは従来通りSNMPでデータを取得し、ネットワーク機器からはTelemetryでデータを取得し、同じGUIでデータの比較をする、という方式をとりました。

【広義のTelemetry収集】

ネットワーク業界としてはIn-band Network Telemetry(INT)やIn-situ Flow Information Telemetry(iFIT)も検討され始めています。そのため、新しい技術を追い続けることも重要になってきます。

データの加工をどこでどのように行うか

データの加工については別のコラムでも取り上げましたが、どこで、どのようにデータを加工するのかはTelemetry収集基盤においては重要になります。収集基盤のどこかのコンポーネントにデータの加工を兼任させるのか、それともデータの加工専任のコンポーネントを新しく作るのか、悩ましいところです。データの収集頻度が高ければ、それだけ加工を行うコンポーネントに負荷がかかります。またデータを取得する機器のベンダーだけでなく、取得するデータの種類(センサーパス等)によって必要な加工が異なります。

Streaming Telemetryのデータ量と収集頻度を考慮すると、データの加工はできるだけ独立させておいた方が望ましいのではないかと考えています。それは取得するデータの追加に柔軟に対応するという面からも言えることです。そのため弊社のTelemetry収集基盤ではデータ自体の加工(不要な文字列の削除等)は独立したコンポーネントでデータの加工を行い、単純なデータの付与(タグ付け等)はデータを転送するコンポーネントで行っています。また、データの活用のために使うツールも人それぞれで、ツールにあったデータの加工を行わなければなりません。実現したいことを行うためにどのツールを使い、そのために必要なデータ形式は何かを把握しておく必要があります。

【各コンポーネントのデータ加工の役割】

大量のデータをどのように捌くか

Streaming Telemetryは取得対象機器への負荷の軽さから、SNMPに比べてデータの取得間隔を短くできることが利点の一つです。エンコーディングによってSNMPに比べてStreaming Telemetryの方が一回に取得するデータ量が小さくなることもありますが、データの取得間隔を短くしたことによって、データの総量が増大することが考えられます。この増大するデータを捌くために、大きく二つの視点からデータ収集基盤を再検討しています。

●データの流れの視点

取得するデータ量が増えるということは、ネットワークを流れるデータ量が増えることになります。また、データをどこで加工するのか(加工してからデータを流すのか、データを流してから加工するのか)によって流れるデータ量も変化します。今までの監視では十分であった帯域でも、Telemetryの利用によっては再検討が必要な可能性があります。

ただし、Streaming Telemetryにおいて帯域の検討はそれほど難しくないとも考えられます。決まった情報を決まった時間間隔で対象から取得しているため、基本的には一定量のデータ増加を見込んでおけば問題ありません。ピーク時を想定した設計は必要ないため、取得するデータが決まれば自ずと必要な帯域も決まってきます。これは収集するデータがLAN内に留まっているか、WANに出ていくかによっても異なり、WAN経由になる場合はデータ収集基盤を分散させる手法も検討しても良いかもしれません。

●データの蓄積の視点

流れてきたデータを蓄積する部分についても再検討が必要です。今まで以上のデータ量を保持する必要があるのは当然のことながら、データのライフサイクルについても考える必要があります。これらを考える上で重要なのは「何のためにStreaming Telemetryを使うのか」を明確にしておくことです。Streaming Telemetryはデータ取得方法の一つに過ぎず、抱えている課題を解決するためのツールの一つです。データ量が増えるため、過去の事象を遡りたいというニーズに対してStreaming Telemetryにおいては「必要そうだからデータを取っておこう」というアプローチで対応できるものではないと感じています。また、数秒間隔で取得していたデータを長期間保持していると。それだけでストレージコストが増大します。どれだけの期間、リアルタイムデータが必要なのかあらかじめ定義しておくことが必要となります。

データの蓄積に階層を持たせ、直近のデータはリアルタイムに近い時間間隔でデータを保持し、ある程度(例えば一ヶ月間)経過したデータは傾向がわかるくらいに丸めてデータを保持、またある程度(例えば三ヶ月間)経過したデータはさらにデータを丸めるか、もしくはデータを保持はするが検索対象から外すことで、ストレージコストや検索時に必要なコンピュートリソースを抑えようと考えています。

【データのライフサイクル

part 1のまとめ

簡単にpart 1で取り上げた課題と弊社が取った解決のアプローチをまとめます。

Telemetryに対応していない環境はどうするのか
→Streaming TelemetryだけでなくSNMP等も併用して、広義のTelemetryを収集する。

データの加工をどこでどのように行うか
→データの加工を行うコンポーネントへの負荷を考慮し、加工を行うコンポーネントは独立させつつ、簡単な加工処理は他のコンポーネントでも行う。

大量のデータをどのように捌くか
→データ保持期間をあらかじめ定義し、データ取得からの期間によって粒度を変えて保持、その後廃棄する。

part 1ではTelemetryを活用するまでに必要になる、主にデータの取得と蓄積に関して取り上げました。このあたりは今までのネットワークエンジニアが持っていたスキルだけでなく、他の領域のスキルも必要になっていると感じています。part 2では実際に貯まったデータを活用する際の課題と、収集基盤を継続的に使っていくために検討した内容を共有します。

関連記事

執筆者プロフィール

片野 祐

ネットワンシステムズ株式会社 ビジネス開発本部
第1応用技術部 第1チーム
所属

ネットワンシステムズに新卒で入社。仮想化技術、ハイパーコンバージドインフラ、データセンタースイッチやネットワーク管理製品の製品担当を経て、現在はAI関連技術の技術調査やデータ分析業務の経験をもとに、さまざまな場面でのデータの利活用を推進している。

Webからのお問い合わせはこちらから

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

カテゴリーで検索

タグで検索