EFSのレプリケーション機能を使って東京リージョンから大阪リージョンへレプリケートする

#Amazon EFS

#AWS

いわさ

2022.01.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

Amazon EFSの機能でクロスリージョンレプリケーション出来るようになりました。

Announcing Amazon Elastic File System Replication

これまでは、別リージョンへのデータやバックアップの退避にはAWS BackupやAWS DataSyncを使っていたと思いますが、この機能を使うと数クリックで別リージョンへレプリカを作成することが出来るようになります。

先にまとめ

イメージとしてはリードレプリカを別リージョンへ作成するイメージになります。
書き込みが出来ないので、AWSのDR戦略に当てはめると、パイロットライトとして活用するイメージになると思います。

AWS リストアパイロット - Google 検索

ドキュメント上、RPOとしては15分以内にファイルの変更はレプリケートされるとされています。ただし、以下については15分以上かかるともされています。

ファイルが頻繁に変更される
ファイル数が1億を超える
100GBを超えるファイルがある

実際にためした感じだと、ミニマムなファイルをいくつか作成して、それが同期されるまで1分以内で完了する場合もあれば5分近くかかる場合もありました。
S3のクロスリージョンだと更新されたファイルはすぐに転送されるイメージがあったのですが、それとは同期のタイミングが異なっている所感です。
ドキュメントどおりRPOは基本15分以内、と考えておくのが良いかなと思いました。(レプリカラグはCloudWatchの新しいメトリクスで監視出来るようになっています)

また、リードレプリカの昇格にはレプリケーション構成の削除が必要です。
DR先リージョンでマウント済みであればダウンタイムは無くて再マウントも不要でしたが、構成の削除は10分ほどかかりました。RTOへどの程度影響が出るか、事前に評価しておいたほうが良いと思います。

既存のソースEFSをプライマリに昇格させるようなことは出来ないのでフェイルバックする際は少し面倒かもしれません。

DRリージョンから元のリージョンへ同じ機能でレプリケーション設定する(レプリケート先は新規EFSになる)
新たなマウントターゲットを作成し、既存環境へマウント
逆方向のレプリケーション構成を解除

ためしてみる

実際に東京リージョンで作成したEFSを大阪リージョンへレプリケートしてみます。

レプリケーション有効化

ソースとなるEFSの可用性オプションや自動バックアップ設定、ライフサイクル管理、パフォーマンス設定などはどういう設定でも問題ありません。
レプリカは各種オプションは全てデフォルトあるい未設定になるので必要に応じてDR先リージョンでの設定が必要です。
パフォーマンスモードのみソースEFSと同じ設定となります。

レプリケーションの有効化はソースEFSの「レプリケーション」タブから設定が可能です。

レプリケーション設定で必要な作業は、以下の2点のみです。

送信先リージョンの選択（送信先は１つのみ）
送信先EFSの作成オプションを設定

そうするとすぐに送信先リージョンに新規EFSが作成され、レプリケーションが有効となり、同期が開始されます。
送信先EFSに既存のEFSは選択出来ないのでご注意ください。

大阪リージョンに新規EFSが作成されていますね。レプリケーション設定も確認出来ます。
そして「このファイルシステムは読み取り専用です」の表示が。

マウントして使ってみる

レプリカはマウントターゲットが存在しない状態なので、これをマウントして東京リージョンからどのように同期されるのかなどを少し観察してみます。

東京リージョンでEC2にEFSをマウントし、新規ファイルを作成してみましょう。

sh-4.2$ df
Filesystem            1K-blocks    Used        Available Use% Mounted on
devtmpfs                 990180       0           990180   0% /dev
tmpfs                   1000948       0          1000948   0% /dev/shm
tmpfs                   1000948     456          1000492   1% /run
tmpfs                   1000948       0          1000948   0% /sys/fs/cgroup
/dev/nvme0n1p1          8376300 1556264          6820036  19% /
127.0.0.1:/    9007199254739968       0 9007199254739968   0% /home/hoge
tmpfs                    200192       0           200192   0% /run/user/0
sh-4.2$ cd /home/hoge/
sh-4.2$ sudo vi hoge.txt
sh-4.2$ cat hoge.txt
aaaaa

大阪リージョンでもEC2にEFS(レプリカ)をマウントしておきました。
ファイル作成直後は東京リージョンで作成されたファイルが存在していませんでしたが、1分程度するとファイルが同期されました。
ちなみに、ファイル削除についても同じように同期されました。

sh-4.2$ df
Filesystem            1K-blocks    Used        Available Use% Mounted on
devtmpfs                 982856       0           982856   0% /dev
tmpfs                    991808       0           991808   0% /dev/shm
tmpfs                    991808     400           991408   1% /run
tmpfs                    991808       0           991808   0% /sys/fs/cgroup
/dev/nvme0n1p1          8376300 1575872          6800428  19% /
127.0.0.1:/    9007199254739968       0 9007199254739968   0% /home/hoge
sh-4.2$ cd /home/hoge/
sh-4.2$ ls
sh-4.2$ ls

# ...
# 1分後くらい
# ...

sh-4.2$ ls
hoge.txt
sh-4.2$ cat hoge.txt
aaaaa

読み取り専用なので、やはり書き込みは出来ませんでした。

sh-4.2$ sudo touch hoge2.txt
touch: cannot touch ‘hoge2.txt’: Read-only file system

レプリカラグを確認する

CloudWatchのEFSメトリクスが新たに追加されており、ファイル同期の間隔を監視することが出来ます。

最後に同期されてからの経過時間を指しています。

フェイルオーバーしてみる

フェイルオーバーといってもマウントターゲットが勝手に切り替わるとかそういうものではなく、DRリージョンの読み取り専用EFSが書き込みできるようになります。
これを行うためには、レプリケーション構成を削除する必要があります。
ちなみに、レプリケーション構成の削除はDRリージョン側からのみ可能です。

構成が削除されるまでに10分ほどかかりました。

sh-4.2$ sudo touch touch-hoge.txt
sh-4.2$ ls
efs-replication-lost+found-fs-0de800985409aa64b-1643237373057  hoge.txt  touch-hoge.txt  touch1.txt  touch3.txt

書き込み出来るようになりました。

しかし、先程まで存在していなかったディレクトリ（efs-replication-lost+found-fs-0de800985409aa64b-1643237373057）が存在していますね。
これはドキュメントの以下にて言及されています。

Amazon EFS replication - Amazon Elastic File System

Deleting a replication configuration and changing the destination file system to be write-able can take several minutes to complete. After the configuration is deleted, Amazon EFS might write some data to a lost+found directory in the root directory of the destination file system, using the following naming convention:

レプリケーション削除時に作成される場合がある、とのこと。
詳細深堀りできてないですが、AWS Backupからの復元時にも似たようなディレクトリが作成される場合があります。

Using AWS Backup to back up and restore Amazon EFS file systems - Amazon Elastic File System