本文へスキップ

長距離で大容量ファイルを高速転送する方法

長距離の大容量ファイル転送を、RTT、帯域、ストレージ、ファイル数から診断し、設定調整と転送ツールを実測で比較するガイドです。

WarpSend エンジニアリング 更新 6 分で読めます

海外の編集拠点やデータセンターへファイルを送るとき、契約回線の速度だけでは完了時間を見積もれません。近いサーバーへの転送は速くても、遠い宛先では往復遅延やファイルごとの処理が影響し、回線を十分に使えないことがあります。

まず実際の両端でネットワークとストレージを測り、大ファイル 1 個と普段のフォルダーを比べます。その結果に応じて転送設定、処理の並列化、専用ツールを選べば、改善の理由を説明できるようになります。

納品、収集、同期を含む導入前の試用には、ファイル転送ソフトの評価ガイドを活用してください。業務要件を確認可能な証拠に変え、仕事全体の所要時間と転送速度を分けて評価できます。

距離がファイル転送を遅くする理由

ネットワーク上の距離は往復遅延(RTT)として現れます。LAN では数ミリ秒で済むやり取りが、大陸間では 100 ミリ秒以上になることがあります。一度の待ち時間は短くても、ファイルごとに何千回も繰り返すと完了時間に影響します。

大容量ファイルでは、確認応答が戻るまで十分なデータを送信中に保つ必要があります。多数の小ファイルでは、それに加えて列挙、接続準備、宛先での作成などが重要になります。パケットロス、CPU、読み書き性能、再開や検証に使う時間も含めて考えます。

帯域遅延積の例

経路を継続して使うために必要な未確認データ量の目安は、次の式で求められます。

送信中のバイト数 = ビット/秒 × 往復時間(秒)÷ 8

10 Gbps、RTT 100 ms なら約 125 MB、150 ms なら約 187.5 MB です。アプリ、送受信側のウィンドウ、輻輳制御が十分なデータを送信中に保てなければ、ネットワークインターフェースが 10 Gbps でも同じ速度は出ません。

IETF の RFC 7323は、大きな帯域遅延積に対応する TCP Window Scale を定義しています。大きなバッファーを一律に設定するのではなく、実測しながら必要な容量を確保し、過剰なキューを作らないことが大切です。TCP でも適切な設定と経路条件では高速転送できます。

チームの実際の転送を比較する

現行版を同じファイル、経路、ストレージ、保護設定で比較してください。転送区間の速度と、受信者が検証済みファイルを使えるまでの時間を分けて記録します。WarpSend と FTP の測定方法では比較の手順を説明しています。FTP の結果は SFTP や Aspera の性能を示すものではありません。

WAN で一方向だけ遅い場合の診断

NAS からファイルを読み出す場合は NAS 側の上りとクライアント側の下りを使います。NAS へ書き込む場合は逆です。上り帯域、経路、速度制御、パケットロス、CPU 負荷が方向によって異なることがあります。

実際のエンドポイント間で、まず通常方向と逆方向を測定します。

# Destination test endpoint
iperf3 -s

# Normal: client sends to server
iperf3 -c <server-address> -t 30

# Reverse: server sends to client
iperf3 -c <server-address> -R -t 30

# Aggregate test with four flows
iperf3 -c <server-address> -P 4 -t 30

iperf3 の公式文書では、-R は逆方向、-P は並列ストリームを指定します。複数ストリームで速くなっても、単一ストリームの転送アプリが同じ速度になるとは限りません。

測定結果次に調べる点
一方向だけ iperf3 が遅い回線の速度制御、経路、ロス、CPU、ファイアウォール
iperf3 は速く、大ファイルは遅いストレージ、暗号化、アプリのバッファー、宛先の書き込み
大ファイルは速く、フォルダーは遅いファイルごとの準備、メタデータ、列挙、ウイルス対策、索引作成
並列は速く、単一ストリームは遅い輻輳制御、受信ウィンドウ、CPU、アプリの設計
NAS 内の読み出しも遅いストレージプールとバックグラウンド処理

最初の比較では MTU、暗号化、機器を揃え、一つずつ条件を変えます。速度の中央値に加えて再送、CPU、ディスク使用率を記録してください。小ファイル転送の解説も原因の切り分けに使えます。

高速転送ツールで確認したい仕組み

長い RTT に対応するには、大きなウィンドウ、複数ストリーム、UDP や QUIC を使う転送制御などにより、十分な量のデータを送信中に保つ必要があります。フォルダーでは、ファイルごとに接続や交渉をやり直さず、同じセッションを再利用することも有効です。

