クラウド移行：ファイル転送戦略ガイド

クラウド移行のファイル転送戦略は3つの決断で決まります。転送経路（公衆インターネット・Direct Connect・物理アプライアンス）、カットオーバーモデル（一括・段階的・並行稼働）、そして信頼する整合性チェックの方法です。1Gbpsの回線で50TBの資産を移行する場合、純粋な転送時間だけで約5日かかります。圧縮すれば短縮でき、回線を共用していれば長くなります。ツール選定の前に順序を計画し、リトライと照合のために20%の余裕を予算に組み込んでください。

回線に触れる前にデータセットを把握する

AWS DataSync・Azure AzCopy・Google Storage Transfer Serviceを選ぶ前に、実際に何があるかをインベントリしてください。ファイル共有でdu -shを実行し、データベースカタログに行数を問い合わせ、オブジェクトストアのマニフェストをエクスポートします。私が監査したある中堅企業はNASに8TBあると思っていましたが、スナップショットと隠れた~$ Officeのロックファイルを含めると実際は34TBでした。

インベントリを3軸で分類してください。サイズ・変更率・規制上の重要度です。1MB未満のファイルはオブジェクトごとのオーバーヘッドのためバイト単価での転送が遅くなります。2億件の小さなファイルを持つバケットは10TBのビデオよりも時間がかかることがあります。毎日変わるホットデータと古いPDFや2017年の請求書などのコールドデータを別々に優先度付けしてください。コールドデータは数週間前に送れますが、ホットデータはカットオーバーまで同期を続けるロジックが必要です。

タイムラインに合わせた転送手段を選ぶ

10TB以下で回線が良ければ、TLS 1.3によるオンライン転送が通常最善です。10TBから500TBでは、帯域幅を予約するかAWS Direct Connect / Azure ExpressRouteをプロビジョニングして企業WANを飽和させないようにしてください。500TB超では物理的なシーディングがインターネットより有利です。AWS Snowball Edgeは80TB、Snowmobileはコンテナでエクサバイトを運び、Azure Data Box Heavyは1PBを収容します。

正直に計算してください。1Gbps（持続的に125 MB/s、オーバーヘッドを引くと現実的には80 MB/s）で、100TBは途切れのないスループットで約14日かかります。運用ウィンドウが48時間なら、回線は選択肢になりません。ディスクを送ってください。Egressも考慮してください。古いプロバイダーから100TBを移動するコストは0.09ドル/GBで9,000ドルになり、転送先のコストが発生する前に消えます。

整合性：確認してもチェックサムも実施する

すべての移行にはエンドツーエンドの整合性検証が必要です。トランスポート層のTLSだけでは不十分です。送信元でSHA-256またはxxHash64ハッシュを生成し、ペイロードと一緒に送信し、受信先で再ハッシュします。AWS DataSyncはこれをデフォルトで実行します。--checksumを使うrsync、--check-firstとcryptバックエンドをサポートするrcloneも同様です。

コンプライアンスが必要なワークロードでは、パス・バイト数・ハッシュのCSVであるマニフェストを全保持期間分保持してください。HIPAA対象機関は45 CFR 164.312(c)(1)の整合性管理に基づいてすべてのオブジェクトをログに記録すべきです。GDPRの第5条1項(f)は転送中にファイルが改ざんされなかったことの証明を求めています。DICOMスタディの1バイトのずれは放射線科医のビューアが開くことを拒否する原因になります。

デルタ同期によるダウンタイムの最小化

一括カットオーバーは睡眠の敵です。代わりに、数週間前に初期一括コピーを実行し、その後カットオーバーウィンドウまで毎晩増分デルタを実行してください。Rclone（--update --use-server-modtime）・AzCopy（--overwrite=ifSourceNewer）・Googleのgsutil rsync -dはmtimeまたはハッシュで変更されたファイルを検出してデルタのみを移動します。

データベースには専用の計画が必要です。2TBのPostgreSQLインスタンスにはpg_basebackupプラスWALシッピングを使います。MySQLの場合、転送先にレプリカをセットアップし、カットオーバー時にプロモートします。rsync経由のファイルシステムデルタは最終同期を数時間から数分に短縮でき、土曜夜のメンテナンスウィンドウに収まります。

帯域幅の制御と時間帯別転送

WANの帯域幅を全部占有する移行は悲惨な結果を招きます。朝になる前にヘルプデスクのチケットが積み上がります。積極的にスロットリングしてください。AzCopyは--cap-mbpsを受け付け、rcloneは昼夜のレート設定として--bwlimit 50M:100Mをサポートし、DataSyncは時間あたりの帯域幅上限でタスクをスケジュールします。合理的なポリシーは業務時間中は回線の30%、夜間は90%、週末は100%です。

ファイアウォールでトラフィックも分離してください。移行フローにDSCP値をタグ付けすることで、QoSポリシーがZoomの通話を枯渇させないようにします。MPLSでブランチオフィスに接続している場合、本社を経由してトランポリンするのではなく、SD-WANブレイクアウトを検討して移行トラフィックをローカルに出力してください。

転送中の機密データの扱い

個人情報・PHI・カード会員データを含む移行には、関連する基準を満たす暗号化が必要です。TLS 1.3は最低限の要件です。ステージング中の保存ファイルにはAES-256-GCMでラップしてからアップロードしてください。PCI DSS 4.0の要件4.2.1は公衆ネットワーク上のカード会員データに強力な暗号化を義務付けており、HIPAAの対処可能な暗号化基準はePHIに対して事実上必須です。

移行中の小さなバッチのアドホック転送（コンサルタントがSalesforceのテーブルをエクスポートしたり、DBAが認証情報ボールトを移動したりする場合）には、エンドツーエンドの暗号化ツールが鍵をトランスポートプロバイダーの手の届かない場所に保ちます。HexaTransferは移行中の単発ファイルをきれいに処理します。暗号化はサーバーに何も届く前にブラウザで行われます。

カットオーバーの前にカットオーバーをテストする

サブセットで移行のリハーサルを実施してください。ある1つの部門（例えばマーケティングの共有ドライブ300GB）を選んで、フルパイプラインを実行します。ソースのインベントリ・転送・チェックサム検証・パーミッションマッピング・アプリケーションのフェイルオーバーです。各ステップの時間を計測し、何が壊れたかを文書化してください。

よくある予想外の問題：S3バケットポリシーにきれいにマッピングできないNTFSのACL、rcloneがファイルとして扱うシンボリックリンク、アプリケーション設定に埋め込まれたSMB共有パス、WindowsとLinux転送先間の大文字小文字の感度の違いです。これらをステージングで修正してください。本番稼働の深夜2時にではなく。1週間かかるリハーサルは1か月かかるロールバックを節約します。

移行後の照合

照合が完了してから成功を宣言してください。ソースと転送先のオブジェクト数・合計バイト数・ランダムな1%のハッシュサンプルを比較します。アプリケーションのメトリクスを確認してください。文書管理システムが420万ファイルを報告していたのに転送先が419万件を示している場合、ソースをオフにする前に不足の1万件を特定してください。

カットオーバー後も少なくとも30日間はソースを読み取り専用のままにしてください。インベントリ済みの共有ではなく~/Desktop/old_stuff/にあったために移行されなかったファイルが必要だとユーザーが気づくことは必ず起きます。それを予算に組み込み、驚かないようにし、必要になる前にロールバック手順書を作成してください。

hexatransfer.com で今すぐ試せます — 無料、アカウント不要、最大10GB。