ネットワーク遅延対策技術

連載 :

2011年8月23日(火)

エンジニアリングクラウドを支える技術

第1回では、富士通が発表した次世代ものづくり環境「エンジニアリングクラウド」と、富士通研究所が開発した仮想デスクトップ高速表示技術「RVEC（レベック）」の動画圧縮技術についてお話しました。第2回では、圧縮率が高くかつ極めて高速な静止画圧縮技術についてお話しました。

最終回となる今回は、エンジニアリングクラウドで問題となるネットワーク遅延への対策についてご説明します。

スループット低下の原因はネットワーク遅延とパケットロス

RVECのような仮想デスクトップでは、データの転送にTCP（Transmission Control Protocol）というプロトコルを用いています。TCPを用いた通信では確実にデータが届くことが保証されているため、ファイル転送のFTPや、HTML文書を転送するHTTPなどに用いられています。

さて、仮想デスクトップなどを使って遠隔地からサーバーの操作をしている時に、画面の反応速度が遅いと感じたことはないでしょうか。ネットワーク通信帯域は十分なはずなのに、このようなスループットの低下がTCP通信で発生する原因の1つがネットワーク遅延です。

ネットワーク遅延とは、データがネットワークを介して送信側から受信側に届くまでの時間のことです。遠隔地にあるサーバーとデータをやりとりする時には、データが届くまでの過程で数多くの中継器を通ることになりますが、各中継器においてわずかな処理時間が発生し、それらが積み重なったものが最終的に遅延となります。ネットワーク遅延を表す指標としては、片道ではなく往復にかかる時間である、往復遅延時間（RTT: Round Trip Time）が用いられます。平均的に、日本国内では100ミリ秒以下、日米間で約100ミリ秒、日欧間では約200ミリ秒の往復遅延時間があります。

では、なぜこのネットワーク遅延によりTCP通信のスループットが低下してしまうのでしょうか。TCP通信ではデータをパケットと呼ばれる最小単位に分割して送信しますが、確実にデータが届くことを保証するために、図1のように受信したパケットごとにACKと呼ばれる応答を返します。送信側ではACKが戻ってくるまで次のパケットの送信を待つため、ここで待ち時間が発生します。往復遅延時間が大きくなるとACKが戻ってくるまでの時間も遅くなりますので、この待ち時間が大きくなり、結果的にTCP通信のスループットが低下してしまいます。

図1：TCP通信の仕組み（クリックで拡大）

実際のTCP通信では1つずつのパケットではなく、複数個のパケットを同時に送信することができ、そのパケットの数（データサイズ）をウィンドウサイズと呼んでいます。ウィンドウサイズはOS（Operating System）によって異なりますが、一般的には64キロバイト程度です。TCP通信の最大スループットはこのウィンドウサイズと往復遅延時間から図2の式で求めることができます。

図2：TCP通信の最大スループット

RTTが100msでウィンドウサイズが64キロバイトの場合には、この式に当てはめると、ネットワーク通信帯域がどんなにあったとしも、TCP通信では5Mbps以上のスループットは出ないことになります。

TCP通信のスループットを劣化させるもう1つの原因がパケットロスです。通信が集中してしまう輻輳が発生し中継器でパケットが溢れてしまう、通信ノイズの影響でパケット内の情報が壊れてしまう場合などにパケットロスが発生します。パケットロスが発生すると送信側にはACKが帰ってきませんので、TCP通信では一定時間後に同じパケットを再送信します。ACKが帰ってくるまで何度でも同じパケットを送らなければいけませんので、TCP通信のスループットの低下につながります。

このようなTCP通信のスループット低下への対策として、ウィンドウサイズの設定値を大きくするという手法があります。ウィンドウサイズを大きくすることで、同時に送信できるパケットの数を増やすことができ、ACKを待たずに次々とパケットを送信することが可能になります。しかし、パケットロスが発生した場合には、ロスしたパケットまでさかのぼって再送することになるため、パケットロスが増加した場合にはスループットが低下してしまうという問題があります。

ネットワーク遅延対策技術～消失訂正符号

ネットワーク遅延とパケットロスの両方に対応するため、我々はTCPの代わりにUDP（User Datagram Protocol）に注目しました。UDPとはライブ中継などのストリーミング動画中継に用いられるプロトコルです。UDP通信はACKを待たずに次々とデータを送る方式ですので、データが確実に到達する保証はありませんが、TCP通信と違いネットワーク遅延やパケットロスの影響によるスループットの低下が発生しないという特徴があります。しかし、ストリーミング動画であれば、画面の一部分が一時的に消えてしまっても問題はありませんが、エンジニアリングクラウドでの仮想デスクトップでは、CAD画像が崩れてしまう、操作情報が送られないなどの問題が起きてしまいます。

