今回は、モニタリングの基本に戻って、トラフィック監視についてお話をしたいと思います。

みなさん、トラフィック監視はしていますか？

大体の方が、トラフィック監視をしていると回答されるでしょう。
では、すこし質問の方向性を変えてみるとどうでしょうか。

そのトラフィック監視の手法は適切ですか？

もしかしたら、現時点で課題感を持たれている方もいるかもしれませんし、適切かどうかと聞かれると、ちょっと回答に困る方もいるかもしれません。

そこで、トラフィック監視をおこなう目的を改めて考えてみましょう。

多くの方が、帯域幅に対する使用量（率）を把握することで、リソースに余裕があるか、または不足しているかを確認するために監視をされていると思います。ただ、この状態を正しく監視することは、実はとても難しいことなのです。

ネットワーク通信帯域の単位は、bps で表現されます。100 Mbps や 1 Gbps といった単位で、秒間何ビットの転送容量があるかということになります。

現状、トラフィック監視の手法は、ネットワーク機器やサーバーのインターフェースの Octet（バイト）のカウンター値を取得し、前回値との差分から平均の秒間単位時間の通信量を算出する値が一般的です。これは、スループットを監視しているようですが、実は容量を監視しているということです。

つまり、毎秒と言っておきながら、値は毎秒計算された値を取得しているわけではなく、短くて 1 分、長いと 10 分や 15 分といった間隔で取得した値から算出した平均値を監視しているわけです。目まぐるしく変化するトラフィックに対して、監視間隔での平均値をあたかも秒間の値であるかのように監視していることを忘れてはいけません。

高帯域化が進んだことで、瞬間的にスイッチの転送能力を超えた大量のトラフィックが流れることで、パケット廃棄や通信遅延が発生するといった事象が発生しています。ただし、従来の監視手法では、1分間隔で監視していたとしても、このタイミングで突発的なバーストトラフィックが発生していたかを正しく把握することができません。それでも、トラフィックのモニタリング手法としては古くからのやり方がスタンダードであり、このような高帯域トラフィックをモニタリングする仕組みが、一般的には広まっていないという課題があります。

SNMP では、ポーリング間隔を極端に短くすることが現実的でなく、Telemetry という手法に注目が集まっています。

次世代 SNMP なんて言われていますが、現時点で取得可能なメトリックは MIB 相当なので、Telemetry の強みは、SNMP より短い間隔で監視ができるという点と、ポーリング型ではなく、pub / sub モデルによる効率的な監視がおこなえるという点にあると言えます。

トラフィックだけでなく、CPU 使用率などもめまぐるしく変化する値の一つです。詳細な監視間隔でモニタリングする手法は、従来の監視方法では見つけることができなかった問題を明らかにするメリットがあります。

一方で、膨大なデータを取り扱うことになるので、値の保持の仕方やそこからのアラートの発生方法などは検討が必要であることに注意しなければいけません。メトリックによっては、さほど詳細な間隔で監視をする必要がないものもあるので、従来の監視手法との使い分けも必要かもしれません。

SNMP にこだわって製品を開発してきた IBC も、このバーストトラフィック、時にはマイクロバーストとも表現されるトラフィックの監視手法には、頭を悩ませてきました。自然な流れで Telemetry に着目したものの、対応機種の少なさやベンダーごとの独自の実装方式への対応は、現時点では難しい状況にありました。

また、Telemetry を実装する目的として、バーストトラフィック監視に着目したものの、例えば、5 秒や 10 秒間隔で値を収集したところで、結局 Octet カウンターの平均値を監視するだけでは不十分ではないかと考えていました。

そんな矢先に、APRESIA Systems 様より協業のご相談をいただき、彼らが開発したバーストレコーダーの機能の紹介を受け、まさに私が求めていた値を収集できる可能性を感じ、機能開発に踏み切りました。

詳細はこちらを参照ください。
https://system-answer.com/2019/06/05/24338/

トラフィック解析単位が、125 マイクロから 10 ミリ秒という詳細な帯域分析が可能であり、ヒストグラム情報として統計情報を保持していることから、この統計情報を取り込むことで、高帯域トラフィックの発生傾向を把握することが可能になりました。

値を取得する従来の監視手法では、取得する数値の数が膨大すぎることから、あえて値を一定の帯域幅で丸め込んでしまい、その帯域幅での通信があった回数を 1 分間隔で収集することで、取得負荷を低減する手法を取りました。

これによって、値自体はマイクロ秒オーダーで分析した情報を、従来通りの 1 分間隔のデータ収集で表現することに成功しました。

分析する帯域幅（ヒストグラム情報）は、任意に変更することができるので、10 Gbps であれば高帯域部分（例えば 8 – 10 Gbps といった値）にフォーカスして、この帯域幅でどの程度の通信があったかといった監視をおこなえるようになりました。

この例では、従来の 1 分間隔の Octet カウンターのトラフィック監視では、3 Gbps 程度のトラフィックであるインターフェースに対して、500 マイクロ秒単位で解析した結果では、黄色の部分が約 4 – 5 Gbps 、赤色の部分では約 7 – 10 Gbps の帯域幅での通信が発生していたことがわかります。

分析の単位時間が 500 マイクロ秒であるため、1 分間ではカウンター値が 12 万カウントに上昇します。（60 * 1,000 * 1,000 / 500 = 120,000）通常のトラフィック監視では、トラフィック量を監視しているため、トラフィックが上昇すると値が上昇するグラフとなりますが、ヒストグラムの統計値を収集するため、この 12 万カウントは一定で、その中の帯域幅の内訳が変化するようなグラフの表現となります。

この例では、すべてのトラフィックを解析対象としていますが、バーストレコーダーの機能として、前段に ACL 処理を入れることができるので、特定の送信元、宛先、プロトコルに特化してトラフィックを解析するといったことも可能です。

この機能連携は、昨年の Interop ShowNet でも実証実験を済ませており、IBC としては初となる Award のファイナリストにも選出していただきました。

現在、このような PoC を経て、実際にお客様にご利用いただけるように、正式機能としてのリリースを目指し、ヒストグラム情報の連携強化とトラフィック詳細分析といった機能開発をおこなっています。

このような新たなトラフィック監視にご興味があれば、ぜひ弊社までお気軽にお問い合わせください。

by マーケティング統括部 ソリューションサービス部 部長 明星 誠