夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想=『夢』と、潰えた夢=『ガラクタ』の集積場です。

Amazonの中の人によるAWS re:Invent 出張報告会での注目スライドサマリ(EBS)

こんにちは。

昨日Amazonの中の人によるAWS re:Invent 出張報告会に参加してきました。

発表内容やプロダクトアップデートについてはこの後スライドがアップされるそうなので割愛し、
出張報告会で注目すべきと中の方達が説明していたBreakOutSessionについて中身をざっと見てみました。
・・・ざっとの割にやたらと時間がかかるあたりが慣れていない所以ですね。

尚、私自身はAWSについて初心者なので、他のサイトであまり解説されていなかったセッションに限っています。
正式なAWSエンジニアのまとめがある場合はそれを見た方がいいかと^^;

まず、1つ目はSTG302、Amazon EC2とEBSの性能を最大限発揮するためのセッションです。EBSのIOの中身についても触れられています。

1.STG302 Maximizing EC2 and Elastic Block Store Disk Performance(スライド)(動画

一番大きなポイントは、下記の通り「EBSはHardDriveではない」ということ。

EBSは下記のように表わされる、一種のネットワークドライブとなる。

そのため、下記のようなきめ細やかな帯域設定が可能となっている。

結果、EC2のネットワーク帯域によってEBSが発揮される性能は左右される。

ただし、EBS最適化されたインスタンスについてはEBSに対してSANのようにアクセス可能となる専用帯域が用意されるため、ネットワーク帯域の影響を受けない。

パフォーマンスは基本はIOPSとレイテンシで規定される。
キュー数(EBSに対するIOの最大並列度)は基本4にし、その後チューニングをかければいい。
但し、24をオーバーするような値にするとIOPSは増えるかもしれないが、その分レイテンシは増大する。

EBSは作成直後は5%〜50%程の性能劣化が発生した状態になっているため、「Pre-Warming」処理を行うことを推奨する。
→ 性能は全チャンクがアクセスされたタイミングで最大化されるため。
→ 4MBブロックごとに書込み(LinuxであればDDコマンド)を行えばいい。

Raidを組む時は同サイズ同性能のEBSを組み合わせ、mdadm上でLVMを使用する。その際、Raid5/6は使用しないこと。(Raid0/10を使用する)
「Pre-Warming」を済ませた前提であれば、Sequential/RandomのIOパターンの違いは性能にそれほど影響は出ない。
→ AWS上で動作する際の各種RDB、NoSQLのチートシートも説明。ブロックサイズなどもあり、その前提でのEBSを使った際のMAX IOが記述

SSDインスタンスのレプリカを行う場合はfsyncやfull_page_writesといった整合性機能を無効化した方が性能は引き出せる。
また、EBSを含む個所へのバックアップは性能ギャップが大きいため、優先度低の状態でのバックアップが望ましい。

尚、EBS自体はパフォーマンス単価、容量単価的にも高めとなるため、使い分けること。

その他重要ポイント

  • Ext4 or XFSを使用する(journalの影響は大きい)
  • nobarrier、noatime、noexec、nodiratime
  • ファイルディスクリプタリミットを高く設定
  • read-aheadsを低く設定
  • SNAPSHOTを取れ!(EBSは故障率が年0.1〜0.5%となっており、S3等と比べると信頼度は下がる。かつ、スナップショットは差分バックアップのため効率いい)

=====
EBSはDiskDriveではなく、ネットワーク越しのドライブという所がポイントなのかもしれません。
・・・ただ、色んなインスタンスにマウント出来るという時点でそういうことはわかりますが、明確にそのあたりを理解できていなかった気はします。
あとはEBS最適化という項目の存在なども。