AWS DataSync で東京リージョンにあるEFSのデータを大阪リージョンにあるS3へデータ転送してみる
EFSに保存しているデータを別リージョンへ退避する方法を考えていました。AWS Backupを利用したバックアップデータの転送以外にもAWS DataSyncでEFSのデータを別リージョンのEFSや、S3へデータ転送できます。 本記事では東京リージョン（ap-northeast-1）にあるEFSのデータを大阪リージョン（ap-northeast-3）にあるS3へデータ転送を例に紹介します。
以下リンクの大阪リージョン使ってみた版です。
確認結果まとめ
- 東京リージョンのEFSから大阪リージョンのS3へデータ転送（同期）は可能だった
- DataSyncタスクの最小実行間隔は1時間
- バーストモードのEFSはDataSyncのアクセスによりバーストクレジットを消費する
- S3へはマルチパートアップロードするためライフサイクルルールで「不完全なマルチパートアップロードをクリーンアップする」を設定しておきたい
- マネージメントコンソールかDataSync画面から確認できる実行結果は最大30日分
- サービスクォータによるもの
- 実行ログはCloudWatch Logsへ保存することができる
検証環境
東京リージョンにあるEFSをマウントしたEC2からファイルを書き込みます。EFSのデータをAWS DataSyncを使って、大阪リージョンのS3バケットへ同期モードでデータ転送します。
前提として東京リージョンにバーストモードのEFSと作業用のEC2インスタンス、大阪リージョンにバージョニングを有効化したS3バケットを作成した状態からはじめます。
-
Icons made by Freepik from www.flaticon.com
AWS DataSyncの設定
セキュリティグループ作成
DataSync用のセキュリティグループを作成します。ここが疑問だったのですがDataSync自体にアクセスするものはあるのでしょうか？現時点では必要性を感じられなかったためインバウンドルールは何も設定していません。
インバウンドルール
アウトバウンドルール
EFSのセキュリティグループにDataSyncセキュリティグループからのNFSアクセスを許可します。
ロケーション作成
「東京リージョンにあるEFS」と「大阪リージョンにあるS3」という定義みたいなものを作成します。あとのタスク設定で送信元、宛先の指定にこのロケーション設定を利用します。
後の送信元にあたるEFSロケーション作成します。特定のサブディレクトリのみデータ転送対象にするときはMount pathにディレクトリを指定します。Security groupsはDataSync用のセキュリティグループを指定します。今回だと対象のEFSへアクセスできるセキュリティグループであればOKです。
後の宛先にあたるS3ロケーション作成します。大阪リージョン選択しています。DataSyncがS3へアクセスに必要なIAMロールはAutogenerateから自動生成可能です、そうマネコンならね。
自動生成されたIAMロール・IAMポリシーは以下です。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket",
"s3:ListBucketMultipartUploads"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::dr-dev-efs-data-osaka"
},
{
"Action": [
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:GetObject",
"s3:ListMultipartUploadParts",
"s3:PutObjectTagging",
"s3:GetObjectTagging",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::dr-dev-efs-data-osaka/*"
}
]
}
タスク作成
タスクがデータ転送に関する設定です。
送信元の設定です。EFSのロケーションを選択します。
宛先の設定です。S3ロケーションを選択します。
転送設定です。EFSのデータと同期するS3にしたいのでKeep deleted filesのチェックを外しました。データ検証オプションは推奨値のVerify only the data transferredを選択しています。
毎時00分に実行します。データ転送の最小間隔は1時間でした。
NGパターン
スケジュール設定にCustomがあったので、
1分間隔にしてみたのですがタスク作成時にエラーで失敗しました。入力しようと思えば入力できるけどあくまでも最小間隔は1時間。Customの利用用途としては「月曜日から金曜日の0時に実行」というような使い方でした。
CloudWatch Logsにログ保存する設定を有効化します。CloudWatch LogsのロググループはAutogenerateから自動生成できます。
東京から大阪へと確認して完了です。
タスク完成しました。あとは毎時00分になるのを待ちます。その前にEFSは空なのでなにかファイルを置いておきます。
EFSをマウントしたEC2より
作業用のEC2インスタンスにEFSをマウントします。
sudo yum install amazon-efs-utils sudo mkdir /mnt/efs sudo chown ec2-user: /mnt/efs sudo mount -t efs fs-0eab4d26ec6e011a7 /mnt/efs
/mnt/efsにEFSがマウントされました。
$ df -h ファイルシス サイズ 使用 残り 使用% マウント位置 devtmpfs 468M 0 468M 0% /dev tmpfs 479M 0 479M 0% /dev/shm tmpfs 479M 456K 479M 1% /run tmpfs 479M 0 479M 0% /sys/fs/cgroup /dev/nvme0n1p1 8.0G 1.5G 6.6G 19% / tmpfs 96M 0 96M 0% /run/user/0 tmpfs 96M 0 96M 0% /run/user/1000 fs-0eab4d26ec6e011a7.efs.ap-northeast-1.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs
適当な容量のファイル作成しEFSに保存します。
dd if=/dev/zero of=/mnt/efs/5mb.dummy bs=1M count=5 dd if=/dev/zero of=/mnt/efs/10mb.dummy bs=1M count=10 dd if=/dev/zero of=/mnt/efs/200mb.dummy bs=1M count=200
3つテストファイルが保存されました。準備完了です。
ls -lh /mnt/efs 合計 215M -rw-rw-r-- 1 ec2-user ec2-user 10M 10月 31 07:13 10mb.dummy -rw-rw-r-- 1 ec2-user ec2-user 200M 10月 31 07:13 200mb.dummy -rw-rw-r-- 1 ec2-user ec2-user 5.0M 10月 31 07:13 5mb.dummy
転送先の大阪リージョンにあるS3の中身を確認しておきます。今のところ空です。
$ s3-tree dr-dev-efs-data-osaka no objects in dr-dev-efs-data-osaka
転送時間まで待ちます。
データ転送1回目
00分をまわったので大阪リージョンのS3を確認します。3つのテストファイルが保存されています。データ転送されています。
$ s3-tree dr-dev-efs-data-osaka dr-dev-efs-data-osaka ├── 10mb.dummy ├── 200mb.dummy └── 5mb.dummy 0 directories, 3 files
DataSyncの画面から実行履歴を確認できます。サービスクォータを確認すると保存日数は30日が上限でした。回数ではなく日数なのがありがたいところ。
ファイルが4個転送されたことになっています。
マネージメントコンソールからS3バケットを確認します。3つのテストファイル以外にはDataSync用のmetadataのファイルが生成されていました。
DataSyncは同期設定にしています。ファイル1個消して新しいファイル1個追加してみます。200mb.dummyを削除し、400mb.dumyを追加しました。
$ ls -lh 合計 415M -rw-rw-r-- 1 ec2-user ec2-user 10M 10月 31 07:13 10mb.dummy -rw-rw-r-- 1 ec2-user ec2-user 400M 10月 31 08:36 400mb.dummy -rw-rw-r-- 1 ec2-user ec2-user 5.0M 10月 31 07:13 5mb.dummy
また転送時間まで待ちます。
データ転送2回目
200mb.dummyファイルがなくなり、400mb.dummyファイルが追加されています。同期されていることが確認できました。
$ s3-tree dr-dev-efs-data-osaka dr-dev-efs-data-osaka ├── 10mb.dummy ├── 400mb.dummy └── 5mb.dummy 0 directories, 3 files
マネージメントコンソールから確認します。
以前のバージョン確認すると200mb.dummyは削除されていますが確認できます。また、metadataは上書きされるようで新しいファイルになっていました。
以上、DataSyncを利用した大阪リージョンへのデータ転送確認でした。
気になったこと
実際にデータ転送してる中ででてきた疑問を確認したのでまとめます。
Q1: 今回のDataSync用のセキュリティグループのインバウンドは何を設定するのが正しかったのか？
A1: 答えは見つけられず。DataSync自体にアクセスはないであろうという仮設のもと、インバウンドは何も設定せずに本環境ではデータ転送に成功しました。
Q2: データ転送（バックアップ）の整合性は？
A2: データ転送中常に整合性チェックを行い、追加オプションもある。追加オプションはVerify all data in the destinationを指しています。今回は推奨値のVerify only the data transferredを指定していました。
When DataSync transfers data, it always performs data integrity checks during the transfer. You can enable additional verification to compare the source and destination at the end of a transfer.
引用: How AWS DataSync works - AWS DataSync
Q3: データ転送時にEFSのバーストクレジットを消費するのか？
A3: Yes.
DataSync consumes file system burst credits.
引用: Creating a location for Amazon EFS - AWS DataSync
Q4: 自動生成されたIAMポリシーから察するにS3へのデータ転送方法はマルチパートアップロード？
A4: Yes.
DataSync uses the Amazon S3 multipart upload feature to upload objects to Amazon S3. This approach can result in unexpected storage charges for uploads that don't successfully complete.
引用: Troubleshooting AWS DataSync issues - AWS DataSync
ということは、宛先のS3バケットにはライフサイクルルール設定で「不完全なマルチパートアップロードをクリーンアップする」を設定しておいた方が良いですね。
まとめ再掲
EFSを対象にした場合、バーストクレジット消費はアプリケーションに影響がでるかもしれません。ワークロードによるので要検証した方がいいところです。
- 東京リージョンのEFSから大阪リージョンのS3へデータ転送（同期）は可能だった
- DataSyncタスクの最小実行間隔は1時間
- バーストモードのEFSはDataSyncのアクセスによりバーストクレジットを消費する
- S3へはマルチパートアップロードするためライフサイクルルールで「不完全なマルチパートアップロードをクリーンアップする」を設定しておきたい
- マネージメントコンソールかDataSync画面から確認できる実行結果は最大30日分
- サービスクォータによるもの
- 実行結果のログはCloudWatch Logsへ保存することができる
トラブルシューティング用にログ出力レベルの違いを確認しましたので合わせて確認していただけますと幸いです。
おわりに
簡単ではありますが大阪リージョンでの動作確認のためEFSからS3へデータ転送してみました。 当初CloudFormationで書きながら進めていたのですが、AWS DataSyncで必要なセキュリティグループ、IAMロールの設定が初見では何が必要かわからず断念しました。マネージドコンソールからAWS DataSyncの設定を作成しましたのでキャプチャをメインに載せました。 使ったみた感想としては2020年11月のアップデートにより一部リソース間のデータ転送はエージェントが不要になり手軽にはじめられるのが好印象。オンプレミスからのデータ転送にはエージェントが必要なので、なんでもエージェントレスではないことは頭に入れておきたいと思います。
