EDI outsourcing: The evolution to B2B managed services

Transcription

1 Aspera FASP 高速トランスポート TCP ベースの代替転送テクノロジーとの重要な比較 目次 : 2 はじめに 3 高速 TCP の概要 5 UDP ベースの高速ソリューション 10 Aspera FASP ソリューション ハイライト 課題伝送制御プロトコル (TCP) は理想的な状態のもとでは信頼性の高いデータ配信を提供しますが 生来のスループットにボトルネックがあり これが長距離 WAN で見られるパケット ロスと遅延の増加によって顕在化し深刻な問題になります 帯域幅を追加しても 実効スループットに変化はありません ファイル転送速度は向上せず 高価な帯域幅は十分に活用されません ソリューション TCP とは異なり FASP のスループットはネットワーク遅延に左右されず 極めて大きなパケット ロスへの耐久性も備えています FASP の転送時間は ネットワークの状態に関係なく 可能な限り高速で ( 最高で標準 FTP の 1,000 倍 ) 高度な予測が可能です 最高転送速度を制限するのは エンドポイント コンピューターのリソース ( 通常はディスク スループット ) のみです メリット 最高の速度と信頼性 卓越した帯域幅制御 組み込みのセキュリティー 柔軟でオープンなアーキテクチャー

2 はじめに今日のデジタル ワールドでは 巨大データの国際的な転送を含むデジタル データの高速で確実な移動が 事実上すべての業界でビジネスの成功に不可欠となっています 伝送制御プロトコル (TCP) は従来このデータ移動のエンジンとなってきましたが パフォーマンスに生来のボトルネックを持っています ( 図 1) これは往復時間 (RTT) が長くパケット ロスの大きなネットワークでは特に目立ち 広帯域幅ネットワークで最も顕著になります こうした生来の ソフト なボトルネックは TCP の Additive-Increase- Multiplicative-Decrease (AIMD) 輻輳 ( ふくそう ) 回避アルゴリズムによって発生することはよく知られています AIMD は使用可能なネットワーク帯域幅をゆっくりとプローブし パケット ロスを検出するまで伝送速度を上げ パケット ロスを検出すると急激に伝送速度を下げます しかし ネットワークの輻輳とは関係のない物理的なネットワーク メディアによるパケット ロスなど パケット ロスの他の原因によっても 伝送速度が同様に低下することは あまり理解されていません 事実 TCP AIMD 自体がパケット ロスを生じると同時に ボトルネックの一因にもなります AIMD は パケット ロスが発生するまで伝送速度を増加させる際に 使用可能な帯域幅を本来の性質によってオーバードライブします 実のところ この自ら招いたパケット ロスが 他の原因 ( 物理メディア クロス トラフィックのバーストなど ) によるロスを上回り ロスのない通信 チャネル を 予測不可能なパケット ロス率 (plr) を持つ信頼できない チャネル へと変えてしまう場合もあります TCP AIMD のパケット ロスに基づく輻輳制御は スループットに非常に悪い影響を与えます すべてのパケット ロスが再伝送を引き起こし 再伝送が行われるまで受信側アプリケーションへのデータ配信を引き止めます これにより どのネットワーク アプリケーションのパフォーマンスも低化する可能性がありますが 基本的には信頼性の高い大きな バルク データ ( 大量のデータ ) の伝送が損なわれます たとえば 順序どおりの配信 ( バイト ストリーム ) を必要としないファイル転送が損なわれてしまいます この信頼性 ( 再伝送 ) が TCP の輻輳制御と結び付いて ファイル転送のスループットに深刻な人工的ペナルティーが生じます これは WAN 上の FTP HTTP CIFS NFS など TCP 上に構築された従来のファイル転送プロトコルの低パフォーマンスによって明らかです 往復時間とパケット ロス率が低い場合 これらのプロトコルにハードウェア デバイスや代替 TCP を通して適用される TCP アクセラレーションといった最適化で ファイル転送スループットをある程度まで改善できます しかし グローバルな距離では その効果は大幅に減少します さらに このホワイトペーパーで後述するように TCP または UDP の並列ブラスト化テクノロジーは明らかに高いスループットを実現する代替手段を提供しますが その代わりに途方もない帯域幅コストが生じます これらのアプローチでは すでに転送中または受信済みのものと重複する不要なファイル データを大量に再伝送し 時にはこれが巨大な量に達します このために ファイル データを何回も 不要に長い時間をかけて転送することになり 莫大な帯域幅コストが発生します 具体的には 再伝送されているデータ パケットを除く有用ビットのスループット つまり グッドプット が非常に低くなります これらのアプローチでは 無駄なデータでパイプが満たされ ネットワーク帯域幅の使用率が一見向上したように見えるだけで 転送時間は遅いままです TCP 最適化やシンプルなブラスターがネットワーク中心のプロトコルとして高い グッド データ スループットを達成する狭いネットワーク条件では ストレージ システムとの間のデータの移動時にさらにソフト ボトルネックに遭遇します バルク データを最高速度で転送するには 転送中でも受信済みでもない グッド データ を転送するために データのソースから宛先までの転送パス全体で使用可能な帯域幅をフルに利用する エンドツーエンドのアプローチが必要です 様々なネットワーク往復時間 パケット ロス率 帯域幅キャパシティー特性を持つ今日の生活必需品としてのインターネット WAN 環境でこの目標を達成するには バルク データの移動に対する新しい革新的なアプローチが必要です 具体的に必要とされるのは 信頼性と速度の制御を完全に切り離したアプローチです このアプローチの信頼性メカニズムでは 必要なデータのみを再伝送して 100% のグッド データ スループットを実現する必要があります また 共有インターネット ネットワーク上で広く展開される場合 このアプローチの速度制御では 他の転送やネットワーク トラフィックが存在する場合の帯域幅の公平性と輻輳回避の原則を守りながら 必要な場合は優先度の高い転送に専用帯域幅を割り当てるオプションを提供する必要があります Aspera FASP は これらの中心原則の上に構築された革新的なバルク データ転送テクノロジーであり パブリックおよびプライベート IP ネットワーク上でファイルを転送するための従来の TCP ベースのトランスポート技術に代わる最適な手段を提供することを目的としています Aspera FASP はエンドポイント アプリケーション プロトコルとしてアプリケーション層に実装されるため 標準ネットワークの変更は一切不要です FASP は ネットワーク遅延やパケット ロスに関係なく あらゆる IP ネットワーク上で 100% の帯域幅効率でバルク データを転送するように設計されており バルク データを移動するための究極の高パフォーマンス次世代アプローチを提供します 2

