ベンチマークツールFIOを使って、EFSとFSxNの性能検証をしてみた

# この記事について
皆さんAWS上のストレージはどれをお使いでしょうか？
ファイルシステム用途でしたら、有名なのはネイティブサービスのEFS(Elastic File System)かFSx for WindowsかFSx for NetApp ONTAP(以降FSxN)ですよね。中でもLinux用途でしたら、選択肢はEFS or FSxNになってくると思います。これらの二つに割と最近エンハンスが入ったのはご存じでしょうか？


【EFS】今年4月にループットが最大10GiB/s(読み込み)と3GiB/s(書き込み)に上昇

https://aws.amazon.com/jp/about-aws/whats-new/2023/04/amazon-efs-10-gibs-throughput/

【FSxN】去年の暮れに最大スループットは読み込みが4GB/sと書き込みが1.8GB/sに上昇

https://aws.amazon.com/jp/about-aws/whats-new/2022/11/amazon-fsx-netapp-ontap-doubles-maximum-throughput-capacity-ssd-iops-file-system/

なかなかのエンハンス(特にEFS)ですので、「ホントにそんなスピード出るのか？？？」とワクワクです。
今回は実際にこの二つのネイティブサービスがどれだけスピードが出るのか検証してみます。


# やってみた
今回の検証イメージです。

・バージニア北部リージョンでEFS, FSxNをデプロイ(最大パフォーマンスがGAされているのはバージニア北部含めた数個のAZのみのため)
・同リージョンにAmazon Linux 2クライアントm5.largeをデプロイ、各ストレージをマウント
・ベンチマークツールを使い、random read, sequential read, random write, sequential writeのパフォーマンス(スループット、IOPS、レイテンシー)を計測

# EFSとFSxNのデプロイ
EFSは以下の性能のものをデプロイします。
・書き込みスループット 3,414MiB/s
・読み込みスループット 10,242MiB/s
・[AWSのユーザーガイド上]：(https://docs.aws.amazon.com/ja_jp/efs/latest/ug/performance.html)読み込み最大 35,000IOPS、書き込み最大7,000IOPS
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/504005/7dd27bff-a3f2-5806-ae3f-e778d93c4fb2.png)


FSxNは以下の性能のものをデプロイします。
・スループット 4,096MB/s
・160,000IOPS
(・SSDストレージ 5,120GiB)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/504005/88cac721-83df-4928-89b8-2fa78809c192.png)


# Amazon Linux 2クライアントm5.largeをデプロイし、ファイルシステムをマウント
Linux OSのEC2インスタンスを作成し、/home/ec2-user/配下にマウントポイント二つを作成します。
作成したら```df -h```コマンドで指定のIDのファイルシステムがディレクトリにマウントされているか確認します。

**EFS**
```
sudo mkdir -p /home/ec2-user/efs-mnt
sudo mount -t efs fs-xxxxxxx /home/ec2-user/efs-mnt/
df -h
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/504005/86af6a6a-e589-e810-5f1c-98012592afff.png)

同じく**FSxN**でもマウントします。
```svm-dns-name```はFSxのメニューから、ストレージ仮想マシン ＞ エンドポイント ＞ NFS DNS 名で確認できます。(例: svm-09d12bv4f.fs-03dk13dsnd3d.fsx.ap-northeast-1.amazonaws.com)

```
sudo mkdir -p /home/ec2-user/fsxn-mnt
sudo mount -t nfs svm-dns-name:/volume-junction-path /home/ec2-user/fsxn-mnt
df -h
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/504005/73bb1bb4-8f6d-8ec6-6e46-1f43bfd63e26.png)


# ベンチマークツールを使ってファイルIOのパフォーマンスを測る
今回使用したベンチマークツールはfioというのもで、Linuxインスタンスにインストールして使用します。
インストールは```sudo yum install fio```で終わりです。

https://fio.readthedocs.io/en/latest/fio_doc.html

