DataSync 転送時間の見積もり方 — Preparing フェーズの実測から分かったこと

はじめに
DataSync の転送フロー
- 各フェーズの所要時間：実測での桁感
検証環境
実測値からの簡易モデル
- 本番規模での予測
- 近似モデルの適用範囲について
補足：初回転送 vs 更新転送の Preparing 時間
- 読み取れること
実運用への示唆
まとめ
参考

はじめに

BeeX の清水です。

いきなりですが、本記事のまとめです。

Preparing 時間を決めるのは「ファイルサイズ」ではなく「ファイル数」
更新転送でも毎回フルスキャンされる
1,500万ファイルでは Preparing だけで約30分かかる可能性がある

3行まとめ

AWS DataSync でデータを移行する際、タスク実行は Preparing → Transferring → Verifying の3つの主要フェーズで構成されます。

このうち Preparing フェーズは「転送元と転送先双方のファイルメタデータを再帰的にスキャンし、差分を特定して転送対象を決定する」処理です。
公式ドキュメントには以下のように記載されていますが、具体的な所要時間の目安や支配的要因は明示されていません。

Preparation can take just minutes, a few hours, or even longer depending on the number of files, objects, or directories in both locations

移行計画を立てるうえで「Preparing に何分かかるのか」が読めないと、移行ウインドウの設計が破綻します。
たとえば移行ウインドウが8時間しかない環境で Preparing に30分かかるなら、実転送に使える時間は7時間30分です。
この差を事前に見積もれるかどうかで、移行計画の精度が大きく変わります。

本記事では、ファイル数とファイルサイズを独立に変化させた4パターンの検証データをもとに、Preparing 時間の支配的要因を特定した結果を共有します。

DataSync の転送フロー

DataSync のタスク実行は、内部的には以下のステータスを順に遷移します。

フェーズ	処理内容	所要時間の桁感（実測参考値）
Launching	タスク実行の初期化処理	数秒〜数分（通常は気にならない）
Preparing	転送元・転送先双方のファイル・ディレクトリを再帰的にリスティングし、差分を特定	数秒〜数十分（ファイル数に比例。本記事の主題）
Transferring	差分として特定されたファイルを実際に転送	数秒〜数時間（ネットワーク帯域 × データ量に依存）
Verifying	転送済みファイルのチェックサムを比較し、整合性を検証（設定により省略可能）	数秒〜数十分（転送ファイル数に依存）

各フェーズの所要時間：実測での桁感

「DataSync の転送時間」と聞くと Transferring フェーズだけを想像しがちですが、実際にはタスク実行の総所要時間は 全フェーズの合計 です。
以下は別途実施した性能検証（10,000ファイル / NFS → S3）での実測値です。

フェーズ	実測値	支配的要因
Launching	数秒	固定（ほぼ無視できる）
Preparing	数秒〜数分（環境構成に大きく依存）	ファイル数（本記事で詳述）
Transferring	数分〜数時間	ネットワーク帯域 × 総データ量
Verifying	検証モードにより0秒〜数秒（1,461ファイル時の実測）	検証モード設定 × ファイル数

小規模（数千ファイル）であれば Preparing は数秒で終わるため気になりません。
しかしファイル数が100万を超えると Preparing だけで数分〜数十分を消費し、移行ウインドウを圧迫します。

公式ドキュメントでは、Preparing フェーズについて「転送元と転送先双方のコンテンツとメタデータをスキャンし、両者の差分を特定する」処理であると説明されています（How DataSync prepares your data transfer）。

言い換えると、Preparing は巨大ファイルの中身を読む処理ではなく、Linux の find コマンドのようにディレクトリツリーを走査してメタデータ（パス・サイズ・タイムスタンプ等）を集めるフェーズです。
したがって「ファイル数に比例し、ファイルサイズには依存しない」と推測できます。本記事ではこの仮説を実測で検証しました。

なお、本記事の検証は Basic mode で実施しています。
Basic mode では Preparing → Transferring → Verifying が逐次実行されるため、各フェーズの所要時間を独立に計測できます。
Enhanced mode では Preparing と Transferring が並列実行されるため、Preparing 単体の時間を切り出しにくい点にご注意ください。

検証環境

