[PR] あなたが Kindle で読みたいその本、Kindle に対応したら Twitter でお知らせします。

インスタンスタイプによって SSD の性能が変わるのか調べてみた

Posted on

JAWS-UG Meguro #0 のハッシュタグを追いかけていると @yoshidashingo さんがこんなツイートをされていました。

インスタンスストアの SSD はどれも一緒だと漠然と思っていたので驚きました。ドキュメントを読んでみると SSD の TRIM 機能をサポートしたことにより書き込み性能が向上しているとのこと。

TRIM については、このページに詳しい説明がありました。

気になったことは手を動かして調べてみることを心がけているので、さっそくベンチマークを取ってみました。

ベンチマークの諸条件

  • OS: Amazon Linux AMI 2015.03 (HMV)
  • ファイルシステム: ext4
  • インスタンスストアを /dev/sdb にアタッチし /media/ephemeral0 にマウント

m3.large、c3.large、r3.large(TRIM オンとオフの 2 つ)の 4 つで比較しました。 CPU やメモリに差がありますが、ベンチマークの負荷は大したことがないので影響しないと思います。

ベンチマークの計測方法は次のとおり。

  • fio コマンドを root ユーザで実行
  • ランダム書き込みで計測(TRIM の有効性を確認するため)
  • ブロックサイズは 16 KB
  • 4 回計測し、1 回目を除いた平均値を採用(1 回目は値が安定しないため)

fio による EBS ボリュームの性能測定を参考にして、fio のオプションは次のように指定しました。

# fio -name=random-write \
      -ioengine=libaio \
      -rw=randrw \
      -rwmixread=0 \
      -bs=16k \
      -numjobs=16 \
      -iodepth=16 \
      -size=100m \
      -direct=1 \
      -directory=/media/ephemeral0 \
      -group_reporting

ちなみに、Amazon Linux には fio コマンドが入ってないので yum でインストールしました。

# yum install -y fio

インスタンスストアの事前ウォーミング

インスタンスストアも EBS ボリュームと同じように事前ウォーミングすることで最大限のパフォーマンを発揮します。ただし、I2, R3, HI1 インスタンスはアタッチされる SSD が違うようで事前ウォーミングが不要とドキュメントにあります。

今回は m3.large と c3.large に対して事前ウォーミングを行いました。

# dd if=/dev/zero of=/dev/sdb bs=1M
dd: error writing ‘/dev/sdb’: No space left on device
30713+0 records in
30712+0 records out
32204390400 bytes (32 GB) copied, 160.593 s, 201 MB/s

dd コマンドですべてのブロックに書き込むだけです。 5 分程度で終わりました。

TRIM を使えるようにする

OS と SSD が TRIM をサポートしていると、このようにバイト数が返ってきます。 M3 や C3 では 0 が返ってきます。

# cat /sys/block/xvdb/queue/discard_max_bytes
32212254720

R3 は TRIM をサポートしているので、フォーマット / マウントするときにオプションを追加します。ドキュメントの手順どおりに進めます。

# mkfs.ext4 -E nodiscard /dev/xvdb
# mount -o discard /dev/xvdb /media/ephemeral0
# mount | grep /dev/xvdb
/dev/xvdb on /media/ephemeral0 type ext4 (rw,relatime,discard,data=ordered)

これで準備完了です。

ベンチマークの結果

ベンチマークの結果です。単位は IOPS です。

1 回目2 回目3 回目平均
m3.large15937162431615116110
c3.large22338231832278522769
r3.large2611261126112611
r3.large (TRIM)2611261126112611

平均値をグラフにしたのが下の図です。

インスタンスストアの IOPS

R3 が一番良い結果になると思っていたのですが、実際には M3 と C3 の方が桁違いの IOPS を出しました。

ランダム書き込みという条件が良くないのかと思いシーケンシャル書き込みやランダム読み書きも試しましたが、R3 が常に最下位という結果でした。

TRIM の有効性が見られないのは、空きブロックがなくなるまで使わないと TRIM の効果が現れないためと思われます。

まとめ

R3 インスタンスにアタッチされる SSD が違うことが検証できましたが、他にもわかったことがあります。

  • M3 と C3 は高い IOPS が得られるが、ぶれ幅が大きく安定しない
    • もしかすると他のゲストマシンの影響を受けているかも。ハードウェア専有インスタンスだと結果が変わりそう
  • R3 はそこそこの IOPS だが、ぶれ幅が少なく安定している
  • 今回のベンチマークでは TRIM の効果は見られなかった
    • 頻繁に書き込むような使い方をしていると効果が出てくるはず

ドキュメントを読んで鵜呑みにするのではなく、自分の目でしっかりと検証することは大事ですね :)