クラウドの円滑な導入に欠かせないネットワークパフォーマンス

クラウドコンピューティングで適切なパフォーマンスを確保するためには、戦略的なプランニング、円滑な導入、サービスの継続性の3つが重要である事を第1回で紹介させて頂きました。

今回はその中から、円滑な導入を実現するための課題をWAN最適化でどのように解決できるかについて説明していきます。

移行（マイグレーション）

パブリックやプライベートクラウドへの移行には、ネットワークの遅延やコスト、競合（複数のデバイスが同一のハードウェアを利用しようとする）が課題となります。これらの問題はWAN最適化ソリューションによって解決可能です。例えば、リバーベッドテクノロジーのSteelheadというWAN最適化装置を利用した場合、データ移行時に発生する負荷とハイブリッドクラウドへのデータ転送を最適化する事ができます。

・最初の移行

アプリケーションやデータ、またはサーバーの完全イメージを拠点からデータセンターへ、プライベートデータセンターからパブリッククラウドへ移行する時に、WAN最適化装置では、最初の転送時も高速化する事ができます。

・移行の拡張

最初は部分的なテスト移行から始め、徐々にクラウド移行を拡張していく手法もあります。 WAN最適化装置を利用する事により、段階的な移行を実行しているにもかかわらず、ユーザーが全く気付かないまま移行が完了しているケースもあります。

パフォーマンス

ネットワークのパフォーマンスを確保するためには、帯域を増幅すれば良いという話をよく聞きますが、実際には帯域が十分に余っていたとしてもネットワークのパフォーマンスに影響を与える複数のボトルネックが存在します。一般的にWANとLANを比較した場合、WAN回線の方が帯域が狭く、遅延が大きくなります。　WAN回線のパフォーマンスに影響を及ぼす代表的なボトルネックは4つあり、それぞれ説明していきたいと思います。

1番目のボトルネックは当然ながら帯域です。　どのアプリケーションも契約帯域幅以上のスピードでデータ転送を実現する事はできません。残り３つのボトルネックは遅延に関係してきます。 この遅延のボトルネックを認識するには、広帯域を契約しているか、帯域幅に問題を抱えていないケースが殆どです。遅延からのボトルネックにより、アプリケーションが契約している帯域幅を利用できていないケースや帯域は大幅に余っているはずなのに、アプリケーションが遅いという状況に心当たりがあると思います。

遅延からのボトルネック - 1

1つ目の遅延からのボトルネックは、エンドツーエンドでアクノレッジ（確認応答）を行うTCPの特性です。 TCPは、ウィンドウサイズによって一度に送信できるデータ量（セグメント）が決まっています。受信側のウィンドウが満杯になると、送信側は受信側からのアクノレッジが無いと新たにパケットを送信する事ができません。ウィンドウの最大値が小さすぎると回線のスループットは下がります。なぜなら、一度に送信できる量はウィンドウの最大値までとなり、毎回通信先からアクノレッジが届いてからしか次のセグメントを送信できない事になるからです。　現在では、様々な手法でこの制限を克服する事が可能となっています。　また最新のオペレーティングシステムでも大きめのTCPウィンドウサイズを利用できるようになっています。　しかしながら、多くのクライアントとサーバーの設定はWAN向けにではなく、LAN向けに設定されている事が多く、WANの遅延を考慮したTCPスタックを持つクライアントやサーバーはあまり多くありません。

日本国内の遅延は、各種回線サービスや計測地域により異なりますが、大よそ10msecから40msecの範囲で通信されていると仮定したとします。図1のグラフは、1.544Mbps（T1）の回線でTCPコネクションの最大ウィンドウを64KBの設定で、遅延を増加していった時のスループットグラフです。遅延が小さい場合は、想定帯域幅と同じスループットを利用でき、40msecを超えたところから帯域幅が小さくなっていきます。日本国内では、TCPのレベルでは帯域にあまり影響は無いように見えます。しかしながら、ここで図3のグラフにて、最大ウィンドウサイズを小さくしてみた場合のスループットをT1回線とT3回線（45Mbps）で比較してみます。T1回線のスループットは殆ど変化が無いように見えますが、T3回線は遅延が増加すると極端にスループットが下がってしまいます。このグラフからウィンドウサイズが非常に重要であるという事をお伝えできたかと思います。