AWS Summit 2014 Tokyo「Amazon EBS ボリュームの性能特性と構成方法を習得する！」レポート

#レポート

#AWS

虎塚

2014.08.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、虎塚です。

先月のAWSサミットのセッション「Amazon EBS ボリュームの性能特性と構成方法を習得する！」をタイムシフト聴講しましたので、レポートします。このセッションは、Tech Deep Diveと名付けられた技術セッションの1つです。

テーマは、Amazon EBSの性能特性と構成方法について。検証結果を交えながらの紹介です。講師は、松本大樹さん（アマゾンデータサービスジャパン）です。

Amazon EBS (Elastic Block Store) とは？

OSからブロックデバイスとして見えるストレージ
OSやアプリケーション、データを入れて使う
S3へスナップショットを取ることができる
99.999%の可用性を持つように設計されている

2014年7月時点でEBSは3種類ある。

EBS Magnetic Volumes（旧standard）: 最も古くからあり、性能はベストエフォート。; 8円 /GB/月くらい。安い。
EBS Provisioned IOPS (SSD) Volumes (PIOPS): I/O性能を保証。年間99.9%の期間は指定したI/O性能の±10%以内の性能を保証する; 14円 /GB/月くらい
EBS General Purpose (SSD) Volumes (gp2): クレジットという新しいルールで動く。これが貯まると性能がバーストする（後述）; 12円/GB/月くらい

各EBSの性能特性を見る

c3.8xlargeインスタンスに3種類のEBSをマウントして、FIO 2.1.5で性能検証を行った結果について。

1.1. Magnetic Volume: ランダムリード/ライト

IOPS: 凸凹。230 IOPSくらい。Magnetic Volumeは 100〜200 IOPS といわれているとおりの値
スループット: (ブロックサイズ 1MB) 25MB/sec くらい
全体的に、I/O量によって上がったり下がったり。ベストエフォート型らしい性能特性を持つ
時系列グラフで見ると、一瞬だが性能が0になったり、跳ね上がったりと、一定ではない

1.2. Magnetic Volume: シーケンシャルリード

IOPS: (ブロックサイズ1kB) 4000 IOPSくらい
スループット: 100MB/secくらい
昔からstandard（現Magnetic Volume）は、シーケンシャルリードに強いといわれている。大量読み込みが必要なバックアップなどの場面では、使い物になる
時系列グラフで見ると、ランダムリード/ライトよりは若干性能が安定。性能が落ちる箇所がところどころある

2.1. Provisioned IOPS: ランダムリード/ライト

IOPS: 4kB程度の小さいブロックサイズでは4000IOPS
スループット: ブロックサイズが大きくなると、IOPSが減る代わりにスループットが伸びる。130MB/sec 程度がデスクの限界と思われる
時系列グラフで見ると、かなり安定。4000IOPSあたりを推移。0になることはほとんどない
データベースのようにI/O性能が固定されたほうがよい用途には、このボリュームがオススメ

2.2. Provisioned IOPS: シーケンシャルリード

IOPS: ブロックサイズ32kBまで4000IOPSをキープ
スループット: ブロックサイズ32kB以上はIOPSが落ち、代わりにスループットが一定になる。やはり130MB/secあたりで頭打ち

3.1. General Purpose: ランダムリード

1TBのボリュームで3000IOPSを確保した状態で確認。

IOPS: 3000IOPS で頭打ち
時系列グラフで性能を見ると、ここまでのすべてを通して最も安定した性能が出ている

3.2. General Purpose: シーケンシャルリード

IOPS: 3000IOPSで頭打ち
IOPS: 130MB/secスループットで頭打ち

3つのデスクのコストを比較

※3種類のデスクで構成してみたコスト比較表がスライドにあるので、ご覧ください。

「要件: 3000IOPS / 容量1TB」のとき: Magnetic（8時間連続）:費用が結構かかる; Magnetic（1億回I/Oを発生させた場合。これは容量の10%）: 安い; Provisioned IOPS: 最も高い; General Purpose: 安い。Provisioned IOPSの3分の1程度

「要件: 4000IOPS / 容量1TB」のとき: General Purposeは1ボリュームあたり3000IOPSなので、2000IOPS x 2でRAIDを組んだ; Magnetic（8時間連続）:費用が結構かかる; Magnetic（1億回I/Oを発生させた場合。これは容量の10%）: 安い; Provisioned IOPS: 最も高い; General Purpose: 安い。やはりProvisioned IOPSの3分の1程度

IOPS指定タイプでは、General Purposeの方が、Provisioned IOPSよりずっと安い。

EBS性能特性のまとめ