検証は AWS 上に構築した以下の環境で実施しました。
本番環境ではエージェントをオンプレミスの NFS サーバー近くに配置することが推奨されますが、今回は Preparing 時間の要因分析が目的のため、同一リージョン内の EC2 で構成しています。

項目	設定値
リージョン	同一リージョン内（EC2 → S3）
タスクモード	Basic mode
DataSync エージェント	EC2 上にデプロイ（検証用途）
検証モード	`NONE`（Verifying をスキップし、Preparing + Transferring のみ計測）
実行方法	各パターンを個別に実行（同時実行による干渉を排除）

検証パターンと実測結果

テストデータの設計

Preparing 時間に影響する要因を切り分けるため、「ファイル数」と「ファイルサイズ」を独立に変化させた4パターンを用意しました。

パターン	ファイル数	総容量	1ファイルあたり	目的
few-small	100	1MB	10KB	ベースライン（少数・小容量）
few-large	100	1GB	10MB	ファイル数を固定してサイズだけ増やす
many-small	10,000	100MB	10KB	サイズを固定してファイル数だけ増やす
many-large	6,642	6.3GB	約1MB	両方大規模（※）

※ many-large は当初 10,000 ファイル / 10GB を予定していましたが、検証用 EC2 のディスク容量制約により 6,642 ファイル / 6.3GB での実施となりました。
結果的にこの「計画と異なるファイル数」が仮説の裏付けに貢献しています（後述）。

実測結果

パターン	ファイル数	総容量	Preparing 時間
few-small	100	1MB	2.6秒
few-large	100	1GB	2.6秒
many-small	10,000	100MB	3.7秒
many-large	6,642	6.3GB	2.6秒

結果の分析

なお、今回の検証は最大でも1万ファイル規模であり、Preparing 時間の差は秒単位に留まっています。
ただし後述の別検証では、同じ10,000ファイル規模でも環境条件により Preparing が100秒超となるケースを確認しており、ファイル数増加に伴う影響は実環境ではより顕著になります。
また、本検証では Verifying を NONE に設定しているため、計測値には Verifying の時間は含まれていません。

ファイルサイズの影響は確認できず

few-small（総容量 1MB）と few-large（総容量 1GB）を比較します。
容量が 1,000倍 に増えても、Preparing 時間はどちらも 2.6秒で一致しました。
前述の通り、Preparing は find コマンド的なメタデータ走査であり、ファイルの中身は読まないため、サイズが変わっても処理コストは変わりません。

ファイル数が支配的

few-small（100ファイル）と many-small（10,000ファイル）を比較します。
ファイルサイズは同じ 10KB ですが、ファイル数が100倍になると Preparing 時間は 2.6秒 → 3.7秒に増加しました。

増加幅は約1.1秒。「たった1.1秒の差で支配的と言えるのか？」と思われるかもしれません。
これは今回の検証が最大10,000ファイル規模に留まっているためです。

実際、同プロジェクトで別途実施した性能検証（手動構築環境・10,000ファイル規模・NFS → S3）では、Preparing 時間が 122〜143秒 を記録しています。
本記事の検証環境（CDK構築・同一VPC内）とはネットワーク経路やNFSサーバーのスペックが異なるため絶対値の直接比較はできませんが、「ファイル数が増えると Preparing 時間が顕著に伸びる」傾向は一貫しています。
さらに、本番環境（約1,500万ファイル）では Preparing が 数十分規模になる と予測されます。

小規模検証では秒単位の差に見えますが、ファイル数がスケールすると分〜十分単位の差に拡大する構造です。

many-large の結果が仮説を補強

many-large は当初の計画（10,000ファイル）に対してディスク容量不足で 6,642 ファイルに留まりました。
この「想定外」が逆に有用なデータポイントになっています。

many-large: 6,642ファイル / 6.3GB → 2.6秒
many-small: 10,000ファイル / 100MB → 3.7秒

容量は many-large のほうが 63倍 大きいにもかかわらず、ファイル数が少ない many-large のほうが Preparing 時間は短くなっています。
「Preparing 時間を決めるのはファイル数であり、容量ではない」という結論を裏付ける結果です。

測定の揺らぎについて

なお、Preparing 時間は AWS 側の初期化処理やネットワーク状態の影響を受けるため、秒単位の揺らぎがあります。
今回の検証では同一条件での複数回実行は行っていないため、個々の値には ±数百ミリ秒程度の誤差が含まれる可能性があります。
ただし、「ファイルサイズを1,000倍にしても変わらない」「ファイル数を増やすと増える」という傾向は、揺らぎの範囲を超えた明確な差として現れています。

