十数TBのデータをAmazon S3の別バケットへ移す計画を立てていたとき、私はAWSサポートに「DataSyncの実行中に、転送元のオブジェクトを追加・上書き・削除したらどうなるか」と問い合わせました。
コピーの所要時間とは別に、切替の判断基準を決める必要があったからです。コピー中も業務が動くなら、転送先にはいつの時点のデータが揃うのでしょうか。DataSyncのタスクが成功したら、そのまま切り替えてよいのでしょうか。
私が移行計画で分けて考えるのは、初回コピーにかかる時間と、書き込みを止めてから切替が終わるまでの時間です。以下では、S3バケット間のコピーを例に、両方をどう見積もり、何を確認して切り替えるかを整理します。
1. 最大5 Gbpsで見積もれるのは、転送時間の理論下限
エージェントを使用しないDataSync転送では、1タスクあたり最大5 Gbpsです。たとえば20 TBを5 Gbpsで連続転送できたとしても、約8時間53分かかります。これは10進単位で容量を速度で割った試算です。実際のタスクには、対象オブジェクトの列挙や転送結果の検証も含まれます。移行計画では、本番に近いサイズ分布・件数で、起動から完了までの所要時間を測ります。
速度を改善したい場合は、同じデータセットでBasicとEnhancedを比較します。Basicは準備・転送・検証を順に進め、Enhancedは列挙・準備・転送・検証を並行して進めます。EnhancedではAPIの PrepareDuration、TransferDuration、VerifyDuration がいずれも0を返すため、比較には TotalDuration を使います。切替リハーサルでは、タスクの時間とは別に、書き込み停止から照合・切替までを通しで計測します。
もう一つの選択肢は、互いに重複しないプレフィックスに分け、複数のタスクを並列に実行する方法です。たとえば archive/2024/ と archive/2025/ を別タスクに割り当てます。並列化の効果は、最初のタスクを開始してから最後のタスクが完了するまでの時間で判断します。データ量が一方に偏ると、そのタスクの完了が全体を左右します。
参考：AWS DataSyncのクォータ ／ タスクモードの選択 ／ タスク実行結果のAPI仕様
2. タスクが成功した時点で、S3のデータは揃っているか
AWSサポートからは、準備時に転送対象を洗い出し、転送時にその情報と照らし合わせる仕組みだと説明を受けました。準備中や転送中に追加・上書き・削除されたオブジェクトは、その回の転送に変更が反映されないことがあるとのことです。この処理順序はBasicの説明と整合します。S3間では2024年10月からEnhancedも選べるため、挙動やログを調べるときは、まず対象タスクのモードと検証設定を確認します。
対策として、転送元の更新を止めてデータの状態を固定する時間を設けること、その確保が難しければS3レプリケーションなどの別の手段を検討することを勧められました。
たとえば、Enhancedで report.csv の転送と検証が済んだ後、タスク全体が終了する前に、転送元で同じキーが上書きされたとします。Enhancedの既定の検証対象は、そのタスクで転送したデータです。タスクの結果が SUCCESS でも、上書き後の内容が転送先に反映されたかは、結果ステータスだけでは判断できません。更新のタイミングによっては、検証不一致が起きることもあります。
| コピー中に起きる変更 | 切替前に確認すること |
|---|---|
| オブジェクトの追加 | 新しいキーが転送先に存在するか |
| 同じキーへの上書き | 転送先が切替時点の内容になっているか |
| オブジェクトの削除 | 転送先に残す方針か。削除を反映するなら、不要なキーが残っていないか |
Basicでは、対象範囲全体を転送後に検証する POINT_IN_TIME_CONSISTENT を選べます。これは転送後の照合設定で、書き込みを続ける転送元をある時点で固定する機能とは役割が異なります。切替の基準時点を定め、その時点の状態と転送先をどう照合するかを手順に落とします。
参考：Enhancedの提供開始 ／ DataSyncの検証オプション ／ 検証不一致のトラブルシューティング
3. 最終差分と照合を、切替手順に組み込む
以下は、初回コピーを稼働中に行い、最終差分の転送前に書き込みを止められる場合の設計例です。
初回コピーと最終差分を分ける
- 稼働中に初回コピーを行う。 結果とログを確認し、エラーや再転送が必要な対象を洗い出します。
- 転送元への更新を止める。 アプリ、バッチ、外部連携などの書き込み元を洗い出し、実行中の更新が終わった時点を切替の基準にします。照合が終わるまで、転送先への業務書き込みも止めておきます。
- 差分転送を実行する。 変更分の転送に加え、転送元にないキーを転送先にも残すかを事前に決めます。削除を反映する
REMOVEを使う場合は、転送先だけに存在するデータを消してよい範囲かを確認します。全件転送のTransferMode=ALLでは転送先をスキャンしないため、PreserveDeletedFiles=REMOVEは組み合わせられません。 - 結果を照合して切り替える。 タスク結果、エラーや想定外のスキップ、対象キーの不足や余分なキーを確認し、必要な範囲では内容も照合します。条件を満たしたら、参照先と書き込み先を切り替えます。
差分転送を再実行して転送0件になることは、補助確認に使えます。たとえば、転送元で削除されたキーを転送先に保持する設定では、転送0件でも古いキーが残り得ます。切替直前のキーとサイズの確認には、対象プレフィックスを ListObjectsV2 で両側ともページ末尾まで取得して照合します。S3 Inventoryは日次・週次の出力なので、事前調査や監査に使います。
参考：DataSyncのタスクオプション ／ ListObjectsV2 ／ S3インベントリ
同じサイズの上書きは、どう見分けるか
キーとサイズだけでは、同じサイズに上書きされたオブジェクトを見分けられません。大容量オブジェクトでは、ETagをそのまま内容照合に使うのにも注意が必要です。マルチパートアップロードで作られたETagはオブジェクト全体のMD5とは異なり、同じ内容でもパートの分け方が違うとETagが異なる場合があります。
オブジェクト本体を取得せずに照合するなら、両バケットで HeadObject を ChecksumMode=ENABLED で呼び出し、両方が FULL_OBJECT で、同じアルゴリズムのチェックサムが取得できる場合に値を比較します。たとえば、両方にオブジェクト全体の ChecksumCRC64NVME があれば、その値を照合します。片方しか値がない場合や、片方がパート単位の値を組み合わせる COMPOSITE の場合は、この方法で直接比較できません。
比較できる値がなければ、必要な対象だけ両側から読み出し、オブジェクト全体のSHA-256を同じ方法で計算して比べます。既存データに比較可能なチェックサムがどの程度あるかを事前に確認します。読み出し照合が必要な対象が多ければ、そのデータ量と照合時間をリハーサルで測り、費用も見積もります。
移行費用を見積もる際は、DataSyncの料金に加え、S3のリクエスト料金も含めます。切替前の照合で両バケットを列挙したり、チェックサムを取得したり、オブジェクト本体を読み出したりする場合は、その分の LIST・`HEAD`・`GET` も見積もりに入れます。タグなども業務で使う場合は、内容のチェックサムとは別の照合項目にします。
参考：S3オブジェクトのETagとチェックサム ／ HeadObject ／ マルチパートアップロードのチェックサム
書き込みを長く止められない場合は、S3レプリケーションを検討する
S3レプリケーションを使う場合は、まず転送元・転送先の両方でバージョニングを有効にします。既存バケットで有効にする場合は、上書きや削除後に残る旧バージョンの保管費用と、ライフサイクルによる保持・削除ルールを見直します。そのうえで、ライブレプリケーションのルールを先に設定し、新規書き込みを複製する経路を作ってから、S3 Batch Replicationで既存分を移します。
現行形式のレプリケーションルールでは、削除マーカーの複製は既定で無効です。複製が必要なら、ルールが対応していることを確認して明示的に有効にします。バージョンIDを指定した削除や、ライフサイクルが作成した削除マーカーは複製されないため、要件に含まれる場合は別途扱いを決めます。
レプリケーションは非同期です。切替前には、既存分のジョブ結果とライブレプリケーションの未完了・失敗を確認し、旧バケットへの書き込みをどこで締め切るかを決めます。書き込みを一切止められない場合は、旧バケットに遅れて到達する更新も含め、アプリ側の書き込み先の切替方法を設計する必要があります。
参考：レプリケーションの要件 ／ S3 Batch Replication ／ S3が複製する対象と削除時の挙動
まとめ
移行計画に所要時間を書くときは、初回コピーと書き込み停止を別の欄にします。停止時間の欄には、最終差分だけでなく、照合と切替までの実測時間を入れます。切替判定の欄には、対象範囲、削除の扱い、内容まで確認する範囲を書きます。今回の問い合わせで私が改めて意識したのは、切替当日に迷わないよう、どの時点のデータを揃え、何が一致すれば進めるかを移行計画の段階で決めておくことです。
コメント