絶品ゆどうふのタレ

ふと気づいたことを綴るだけのメモ

AWS Summit 2015 - Day1 - EBSパフォーマンスベンチマーク2015

AWS
  • AWS 小林さん

EBSのおさらい

  • ブロックレベルのストレージ
  • スナップショットを使ってバックアップ
  • 暗号化

  • 99.999%の可用性

  • 特徴

    • 容量は1G単位で16TBまで
      • マグネティックは1TBまで
    • AZごとに独立
    • スナップショットから任意のAZに復元可能

  • 1つのEBSを複数のインスタンスから参照することはできない

    • 付け替えは可能

アーキテクチャ

  • AZ内で複数のHWにレプリケートしている

ボリュームタイプ

  • ３種類からユースケースに合わせて
    • General Purpose SSD
    • Provisoned IOPS SSD
    • Magnetic
  • Snapshotをとって復元することで、ボリュームタイプを変更可能

汎用SSD

  • デフォルト
    • 費用対効果の高いディスク
  • 一時的に3000IOPSになるバースト機能を備えている

  • 1GBあたり3IOPSを常時確保(ベースパフォーマンス)

    • 容量が1000GB以下の場合は3000IOPSに一時的に引き上げるバーストが可能
      • たとえばOS起動時にはバーストさせて一気に起動させたり
    • 最大は10,000 IOPSまで上昇
      • 3334GBを超えたところで、常時10000IOPS

  • バーストの継続時間はIOクレジットの残高で決まる

    • バーストが発生するとクレジットを消費
    • 下回ったら時間とともにクレジットが溜まっていく

  • 容量とスループット

    • 容量依存でスループットが上がる
    • 170GB以下では128MB/s
    • 徐々に上がる
    • 214GB以上では常時160MB/s

Provisioned IOPS

  • SSDを超える性能
  • 99.99%の時間について、指定IOPSの+-10%の範囲で性能発揮する
  • 最大20000IOPSまで
  • 最大320MB/s(1280IOPS以上)
    • IOPS設定値依存

Magnetic

  • 磁気ディスク
    • かつてのデフォルト
  • コスト安
  • 1TBまで
  • 平均100IOPS
  • 最大数百IOPSまでバーストできる場合がある
  • IOPSの命令回数ベースで課金

パフォーマンスの律速要素

EC2インスタンス側のスループット

  • EBS-Optimized オプションを有効に

  • インスタンスタイプごとに上限値があるので、そこに到達していないか

    • CloudWatchの Volume Read/Write Bytesの合計値で判断

  • 上限に達している場合は、インスタンスタイプを大きくする

  • EBS最適化をOnにすると、EBSへのアクセス回線をインターネットの帯域と別に確保する

EBS側のIO性能を改善する

  • EBS側の実績値を確認する
    • CloudWatchの Volume Read/Write Opsを参照
    • OS から見てもいい
  • 上限に達していたばあいは、ボリュームの上限を改善

EBS側のスループットを改善する

  • 個々のボリュームのスループットを確認する
    • CloudWatchの Volume Read/Write Bytesを確認
  • 上限に達していた場合は、ボリュームタイプとスループットを確認

事前ウォーミング

  • EBS各ブロックの初回アクセスに限り、IOPSが5~50%低下する
    • 性能測定など
  • プレウォーミングを実施すると、回避できる

  • 実運用時には事前ウォーミング不可能な場合もある

  • 実行方法

RAID構成

ベンチマーク検証

  • それぞれのボリュームタイプについて、仕様通りの性能が出ていることを確認

  • RAIDによってそれを超えた性能が出せることをチェック

  • 構成

    • c3.8xlarge
    • 2015.03
    • xfs
    • EBSはpre-warmingずみ

  • このへんはもうグラフ見ないと伝えづらい。。。

  • こまかいブロック(8KB, 16KB)の場合はIOPSが高まって、そちらで頭を打つ
  • 大きなブロック(4MB)の場合は、IOPSの上限の前に、スループットが頭を打ってしまう
  • 大きなブロックの場合、IOPS値を大きく取り過ぎてしまうと費用がもったいない場合があるので、注意

インスタンスストアとEBS

  • もっと性能が欲しい場合は、インスタンスストアを使う
  • 追加ストアなしで使えるディスク
  • スループットはEBSとは独立している
  • インスタンスを止めるとデータは消える
    • 再起動では消えない
  • アプリケーションが使う一時的なデータの置き場所や分散システムのデータ置き場

ベンチマークをしてみる

ボリュームの暗号化

  • AES-256
  • ハードウェア機能を使って暗号化するので、パフォーマンスに影響しない
    • ほんと？というのを確認

  • fioで負荷をかけてiostat/vmstatでチェック

  • 実際にグラフを見ると、IOPSはほぼ変わらない

  • CPU使用率も殆ど差がない

典型的な構成例

  • 小さいデータへのアクセスが多い場合

    • 必要IOPSが得られるようにEBSを構成
    • ブロックサイズが小さければ、スループットがボトルネックになることは少ない
    • 本来必要な容量よりも多く取ることで、IOPSを稼ぐ
    • 単一で難しければRAID 0

  • 大きいデータへのアクセスが多い場合

    • IOPSよりもスループットを重視
    • シーケンシャルな場合も同様
    • 無駄にIOPSを高めないようにするほうが、コストを抑えられる

  • 低コストなストレージが必要な場合

    • アクセス頻度が低い・パフォーマンスが不要な場合はマグネティック

  • 極めて高いIOが必要な場合

    • インスタンスストアを利用する
    • OSやアプリケーションが必要とする大事なデータはEBSを利用する

まとめ