実測値からの簡易モデル

4つの実測データポイントから、近似的に以下のモデルを導出しました。

 Preparing時間(秒) ≈ 2.5 + 0.00012 × ファイル数

項目	値	意味
基本オーバーヘッド	約2.5秒	ファイル数がゼロでも発生する固定コスト（タスク初期化・ロケーション接続等）
ファイル1個あたりの増分	約0.12ミリ秒	メタデータ1件のスキャンにかかる時間

このモデルは実質的に2点（100ファイル・10,000ファイル）を結んだ直線の傾きから導出した近似です。
大規模ファイル数への外挿は桁感を掴む目的であり、精度を保証するものではありません。
実環境では NFS サーバーの I/O 性能やネットワーク条件により、この値から大きく乖離する可能性があります。

本番規模での予測

この近似モデルを使って、本番規模のファイル数に対する Preparing 時間を予測します。

ファイル数	予測 Preparing 時間	備考
1,000	約2.6秒	小規模環境。ほぼオーバーヘッドのみ
10,000	約3.7秒	中規模環境
100,000	約14.5秒	大規模環境。体感で「少し待つ」レベル
1,000,000（100万）	約2分	移行計画に組み込む必要あり
10,000,000（1,000万）	約20分	移行ウインドウへの影響が無視できない
15,000,000（1,500万）	約30分	今回の案件規模

今回の案件では約1,500万ファイルが移行対象でした。
移行ウインドウが8時間（480分）の場合、Preparing だけで約30分を消費する計算になります。
全体の約6%ですが、「転送速度だけで移行時間を見積もる」と30分のズレが生じるため、移行計画には必ず Preparing 時間を加算する必要があります。

近似モデルの適用範囲について

この近似モデルはあくまで今回の検証環境（同一リージョン内・EC2 エージェント・NFS → S3）での実測値に基づくものです。
以下の要因で実際の値は変動する可能性があります。

NFS サーバーのリソース負荷（CPU・メモリ・ディスク I/O）
ネットワークレイテンシ（オンプレミス → AWS 間の距離）
転送先側のオブジェクト数（S3 側のリスティングコスト）
エージェントのスペック（CPU・メモリ）

特に NFS サーバーのリソース負荷については、別途実施した性能検証で以下のデータを得ています。
NFS サーバーにメモリ80%の負荷をかけた状態と負荷なしの状態で、Preparing 時間を比較しました。

データパターン	負荷なし	メモリ80%負荷	差分
小サイズファイル多数（10,000ファイル）	143秒	127秒	-11%（むしろ速い）
大サイズファイル少数（10ファイル）	127秒	157秒	+24%
本番データ分布（1,095ファイル）	122秒	119秒	-2%（ほぼ同じ）

結果として、メモリ負荷の影響に 一貫した傾向は見られませんでした。
速くなるケースも遅くなるケースもあり、今回の検証環境ではメモリ負荷は Preparing 時間の支配的要因ではないと判断しています。
なお、「負荷ありで速くなった」ケースは測定誤差や Linux ページキャッシュの状態差によるものと考えられ、「メモリ負荷が性能を改善する」とは解釈していません。

ただし、これは「NFS サーバーのリソース状態が一切影響しない」という意味ではありません。
今回の検証環境は EC2（同一リージョン内・高速なネットワーク・EBS ストレージ）であり、本番のオンプレミス環境とは条件が異なります。
以下のようなケースでは Preparing 時間が延びる可能性があります。

NFS サーバーの CPU が常時高負荷で、メタデータ応答が遅延している場合
ディスク I/O が飽和しており、ディレクトリエントリの読み取りに時間がかかる場合
エージェントサーバー自体のメモリが不足し、スワップが発生している場合

本番環境での移行計画には、実環境に近い条件での事前検証を推奨します。
本モデルは「桁感を掴むための参考値」として活用してください。

補足：初回転送 vs 更新転送の Preparing 時間

同じデータセット（100ファイル / 1MB）を使い、S3 側の状態を変えて Preparing 時間を比較しました。
日次増分転送を運用する場合、「初回と2回目以降でどれくらい差があるか」は計画上重要なポイントです。

