2016/07/04 / 最終更新日時 : 2017/09/27 Kazunori INABA クラウド

Amazon EFSのディスクベンチマーク

AWSのディスク共有可能なマネージドストレージサービス Amazon Elastic File System(EFS)が、ついに正式リリースされました。

・Amazon Elastic File System
https://aws.amazon.com/jp/efs/

・AWS Blog – Amazon Elastic File System – Production-Ready in Three Regions
https://aws.amazon.com/jp/blogs/aws/amazon-elastic-file-system-production-ready-in-three-regions/

EFSは、簡単にいうと「NFSマウントが可能なマネージドNASサーバー」で、以下のような特徴があります。

  • ファイルシステムは複数のゾーンで冗長化。
  • ストレージ容量は自動拡張。
  • 複数ゾーン、複数サーバーからの同時マウントが可能。
  • 課金はディスク使用量の分だけ。

より詳しい説明や設定方法等は、クラスメソッドさんの記事がとても参考になります。

・Developers.IO 【新機能】Amazon Elastic File System (Amazon EFS)がついにGA (一般利用可能)に！
http://dev.classmethod.jp/cloud/aws/amazon-elastic-file-system-is-generally-available/

今回は、パフォーマンスを確認するため、ディスクベンチマークテストを行いました。

isdベンチマークテストの基本的な条件

ベンチマークテストの基本的な条件は次のとおりです。

  • ベンチマークツールは、ディスク性能計測のdbench
  • リージョンは「米国東部、バージニア北部(US East, N.Virginia)」
  • ベンチマークテストを実施するNFSクライアントはEC2, t2.micro, Amazon Linux, ディスクはSSD 8GB
  • dbenchの同時接続数は1と4で計測
  • 計測日は2016年7月2日（日本時間）

ベンチマークテストは、次の5タイプのディスクに対して行いました。

  1. ローカルディスクEBS (gp2)
  2. NFSマウントしたEFS (General Purpose)
  3. NFSマウントしたEFS (Max I/O)
  4. NFSマウントしたNFSサーバー (同一ゾーン)
  5. NFSマウントしたNFSサーバー (異なるゾーン)

2, 3のEFSは、performance modeであるGeneral PurposeとMax I/Oの2つのタイプを用意しました。

4, 5は比較のため、EC2によるNFSサーバーを、クライアントと同一ゾーン、クライアントと異なるゾーンの2タイプ用意しました。
NFSサーバーのEC2インスタンスタイプは、クライアントと同じt2.micro, EBS(gp2), Amazon Linuxです。

NFSのマウント方法は、AWS Management Consoleの「EC2 mount instructions」で表示されるとおりで、コマンドは次のようになります。
この例では、マウントポイントは　/efs、NFSのバージョンは4.1です。

　# mount -t nfs4 -o nfsvers=4.1 us-east-1b.<File System ID>.efs.us-east-1.amazonaws.com:/ /efs

 

dbenchの計測時は、負荷パターンファイルを計測対象のマウントポイントにコピーしてから計測を実行します。
計測時間はデフォルトのウォームアップ2分、計測10分です。
マウントポイントが /efs の場合の計測コマンドは次のとおりです。

　# dbench -c /efs/client.txt -D /efs/ 1

　# dbench -c /efs/client.txt -D /efs/ 4

 

isdベンチマークテスト結果

dbenchによるベンチマークテストの結果は次のとおりです。

dbench 同時接続数1

Throughput (MB/sec) max latency (msec) レイテンシ補足
1. ローカルディスク (gp2) 164.736 259.234 ほぼ10～15msec
2. NFSマウントしたEFS (General Purpose) 2.052 242.399 ほぼ20～60msec
3. NFSマウントしたEFS (Max I/O) 0.978 292.301 ほぼ30～140msec
4. NFSマウントしたNFSサーバー (同一ゾーン) 6.448 405.996 ほぼ10～20msec
5. NFSマウントしたNFSサーバー (異なるゾーン) 5.359 204.463 ほぼ30～120msec

 

dbench 同時接続数4

Throughput (MB/sec) max latency (msec) レイテンシ補足
1. ローカルディスク (gp2) 422.737 151.569 ほぼ10～70msec
2. NFSマウントしたEFS (General Purpose) 8.015 1533.521 ほぼ30～100msec
3. NFSマウントしたEFS (Max I/O) 3.850 251.272 ほぼ60～140msec
4. NFSマウントしたNFSサーバー (同一ゾーン) 17.925 253.504 ほぼ10～40msec
5. NFSマウントしたNFSサーバー (異なるゾーン) 15.831 74.720 ほぼ20～50msec

 

