こんにちは、こんばんわ！クラウドインテグレーション事業部の魚介系エンジニア松尾です。

ここ数回に分けて EFS のデータを AWS アカウント間でコピーする方法について紹介させていただきました。
今回はその前段となる、冗長化などで移行ケースが多いであろう「Amazon EBS から Amazon EFS へデータを移行する方法」をご紹介したいと思います！

前回の記事については以下となります。

techblog.forgevision.com techblog.forgevision.com

はじめに

AWS ではストレージ間のデータの移行に関して様々な移行サービスを提供しておりますが、実は EBS から EFS へのデータ移行に関しては特にそういったサービスの提供はございません。(今後リリースされないとは言い切れませんが・・・)

そのため今回は、以下の AWS re:Post の Knowledge Center で公開されている手順を使った Amazon EBS から Amazon EFS へデータ移行をご紹介させていただきます。

repost.aws

はじめに

前提事項

前述の記事の中で、以下3つのツールが紹介されています。

GNU parallel
msrsync
fpsync

どのツールにおいてもデータ転送ジョブをパラレルで実施するため、さほど大きな違いは無さそうです。
本記事では fpsync を使ったデータ転送をご紹介したいと思います。(感覚的に手順が分かり易かったので・・・)

fpsync 以外のツールの詳細は以下公式ページよりご確認下さい。

GNU parallel
www.gnu.org
msrsync
github.com

なお EFS は既に作成済みであることを前提に手順を記載させていただきます。

fpsync とは？

fpsync は fpart と rsync を利用して複数の同期ジョブを並行して起動するシェルスクリプトです。
rsync はデータ転送・同期を行うためのツールとして有名かと思います。
fpart に関しては、ファイルツリーをソートして「パーティション」に詰め込むツールということで、説明だけを読むと単体で使うことはあまり無さそうに思えますが、fpsync はこの fpart と rsync と組み合わせることによって、fpart で生成したパーティションに対し複数の rsync を並列処理することができる機能を提供しているようです。

fpsync に関する詳細が知りたい方は以下の公式ページよりご確認下さい。

www.fpart.org

fpsync の実行

実際に fpsync を実行してみます。

初めに作成済み EFS にマウントを行います。
今回は EFS のマウントヘルパーを利用するため、パッケージをインストールの上マウントを実施します。

sudo yum install -y amazon-efs-utils
sudo mount -t efs -o tls fs-xxxxxxxxxxxxxxxx:/ /mnt

※「xxxxxxxxxxxxxxxx」は事前に作成を行った EFS のファイルシステム ID を指定します。

次に fpsync をインストールします。
EPEL リポジトリを有効にして fpart パッケージをインストールします。
※本手順は Amazon Linux 2 向けとなります。

sudo amazon-linux-extras install epel
sudo yum install fpart -y

実際に fpsync を使って EBS のデータを EFS に移行してみます。
計測の為にスレッド数を変えて2回実施します。

なお、環境としては以下を利用して移行を行います。

マシンスペック	ファイルサイズ	ファイル数量
t2.micro	1MB	5000

1回目

fpsync -n 1 /root/work/ /mnt/

2回目

fpsync -n 8 /root/work/ /mnt/

上記のコマンドの補足としては、「-n」が rsync を実行するスレッド数、「/root/work/」が移行元ディレクトリ、「/mnt/」が移行先ディレクトリとなります。

コマンドを実行した結果、計測結果としては以下の通りとなりました。

1回目	2回目
6分23秒	2分20秒

かなり低サイズの EC2 スペックでの実施であったため、単純に8倍の速度とはいきませんでしたが、スレッド数が多いと3倍近くスピードが変わりました。
実際の運用ではこれよりも多くのスレッドで実行できるマシンスペックかと思いますので、環境に応じて適切な値をご調整下さい。

なお、実行中のプロセスは以下のようになり、指定したスレッド数に応じて rsync プロセスが増減する形となります。