パターン	転送状態	変更ファイル数	Preparing 時間
A	新規転送（S3 が空）	100（全て）	1.6秒
B	更新転送	0（変更なし）	1.2秒
C	更新転送	1	1.2秒
D	更新転送	100（全て）	1.1秒

読み取れること

初回転送はやや遅い

新規転送（A: 1.6秒）と更新転送（B〜D: 1.1〜1.2秒）を比較すると、初回のほうが数割程度余分に時間がかかっています。
S3 側にオブジェクトが存在しない状態では、転送先のリスティング結果が「空」であることを確認するためのオーバーヘッドが発生していると推測されます。

なお、この比較はサンプル1回ずつの実測であり、秒単位の揺らぎを考慮すると正確な割合は断定できません。
「初回は更新転送より遅い傾向がある」という定性的な結論として捉えてください。

変更ファイル数は Preparing 時間に影響しない（重要）

変更なし（B: 1.2秒）、1ファイル変更（C: 1.2秒）、全ファイル変更（D: 1.1秒）で Preparing 時間はほぼ同じです。
これは DataSync が Preparing フェーズで 常に転送元・転送先双方の全ファイルをスキャン していることを意味します。

この挙動は実運用で非常に重要です。
たとえば日次増分転送で「昨日から変更されたファイルは10件だけ」という状況でも、DataSync は1,500万ファイル全件を走査します。差分検出のために全件スキャンが必要だからです。

「変更がないならスキャンも速いのでは？」「差分が少なければ Preparing も短いのでは？」と期待したくなりますが、実際には差分の有無に関係なく全件走査が行われます。
つまり、Preparing 時間を短縮するには「変更を減らす」のではなく「スキャン対象のファイル数自体を減らす」しかありません。

日次増分転送を設計する以下の前提で移行ウインドウを計算することを推奨します。

Transferring は差分転送だが、Preparing は毎回フルスキャン

日次バッチ運用では2回目以降が安定

初回実行さえ完了すれば、2回目以降は安定した Preparing 時間が期待できます。
日次増分転送の運用設計では、初回のみ余裕を持って見積もり、2回目以降は定常値で計画すれば問題ありません。

実運用への示唆

Preparing 時間を短縮する方法

Preparing 時間を短縮する唯一の方法は **スキャン対象のファイル数を減らす** ことです。
ファイルサイズをいくら大きくしても（あるいは小さくしても）効果はありません。

対策	効果	適用場面
tar/zip でアーカイブ化	ファイル数を劇的に削減できる	ログファイル・画像ファイルなど小ファイルが大量にある場合
タスクを日付単位で分割	1タスクあたりのスキャン対象を限定できる	日次増分転送で過去データのスキャンを避けたい場合
Include/Exclude フィルタ	不要ファイルをスキャン対象から除外できる	一時ファイル・キャッシュ・アーカイブが混在する場合
Enhanced mode の利用	Preparing と Transferring が並列実行される	S3 間転送など Enhanced mode が利用可能な構成の場合

たとえば1,500万ファイルを一括で転送すると Preparing に約30分かかりますが、日付やディレクトリ単位で5タスクに分割すれば、1タスクあたり300万ファイル → Preparing 約6分に短縮できます。

ただし、タスク分割にはトレードオフもあります。

タスク数が増えると管理・監視の複雑さが増す
エージェント1台では同時に1タスクしか実行できないため、分割しても直列実行なら合計 Preparing 時間は変わらない
並列実行するにはエージェントを複数台用意する必要がある

タスク分割の設計判断（分割粒度・Include/Exclude の組み合わせ・集約転送時の注意点）については、別記事で詳しく扱う予定です。

移行計画への組み込み方

移行計画を立てる際は、以下の手順で Preparing 時間を見積もることを推奨します。

1. 事前にファイル数を正確に把握する — find /path -type f | wc -l で総ファイル数を取得
2. 近似モデルで Preparing 時間を概算する — 2.5 + 0.00012 × ファイル数 で秒数を算出
3. 移行ウインドウから Preparing 時間を差し引く — 残りが実転送に使える時間
4. 初回転送は余裕を持って見積もる — 2回目以降は定常値で計画
5. 可能であれば実環境で事前検証する — 近似モデルはあくまで参考値