アプリ・ネットワー クの遅延をすぐに解決︕~DPI（Deep Packet Inspection） の機能紹介~

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

本日はDPI(Deep Packet Inspection)についてお話したいと思います。

よくあるトラブルの内容として、例えば「アプリケーションのレスポンスが悪いなぁ~」と思うことがあると思います。実際にその原因を調査するにもネットワークがボトルネックになって遅くなっているのか？それともサーバー側が遅いのかがわからないことがあります。その時に役立つのが今回紹介するDPI(Deep Packet Inspection)になります。

よく間違えるのは、APM(Application Performance Monitoring)を間違えてDPIを言われる方がいらっしゃいますのが、意味が違いますので十分注意して頂きDPIの機能を紹介したいと思います。

１．DPIのイメージ

DPIのイメージは上図のような感じになります。簡単に言うとネットワーク上でどのようなパケットが流れていて、そのパケットがどのように利用されているのかを分析するものです。例えば、社内用にPCから社内ネットワークを利用してSNS接続をしているアプリケーションやYouTubeのような動画サイトを閲覧してネットワークに不可を与えているケースなどが挙げられるかと思います。DPIはまさにネットワーク上で流れているパケットを詳細に分析して遅延の原因を特定できるようにするものだと思って頂ければと思います。

２．DPIの詳細

DPIの詳細に触れますが、上段のWikipediaの説明の方がネットワークに詳しい方は分かると思いますが、もう少しわかりやすくするために図にしてみました。

今までネットワークにおける障害を調査するにあたり、IPやTCPの情報でどこに流れているトラフィックがポート番号を⾒て識別することをやっていました。現在はHTTPでも様々はアプリケーションを動作しているため、ポート番号だけではどんなものが流れているのが分からないため、英語で⽰すとおりDeep（深く）パケットを調べることで詳細を把握することができます。つまり上図で言うところのアプリケーションデータ部分までしっかり分析することが原因の特定のつながります。

３．DPIの構成

DPIについて詳細を述べてきたものの、実際にどのような構成になるのか？と疑問に思う人がいるかと思いますので、わかりやすくイメージ化してみました。

クライアントからサーバーまでの通信をキャプチャを⾏います。分析をする端末（アナライザー）がクライアント〜サーバー間でパケットを収集できるようにしなければなりません。この場合、ネットワークが流れるスイッチにおいてクライアントが通信するポートに対して、通信ポートを（パケットキャプチャ用に）ミラー化する必要となります。こちらを設定していればアナライザーで分析を⾏うだけです。

４．マニュアル（手動）で解析するとどうなるのか？

パケット解析するソフトウェアについては、昔はsniferなどがありましたが現在はWireSharkが⼀番有名なソフトウェアだと思います。こちらを利⽤してパケットを⾒ることが出来ますが、ネットワークに流れるパケット量は通常は⽬で監視できるレベルではないほどに多いことと、パケットでフローを分析するにはネットワークに精通しているエンジニアでないと解析に時間を要することになります。

そのため、このようなケースではDPI⽤に処理できるようなソフトウェアを購⼊する必要がありますが、⾮常に⾼価になる可能性が⾼いです。

筆者の利⽤したことがDPIソフトウェアとしてはSolarwinds社のNPMという製品がありますが、製品そのものは⾼価ではないがかなりネットワークのことが理解していないと設定が出来ない製品となっております。

５．パケット解析でわかること

パケット解析を⾏うことでアプリが遅くなることの解決策についてお話したいと思います。パケット解析で分かることは上記内容ですが、ここで重要なのはネットワークの応答時間・アプリケーションの応答時間が分かります。また、クライアントが通信しているターゲットとそのプロトコルなども分かりますので、最終的にはネットワークが問題なのか︖アプ

リケーションなのかが判別できるところまで可能にします。

６．ネットワークレスポンス(NRT)の測定

アナライザーがネットワーク応答時間を測定することになるのですが、実際にTCPの3Wayハンドシェイクについて少し説明したいと思います。

クライアント〜サーバー間で通信するときには、このようなやり取りがあるわけですが、実際にネットワークレスポンスタイムがどの部分にあたるのかというと、RTT(Round Trip Time)に相当するところになります。ここについてはあくまでネットワークのみで応答時間を算出することになりますが、次にサーバ側のアプリケーションも含めて応答時間に⽬を向けてみましょう。

７．アプリケーションレスポンス(ART)の測定

こちらはアプリケーションの応答時間の測定についてです。クライアント側からサーバー側にGETの要求を送信して、最終的にサーバー側にパケットを送り始めるまでの時間がARTになります。サーバの応答が遅い場合には明らかにサーバを疑えばよいし、ネットワーク応答が悪い場合にはネットワーク側を調べればよいということになりますので、ネットワーク管理者とサーバ管理者とのたらいまわしもせずにトラブルシューティングが出来るようになります。

実際にこれがどのような出⼒結果については、先ほどコメントしたSolarwinds社のイメージがホームページ上にありましたので、リンクを貼り付けておきますので、参考程度に⾒ていただければと思います。

https://support.solarwinds.com/SuccessCenter/servlet/rtaImage?eid=ka12J000000kK1f&feoid=00N5000000AcxPm&refid=0EM2J000000ysRj

左側に出⼒されているのがApplicationResponse Time(ART)の内容で、右側がNetwork Response Time(NRT)の内容となります。

障害は発見に時間がかかることがあり、それに伴い障害復旧にも時間を要することが多々あります。そのようなときにこのようなお話を理解しておくことで、障害時に切り分けを迅速に行うことができます。

是非ご参考にしていただければと思います。