いよいよ性能評価に移ります。結論だけ欲しい人の為に最初に書いておくと、EBSの1/3程度の読み込み速度でした。
ただしベンチマークにつかうコマンドの設定などで1/10~1/4くらいの間で結果が変わります。とりあえずEBSよりも結構パフォーマンスが落ちることが確認できました。
まぁ、AWSの特性上としてEBSの上にマウントしているのでパフォーマンスが落ちることは当然だと思いますが・・・。
準備編：[AWS] EFSを使ってみよう！準備編！
設定編：[AWS]EFSを使ってみよう！設定編！
評価編：この記事！
ベンチマーク環境
読み込み速度のパフォーマンスを把握したかったので下記の環境でベンチマークを実施しました。
| リージョン | ap-northeast-1 |
| インスタンスタイプ | t2.microとt2.large |
| 比較対象 | EBS / S3 / EFS | マウント先 | 全て同一のインスタンス |
| 暗号化 | 全てのストレージで暗号化オプションを無効に |
| S3のマウント | goofysというツールを使用 |
こんな感じでマウントしておきます。
使用したコマンド
使用したコマンドはfioコマンドとddコマンドです。
ddコマンド自体はベンチマーク用のコマンドではないため厳密な性能評価はできませんが、実行までの時間と秒間の転送量が出るので参考にはなるはずです。
# マウント先ディレクトリを指定してランダム読み込み $ sudo fio --directory=/mnt --name fio_test_file --direct=1 --rw=randread --bs=4k --size=1G --numjobs=4 --time_based --runtime=180 --group_reporting --norandommap
# checkという名前の1[GB]あるダミーファイルをマウント先に配置 $ dd if=check of=/dev/null
fioコマンドの結果
まずはEBSの実行結果です。ちなみに画像はt2.microで実行したときのもの。
お次はS3だったのですが実行がコケた？ようです。エラーを見てると領域の確保ができてないっぽい・・。
最後にEFS。ファイルI/OをみてみるとEBSとは結構差があります。
グラフで比較してみるとこんな感じに。I/Oの単位は[MB]です。
グラフの見方としては値が大きいほうが優秀です。
ddコマンドの結果
ストレージの性能評価ならばfioコマンドで充分なのですが、S3との比較ができなかったのでddコマンドも走らせます。
こちらはEBSの結果です。
今度はS3も実行できました。流石にコピーするコマンドが失敗したら問題ですが・・・。
最後にEFSです。
こうして比較するとddコマンドは3種とも大差がないように見えますが、ddコマンド自体が処理に時間が掛かるのかインスタンスタイプをよいものにすると徐々に差が広がっていきます。
ただし今回は参考程度にS3とEFSの位置づけが知りたかっただけなので、頭打ちになるインスタンスタイプを調査するまでは行っておりません。
ddコマンドの実行時間で比較するとこのような感じに。単位は[秒]でグラフの値が小さいほど優秀です。
おわりに
この読み込み速度が充分に早いのかはもっと厳密なベンチマークを行わなければ結論付けはできません。
今回の検証で事実として言えることは、EFSはEBSの3割程度の読み込み速度で、S3よりも読み込み速度は早いということでしょう。
今後、企業レベルで運用するのであればPHPのソースコードをEFSにおいても問題ないのか、とか動画や画像のような静的コンテンツを使うときにはS3とどちらが優秀になるか色々検証すべきでしょう。
今回は個人レベルで検証できる簡単な結果を共有として記事にしました。参考になれば幸いです。
＜追記 2020/02/15＞
EFS内でgit cloneコマンドを実行したところ、なんと完了まで1時間も掛かってしまいました。
AWSへのサポートに問い合わせたところ、EFSは並列的な同時実行は得意ですが、gitコマンドなど単一スレッドで実行されるコマンドを実行すると非常に遅いそうです。
共通ストレージに速度が求められるケースでは、NFSサーバーを自力で立てるのが良いかもしれませんね。
2020年2月14日にリリースされたEBSマルチアタッチ(東京リージョン未対応)という機能もありますが、これは用途が限られてしまうのでEFSライクには使えない事に注意です。
コメントを残す