3 このホワイトペーパーでは ファイルベースの転送を 加速 する商用分野と研究分野の両方の代替アプローチについて 帯域幅稼働率 ネットワーク効率 および転送時間の観点から説明し それらのパフォーマンスと実際の帯域幅コストを Aspera FASP と比較します しかし 物理的なメディア エラーやクロス トラフィックのバーストによるバッファー オーバーフローが原因で発生するパケット ロスを無視できない WAN ( 広域ネットワーク ) では この改善効果はたちまち失われます これらのネットワークで 1 つのパケット ロスが発生すると TCP 送信ウィンドウは大幅に縮小し 複数のロスが発生するとデータ スループットは壊滅的な影響を受けます ウィンドウあたり複数のパケット ロスが発生すると 通常は伝送タイムアウトが発生し それによって生じた送信側から受信側への帯域幅 - 遅延 - 結果のパイプラインは枯渇して データ スループットはゼロに落ち込みます 送信側は基本的に データ伝送を再度低速で開始する必要があります これとは対照的に Aspera FASP では 伝送速度がパケット ロス イベントと連結していません 脱落データは エンドツーエンドが望む帯域幅に対応した速度で再伝送されます 再伝送では 事実上理想的な帯域幅効率が達成されます データが重複して伝送されることはなく 合計目標キャパシティーがフルに利用されます 図 1: 棒グラフは TCP を使用するファイル転送テクノロジーについて OC-3 (155 Mbps) リンク上の様々なパケット ロスとネットワーク遅延条件で達成可能な最大スループットを示しています ( 黄色で表示 ) このスループットには超えることが難しい理論上の限界があり これはネットワークの RTT とパケット ロスにのみ左右されます 帯域幅を追加しても 実効スループットは変らないことに注意してください ファイル転送速度は向上せず 高価な帯域幅は十分に活用されません 高速 TCP の概要最近では TCP プロトコルの新しい高速バージョンやこうしたバリエーションを実装する TCP アクセラレーション アプライアンスが多数開発されています 高速 TCP プロトコルは AIMD の根本的な欠点を認識し このウィンドウベースの輻輳制御アルゴリズムを改良して それによって生じる人工的ボトルネックを軽減し 長期的な平均スループットを改善しています 一般的にこれらのプロトコルの最先端バージョンでは パケット ロス イベントが発生するまでスループットを増加させる代わりに ネットワーク キューイング遅延などのより充実したシグナルを測定することで輻輳検出を改善することを目指しています これは TCP フローによるパケット ロスの発生を防ぐのに役立つため それによって人工的に輻輳回避を行い パケット ロスがほぼゼロのネットワークで長期的なスループットを向上します 次の図 2 に示すように 高速 TCP の商用バージョン (CUBIC H-TCP BIC などのバリエーションを含む ) のひとつである FAST TCP が 1% のパケット ロスを持つネットワーク上で実現するスループットは 低遅延ネットワーク上では標準 TCP Reno を上回りますが 国や大陸を横断するリンクに一般的な長い往復時間を持つネットワークではたちまち失速します これとは対照的に FASP のスループットはネットワーク遅延が増大しても低下することはなく 最大 100% の効率の伝送と 95% 以上の帯域幅キャパシティーで有効なファイル転送スループットを達成します 同様に パケット ロスが増加した場合 ( 例 : 5% 以上のロス ) FASP のスループットは同じ量だけ低下します パケット ロス率が上がると 加速化された TCP のスループットは Reno の値に近くなります 図 2: 中程度のパケット ロス (1%) を持つリンクでの 1 GB ファイルの転送スループットを Reno TCP 市販の高速 TCP UDT および Aspera FASP について比較しています 低遅延ネットワーク上では加速された TCP は Reno のスループットを改善しますが 国や大陸を横断するリンクに一般的な長い往復時間を持つネットワークではたちまち失速することに注意してください これとは対照的に FASP のスループットは遅延が増大しても低下することはありません 同様に パケット ロス率が増加した場合 ( 例 : 5% のロス ) FASP のスループットは同程度の量だけ低下しますが 高速 TCP では Reno と変わりません 3

