以前、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