概要
AWS で提供している EBS (Elastic Block Store) はいくつかタイプがあり、それぞれパフォーマンス特性が違うことが分かった。そして、同じボリュームサイズであってもインスタンス毎に最大帯域幅が異なるため、 EBS のタイプと性能だけの理解で性能評価すると想定外の結果となる。その例を実際手を動かして確認してみたいと思う。
EBS 性能においての想定例
インスタンスタイプ c4.large で、220GiB の gp2 EBSを作成して、ディスクに 220GiB 分書き込みすると、以下の計算式で約23分くらい終わるであろう。
EBS gp2 ボリュームの最大スループットは、160 MiB/秒 なので、
想定所要時間 = 220 * 1000 (MB換算) / 160 / 60 （分換算） で大体 23 分くだいだろう。
インスタンスタイプ c4.large で、220GiB の gp2 EBSを作成し、パフォーマンス測定する
- マネジメントコンソールにて、c4.large インスタンスを作成
- ボリューム（/dev/sdb）を追加する
- ssh で該当 EC2 へ接続する
- ボリュームに、ファイルシステムを作成する
$ mkfs -t ext4 /dev/sdb
- fstab にマウント設定する内容を追記し、マウントする
$ mkdir -p /mnt/source /mnt/dest
$ echo '/dev/sdb /mnt/source ext4 defaults,nofail 0 2' >>/etc/fstab
$ mount -a
$ chown ec2-user:ec2-user /mnt/*
- 220MB 書き込みする
$ dd if=/dev/urandom of=/mnt/source/test bs=1M count=220K
* * *
dd: error writing ‘/mnt/source/test’: No space left on device
221543+0 records in
221542+0 records out
232303771648 bytes (232 GB) copied, 3763.15 s, 61.7 MB/s
予想した所要時間と実際の所要時間の乖離について
実際、約 62分 かかった。想定した所要時間、約23分 とかけ離れている。理由は、インスタンスタイプ「c4.large」は最大帯域幅が 500Mbps、予想スループット（MB/秒）が 62.5 MiB/s なため、正しい所要時間の計算式は以下となり、約 59 分 かかると予想するのが正しい。
220 * 1000 (MiB換算） / 62.6
実施は62分かかっているので、3分くらい誤差があったが概ね予想時間は正しい。
参考ドキュメント「Amazon EBS 最適化インスタンス」から、最初に想定した、23分以上のパフォーマンスを出すためには、インスタンスタイプ c4.4xlarge が必要な計算となる
220 * 1000 (MiB換算） / 250
インスタンスタイプ c4.4xlarge、220GiB の gp2 EBSを作成し、でパフォーマンス測定してみる
- 作成手順は、インスタンスタイプ c4.large と同様で、インスタンスタイプを 「c4.4xlarge」で作成する
$ dd if=/dev/urandom of=/mnt/source/test bs=1M count=220K
dd: error writing ‘/mnt/source/test’: No space left on device
221543+0 records in
221542+0 records out
232303767552 bytes (232 GB) copied, 1354.88 s, 171 MB/s
232 GB が 約 22 分で完了していることが分かる
参考ドキュメント
-
Amazon EBS ボリュームの種類
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSVolumeTypes.html -
Amazon EC2 インスタンスの構成
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-ec2-config.html -
Amazon EBS 最適化インスタンス
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSOptimized.html