root     18964  3366  0 14:47 pts/0    00:00:00 /bin/sh /bin/fpsync -n 8 /root/work/ /mnt/
root     19137 18964  0 14:47 pts/0    00:00:00 /bin/sh /tmp/fpsync/work/1711550862-18964/1
root     19140 19137  4 14:47 pts/0    00:00:05 /bin/rsync -lptgoD -v --numeric-ids -d --files-from=/tmp/fpsync/parts/1711550862-18964/part.1 --from0 /root/work// /mnt//
root     19145 19140  0 14:47 pts/0    00:00:00 /bin/rsync -lptgoD -v --numeric-ids -d --files-from=/tmp/fpsync/parts/1711550862-18964/part.1 --from0 /root/work// /mnt//
root     19149 18964  0 14:47 pts/0    00:00:00 /bin/sh /tmp/fpsync/work/1711550862-18964/2
root     19152 19149  4 14:47 pts/0    00:00:05 /bin/rsync -lptgoD -v --numeric-ids -d --files-from=/tmp/fpsync/parts/1711550862-18964/part.2 --from0 /root/work// /mnt//
root     19156 19152  0 14:47 pts/0    00:00:00 /bin/rsync -lptgoD -v --numeric-ids -d --files-from=/tmp/fpsync/parts/1711550862-18964/part.2 --from0 /root/work// /mnt//
root     19200 19145  4 14:47 pts/0    00:00:06 /bin/rsync -lptgoD -v --numeric-ids -d --files-from=/tmp/fpsync/parts/1711550862-18964/part.1 --from0 /root/work// /mnt//
root     19213 19156  4 14:47 pts/0    00:00:06 /bin/rsync -lptgoD -v --numeric-ids -d --files-from=/tmp/fpsync/parts/1711550862-18964/part.2 --from0 /root/work// /mnt//

fpsync に関する補足情報

fpsync は私が確認した限りエラー発生時は標準出力されますが、プロセスが動いていること以外の進行状況の確認ができません。
fpsync -l で結果だけ確認できるものの、その点がやや不便だなと感じました。

また、コマンドはフォアグラウンドで実行されるため、セッションが切れるとそのまま停止してしまいます。
セッション切れが不安な場合は、nohup コマンドなどでバックグランドで実行を行う工夫が必要です。

なお、私が実際の運用でより大きなデータ(2.5TB程度)を移行した際、ハングアップでプロセスが停止することが何度かあったため、バックグラウンドの処理と併せてリトライ処理の実装もお勧めします。

考えられるユースケース

fpsync は並列処理に優れたツールであるため、大容量のデータの移行に適しています。
実行するサーバのスペックに応じて同期ジョブの許容数が増えるため、一時的なスケールアップが可能なクラウドサービスとの相性もいいです。

実際の利用ケースとしては以下3点となるかと思います。

EBS から EFS へのデータ移行
1つ目は EBS から EFS にデータ移行を行うパターンです。
EFS は複数のサーバから NFS(Network File System) プロトコルでの同時アクセスが可能なため、冗長化や負荷分散を行いたいという際には必ずといっていいほど話に上がります。
それまでシングルで動いていたサーバのデータをどうやって EFS に移行するかも課題となりますので、そういった際に fpsync が有効に活用できるかと思います。
fpsync はサーバスペックが高ければ高いほど同時実行ジョブを起動可能なため、移行の際はスペックを一時的に上げることをお勧めします。
また、EFS はネットワーク経由でのアクセスとなるため、EFS 側のスループットモードを Elastic または Provisioned にするとより効果的に移行速度を向上できるので、移行の際はそちらも併せてご検討下さい。
EBS から S3 へのデータ移行
2つ目は S3 にデータ移行を行うパターンです。
こちらは昨年リリースされた Mountpoint for Amazon S3 を利用する前提での移行となります。
EFS のように冗長化・負荷分散を目的としたケースではなく、データ分析目的で多数のバイナリファイルを保管する目的で移行するケースです。(前者のケースでの利用が絶対にないわけではございませんが・・・)
EFS へのデータ移行の場合、データ移行後は一般的にアプリケーションが直接 EFS にデータを書き込むため1度きりの fpsync の利用となるかと思いますが、本ケースの場合は初回の移行だけでなく、重い ETL 処理を EBS 上で実施後 fpsync で S3 に移行、軽い処理の場合は、ETL 前に fpsync で S3 に移行し、S3上で ETL 実行など、使いどころがいくつかありそうです。

Mountpoint for Amazon S3 に関する詳細は以下 AWS 公式の GitHub をご確認下さい。

github.com

EBS から EBS へのデータ移行
こちらは前述の2つの移行に関連性のある作業となります。
EFS へ移行したデータは基本的に EBS 上で不要となるかと思いますが、EBS はボリュームの縮小機能を提供しておりません。
また、スナップショットから起動させてもスナップショット取得時のボリュームサイズ以下に設定ができません。
そのため、新たにボリュームを作成しそこに対しデータを移行する必要があります。
EFS にデータを移行後も、数百 GB、数 TB のデータが残ることもざらにあるかと思いますので、そういった EBS to EBS のデータ移行の場合でも fpsync が有効に活用できると考えます。
※この場合は Block 通信であるため並列処理がより活きそうです。