4 パケット ロスに対する標準および高速 TCP の反応により 送信側は送信ウィンドウを縮小するだけでなく ( これによって転送速度が不安定になります ) TCP の順序どおりの配信を保証するために 再伝送パケットを持つ送信ウィンドウの新規パケットを先取する必要があります このように同じ TCP 送信ウィンドウで新規パケットと再伝送パケットを伝送することで 働きの悪い TCP 輻輳制御は 転送の完全性を保証する TCP 信頼性制御に巻き込まれ バルク データなど順序どおりの配信を必要としないアプリケーションの転送スループットに不要なハンディを負わせます TCP の信頼性が保証する内容は 失われるデータが一切ないこと ( 脱落パケットは受信側によって検出され 後で送信側が再伝送します ) および受信データが順序どおりアプリケーションに配信されることです これらの 2 つの保証を遂行するために TCP は脱落パケットを再伝送するだけでなく 脱落パケットが到着するまで その前に到着した順不同のパケットを保留します ( カーネル メモリーに一時的に格納 ) これにより 受信データをアプリケーション層に順序どおりに配信できるようにします 受信側は欠落データを受信するまで着信パケットを RAM に継続して格納する必要があるため 再伝送は最優先の緊急案件となり 新規データの送信はこれに合わせて遅らせる必要があります 具体的には パケット ロス イベントごとに 新規パケットはスローダウンする必要があり ( 通常は 脱落パケットが受信側に再伝送されて確認されるまで 送信ウィンドウはフリーズします ) 再伝送パケットが受信側エンドでバイト ストリームの 穴 を埋めるのを待ちます 要するに TCP の信頼性制御とフロー制御 ( または輻輳制御 ) は 完全に連動するように設計されています このタイプのメカニズムは 多くのアプリケーションで要求される厳密に順序どおりのバイト ストリーム配信を TCP に提供しますが 厳密なバイト オーダーを生来必要としないファイル転送などのアプリケーションには壊滅的な影響を与えます そして これらのアプリケーションには目に見えない人工的なボトルネックがもたらされ 対応するデータ スループットが制限されます これを明確に示すために シンプルな例を考察してみましょう ここでは パケット ロスごとにウィンドウが 8 分の 1 縮小する場合 高速 TCP で輻輳と無関係な 1 つのパケット ロスに起因するスループットの損失量を計算します パケット ロス率が 1% で往復遅延時間が 100 ms の Gigabit ネットワークの場合 パケット ロスごとに速度は 8 分の 1 ずつ低下し (TCP Reno は 2 分の 1) 送信側が パケット ロス イベント前の元の送信速度 (1 Gbps) を回復するまでの所要時間は 1 Gbps 8 ( ビット / バイト ) 1024( バイト / パケット ) 100 ms ( ドロップ率 / ロス ) 100ms 秒となります 高速 TCP は 1 つのパケット ロス イベントだけで この回復期間に 152.6s 1 Gbps 0.125/2 約 8.9 GB ものスループットを失います 実際の WAN では 実効値はさらに大きくなります なぜなら ネットワーク キューイング 物理メディア アクセス スケジューリング 回復などにより RTT が大きくなる可能性があるからです このため 送信側が回復するまでの所要時間は 通常は 秒以上になります 複数のパケット ロスが連続して発生すると大惨事になります Internet Engineering Task Force (IETF) は この影響を次のようにはっきりと述べています LFN ( ロング ファット ネットワーク ) のキャパシティーに合わせてウィンドウ サイズを拡大すると ウィンドウあたりの複数のパケットがドロップする確率も上がります これは LFN 上の TCP のスループットに壊滅的な影響を与える可能性があります さらに RFC 1323 の発行以来 ある種のランダム ドロップに基づく輻輳制御メカニズムがゲートウェイに導入され ランダムにスペースをとったパケット ドロップが一般的になりました これによっても ウィンドウあたり複数のパケットがドロップする確率が上がります 1 この速度低下やスループットの損失は 厳密な順序どおりの配信が必須のバイト ストリーム アプリケーションのために本当に必要な場合もあります さもないと 前述の例では RAM は最低 1 つの RTT で各 TCP 接続の 1 つの脱落パケットを待つためだけに 1 Gbps 100 ms MB 以上の余分なデータを収容しなければなりません しかし このスローダウンはファイル転送アプリケーションには不要です なぜなら 順不同のデータは脱落パケットを待たずにディスクに書き込むことができ 脱落パケットはネットワーク内で使用可能な帯域幅 ( 高度な速度制御メカニズムにより検出 ) に正確に対応するスピードでいつでも再伝送できるからです 実際に TCP だけでは信頼性と輻輳の制御を分離できないため 信頼性の高いバイト ストリーム配信の提供という TCP の目的を IETF が再定義しない限り この人工的なボトルネックは解消されません 2 信頼性の高いストリーミング アプリケーションと非ストリーミング アプリケーションの両方について 1 つの伝送制御プロトコルに依存する従来のやり方は 実際にはどちらにとっても次善の策でしかないことが証明されています 4