計測した値はスループット、IOPS、レイテンシーの3つで、それぞれのファイルシステムに対してrandom write, sequential write, random read, sequential readのIOをブロックサイズ4k, 16k, 64kで実行しています。書き込み方法4種類 x ブロックサイズ3種類 x ファイルシステム2種類の計24回実行しました。
例えばこれはFSxNのマウントポイントに対して16kのブロックサイズでランダム書き込みIOを３分間行う場合のコマンドです。書き込まれたファイルの名前はfio_test_file_rwプラス数字の1GBのファイルがいくつか作成されます。並列実行スレッドは16個です。
```
sudo fio --directory=/home/ec2-user/fsxn-mnt --ioengine=psync --name fio_test_file_rw --direct=1 --rw=randwrite --bs=16k --size=1G --numjobs=16 --time_based --runtime=180 --group_reporting --norandommap
```

# 計測結果

![thruput.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/504005/400bc6d5-ce64-0567-61d9-1ab47a831484.png)

![iops.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/504005/76dbafbb-56d4-ce32-f51d-62e2e3d3c3b4.png)

![latency.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/504005/510d32e6-19a2-ff3f-b733-620698acc388.png)

。。。。



# 考察
今回の検証の結果としては、シンプルなセットアップとベンチマークツールではFSx for NetApp ONTAPに軍配が上がりました。性能検証としては非常に分かりやすい結果を出してくれたと思います。
本検証を行う前、EFSの書き込みが遅いことから、スループットを上げる小ネタなんかを調べておりました。

https://www.docswell.com/s/hmatsu47/KXGX35-2022-04-16-170442#p8

EFSは分散ファイルシステムという特性上、処理を分散すればパフォーマンスが上がるかと思い、記事8Pの状況(EC2 m5.largeの16並列処理までは行ける)を再現してみましたが、やはりそれだけでは性能が他のファイルシステムに追いつくという訳ではなさそうです。

#### どのように使い分けるのか？
とはいっても、EFSはやっぱりフルマネージドのファイルシステム。ファイル共有をset-and-forgetで使いたい方には勝手にスケールしてくれるし可用性も高いので、とても便利なサービスだと思います。それに、そいった使い方をする場合、何千とあるEC2をマウントして帯域を使い切る事なんてないでしょうし、手軽なオプションとしての立ち位置は以前と変わらず、といったところでしょうか。ただ、何かあった時や大規模に使うユーザーにとっては理論上は10GiB/sまでイケるぜ！というのは嬉しいですね。

逆に、ちゃんとファイルシステムを自分の思うように、効率的に使うためなら勉強も惜しまない！という方には断然FSxN(非フルマネージドにはCloud Volumes ONTAPというのもあります！)をお勧めします。ファイルシステム特有の効率化機能も沢山ありますし、日々の業務で多数のファイルを同時に書き込んでいく場合には効率的にキャッシュを使うファイルシステムの方が有利でしょう。


# まとめ
今回の検証では、単純な性能としてはFSxNが大いに上回りましたが、最適なサービスを選ぶのは数字だけの比較ではなくユースケースを意識することが重要です。初期に出来るだけset-and-forgetで楽にファイル共有をしていたものの、ビジネスの拡大によって大規模なファイルシステムを効率的に回したくなった、なんて場合はEFS→FSxNです。逆に、ストレージの知見が足らずFSxNを維持するのは金銭的にも工数的にもコスパが合わない場合EFSに変えた方が良い場合もあります。パフォーマンス結果の数字はあくまで最適なファイルシステムを選ぶ参考までに、ご活用いただけると幸いです。



# 参考記事
Amazon EFS を作成し EC2 からマウントしてみた

https://engineers.weddingpark.co.jp/amazon-efs/

Linux クライアントでのマウント(FSx for NetApp ONTAP)

https://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/attach-linux-client.html

Amazon Elastic File Systemのパフォーマンスを測定してみた

https://blog.serverworks.co.jp/efs-test

ベンチマークツールFio

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/benchmark_procedures.html

その他fio使用の参考記事

https://qiita.com/toshihirock/items/fa4d310115e6921ab0ac