Amazon EFS の最適なスループットモードは？

こんにちは、AWS チームの尾谷です。

先日、検証を通じて Amazon EFS の最適なスループットモードを考察しましたのでアウトプットしたいと思います。

この記事のまとめ

Amazon EFS は 3 つのスループットモードが存在する
バーストスループットは低コストだが、クレジットを消費する
プロビジョンドスループットはクレジットは不要だが高い
Elastic Throughput は青天井
クレジットの消費を体験してみた
クレジットの回復も体験してみた
プロビジョンドモードに変更したら、他のモードには 24 時間待つ必要がある
どのモードも一長一短なので、利用状況を鑑みて設定する必要がある

Amazon EFS の 3 つのスループットモードについて

Amazon EFS はフルマネージドでサーバーレスな弾力性を備えたファイルストレージです。
NAT Gateway や、Internet Gateway と同様、ユーザーでパッチ適用やメンテナンスを行う必要がなく、利用することに注力ができる素晴らしいサービスです。
一方で EC2 インスタンスで NFS サーバーを構築するよりもコストが高く、しっかり理解して使わないと落とし穴もたくさんある印象です。

今日は、利用者が陥りやすいスループットモードについて解説したいと思います。
スループットモードは以下の 3 種類が用意されています。(2023 年 6 月現在)

バーストスループットモード
プロビジョンドスループットモード
Elastic Throughput モード

バーストスループットモード

最も安くご利用いただけるモードです。
ストレージの保存容量に比例して転送速度のベースラインが決まります。
ベースラインを超えた転送には、クレジットが消費されます。
クレジットが枯渇するとベースラインまでパフォーマンスが落ちてしまいます。

プロビジョンドスループットモード

毎月固定の金額を支払うことで、安定した転送を行うモードです。
以下料金ページにも記載されておりますが、1MB ごとに 7.20USD/月が必要ということで、100Mbps をプロビジョニングした際には、700USD が課金されます。

Elastic Throughput モード

使った分だけ精算するモードです。2022 年にローンチした新しいスループットモードで、読み取りと書き込みのそれぞれに課金がされるため、転送量が多いと、プロビジョンドスループットモードを超える高額請求が発生する可能性があります。

aws.amazon.com

クレジットの消費を体験してみた

Amazon EFS をデプロイする

クレジットが消費されていくイメージがつかない方もいらっしゃると思いますので、故意に減らしてみたいと思います。
まずは、Amazon EFS を構築します。

前回ブログを書いた 2020 年 12 月以来、長らく Amazon EFS に触れる機会がなく、久しぶりに EFS を作成しました。
昔なかった簡易デプロイ機能が追加されていて驚きました。最短で VPC だけ選択すれば作成できました。

techblog.forgevision.com

[ファイルシステムの作成] ボタンをクリックし、
任意の名前をつけて、[VPC] を指定して [作成] ボタンをクリックしました。
簡易デプロイ機能で出来上がった EFS は、Elastic Throughput モードでデプロイされました。

クレジットを減少させてみる

ファイル保存領域が少なければ少ないほど、スループットのベースラインは低くなり、クレジットの消費量が多くなります。
そのため、EC2 から EFS に継続的に書き込みを行い、書き込んだファイルをすぐに削除して、ベースラインが上がらないようにして転送を続けてみたいと思います。

Amazon EC2

検証には arm 版 Amazon Linux 2023 を採用しました。
最初、t4g.nano を選択しましたが、継続的に書き込みを行っていくと CPU クレジットが枯渇しました。そのため、途中で c7g.medium に変更しました。

EC2 インスタンスをデプロイし、[接続] ボタンからセッションマネージャーで接続します。
Amazon EFS のコンソールに表示されている [アタッチ] ボタンをクリックして、
表示されたコマンドを参考にマウントしました。

[root@ip-172-29-0-68 ~]# sudo mkdir /mnt/efs
[root@ip-172-29-0-68 ~]# sudo mount -t efs -o tls fs-01a38308da974449b:/ /mnt/efs
[root@ip-172-29-0-68 ~]#

ダミーファイルを書き込むスクリプト

以下の Shell スクリプトを書いて実行しました。

#!/bin/bash

while :
do
    # ファイル書き込み
    dd if=/dev/zero of=/mnt/efs/file1 bs=1024 count=100000
    dd if=/dev/zero of=/mnt/efs/file2 bs=1024 count=100000
    dd if=/dev/zero of=/mnt/efs/file3 bs=1024 count=100000
    dd if=/dev/zero of=/mnt/efs/file4 bs=1024 count=100000
    dd if=/dev/zero of=/mnt/efs/file5 bs=1024 count=100000
    sleep 3
    # ファイル削除
    rm /mnt/efs/file1
    rm /mnt/efs/file2
    rm /mnt/efs/file3
    rm /mnt/efs/file4
    rm /mnt/efs/file5
done

実行すると、すごい勢いでファイルが書き込みされていきました。

CloudWatch メトリクス

CloudWatch メトリクスを確認すると、Amazon EFS の BurstCreditBalance がみるみる減少していきました。

クレジットの回復も体験してみた

クレジットを故意に減少させることができました。
次は、減少したクレジットを回復させる方法を考えたいと思います。

バーストスループットモードでも転送が発生しなければ減少したクレジットは回復していきますが、本番環境で対向からのアクセスを止めることはできません。
そのため、プロビジョンドスループットモードに逃して、回復を待つのが良さそうです。プロビジョンドスループットモードはプロビジョニングする量を任意で決めることができます。
試しに、2MiB でプロビジョニングした場合と、100MiB でプロビジョニングした場合で回復スピードを比較しました。

2MiB/秒でプロビジョニングした場合

2 MiB/秒プロビジョニングの場合は、1 時間で 8GiB 回復しました。

日時	クレジット残
11:41	2.297 TiB
12:40	2.305 TiB

100MiB/秒でプロビジョニングした場合

100 MiB/秒プロビジョニングの場合は、15 分で 76G も回復しました。

日時	クレジット残
15:01	2.239 TiB
15:15	2.308 TiB

ということで、お金を積めば積むほどクレジットの回復量も増えるということが分かりました。

Elastic Throughput モードの場合

少し余談になりますが、Elastic Throughput モードの場合はクレジットは回復しません。
クレジットを減らした状態で、Elastic Throughput モードに切り替えましたが、クレジットのメトリックが出力されなくなりました。その後、バーストモードに戻すと、再びメトリックが記録されるようになりました。

その他注意事項

モードの変更回数は制限があります。
https://repost.aws/ja/knowledge-center/efs-max-throughput-mode-changes

以下は、プロビジョンドモードにしてから、さらにバーストモードに変更しようとした際に表示されたメッセージです。

検証のために毎回 24 時間は待てないので、上記検証は、EFS を何度も削除して、新しい EFS を作成して行ないました。

結局、どのモードが最適？

最適なモードはご利用状況を鑑みて判断する必要がある、という曖昧な回答になります。利用頻度が高くても、転送量が少ない場合はクレジットを消費しないためバーストモードが良いでしょうし、常に 30MB のファイルを転送し続けるようなバッチ処理があれば、プロビジョンドスループットモードで 30MiB/秒をプロビジョニングするのが良さそうです。あまり利用頻度が高くないが、月に数回バーストするといった場合には、Elastic Throughput モードが良いでしょう。

次回は、AWS Lambda と CloudWatch メトリクスを使って自動でモードを変更する方法を解説したいと思います。
最後までお読みくださりありがとうございました。