そこで富士通研究所では独自の消失訂正符号RPS（Random Parity Stream）を新たに開発し、UDP通信とRPSを組み合わせることでネットワーク遅延とパケットロスの影響によるスループットの低下が発生せず、また確実にデータを送受信可能な、高速データ転送技術を開発しました。消失訂正符号とはFEC（Forward Error Correction：前方誤り訂正）の一種であり、送信側であらかじめデータに冗長性を付加しておくことで、送信データの一部が消失した場合でも、受信側では追加の情報を要求せずに、元のデータを復元する技術です。

消失訂正符号の仕組みについて、まずはパリティ符号を例に用いて説明します。送信しようとしているパケットが1、2、3であった場合に、パリティ符号では全てのパケットを加算した6というパケットをパリティパケットとして余分に送信します。途中で2が消えてしまった場合でも、受信側では1と3と6から2というパケットを復元することができます。このようにパリティ符号では1つまでのパケットロスを復元することが可能です。

富士通研究所で開発したRPS符号では、図3のように送信パケットを組み合わせて、全てのパケットをパリティパケットに変換します。例えば、送信するパケットが1、2、3、4であった場合に、1と2を組み合わせたパケットをaとします。同様に2と3を組み合わせたパケットをbとします。この、どのパケットを組み合わせるかというところがRPS符号で最も重要なところであり、長時間に及ぶシミュレーションを行って、パケットロスに対して最も復元できる可能性の高い組み合わせを求めています。

図3のように送信経路でパケットロスが発生しパケットb、e、fの3つがロスしてしまったとしても、受信側では受信することができたパケットdとgを組み合わせてパケット1を復元し、パケットaとdとgからパケット2を復元することができます。このように再送を待たずに受信することができたパケットのみを組み合わせることで元のパケットを復元しています。パケットロスに対してどれくらいのパリティパケットを生成するかを自由に変更できるところがRPS符号の特徴であり、パケットロスの発生確率が大きい回線では余分なパケットを多くすることもできます。

図3：RPS符号とUDPを用いたデータ転送の仕組み（クリックで拡大）

富士通ではUDP転送とRPS符号を使った高速データ転送をパッケージ化した「BI.DAN-GUN」をご提供しています。往復遅延時間が300ミリ秒である日欧間を想定した疑似環境において500MBのファイル転送にかかる時間を評価したところ、TCPを用いたFTP転送では190分かかりましたが、「BI.DAN-GUN」では10分にまで短縮でき、約20倍の高速化の効果が確認できました。

エンジニアリングクラウドでの画面転送への対応

ここまでにご説明したRPSの処理では送信しようとしているパケットの全てを組み合わせて、実際に送信するパケットを生成しています。そのため、ファイル転送のように、転送前に必ずファイルサイズが決まっている必要があるのですが、エンジニアリングクラウドの仮想デスクトップの場合、画面の更新量に応じてデータ転送量が大きく変動してしまうため、転送前にサイズを知ることができません。そこで、転送量が変動するような場合では、送信するデータを一時的にメモリ上に貯め込んでおき、1つのデータとして統合することで、RPSの符号化処理を行えるようにし、ファイル転送の時と同様にUDPで送信します。

この時、メモリに一定量のデータが貯まるまで送信を待っていると、画面の更新量が少ない場合には送信が遅れてしまい、画面更新に遅延が生じてしまいますので、メモリに貯まったデータ量が小さい場合でも一定時間ごとに強制的に送信処理を行っています。

以上のような改良を高速データ転送に適用し、予備実験として画像転送に組み込んだ結果、RTTが200ミリ秒の環境においても、TCP通信のようにスループットが低下せずに、約半分の時間で画面描画が完了することが確認できました。今後この機能を実際にエンジニアリングクラウドの仮想デスクトップ転送へ組み込んでいきたいと考えています。

今回は、富士通研究所で取り組んでいるネットワーク遅延への対応についてご説明しました。これらの技術を用いることで、ネットワーク遅延が大きい場合におけるスループットの低下を改善することが可能になりました。しかし、ネットワーク遅延そのものをなくすことは困難であり、仮にネットワーク遅延が1000ミリ秒ある環境であれば、パケットは1000ミリ秒遅れて到着することになります。このようなネットワーク遅延を根本的に解決するためには、地理的に離れた複数のクラウドを用意し、クラウド間で自動的にデータを同期させ、ユーザーはネットワーク遅延の最も小さいクラウドを利用することができるようにすることが必要です。このようなネットワーク遅延への対応につきましても、今後取り組んでいきたいと考えています。

まとめ

これまで全３回の連載に分けて、富士通の次世代ものづくり環境「エンジニアリングクラウド」を支えるコア技術についてご説明してきました。エンジニアリングクラウドの、安全性・信頼性、既存システムや他クラウドとの連携、グローバルレベルでの標準化・共通化等は、これらの富士通独自の技術やノウハウにより支えられています。

今後も富士通では、エンジニアリングクラウドを通じて、お客さまのものづくりを支援していきたいと考えています。