5 UDP ベースの高速ソリューション TCP が提供する信頼性は ネットワーク スループットを低下し 平均遅延を増大させ 遅延ジッターを悪化させます 輻輳回避から信頼性を分離するための取り組みが 長年にわたって行われてきました TCP 自体の変更が複雑であるため 最近では研究機関と業界は速度制御と信頼性制御を別々に装備するアプリケーション レベルのプロトコルを追求しています こうしたアプローチでは トランスポート層に TCP の代わりに UDP を使用し アプリケーション層に信頼性を実装します こうしたアプローチのほとんどは UDP ブラスターであり UDP を使用してデータを確実に移動し 脱落データを再伝送するための手段を採用しています しかし 使用可能な帯域幅を深く考慮していないため スループット自体の崩壊は言うまでもなく ネットワーク崩壊のリスクを招きます 図 3 は 商用 UDP データ ブラスターである Rocketstream を 一般的な WAN 条件のもとで (RTT とパケット ロスを増加させて ) 300 Mbps リンク上で実行した場合のスループットを示しています オープン ソース実装の Tsunami や UDT (Signiant File Catalyst Sterling Commerce などの製品が使用 ) といった UDP ソリューションは パケット ロスが発生したら伝送速度を下げるという単純なアルゴリズムにより UDP ブラスターの輻輳制御の強化を試みてきました バック オフはケースバイケースで ( つまり 帯域幅 往復遅延時間 パケット ロス フロー数の特定の組み合わせで ) 特定ネットワーク パスで合理的なパフォーマンスを達成できるように 調整 できます しかし この設計は本来の性質により 任意の現実世界のインターネット ネットワークの広範な RTT とパケット ロス条件とフローの並行性に適応することは不可能です その結果 これらのアプローチは使用可能な帯域幅を十分に活用できないか 一見したところ パイプを満たす ことはできても そのプロセスで重複したデータ伝送でネットワークをオーバードライブします 場合によっては 一般的なネットワーク状態で 重複したデータが最大 50% にも達します これは第一に帯域幅の無駄遣いであり 第二に有効なファイル転送スループット ( グッドプット ) の崩壊をもたらします 最後に これらのアプローチの過程では 他のトラフィックがネットワークを使用できなくなる可能性があります なぜなら これらのアプローチのオーバードライブによって他の TCP アプリケーションでパケット ロスが生じ その有効スループットを停滞させるからです 図 3: 棒グラフは RocketStream の 300 Mbps リンクでの様々なパケット ロスおよびネットワーク遅延 (WAN) 条件で達成されるスループットを示しています 高さがゼロのバーは 送信側と受信側の接続の確立に失敗したことを示します RTT またはパケット ロス率が高い場合 RocketStream はよくこの状況に陥ります 私たちはこれらの問題をデモするために 最も先進的な再伝送用 (NACK ベース ) UDP トランスポート ソリューションのひとつである UDT ( 商用ベンダーが再パッケージしたもの ) を選びました 具体的には 以下が含まれています 貧弱な輻輳回避 UDT で採用されている Dynamic AIMD アルゴリズム (D-AIMD) は AIMD と同じように動作しますが Additive Increase (AI) パラメーターは減少します 伝送速度が上がると AI は速度増加のペースを下げます このアプローチでは 前述した TCP の重要な問題 ( 信頼性と速度制御の連動 ) を認識していません その代わりに 1 つのパラメーターを調整することで AIMD や TCP の低パフォーマンスを解決できると想定しています 実際 特に調整された D-AIMD は特定のシナリオでは TCP のパフォーマンスを上回りますが 別のシナリオではたちまち TCP のパフォーマンスを下回ります そのため 多くの一般的な WAN では UDT のパフォーマンスは実際には TCP より劣ります 5

