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

記事タイトルとURLをコピーする

こんにちは、SRE2課の松井(紀)です。

Amazon Elastic File System(以下EFS)でパフォーマンス向上についてのアナウンスがありましたので、実際に2022/02現在のEFSのパフォーマンスを測定してみたいと思います。

EFSはI/Oがボトルネックになり採用を見送っている方もいらっしゃるかと思います。本ブログを通してAWS上のストレージ選択する際の参考になれれば幸いです。

はじめに

2022/02/14 以下公式ブログにてアナウンスがありました。

パフォーマンスの向上に取り組み、 1秒あたりの読み取り操作を400%増加させ、クライアントごとのスループットを100%増加させ、さらに読み取りスループットを3倍にしました。
過去数週間にわたって、既存のすべてのEFS汎用モードファイルシステムで「スイッチを切り替え」、このパフォーマンスの向上を有効にしたため、すでに改善に気付いているかもしれません。もちろん、作成する新しいファイルシステムにもメリットがあります。 https://aws.amazon.com/jp/blogs/aws/amazon-elastic-file-system-update-sub-millisecond-read-latency/

前提

  • OS:Amazon Linux 2
  • インスタンスタイプ:t3.micro
  • リージョン:ap-northeast-1

測定方法

公式ドキュメントに、fioを使用したベンチマーク方法について紹介がありましたので参考にします。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/benchmark_procedures.html

EC2インスタンスの作成、及びEFSの作成手順については割愛します。

## fioのインストール
$sudo yum install fio
$fio --version
fio-2.14

## ディレクトリーの作成とEFSマウント
$sudo yum -y install amazon-efs-utils
$mkdir ~/efs fio
$sudo mount -t efs -o tls fs-xxxxxxxxxxx:/ efs

公式ドキュメントに記載のコマンドを実行して、各種オプションと実行結果の確認をしてきましょう。

sudo fio --directory=/home/ec2-user/fio --ioengine=psync --name fio_test_file --direct=1 --rw=randwrite/
 --bs=16k --size=1G --numjobs=16 --time_based --runtime=180 --group_reporting --norandommap

Jobs: 16 (f=16): [w(16)] [100.0% done] [0KB/38048KB/0KB /s] [0/2378/0 iops] [eta 00m:00s]
fio_test_file: (groupid=0, jobs=16): err= 0: pid=8877: Tue Feb 15 08:40:43 2022
  write: io=7270.4MB, bw=41358KB/s, iops=2584, runt=180010msec
    clat (usec): min=455, max=95342, avg=6187.43, stdev=2905.72
     lat (usec): min=455, max=95343, avg=6188.18, stdev=2905.74
    clat percentiles (usec):
     |  1.00th=[ 2288],  5.00th=[ 3376], 10.00th=[ 4640], 20.00th=[ 5152],
     | 30.00th=[ 5280], 40.00th=[ 5344], 50.00th=[ 5408], 60.00th=[ 5536],
     | 70.00th=[ 5792], 80.00th=[ 6368], 90.00th=[ 9280], 95.00th=[11968],
     | 99.00th=[18048], 99.50th=[19328], 99.90th=[29056], 99.95th=[36096],
     | 99.99th=[47360]
    lat (usec) : 500=0.01%, 750=0.07%, 1000=0.42%
    lat (msec) : 2=0.37%, 4=7.35%, 10=83.26%, 20=8.15%, 50=0.36%
    lat (msec) : 100=0.01%
  cpu          : usr=0.09%, sys=0.40%, ctx=470156, majf=0, minf=147
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=465304/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: io=7270.4MB, aggrb=41358KB/s, minb=41358KB/s, maxb=41358KB/s, mint=180010msec, maxt=180010msec

Disk stats (read/write):
  nvme0n1: ios=33/572504, merge=0/8208, ticks=106/3718507, in_queue=3718612, util=99.95%

オプション

  • directory:測定したいファイルパスにテスト用のファイルを作成する
  • ioengine:job I/Oをどのように行うかを決める(sync, psync, vsync, libaio)
  • name:ジョブ名
  • direct:non-buffered I/Oの設定。バッファを使わない場合は1を指定
  • rw: 読み書きの動作を指定(read, write, randread, randwrite, randrw)
  • bs:ブロックサイズ
  • size:Job全体のI/Oサイズ
  • numjobs:同じワークロードを実行するスレッドをいくつ生成するか
  • time_based :指定した場合、指定秒になるまで繰り返す
  • runtime:最大実行時間
  • group_reporting:結果をグループ化させる
  • norandommap:ランダムI / O実行時、一度読み書きされたブロックを再度検証しないようにする

計測項目

今回は以下2点を計測の項目としました。

 write: io=7270.4MB, bw=41358KB/s, iops=2584, runt=180010msec
  • bw→スループット
  • iops→IOPS

測定シナリオ

インスタンスにアタッチされたAmazon EBS(以下EBS)のgp2とEFS(デフォルトの設定)でランダムリード・ライト性能をそれぞれスループットとIOPSで比較します。
複数シナリオがある場合は、configファイルを作成すると1度に複数シナリオが実行出来るので作成しました。

$vi fio.config

[EBS-random-read]
rw=randread
bs=4k
size=2G
directory=/home/ec2-user/fio/

[EBS-random-write]
rw=randwrite
size=2G
bs=4k
directory=/home/ec2-user/fio/

[EFS-random-read]
rw=randread
size=2G
bs=4k
directory=/home/ec2-user/efs/

[EBS-random-write]
rw=randwrite
size=2G
bs=4k
directory=/home/ec2-user/efs/

fio実行時に引数に先程作成したconfigファイルを指定すると、config内で作成したシナリオ分だけテストを実行します。

$fio fio.config

ベンチマーク結果

random read

ボリューム EBS EFS
IOPS 1607 597
スループット(KB/S) 6430.9 2390.5

本シナリオでは、約3倍の性能差が確認出来ました。EFSのランダムリード、かなり遅いと想定していたので、意外な結果です。

random write

ボリューム EBS EFS
IOPS 3544 3493
スループット(KB/S) 14178 13976

書き込みに関しては本シナリオでは性能差は出ませんでした。

まとめ

2022/02現在のEFS性能をEBSと比較してみました。
東京リージョンでEFSが使用出来るようになったときは10倍以上性能差がありましたが、アップデートによってかなり性能が改善されていることがパフォーマンス測定で分かりました。

EFSは最近新たにレプリケーションに対応するなど頻繁にアップデートが行われているため、今後にも期待したいと思います。

参考:新機能 – Amazon Elastic File System (EFS) のレプリケーション https://aws.amazon.com/jp/blogs/news/new-replication-for-amazon-elastic-file-system-efs/

ではまた。

松井 紀樹(記事一覧)

CI部SRE2課

オンプレサーバーの修理屋からAWSのインフラ構築へジョブチェンジ

AWS資格6冠

筋トレとサウナが趣味。大胸筋が歩いてる