この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
EC2で構成されたシステムのパフォーマンスを向上したい場合、一番簡単なのはインスタンスタイプを変更してスケールアップすることですが、ディスクI/Oがネックになっていることも多々あります。
EBSのパフォーマンス向上の手段としては大きく二つあります。
- EBS最適化インスタンス ... 通常EC2とEBS間の通信は他のネットワークトラフィックと共存していますが、EBS最適化(EBS optimization)インスタンスに設定することでEC2とEBS間に専用のネットワークスループットが確保され、他のネットワークトラフィックの影響を最小化することが出来ますので、EBSのパフォーマンスが安定的に引き出せます。
- Provisioned IOPS ... 作成時にIOPSレートを指定出来るボリュームです。最小200〜最大4000IOPSの範囲で指定可能です。なおその性質から上記のEBS最適化インスタンスと組み合わせて使用することが推奨されています。
さて、当然高いIOPSでプロビジョニングされたEBSはハイパフォーマンスに決まってますが、
- この専用のネットワークスループットが確保されるEBS最適化インスタンスを設定しただけで、どのくらい性能差が出るものなんだろう？
- 他のネットワークトラフィックというのはどの程度影響があるものなのだろう？
というのが、今回のスタート地点です。
ベンチマークの対象
EBS最適化インスタンスは以下のインスタンスタイプが使用出来ます。今回は1000Mbpsの帯域を確保可能なm1.xlargeにしました。
| インスタンスタイプ | 帯域 |
|---|---|
| m1.large | 500 Mbps |
| m1.xlarge | 1000 Mbps |
| m2.2xlarge | 500 Mbps |
| m2.4xlarge | 1000 Mbps |
| m3.xlarge | 500 Mbps |
| m3.2xlarge | 1000 Mbps |
| c1.xlarge | 1000 Mbps |
また、EBS最適化インスタンスの検証は、それなりにネットワークトラフィックが高い状況で無いと確認が出来ません。そこでもう1台EC2を起動し、abでHTTPリクエストをガンガン掛けておきます。構成と結果予想は以下のような感じです。
ベンチマークの準備
今回のベンチマークはド定番であるところのfioを使用しました。
作成したEBSをext4、inode=512でmkfsし、特にオプションを付与すること無く普通にマウントします。
$ sudo mkfs.ext4 -I 512 /dev/xvdj
$ sudo mkdir /mnt/standard
$ sudo mount /dev/xvdj /mnt/standardfioをインストールします。
$ sudo yum -y install rpm-build libaio-devel gcc make
$ wget http://pkgs.repoforge.org/fio/fio-2.1.4-1.rf.src.rpm
$ rpmbuild --rebuild fio-2.1.4-1.rf.src.rpm
$ sudo rpm -Uvh rpmbuild/RPMS/x86_64/fio-2.1.4-1.amzn1.x86_64.rpmfioは以下のようなオプションで実行しました。sequential read/write、random read/writeの4パターンで、O_DIRECTアクセスでブロックサイズを16KB、計測に使うファイルサイズを12GB、並列ジョブを64個にして、1分間実行します。
$ fio -filename=/mnt/standard/testfio.file -direct=1 -rw=read -bs=16k -size=12G -group_reporting -name=seqread -numjobs=64 -runtime=60
$ fio -filename=/mnt/standard/testfio.file -direct=1 -rw=write -bs=16k -size=12G -group_reporting -name=seqwrite -numjobs=64 -runtime=60
$ fio -filename=/mnt/standard/testfio.file -direct=1 -rw=randread -bs=16k -size=12G -group_reporting -name=randread -numjobs=64 -runtime=60
$ fio -filename=/mnt/standard/testfio.file -direct=1 -rw=randwrite -bs=16k -size=12G -group_reporting -name=randwrite -numjobs=64 -runtime=60実行中は妨害EC2から以下のようにabを実行しネットワーク負荷を掛けます。index.htmlのファイルサイズは900KBです。
$ ab -n 100000 -c 100 http://対象WebサーバのIPアドレス/index.htmlベンチマーク結果
結果としては、全てのパターンで非EBS最適化インスタンスよりEBS最適化インスタンスのほうが高いパフォーマンスが得られました。やはりEC2-EBS間のネットワークスループットは、他のネットワークトラフィックの影響を大きく受けてしまうようです。
Bandwidth(KB/s)
| R/W | Standard | Optimized |
|---|---|---|
| Seq Read | 50802 | 89110 |
| Seq Write | 3799.9 | 10315 |
| Rand Read | 1791.6 | 2379.5 |
| Rand Write | 5431.8 | 10426 |
IOPS
| R/W | Standard | Optimized |
|---|---|---|
| Seq Read | 3175 | 5569 |
| Seq Write | 237 | 644 |
| Rand Read | 111 | 148 |
| Rand Write | 339 | 651 |
まとめ
知識としては理解していたところなのですが、実際に手で試すと改めて理解出来ました。通信量の多いシステムではEBS最適化インスタンスに設定するだけでも効果がありますので、簡易なスケールアップの手段として使えますね！
5
