読者です 読者をやめる 読者になる 読者になる

プログラマでありたい

おっさんになっても、プログラマでありつづけたい

AWSのEBS Provisioned IOPSからEBSについて妄想する

aws


 以前、EBSの内部構造を調べていて「結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について」という記事を書きました。そこでEBSの性能はネットワークの帯域で制約される旨を書きました。すると、@namikawaさんに次のような指摘を頂きました。

このsh2さんのブログにも書いてあるけど、QEMUなりcgroupのレイヤでの制限に近いやり方なのかなぁと思っています。ただの想像ではありますが。d.hatena.ne.jp/sh2/20121217


 確かにネットワークが性能の制約にはなりうるけど、ネットワークだけではProvisioned IOPSのようなIOPS単位での性能の制御は出来ないなぁと疑問に思っていました。気になったので、EBS絡みの性能測定や考察・Tipsを読んでみましたが、まだまだ解らない所だらけです。それでも、今回得た情報を元にProvisioned IOPSからEBSがどういう物なのか妄想してみます。
※あくまで想像でEBSの実際と異なる可能性が高いので、その辺りご了承ください。

EBSの基本的な動作



 まずはEBSの基本的な動作の確認です。一部、バーストについては経験則の部分がありますが、他は公式情報にも載っている内容です。

  • Standard EBSは、100IOPSを目標に設定されている。
  • Standard EBSは通常はバーストされて、それ以上の性能が出る。
  • Standard EBSで一定時間I/Oが高い状態が続いた場合、もしくは同一ホスト上の他インスタンスが高I/Oの場合にバーストは解除され低速になる。(バースト解除の正確な発動条件は不明)
  • Provisioned IOPSのEBSはブロックサーズ16KBで計算されている。1000IOPSに設定した場合で16KB以下なら1000IOPS出る。32KBなら500IOPSになる
  • Provisioned IOPSは指定したIOPSの±10%の範囲を99.9%の確率で確保する。バーストしないため高速ではなく安定を重視した設計になっている。

EBSの性能のファクター



 rx7さんのEBSの性能ベンチマークSH2さんのProvisioned IOPSの記事を読むと、EBSの性能がネットワークの制御だけではないのが解ります。その後に、Cloud, Big Data and Mobile: Part 5: Understanding Amazon Elastic Block Store Performance: LatencyとAmazon公式のWorkload Demand - Amazon Elastic Compute Cloudを読んでいると、EBSの性能のファクターは下記の3つがあるのが解りました。

  • ネットワーク帯域
  • レイテンシー
  • キュー


 ネットワーク帯域については、制約条件になるのは解っていました。では、レイテンシーとキューというのは何でしょう?レイテンシは、遅延時間です。キューは、Queue Depthで同時に発行するIO要求の命令数です。公式のユーザガイドによると、200IOPSにつき1を用意せよとのことです。1,000IOPSならば5ですね。レイテンシが高い場合は、予定しているIOPSに対してのキューを確認せよとのことです。もっともこの3つは性能のファクターであって、実際にどうやって制御しているかの謎は残ります。

まとめ



 調べていても、中々EBSの性能制御の実態は解りません。想像レベルですが、Provisioned IOPSはレイテンシを監視しながらI/O Requestレベルで性能を制御しているのではないでしょうか?I/O Requestの制御方法についてはSH2さんが紹介しているような、cgroupのような何かなのかもしれません。いずれにせよ、私の理解の範疇外なのでじっくり勉強していこうと思います。
 EBSはAWSのサービス群の中で一番物理のデバイスに近いサービスで、それ故に障害発生率が高いのだと思っていました。しかしProvisioned IOPSを考えると、単純にそうとも言えないことが解ってきました。Provisioned IOPSを実現している技術が、次のAWSのサービスの重要なファクターになるかもしれませんね。個人的には、AWS上でNAS的なサービスを実現する新技術が欲しいです。複数インスタンスからアタッチ出来るEBSとか。(全く別方向の技術というのは承知しておりますが)

おまけ



 EBS絡みの資料を読んでいるうちに、各インスタンスタイプ別の限界I/O性能の資料を見つけました。c1.mediumの性能の低さが気になるところですが、後は概ね納得です。

Instance Type EBS-optimized Available Maximum Throughput (MB/s)* Max 16K IOPS
c1.medium No 32 2,000
c1.xlarge Yes 125 8,000
c3.large No 62.5 4,000
c3.xlarge Yes 62.5 4,000
c3.2xlarge Yes 125 8,000
c3.4xlarge Yes 250 16,000
c3.8xlarge No 800 48,000
cc2.8xlarge No 800 48,000
cg1.4xlarge No 800 48,000
cr1.8xlarge No 800 48,000
g2.2xlarge Yes 125 8,000
hi1.4xlarge No 800 48,000
hs1.8xlarge No 800 48,000
m1.small No 62.5 4,000
m1.medium No 62.5 4,000
m1.large Yes 62.5 4,000
m1.xlarge Yes 125 8,000
m2.xlarge No 62.5 4,000
m2.2xlarge Yes 62.5 4,000
m2.4xlarge Yes 125 8,000
m3.xlarge Yes 62.5 4,000
m3.2xlarge Yes 125 8,000
t1.micro No 32 2,000


See Also:
結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について
Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き


参照:
Provisioned IOPSの検討 - JPOUG Advent Calendar 2012 - SH2の日記
Amazon EC2性能検証!気になるパフォーマンスをインスタンスタイプやリージョン毎に計測・比較してみた - 元RX-7乗りの適当な日々
Amazon EBS の性能ベンチマーク その1 (Standard編) - 元RX-7乗りの適当な日々
Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編) - 元RX-7乗りの適当な日々
Amazon EBS の性能ベンチマーク その3 (Provisioned IOPS編) - 元RX-7乗りの適当な日々
Amazon EBS Volume Performance - Amazon Elastic Compute Cloud
Cloud, Big Data and Mobile: Part 1: Understanding Amazon Elastic Block Store