6 UDT の積極的なデータ送信メカニズムによって劇的な速度変動とパケット ロスが発生し スループット自体が下がるだけでなく 他のトラフィックも危険にさらし 全体的なネットワーク パフォーマンスを低下させます 標準 TCP フロー ( 例 : Web クライアントの HTTP セッション ) が UDT 転送と帯域幅を共有する一般的な WAN では TCP フローは UDT フローの積極性によりサービス拒否がもたらされる可能性があります ( 図 4) 実際に UDT に関するオリジナルの論文 2005 年の Optimizing UDP-based Protocol Implementations では 極度の TCP 非友好性の可能性について理論的に研究し この極度の非友好性を回避するために特定の条件を満たすことを提案しています 2 現実には 非常に一般的な WAN ( 例 : RTT が 100 ms plr が 0.1% の WAN) の場合 条件を満たすことはできないため TCP のこの極度の非友好性を避けることはできません したがって 通常の顧客が UDT ベースのデータ移動ソリューションを使用するには UDT がネットワーク エコシステム全体の運用 ( 例 : Web 電子メール VoIP ネットワーク管理) にダメージを与えないことを保証するためのある種の QoS の対応により多くの時間と費用を費やす必要があると考えられます 図 4: パケット ロス率が 0% RTT が 50 ms の一般的な T3 リンクにおける 1 つの UDT 転送のファイル転送スループットと 標準 TCP フローに対する UDT 転送の影響 UDT フローが終了するまで TCP フローはそのほとんどの期間 見えません UDT の積極的な送信と欠点のある再伝送により 貴重な帯域幅の効率が低下し しばしば顧客は不必要に帯域幅を追加購入する事態に追い込まれます ( 高価な帯域幅をより効果的に活用するためのソリューションが 実際には帯域幅を浪費しているのです ) 一部の実験では送信速度 受信速度 実効ファイル転送速度に大きな差異が見られます ( 図 6 および 7) これは 主として UDT の過度に積極的なデータ注入と欠点のある再伝送メカニズムにより ルーターと受信側で多くのデータがドロップすることを示しています 一般的な WAN の一部では 測定された効率 ( グッドプット ) が 20% 未満に落ち込んでいます これは UDT によって 100% フルに使用されているネットワークでは 80% の帯域幅キャパシティーで冗長 ( 重複 ) データを受信側に伝送しているか 有用なデータをオーバーフローしたバッファーに伝送していること (UDT 自体によるオーバードライブ ) を意味します 正確な比較を行うために UDT の使用が標準的なユーザーにもたらす メリット と コスト を定量化できます メリット は 必要なデータを転送するための帯域幅の効率的な使用 ( グッドプット ) によって測定できます これはスピーディーな転送時間に直接変換されます 一方 コスト は 1 つの必要なデータ パケットを転送するための作業として要約でき この作業は 1 つの必要なパケットを別のネットワーク エンドのアプリケーション層に正常に配信するための重複コピーの転送数 として定義できます このコストはまた 他の転送にもたらされるコストも意味します これは帯域幅の公平な共有が失われることによって反映されます ( 図 4) つまり 他の転送の低下したスループットになります 具体的には すでに図 5 で一部反映されているように UDT は広範な WAN の状態で有効な転送スループットが低く ( このため転送速度が遅くなり ) その結果ユーザーへのメリットはほとんどありません また オーバードライブと重複した再伝送に関連する帯域幅コストは 他のワークフローに大きな影響を与えます 図 5 は 様々な RTT とパケット ロス率において T3 (45 Mbps) リンク上で 1 つの UDT 転送によって 1 つのパケットを伝送する際の全コストを示しています ほとんどの一般的な WAN では 1 つのパケットを転送するために 8 ~ 10 回の再伝送が必要です 言い換えれば 1 GB のファイルを転送するために UDT 送信側は結局 9 ~ 11 GB もネットワークに送出するのです 転送には本来必要とされる時間の 9 ~ 11 倍もかかり 他のフローにも大きなパケット ロスを招きます 6

7 コスト ( 図 5 ) は UDT 送信側の過度に積極的な注入速度と UDT 受信側がドロップする重複した再伝送によって発生します より具体的には 送信コストは 送信側の過度に積極的な注入によるロス つまりルーターのパケット ドロップを反映して定義できます また 送信コストは 受信側でドロップする重複した再伝送を反映します より正確には 送信コストは以下のようになります 図 5: 棒グラフは 様々な RTT とパケット ロス率における 1 つの UDT 転送の再伝送を示しています 伝送コスト を表す各バーの高さは 1 GB のファイルを転送する場合に再伝送されるデータの量 (GB 単位 ) です 高さがゼロのバーは 送信側と受信側の接続の確立に失敗したことを示します RTT またはパケット ロス率が高い場合 UDT はよくこの状況に陥ります 元のファイル サイズの最大 9 倍の量が送信され 無駄に再伝送されていることに注意してください 受信コストは以下のとおりです 図 6: 棒グラフは T3 リンク上での様々な RTT とパケット ロス率における 1 つの UDT 転送の送信速度 受信速度 実効速度を示しています 送信速度と受信速度の大きな差異は 介在するネットワーク パス上で大量のパケット ロスが発生することを暗示しています また 受信速度と実効速度の大きな差異は 重複する再伝送が何回も行われることを暗示しています 7

