LTN Blog 〜 Lenovo Technology Network 〜

レノボのソリューション・サーバー製品に関する技術情報、お役立ち情報をお届けします

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

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は表記のような内容を取り上げて行きたいと思います。

 

よくアプリケーションを使っていて、「レスポンスが悪いなぁ~」と思うことがあると思います。実際に調査するにもネットワークが遅くなっているのか?それともサーバ側が遅いのかが分からないと思います。そのときに役に立つのが今回紹介するDPI(Deep Packet Inspection)になります。

こちらの言葉は、今週ニューオリンズで開催されたNutanix社の.NEXTのイベントにおいて、Netsilの紹介されていた際にプレゼンターがDPIということ紹介がされていたものです。【実際にはNetsilはAPM(Application Performance Monitoring)であり、DPIではない】その意味もあり、しっかりとDPIの機能を紹介したいと思っております。

 

まず最初にDPIについて簡単に紹介したいと思います。

1.DPIのイメージ

f:id:t_komiya:20180512021504p:plain

イメージはこのような感じです。簡単に言うとネットワークの中に何が流れていて、それがどう使われているのかを分析するものです。社内ネットワークにも関わらず無駄にSNSに接続しているようなアプリや動画サイトに接続されていることでネットワークに負担をかけていることも考えられるようなシーンもあると思います。DPIはまさにネットワークに流れているものを詳細に遅延になっているものの原因を調べることが出来るものだと思って頂ければと思います。

ではその詳細について説明したいと思います。

2.DPIの詳細

f:id:t_komiya:20180512021937p:plain

上段のWikipediaの説明はネットワークに詳しい方は分かるかと思いますが、一般の方には少し難しいので図にしてみました。

今までネットワークの調査するにあたり、IPやTCPの情報でどこに流れているトラフィックがポート番号を見て識別することをやっていましたが、現在はHTTPでも様々はアプリケーションを動作しているため、ポート番号だけではどんなものが流れているのが分からないため、英語で示すとおりDeep(深く)パケットを調べることでネットワーク上でどのようなアプリケーション通信しているのかを見てしまうということがこちらでお話したい内容となります。

3.DPIの構成

f:id:t_komiya:20180512022551p:plain

DPIについては、どのような構成になるのか?と疑問に思う人がいると思いますので、こちらに図で示しております。

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

4.マニュアルで解析するとどうなるのか?

f:id:t_komiya:20180512023131p:plain

パケット解析するソフトウェアについては、昔はsniferなどがありましたが現在はWireSharkが一番有名なソフトウェアだと思います。こちらを利用してパケットを見ることが出来ますが、ネットワークに流れるパケット量は通常は目で監視できるレベルではないほどに多いことと、パケットでフローを分析するにはネットワークに精通しているエンジニアでないと解析に時間を要することになります。そのため、このようなケースではDPI用に処理できるようなソフトウェアを購入する必要がありますが、非常に高価になる可能性が高いです。

筆者の利用したことがDPIソフトウェアとしてはSolarwinds社のNPMという製品がありますが、製品そのものは高価ではないがかなりネットワークのことが理解していないと設定が出来ない製品となっております。次回のブログにてオススメのDPI製品を紹介できればと考えております。

5.パケット解析で分かること

f:id:t_komiya:20180512023900p:plain

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

 

6.ネットワークレスポンスタイム(NRT)の測定

f:id:t_komiya:20180512024437p:plain

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

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

7.アプリケーションレスポンスタイム(ART)の測定

f:id:t_komiya:20180512030149p:plain

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

 

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

https://www.solarwinds.com/-/media/solarwinds/swdc/topic-page-images/npm/orion-qoe-dashboard.ashx

真ん中に出力されているのがApplication Response Time(ART)の内容で、一番右がNetwork Response Time(NRT)の内容となります。

 

このように、何か遅いというものを可視化することで、迅速なトラブルシューティングにつながるのはいかがでしょうか。

 

宜しくお願い致します。