ちょっと話題の記事

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

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)まで出た

構成のポイントのまとめ

構成を決める際のチェッックポイントは、次のとおり。

  • EBS Optimizedを有効にしてEBS用の帯域を確保しているか(帯域が足りないとき、安定した帯域がほしいとき)
  • 必要な帯域を満たすインスタンスタイプを選択しているか
  • アクセス特性に適したEBSを選択しているか
  • 必要なスループットとIOPSが満たせるデスク本数を構成しているか
    • 4000IOPS を2本使えば 8000IOPS, 10本使えば 40000IOPS
  • 価格面で最適なEBSを選択し、コスト計算しているか
  • 要件上、Encrypt Optionは必要か

まとめ

  • アクセスパターンやIOPS、スループット性能を考慮して、最適なEBSを選択しよう
  • 要件に応じて適したEC2インスタンスタイプを選択し、必要ならEBS-Optimizedを利用しよう
  • お客様の求める要件(性能面、コスト面、システム・運用要件など)に最適な構成を利用しよう

感想

分かりやすいセッションでしたし、非常に参考になりました。IOPSが指定できたりSSDボリュームが加わったりと、EBSの機能は日々進化していますが、今回のセッションのおかげで復習が捗りました。この資料を参考に、最適なEBSを選択してシステムを構成したいと思います。

検証結果を公開してくださったことで、具体的な数字を知ることができて有り難かったです。また、複数本のうち1本だけクレジットが減った状態だったらどうなるか?という検証が面白かったです。コストの話では、General Purposeの安さが意外でした。

それでは、また。