8 図 7: パケット ロス率が 0% 1% 5% RTT が 100 ms 200 ms 200 ms の T3 リンク上の 1 つの UDT 転送の送信速度 受信速度 実効受信速度 送信速度と受信速度のギャップは ルーターで大量のデータが脱落したことを暗示します また 受信速度と実効受信速度のギャップは UDT 受信側で重複する再伝送の大量のドロップが発生したことを反映しています (a):plr が 0% RTT が 100 ms の T3 リンク上の UDT 転送 送信コストが高くなるほど ルーターでドロップするパケットが多くなります 一方 受信コストが高くなるほど 受信側でドロップするパケットが多くなります 図 7 は T3 リンク上の様々な RTT とパケット ロス率における 1 つの UDT 転送の送信速度 受信速度 実効速度を示しています 速度比 ( 送信速度対受信速度 受信速度対実効速度 ) は 前述の定義されたコストになります すべてのネットワーク構成で 送信速度は常に受信速度より速く 受信速度は常に実効速度より速くなっています これらのコストにより ネットワークは ネットワークの使用率 ( スループットを帯域幅で割り算した値 ) が 1 に近い運用ポイントに後押しされますが ネットワーク効率 ( グッドプットを帯域幅で割り算した値 ) はわずか 15% にしかなりません その結果 どのファイル転送も 本来あるべき速度の 6 分の 1 以下の速度になります 明確に示すために 様々な WAN でのシンプルなファイル転送の例について 以下のパフォーマンスに関連する質問に答えることで 前述のコストを検証します 送信するバイト数は? 実際に送信されるバイト数は? 実際に受信されるバイト数は? 転送の所要時間は? 実効ファイル転送速度は? この答えを表 1 にまとめ 同じ条件下での Aspera FASP と比較します (b) plr が 1% RTT が 100 ms の T3 リンク上の UDT 転送 (c):plr が 5% RTT が 200 ms の T3 リンク上の UDT 転送 8

9 帯域幅 (Mbps) RTT (ms) plr (%) 送信する量 (MB) 送信が必要な量 ( 実際のデータ + メディアによる不可避のロス MB) 実際の送信データ量 (MB) 送信コスト ( 送信側のオーバーヘッド %) 実際の受信データ量 (MB) 受信コスト ( 受信側のオーバーヘッド %) 所要時間 ( 秒 ) 実効ファイル転送速度 (Mbps) 測定されたネットワーク使用率 ネットワーク効率 ( 有効な使用率 %) % % % 28.4% % % % 28.8% % % % 21.4% % % % 13.7% % % % 33.5% % % % 14.0% % % % 11.5% % % % 9.8% % % % 6.4% % % % 3.0% 表 1: 一般的な WAN での UDT ファイル転送 高い帯域幅コストと遅い転送速度 帯域幅 (Mbps) RTT (ms) plr (%) 送信するデータ量 (MB) 送信が必要な量 ( 実際のデータ + メディアによる不可避のロス MB) 実際の送信データ量 (MB) 送信コスト ( 送信側のオーバーヘッド %) 実際の受信データ量 (MB) 受信コスト ( 受信側のオーバーヘッド %) 所要時間 (s) 実効ファイル転送速度 (Mbps) 測定されたネットワーク使用率 ( 受信側 ) ネットワーク効率 ( 有効な使用率 %) % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % 表 2: 一般的な WAN での Aspera FASP ファイル転送 ほぼゼロの帯域幅コストと高速な転送速度 9

