- ナレッジセンター
- 匠コラム
Telemetry活用に向けた課題と解決へのアプローチ(part 2)
- 匠コラム
ビジネス開発本部 第1応用技術部
第1チーム
片野 祐
はじめに
「ネットワーク創生する価値 再考」というタイトルでTelemetryについて数回に分けて紹介しており、再考④ではWorkflowエンジンによる管理の自動化について述べました。ネットワークの自動最適化を目指してTelemetryに注目し活用を検討してきましたが、再考④のまとめにある通り、まだ課題が残っていることも事実です。そこで今回は考えられる課題の解決に向けてどのようにアプローチし、弊社で構築してきたTelemetry収集基盤（TelemetryPoC）をどのように拡張していったのか紹介します。
※今回紹介する内容については検討中の内容も含まれており、今後も継続して検討を進めていく予定です。
検討を進めて見えてきた課題
ネットワークの自立最適化についてTelemetryを使う際に、弊社内での検討や外部での紹介を通して見えてきた課題を少し挙げてみます。
- Telemetryに対応していない環境はどうするのか
- データの加工をどこでどのように行うか
- 大量のデータをどのように捌くか
- 膨大なデータの中から自分の欲しい情報をどのように見つけるか
- Telemetryを「守り」に使うか、「攻め」に使うか
- Telemetry収集基盤の安定性の向上させるにはどうするか
- Telemetry収集基盤自身の監視をどのように行うか
ここで挙げた課題について、答えが決まっていないものもあると思いますが、これらについて検討した内容を以下で共有していきたいと思います。part 2では後半の4つに注目し、データの活用、Telemetry収集基盤をどのように継続的に使っていくか検討した内容を共有します。
膨大なデータの中から自分の欲しい情報をどのように見つけるか
データの加工とも関係がありますが、データを貯めるだけでなく活用できなければ意味がないため、自分が必要とするデータを迅速に見つける方法が必要になります。データをどのように検索、可視化するかをあらかじめ考えた上で、それに適した形式でデータを蓄積する必要があります。どのような検索、可視化をする必要があるのかによって、適したデータベースを選定する必要があります。行指向なのか列指向なのか、データフォーマットの事前定義が必要なのかどうか、というような、データ量が膨大になったために、ネットワーク運用者に求められるスキルも広くなっています。
データドリブンという言葉がいろいろなところで使われるようになり、それを実現するためにはデータの扱いに慣れることも重要です。ネットワークエンジニアが多い弊社ですが、社内でデータ分析に関する勉強会が開かれたり、データ分析コンペが開催される等、データを扱うためのエンジニアの意識改革も日々行われています。
Telemetryを「守り」に使うか、「攻め」に使うか
Streaming Telemetryを使うことで今まで見ることのできなかったバースト性のトラフィックを検知することや、SNMPでは取得することのできなかった情報を取得することができるようになります。これらを実現したい背景には「予期していなかった事象へ対応するコストを減らしたい」というものがあります。この「コストを減らしたい」という背景にも稼働中のネットワークやサービスを停止させないことが前提にあると思います。しかし、通常本番環境では冗長構成やバックアップ回線が取られているため、これで賄えてしまう問題についてはStreaming Telemetryを有効活用できているとは言えません。もちろん今までであれば気付かなかった事象に対応できるのであればそれに越したことはないですが、運用コストの削減という「守り」の強化に対する予算やモチベーションはなかなか厳しいのも事実だと思います。そこでStreaming Telemetryだからこそできることに注目して「攻め」の活用もこれから重要になってくると考えています。その一つとして、機械学習を使って人間の目ではわからない気付きを得たり、異常検知をしたり、予知保全をすることが考えられます。機械学習を行うにあたりデータ量というのは一つのキーポイントになり、またこの先起こりうる事象を予測することで、先手を打った対応ができます。
収集したデータをどのように活用するかについて、明確な回答はなく抱えている課題次第だと思います。「守り」も「攻め」も、どちらの方が良い、ということはなく、どちらも重要な要素なので、ここでもなぜTelemetryを活用したいのか、何を実現したいのかをあらためて考えることが答えへの一歩目になると思います。
Telemetry収集基盤の安定性の向上させるにはどうするか
ここまではTelemetryデータの取得や活用について述べてきましたが、そもそものTelemetry収集基盤側にも目を向ける必要があります。こちらも過去のコラム（こちらやこちら）で紹介してきましたが、いくらデータを取得してもその収集基盤自身が正常に動作しなければ意味がありません。
検証の際に流していたデータ量では正常に動作していても、流すデータ量を増やしたり、一定期間データを流し続けてデータがある程度貯まると問題が起こる、ということもしばしばありました。コンポーネントの冗長化を計るだけでなく、一部のコンポーネントが停止した際にデータの完全性が保たれるのかにも注目して構成を検討しています。例えば収集基盤を構成するコンポーネントをクラスタ化したり、ソフトウェアのバージョンを上げることで機能追加や安定性の向上を図っています。また、弊社ではWeb Scaleに対応するべく各コンポーネントをコンテナ(docker)で動かし、オーケストレーションツールとしてkubernetesを利用していました。当初はkubernetesの状態を確認するのに基本的にCLIで操作をしていましたが、Web UI(Dashboard)を導入することでGUIでコンポーネントの状態を確認できるようにしたり、Red Hat社のOpenShiftのようなベンダー製の管理プラットフォームを利用することでさらに利便性を向上させていきました。OSSとベンダー製ツールの組み合わせに関して、今後も検討を続けていく予定です。
Telemetry収集基盤自身の監視をどのように行うか
収集基盤の安定性向上とも関連しますが、収集基盤自身が正しく稼働しているかモニタリングすることも重要になります。基盤の監視を行うことで運用の品質が向上するだけでなく、基盤が正しく継続稼働することでTelemetryを使って実際に行いたい業務に集中することができます。
収集基盤自身のモニタリングデータをどこに蓄積していくか、大きく二つ考えられます。
●Telemetry収集基盤と同じところにモニタリングデータも入れる
今回収集基盤として採用しているElastic Stackはdockerやkubernetesとの親和性も高く、モジュールを追加することでコンテナのメトリック情報をログ情報を取得することができます。そのため、一つの収集基盤にすべてのデータを入れることで、コンポーネントをできるだけ増やさず一元管理をすることができます。
●モニタリング用の収集基盤を別に立てる
上記のようにすべてのデータを一ヶ所に入れた場合、活用のために収集していたTelemetryデータと管理のために収集していたモニタリングデータが何らかの障害によって共倒れしています可能性を秘めています。そのため、モニタリングデータのみ別出しすることで、より安全にクラスタの監視を行うことができます。実際、いくつかの監視ソフトウェアではモニタリングの機構を別に持っているものがあります。
モニタリング用の収集基盤を立てると、その分追加のリソースやコンポーネント数が増えます。これらはトレードオフなので、自身にあった方法を選択していくとよいでしょう。
おわりに
最後ににpart 2で取り上げた課題と弊社が取った解決のアプローチをまとめます。
膨大なデータの中から自分の欲しい情報をどのように見つけるか
→検索や可視化で使うツール、どのように可視化するのかをあらかじめ考慮し、それぞれに適したデータ形式でデータを貯める。
Telemetryを「守り」に使うか、「攻め」に使うか
→「守り」においても「攻め」においてもTelemetryを使う目的を明確にし、特にStreaming Telemetryでしかできないことは何かを検討する。
Telemetry収集基盤の安定性の向上させるにはどうするか
→コンポーネントの冗長化、ソフトウェアのバージョンアップ、OSSとベンダー製ツールを併用する。
Telemetry収集基盤自身の監視をどのように行うか
→管理、運用面を考慮し、Telemetry収集基盤で自身の監視も行うか、別に監視用基盤を立てるか検討する。
本コラム（part1, part2）でネットワークの自動最適化を目指したTelemetryの活動の中で新たに見えた課題と弊社が取ってきた解決へのアプローチについて共有しました。このコラムではTelemetryデータが収集できる技術を持っているところから始まっていますが、初めてTelemetryデータの収集を行ったときは、データを収集して簡単な可視化をするところに行き着くまでにも苦労が絶えませんでした。Telemetryの活用を検討した苦労話も含め、ご興味のある方は弊社担当営業までご連絡ください。
関連記事
執筆者プロフィール
片野 祐
ネットワンシステムズ株式会社 ビジネス開発本部
第1応用技術部 第1チーム
所属
ネットワンシステムズに新卒で入社。仮想化技術、ハイパーコンバージドインフラ、データセンタースイッチやネットワーク管理製品の製品担当を経て、現在はAI関連技術の技術調査やデータ分析業務の経験をもとに、さまざまな場面でのデータの利活用を推進している。
Webからのお問い合わせはこちらから
ナレッジセンターを検索する
カテゴリーで検索
タグで検索