パケットモニタリングで可視化する真のユーザー体験

ネットワークを利用するユーザーは、実際にどのような体験をしているのか

ネットワークのモニタリングは、多くの企業や団体が実施しているでしょう。ですが、モニタリングの対象はネットワーク機器やサーバに対する動作監視がほとんどだと思います。Web会議や動画配信など、帯域を必要とするアプリケーションや用途が急速に増加している現在、単に機器の状態を監視するだけでは、不十分になっています。

機器の状態を監視するだけでは不十分

　ネットワーク機器のモニタリング方式としては、古くからSNMPが測定方法として利用されています。全体のトラフィック使用量が把握でき、機器の動作状況を知ることが可能です。
　欠点としては、スイッチポート単位のトラフィック量が把握できますが、粒度が低く、トラブルシューティングの情報源として十分ではありません。
　また、ネットワークを利用しているユーザーが、どういった実体験をしているのか、という現実的な状況についてはまったくわからないのです。
　モニタリングには、下記のような方式があります。

• ●機器（装置）モニタリング
  対象：機器(サーバやネットワーク機器)
  指標：機器リソース（CPUやメモリ、その他ハードウェアの状況）
  取得方法：SNMP
• ●フローモニタリング
  対象：ネットワーク機器が集計する通信統計値
  指標：送信元・宛先・TCP/UDPポート番号ごとの通信量（ヘッダ情報）
  取得方法：NetFlow/IPFIX
• ●パケットモニタリング
  対象：パケット取得ポイントに流れるユーザーの通信
  指標：フローモニタリングの指標＋アプリケーションの応答時間、その他パケットに含まれる行動履歴
  取得方法：ネットワークTAPによる通信データの分配、ネットワーク機器からの通信データミラーリング

拡大するネットワークの利用

　Web会議やVDI（Virtual Desktop Infrastructure、デスクトップ仮想化）は以前から利用されていますが、新型コロナウイルス禍以降は急速に利用が拡大しています。業務データを社内や一部の社員など限られた環境で利用している状況であれば、装置の動作状況だけを監視していても十分だったかもしれません。
　しかし、動画や音声が大量にネットワークを利用するようになると、ネットワーク機器は正常に動作していても、ユーザーが体験している状況とは違っていることがあります。
　例えば、在宅勤務でWeb会議が増えたけれど、つながらなかったり、映像がコマ落ちしたり、音声が飛ぶことがあるなど、障害とは呼べないまでも使い勝手が悪い現象は起こるでしょう。あるいは、Microsoft365を使用しているユーザーから「いつもより動作が遅く感じるのだけど」と連絡があることも増えています。
　しかし、この場合は、社内なので報告があるのですからまだ救われるのです。原因はわからないけど、何らかの不具合か問題があるのかも、といった認識ができます。
　しかし、社員以外の方はどうでしょう。自社の宣伝用ホームページで、商品の表示に時間がかかったり、途中で止まったりすれば、重大な機会の損失に直結します。ユーザーは、ユーザー側のネットワークに問題があるのかと考えてしまうかもしれません。同じような現象が何度も発生してしまうと、再度の利用はないかもしれません。
　こういったことを避けるためにも、ユーザーがどういったネットワークの体験をしているのかを知ることは重要なのです。

パケットモニタリングの利点

　機器（装置）監視だけでは、真のユーザー体験はわかりません。ネットワークが正常に動作していても、ユーザーが体験するネットワークの品質の善し悪しはわからないのです。
　機器（装置）モニタリングには限界があります。機器の障害やリソースの枯渇を検知し、システムダウンを避ける機器（装置）モニタリングは以前から実施されていますが、仮想化やソフトウェアが高度に抽象化された現在のシステムにおいては、機器（装置）モニタリングのみでは対応できないケースも増加しています。
　ユーザーから特定のシステムが遅いとか、動かないなどの報告があっても、大規模システムでは疑わしい場所（調査対象装置）が膨大になることや、機器障害を検出していない状態での調査は難しいのです。
　また、ユーザーからの報告を事実確認すること自体難しく、調査を困難にする大きな要因になっています。
　一方、パケットモニタリングは、ユーザーの通信データそのものを蓄積し、通信データからユーザーの体験を可視化することができ、ユーザーが感じる応答性の低下や通信不具合についても報告を受ける前に把握することが可能です。解析についても、ユーザーの通信そのものが保存されているため、その時点での実際の通信の状況を実データを基に確認し、原因がアプリケーションなのか、それともネットワークなのか、そもそもパケットは届いていたのかを客観的に判断することができます。
　パケットモニタリングによって、原因を解析した上で装置の調査に移行することで、問題解決までの時間を短縮することも可能になります。さらに、パケットモニタリングは自ら通信を発生することなく受動的に動作する（パッシブモニタリング）ため、導入に当たって既存の環境に影響を与えないという利点があります。
　通販サイトのような一般消費者向けサービスでは、ユーザーが不具合をサービス提供者に通告するケースは少ないでしょう。ユーザーがどういった体験をしているのかを常時モニタリングすることによって、受動的な報告に頼ることなくサービスの品質を維持することができ、パケットモニタリングによって機会損失リスクを可能な限り小さくすることができます。