10 UDT ファイル転送のパフォーマンスによる直接的な結果 ( 表 1 ) は 有用なデータが全くネットワークを通過しないか またはネットワーク効率を犠牲にしてネットワークを通過する というものです ( 表 1 の 8 番目の列に表示 ) これは低パフォーマンスの原因となるだけでなく 帯域幅を飽和させることで他のネットワーク トラフィックに対するサービス拒否も招きます 送信速度とネットワーク使用率を高めるために一部の UDT および TCP ソリューションで採用されている並列転送の作成は 帯域幅の浪費を悪化させるだけで 顧客は追加帯域幅への時期尚早な投資を行わざるを得なくなります これによるネットワーク使用率とスループットの向上はほとんど見られず 結果として生じるコスト ( 図 8) は劇的に上昇します 2 つの UDT セッションにより 再伝送がさらに 40% も増加します 同じ例 ( 表 1) では 1 GB 未満のファイルを完全に配信するために UDT は 13 GB ~ 15 GB ものデータをネットワークに送出しています 並列 TCP または UDT 転送を使用したソリューションのパフォーマンスは 同様か さらに低下します ( 図 8 を参照 ) 図 8: 並列 UDT ストリームの帯域幅コスト このグラフは RTT とパケット ロス率が異なる場合に T3 ネットワークで 1 つの 1 GB ファイルを転送する際の 2 つの並列 UDT セッションの再伝送コストを示しています 伝送コスト を表す各バーの高さは 1 GB のファイルを転送する場合に再伝送されるデータ量 (GB 単位 ) を示します 高さがゼロのバーは 送信側と受信側の接続の確立に失敗したことを示します RTT またはパケット ロス率が高い場合 UDT はよくこの状況に陥ります このプロセスでは ファイル サイズの 14 倍の 14 GB 近くが再伝送されていることに注意してください Aspera FASP ソリューション Aspera FASP は TCP で対応できないギャップを埋めて バイト ストリームの配信を必要としないアプリケーションに信頼性の高いトランスポートを提供し 信頼性と速度の制御を完全に分離します トランスポート層で標準 UDP を使用し チャネル上の実際の脱落パケットだけを再伝送する理論的に最適なアプローチを通して アプリケーション層における輻輳制御と信頼性制御を切り離します 速度制御と信頼性を分離するため TCP ベースのバイト ストリーミング アプリケーションのように脱落パケットの再伝送のために新規パケットがスローダウンする必要はありません 伝送中に脱落したデータは エンドツーエンド パス内で使用可能な帯域幅に対応する速度または構成された目標速度で再伝送されます 重複する再伝送はゼロ 受信コストもゼロになります パス内で使用可能な帯域幅は 遅延ベースの速度制御メカニズムによって発見され 送信コストはほぼゼロになります 具体的には FASP 適応速度制御では 小さな安定した量の キューイング をネットワークで維持するために ネットワーク ( またはディスクベースの ) 輻輳の主要なシグナルとして測定されたキューイング遅延を使用します 測定されたキューイングが目標を下回ると ( 使用されていない帯域幅があり 転送速度を上げるべきであることを示す ) 調整機能によって転送速度が上がります また キューイングが目標を上回ると ( 帯域幅がフルに使用されており 輻輳が顕著であることを示す ) 調整機能によって転送速度が下がります FASP では 定期的にプローブするパケットをネットワークに送信することで 転送パスのキューイング遅延に関するより正確でタイムリーな測定値を取得できます キューイング遅延の上昇を検出すると FASP セッションは目標キューイングと現在のキューイングの差異に比例して転送速度を減速するため ネットワークのオーバードライブが回避されます ネットワークの輻輳が落ち着くと FASP セッションは目標キューイングの比率に従ってすばやくスピードアップするため 使用可能なネットワーク キャパシティーの 100% 近くを再度フルに使用できます 10

11 TCP の速度制御とは異なり FASP 適応速度制御には大きなメリットがいくつかあります まず 輻輳を示す最初のシグナルとしてネットワーク キューイング遅延を使用し 2 番目のシグナルとしてパケット ロス率を使用するため メディアによりパケット ロスが発生するネットワークの人工的なスローダウンではなく ネットワークの輻輳の正確な推定が得られます 次に 組み込みのクイック レスポンス メカニズムにより 同時転送が多数ある場合 高速ファイル転送は安定した高スループットを実現するために自動的にスローダウンできます また 使用されていない帯域幅を効率的にフルに使用するために自動的にスピードアップできるため 配信時間の効率が高まります 3 番目に 高度なフィードバック制御メカニズムにより FASP のセッション速度は 安定し釣り合いのとれた速度によりすばやく収束できます この速度によって 輻輳のあるルーターのバッファーにキューイングされたビットの目標量が注入されます 安定した伝送速度とキューイング遅延により QoS ハードウェアやソフトウェアへの追加投資なしでエンド ユーザーに QoS 体験を提供できます データ配信時間は予測可能になり データの移動は同じネットワークを共有する他のアプリケーションに透過的です 4 番目に NACK ベースの UDP ブラスターとは異なり 帯域幅のフル活用によって事実上ネットワークのコストはゼロになり 常に 100% 近くのネットワーク効率を維持できます 図 10: 他の FASP および標準 TCP トラフィックとの FASP 共有リンク キャパシティー プロトコル内およびプロトコル間の公平性 ( フェアネス ) を実現しています 図 11: TCP がネットワーク状態によって制限される状況で FASP は使用可能な帯域幅を利用し FASP フロー間および他の (TCP) トラフィックとの間で完全な公平性を実現します 図 9: 棒グラフは 革新的な FASP 転送テクノロジーを使用するファイル転送テクノロジーについて 様々なパケット ロスとネットワーク遅延条件のもとで 1 Gbps リンク上で達成されるスループットを示しています ネットワーク遅延やパケット ロスによって帯域幅効率が下がることはありません 使用可能な帯域幅の効率的な利用に加え 遅延ベースの FASP 適応速度制御では アプリケーションは転送サービスで意図的な優先順位付けを構築できます ネットワーク キューイングに対する組み込みのレスポンスは 同時 FASP 転送に対する差別化された帯域幅優先度の提供など アプリケーション目標に対応できるように 個々の転送を優先順位付け / 優先順位解除するためのバーチャル ハンドル を提供します 11

