#AWS
#EBS

EBS 最適化インスタンスの確認

More than 1 year has passed since last update.

概要

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 分で完了していることが分かる

参考ドキュメント