中断後の再開と検証も評価に含めます。ピーク速度が高くても、切断のたびに大部分を送り直すなら、実際の完了時間は延びます。転送済みの進捗を保持できるか、宛先で内容を照合するかを試してください。

測定値は データ送信中のスループットと、開始処理・交渉・送信・検証・完了通知を含む 総所要時間に分けます。WarpSend でも両方を記録し、開始や最終検証の時間を含めて改善を評価しています。

WarpSend の転送経路

WarpSend のエンドポイント間転送には、直接接続できる場合の Tunnel と、WarpFabric で暗号化データを一時保管する Shuttle があります。転送での Shuttle フォールバックには、有料 UDP 速度プランが必要です。経路と保護方式はセキュリティの説明をご確認ください。

WarpDirect は直接転送、WarpSync は反復するフォルダー同期、WarpShare はブラウザーリンクでの配布に使います。WarpShare はアップロード量と保持期間の延長を基準にした別の料金体系で、UDP 速度プランは不要です。ダウンロードに追加料金やプラン別速度制限はありません。現在の条件は料金ページにまとめています。

IBM Aspera と比較する場合

IBM Aspera は独自の FASP を使い、長距離やパケットロスのある経路で利用可能な帯域を活用する設計です。既存のメディア連携、自動化、オンプレミス運用、契約上の FASP 要件がある場合は、その価値も含めて比較します。IBM Aspera 製品概要

判断項目IBM AsperaWarpSend
既存メディア基盤との連携製品群と FASP の互換性を確認FASP 互換製品ではない
エンドポイント導入デスクトップアプリ、サーバー、ゲートウェイなど構成による直接転送・同期の両側にエージェント
ブラウザー配布選択製品と HTTP ゲートウェイなどの構成によるWarpShare
管理範囲自己管理型を含む製品群から選択対応端末と NAS をマネージドサービスで管理
評価方法対象エディションと既存連携を含めて検証実際の端末・経路・データで試験転送

Aspera のクライアントとファイアウォール要件は、使用する世代と構成で確認してください。接続方法の文書とファイアウォール要件が出発点になります。代替製品の比較ガイドとWarpSend との比較も参考にできます。

自分の経路で比較する

単一の大ファイル、中規模のファイル一式、多数の小ファイルの 3 種類を使うと、データ本体の転送とファイルごとの処理を分けて評価できます。両方向で複数回測り、中断からの再開、暗号化を有効にした性能、受信者の操作、ハッシュ検証まで確認してください。

既存の FTP/SFTP が納期と安全性を満たすなら、その構成を維持する選択もあります。改善が必要な場合は、WarpSend を試すときも同じ条件を使い、総所要時間と運用の手間を比較します。時間計画は転送時間計算ツール、保護要件は安全な大容量ファイル転送、FTP の接続処理はFTP の解説で確認できます。

よくある質問

10Gbps回線でも遠隔拠点間ではなぜ遅くなるのですか?

回線速度は上限の1つにすぎません。RTT、送信中に保てる未確認データ量、パケットロス、輻輳制御、送信側上り、ストレージ、CPU、ファイル数が全体のスループットに影響します。プロトコル調整前に、実際の経路を両方向で測定してください。

ネットワークとNAS ストレージのどちらが遅いか確認する方法は?

実際のエンドポイント間でiperf3を通常方向と逆方向に実行し、ローカル送信元読み取り、ローカル宛先書き込み、単一大容量ファイル、代表的な小ファイルフォルダーを比較します。iperf3が速くファイルコピーが遅いなら、ストレージ、プロトコル、CPU、メタデータを調査してください。

iperf3を複数ストリームで測れば、単一ファイルも速いと証明できますか?

できません。並列ストリームは経路全体の性能を示し、単一フローやCPU制限を回避できる場合がありますが、単一ストリームアプリは遅いままのことがあります。1 ストリームと複数ストリームを両方記録し、実際の転送ツールを測定してください。

WarpSendは長距離で常にFTPやSFTPより速いですか?

すべての経路とファイル構成と処理負荷で常に勝つツールはありません。ロスの少ない経路での単一大ファイル転送では、十分に調整された転送方式は同じ回線上限に近い速度に入ります。多数のファイル、中断、運用上の配信要件では、接続の再利用、一括処理、再開、検証が重要です。実際のファイル構成と処理負荷で比較してください。