12 ネットワーク トランスポートの人工的なボトルネックを取り除き 全リンク帯域幅をエンド ユーザーに解放する FASP 転送では 時として ディスク IO ファイル システム CPU スケジューリングなどで新たなボトルネック ポイントが出現します これにより 伝送速度がフル ライン スピードに引き上げられた場合 特にマルチ Gigabit ネットワークでは 必然的に新しいハードルが生まれます 比較的低速なストレージ パスに書き込む高速ファイル転送でのデータ脱落を回避するために FASP 適応速度制御はディスク フロー制御を含めるように拡張されています ディスク バッファーについては 同様の遅延ベースのモデル ( 特許出願中 ) が開発されています ネットワークとディスクのダイナミクスはタイム スケールが異なるため 2 タイム スケール設計を採用して帯域幅とディスク速度の両方の変化に適応しています 細粒度の高速タイム スケールでは ローカル フィードバック メカニズムが受信側エンドに導入されて オペレーティング システムのスケーリングなどに起因する定期的なディスク スローダウンに適応しています また 粗粒度の低速タイム スケールでは 帯域幅制御とディスク制御の両方に対して 統合型の遅延ベースの輻輳回避が実装され FASP 転送は使用可能なネットワーク帯域幅とディスク速度に同時に適応することが可能となっています IBM 社の一員である Aspera について IBM 社の一員である Aspera は ファイル サイズ 転送距離 ネットワークの状態に関係なく世界のデータを最高速度で移動する次世代トランスポート テクノロジーを創出しています Emmy 賞を授与された特許取得済みの FASP プロトコルをベースとする Aspera ソフトウェアは 既存のインフラストラクチャーをフルに活用して 最高速かつ予測し得る最高のファイル転送体験を実現します Aspera のコア テクノロジーは 帯域幅に対する比類ないコントロール 完全なセキュリティー そして妥協のない信頼性を提供します 六大陸の様々な業界の組織が Aspera ソフトウェアを使用してビジネス クリティカルなデジタル資産のトランスポートを行っています 詳細情報 IBM Aspera ソリューションに関する詳細については ibm.com/software/aspera をご覧ください また をフォローしてください ファイル システムのボトルネックは 様々な面で現れます 実際に スモール ファイルを多数転送する場合 その合計と同じサイズの 1 つのファイルを転送する場合よりスピードが格段に落ちることがよくあります FASP は今までにないファイル合理化テクニックを使用して ファイル システムに起因する人工的なボトルネックを解消し 多数のスモール ファイルを転送する際に同じ理想的な効率を実現します たとえば 米国からニュージーランドまで 155 Mbps の実効転送速度で OC-3 全体を使用して 1,000 個の 2 MB のファイルを伝送できます この結果 FASP は FTP や UDT といった TCP または UDP ベースのファイル転送テクノロジーの根本的なボトルネックを解消し パブリックおよびプライベート IP ネットワーク上の転送を劇的にスピードアップさせます FASP は 不完全な輻輳制御アルゴリズムに起因する人工的なボトルネック ( 物理メディア クロス トラフィックのバースト プロトコル自体の欠陥に起因する ) パケット ロス および信頼性と輻輳制御の連動を除去します さらに FASP のイノベーションは ディスク IO ファイル システム CPU スケジューリングなどから新たに発生するボトルネックも解消し 最も長距離な最高速 WAN 上でもフル回線速度を実現します このような FASP は TCP では対応できない増大するギャップを埋める次世代の高パフォーマンス トランスポート プロトコルとして 大きなファイルベースのデータを必需品としてのネットワーク上で長距離にわたって転送し 世界中のデジタル データの日々の大量移動を可能にします 12

13 Copyright IBM Corporation 2015 IBM Corporation Route 100 Somers, NY U.S.A 年 1 月 IBM IBM のロゴ ibm.com および Aspera は International Business Machines Corporation の米国およびその他の国における商標または登録商標です 本文書の初出時に 上記およびその他の IBM 商標に この情報の最初に現れる個所で適切な表示 ( または ) が付いている場合 この情報が公開された時点で IBM が所有する登録商標または慣習法上の商標であることを示しています このような商標は 他の国で登録された あるいはコモンロー商標である可能性があります 現時点での IBM の商標リストについては (ibm.com/legal/copytrade.shtml) でご覧いただけます Sterling Commerce Sterling Information Broker および Sterling Integrator は IBM 社の一員である IBM International Group B.V. の商標または登録商標です 他の製品名 会社名 またはサービス名は 他社の商標またはサービスマークである可能性があります この文書は 発行日現在 最新のもので IBM は随時変更を加える場合があります 本資料に記載の製品 サービス または機能が日本においては提供されていない場合があります 性能データとお客様の事例は 説明目的のみのために提示しています 実際の性能結果は 特定の設定や運用条件によって異なる場合があります 他社の製品またはプログラムと IBM の製品またはプログラムを併用した場合の操作の評価および検証は お客様の責任で行ってください 本資料に掲載されている情報は 現状のまま 提供するものであり 商品性の保証 特定目的への適合性に対する保証 および非侵害の保証または条件を含め いかなる明示的または黙示的な保証も行いません 日本 IBM 製品は日本 IBM 所定の契約書の条項に基づき保証されます 1 Jacobson, V. Braden, R. および Borman, D. TCP Extensions For High Performance Internet Engineering Task Force (IETF ) 1992 年 5 月 2 Ibid 1992 年 3 Gu, Yunhong および Grossman, R. Optimizing UDP-based Protocol Implementations 2005, リサイクルにご協力ください ZZW03306-JPJA-01