Magnetic Volume: ランダムアクセスは100〜200IOPSまでで弱い; シーケンシャルアクセスなら100MB/sec程度のスループットが出るので悪くない
Provisioned IOPS / General Purpose: SSDだけあって、ランダムアクセス、シーケンシャルアクセスともに、指定分のIOPSは安定して出る; 1デスクあたり130MB/secくらい出る

General Purpose (SSD) をきちんと理解する

General Purposeという新しいルールを覚えよう。

General Purpose詳細

ベースパフォーマンス: 1GB あたり 3IOPS: 容量に応じてベースパフォーマンスが決まる。バーストすると 3000IOPS までいく。; 1000GB にすると 3000IOPS 固定になる。これは、Provisioned IOPSで3000IOPSを指定したときの振る舞いと似ている。; 瞬間的にIOPSが必要な用途に向いている。
料金: 1GB あたり月 0.12ドル: IOPSに対して課金はない。あくまでも確保した容量に課金される

「クレジットの消費」とは

負荷をかけると、内部的に持っているクレジットというものを消費していく

最初は3000IOPSが出る
容量100GB gp2デスクに負荷をかけると、クレジットが減っていく。ベースの 300IOPS を超えた負荷をかけて、クレジットがなくなると、3000IOPS から 300IOPS に落ちる
容量500GB gp2デスクに負荷をかけると、クレジットが減っていく。ベースの 500IOPS を超えた負荷をかけ、クレジットがなくなると、3000IOPS から 1500IOPS に落ちる

負荷とクレジット: 開始時は540万クレジット。これがMAX; クレジットが残存している間は3000IOPS出る。クレジットがなくなると、性能がベースパフォーマンスまで落ちる; 負荷を止めたり、ベースより下の負荷をかけると、クレジットを貯めることができる; クレジットが貯まっていると、再びベース以上の高い負荷がきたとき、3000IOPSまでバーストできる

t2インスタンスはこれに近い振る舞いをするので、今後Amazonはこれに近いルールに寄せていくかもしれない。ぜひルールを覚えてほしい。

検証: 4本のデスクでRAIDを組んだらどうなるか

クレジットが満タンの間は、4本分の性能が出る。クレジットがなくなると、ベースパフォーマンスを維持する。

1本だけクレジットが減った状態ではどうなるか: 4本のうち1本だけ、負荷を単独で余分にかけて、4本中3本だけ満タンの状態を作った; ベース以上の負荷をかけると、全部がバーストした分の性能が出た; しかし、1本でもクレジットが尽きると、全部のデスクが引きずられてベースラインまで落ちた

Provisioned IOPS と General Purpose のどちらがよいか

Provisioned IOPS: 非常に高いI/O性能を求められるミッションクリティカルなシステムに最適。大型データベースなど; 1デスクあたりの上限が 4000IOPS と高い; 年間99.9%の期間、指定したIOPSの±10%を実現する（これはgp2には書かれてない）
General Purpose: 短期的に負荷が集中するシステムや、それほどパフォーマンスが要求されない中小規模のデータベース、開発検証環境に向く; OSのブートボリュームに使うのもよい（起動時にスパイクがかかり、デスクからのリードが多いため）

Encrypt Optionについて

Encrypt Optionとは: EBSを暗号化するための機能
暗号化キーはAWSが持っている
- そのため、暗号化したボリュームをアカウント間で共有することはできない
すべてのEBSタイプで利用できる
スナプショットも暗号化される
ルートボリュームへの暗号化はできない
暗号化処理は、EC2側でなく物理ホストのハイパーバイザーで行うので、性能への影響はほとんどない

Encrypt Optionを使う場合と使わない場合の性能検証結果: IOPSの性能差はまったくない; CPU利用率は、暗号化した方が若干高い（Wait IO）が、無視できる範囲と考えてよい

AWS上でどう構成すべきか

EC2で帯域が詰まると引っ張られるので注意: EBSのデスクを増やしたらEC2もそれなりに大きなインスタンスタイプにしなければ性能が出ない
EBS-Optimized機能とは（c3.xlargem c3.2xlarge, c3.4xlarge）: EBS用に帯域を確保する; この機能を使うと、ネットワーク負荷とEBS負荷が分離される; この機能を使わないと、ネットワーク負荷とEBS負荷が共有されるので、ネットワーク負荷が大きいときにI/Oの帯域が潰される; 確保される帯域はインスタンスタイプによって異なるが、インスタンスが大きいほど大きくなる; c3.8xlargeにはこの機能がないが、インスタンスタイプの仕様として帯域が10GBある

どこまで性能が出るかの検証結果: 24本の Provisioned IOPS で、4000IOPS を指定したものをRAID0で組んだ場合; c3.8xlarge（帯域10GB）を利用して、理論的には 96000IOPS 出るところで、92000IOPS まで出た; ブロックサイズ1MBのシーケンシャルアクセスで、1081MB/sec (8.7 Gbps)まで出た