オンプレミスのNASから Amazon EFS へデータ移行するために AWS DataSync を試しました。そこで私が「事前に知っておくとトラブルを減らせるかも」と感じたことを書いておきます。

ロケーション・タスク定義

EFSロケーションはEFSマウントターゲットが存在するサブネットでないと作成できない

転送先のストレージがEFSである場合「EFSロケーション」の作成が必要です。その作成時にサブネットを指定する必要があるのですが、EFSマウントターゲットが存在するサブネットしか指定できません。

AWSマネジメントコンソールから作成する場合はそもそも選択肢に出てきませんが、APIなどからマウントターゲットがないサブネットを指定すると以下のように失敗します。

No valid mount targets for EFS filesystem arn:aws:elasticfilesystem:ap-northeast-1:... found in subnet subnet-... Please provide a subnet that contains a mount target."

EFSロケーション（とタスク）の作成にはプライベートIPアドレスが必要

EFSロケーションとDataSyncタスクを作成すると、指定したサブネットのプライベートIPアドレスが消費されます。

私が確認したところ、EFSロケーションを「1つ」作成するのにIPアドレスが「4つ」必要でした。前述のマウントターゲットにもIPアドレスが必要なので、EFSロケーションを配置するサブネットには十分なIPアドレスを確保する必要があります（というか私がロケーションを大量に作ってIPアドレス足りなくなりました）。

「よくある質問」に「DataSyncは...ENIを作成する」とあるので、これによるものですかね。

DataSync サービスは、DataSync サービスによって管理される Elastic Network Interfaces (ENI) の VPC 内からファイルシステムをマウントすることで行われます。DataSync は、ユーザーの代わりにこうした ENI の作成、使用、削除を完全に管理します。

1タスクで転送するファイルの数にはエージェントのメモリ量に応じた要件がある

オンプレミスのストレージからAWSへデータを転送する場合はエージェントを立てる必要がありますが、その要件として転送するファイルの数に応じた搭載メモリ量が書かれています。

RAM— 設定に応じて、以下のいずれか

2,000 万個以下のファイルを転送するタスクでは、VM に割り当てられた 32 GB の RAM。

2,000 万個を超えるファイルを転送するタスクでは、VM に割り当てられた 64 GB の RAM。

メモリ不足が起きないよう、上記を考慮してタスクを作成する必要がありそうです。

私の場合は以下の方法で1タスクあたりの転送ファイル数を絞りました。

転送元となるNFSロケーションをディレクトリ別に作成する
- 「マウントパス」設定でディレクトリを指定
  - https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/create-nfs-location.html#configuring-nfs
タスクの「フィルタリングのオプション」を設定する
- https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/create-task.html#configure-filter

今のところ最大3,300万ファイルの転送を問題なく実行できています（64GBメモリ搭載のエージェントで）。

遭遇したエラー

NASのNFSマウントが失敗する

mount.nfs: access denied by server while mounting ...

というメッセージが出てNASをマウントできないことがありましたが、NFSロケーションの「NFS Version」を「Automatic」からバージョン指定に変更したら解消されました。

EFSのマウントがたまに失敗する

タスクを開始してすぐに、

The DataSync destination location is not mounted correctly. Please contact AWS support if the error persists.

というメッセージで失敗することがありました。
再実行すれば問題なく実行されます。

転送結果の検証で不備が報告される

DataSyncは処理の中でデータの整合性をチェックしてくれます。

この検証でたまに不備が検出されるので、確認と復旧が必要です。

不備がみつかると以下のようにエラー表示されます。

CloudWatch Logsに以下のようなログが出力されるので、検証に失敗したファイルのパスを確認します。

[NOTICE] Verification failed <> /path/to/abc.txt

転送先であるEFSを確認すると「ファイルは存在するが中身が0バイト」といった状況がありました。
以下のように操作することで不備のあったファイルだけ再転送することができます。

マネジメントコンソールからエラーのあったDataSyncタスクを開き「Start with overriding options」を選択
「Data to scan」で「Specific files folders」を選択
「Include patterns」の「Pattern」に不備があったファイルのパスを指定
「Start」を実行

（EFSの）パフォーマンス

これはDataSyncではなくEFSの話ですが、書き込み先となるEFSの「スループットモード」が「バーストモード」の場合、データ転送でバーストクレジットを使い切ってしまわないか注意が必要です。

バーストモードの場合、スループットがベースラインを上回るとバーストクレジットを消費します
新しくEFSファイルシステムを作成すると2.1TiBのクレジットが付与されますが、これは「ストレージから発生したクレジットを使用せずに、6.12 時間 100 MB/秒の計測スループットでバーストすることができる」量です
DataSyncによって長時間高速の転送を続けると、このクレジットを使い切ってしまうかもしれません
- クレジットがないとベースラインスループットに制限され、転送にかかる時間が伸びます
「プロビジョニングモード」にすると追加料金に応じて一貫したスループットが提供されるようです（使ったことはない）

料金

DataSyncは「コピーされたデータ」の容量に応じて費用が発生します。
（もちろん転送先がEFSであればその費用も）

以上です。