（参考）WordPressのダウンロードファイル展開

ファイル操作のパフォーマンスの参考のため、最新のWordPressのダウンロードファイルを展開する時間をtimeコマンドで計測してみました。

　# time tar zxvf latest-ja.tar.gz

 

実行時間(real)の秒数は次のとおりです。

　real (sec)　
1. ローカルディスク (gp2) 　0.263
2. NFSマウントしたEFS (General Purpose) 　64.455
3. NFSマウントしたEFS (Max I/O) 　121.305
4. NFSマウントしたNFSサーバー (同一ゾーン) 　20.726
5. NFSマウントしたNFSサーバー (異なるゾーン)　 　32.199

 

isd考察

EFS (General Purpose)は、ローカルディスクEBSに比べると桁違いに遅いのですが、EC2によるNFSサーバーとはそんなに大きな違いはありません。
つまり、そもそもNFSプロトコルは遅いということです。

僕は、正式リリース前のプレビュー版のときも同様のベンチマークテストを行いました。
正直、そのときは本当にこのままリリースされていいのかな？と思うぐらい遅かったのですが、そのときに比べると、スループット、レイテンシとも大きく改善されています。
とくに、レイテンシはほぼ100msec未満で安定しています。

冗長化されたマネージドサービスでストレージ容量も自動拡張できて運用管理が圧倒的に楽なので、EC2でNFSサーバーたてるよりは、EFSを使うべきでしょう。

これで実際に本番環境で使えるのか？
たとえば、Webサイトであれば
「WordPressをEFS領域に置いてAuto Scalingする。DBはRDS。」

　ELB + (Auto Scaling)WordPress on EC2/EFS + RDS

というような構成で大丈夫か？と言われると、Nginx Proxy CacheやCloudFrontでキャッシュをうまく使ってディスクI/Oを減らせれば、問題ないように思います。

なお、AWS Blogの説明によると、ディスク性能については「EBS(gp2)のようにクレジット制で、最低でも100MB/secにバーストする」とのことですが、CloudWatchでDataReadIOBytes, DataWriteIOBytesを見ると、45-60kB/secを推移していました。
つまり、今回のテストではバースト性能を全く引き出せていません。
NFSマウント時のオプションを調整したり、クライアント側EC2のインスタンスタイプを上げてネットワーク性能を上げることで、NFSマウント時のディスク性能をアップさせる余地があると思われます。

また、EFSの2つのperformance mode 「General Purpose(Default)」と「Max I/O」については、AWS Managemenet Consoleで以下のような説明があります。

Choose performance mode:
We recommend General Purpose performance mode for most file systems.
Max I/O performance mode is optimized for applications where tens,
hundreds, or thousands of EC2 instances are accessing the file system
– it scales to higher levels of aggregate throughput
with a tradeoff of slightly higher latencies for file operations.

「Max I/O は、10, 100, 1,000などの大量のEC2からのアクセス向けに最適化している。
　スループットを大きく上げる代わりに、レイテンシも大きく増える。」
ということです。
この説明や、今回のベンチマークテストの結果から、通常は「General Purpose(Default)」で十分なのでしょう。

isdまとめ

正式リリースされたAmazon EFSのディスクベンチマークテストを行い、EC2によるNFSサーバーとの比較結果をまとめました。

Webシステムにおいて、アプリケーションの何らかのファイルやコンテンツファイルを複数サーバーから共有したいケースは多いと思います。
Amazon S3で共有してもよいのでしょうが、ネットワークマウントしてローカルディスクと同様に扱えるのですから、アプリケーションからの制御が楽ですね。
NFSサーバーやGlusterFS等を利用して高可用性をもつ共有ディスクストレージを自前で構築・運用するのはなかなか難しいのですが、それが安価で簡単に設定・利用できる素晴らしいサービスです。

今のところ、US East (Northern Virginia)、US West (Oregon)、Europe (Ireland) の3リージョンのみのリリースですが、早く東京リージョンにもリリースされるとよいですね。

なお、ベンチーマークテストの結果はひとつの目安にすぎませんので、採用にあたっては実際にアプリケーションを設置＆動作確認して判断されることをおすすめします。
 

Follow me!

カテゴリー
クラウド