この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
本記事は AWS re:Invent 2017 のセッション「STG306 - Deep Dive on Amazon Elastic Block Store (Amazon EBS)」のレポートです。
スピーカー
- Jody Gibney - Senior Manager, Product Management, AWS
- Marc Olson - Principal Software Engineer
概要
EBS の機能と価値、ベストプラクティスやパフォーマンス、ボリュームタイプ別の詳細などが紹介されました。
In this popular session, discover how Amazon EBS can take your application deployments on Amazon EC2 to the next level. Learn about Amazon EBS features and benefits, how to identify applications that are appropriate for use with Amazon EBS, best practices, and details about its performance and volume types. The target audience is storage administrators, application developers, applications owners, and anyone who wants to understand how to optimize performance for Amazon EC2 using the power of Amazon EBS.
レポート
AWS ブロックストレージの選択肢
- EC2 インスタンスストア
- SSD / HDD
- EBS SSD
- gp2 / io1
- EBS HDD
- st1 / sc1
※マグネティック(standard) には以後も一切触れずでした。旧世代だから？
EC2 インスタンスストア
- インスタンスローカル
- 永続的ではないデータストア
- （デフォルトでは）二重化もされない
- スナップショットもサポートされない
- SSD or HDD
EBS
- Block storage as a service
- APIを通してボリュームを作成・アタッチ
- サービスへはネットワークを経由する
- EBS は「物理的なディスク装置」ではない
- 裏にたくさんの物理ディスクを持った仮想的なもの
- ボリュームは EC2 とは永続的に独立している
- ストレージ(EBS)とコンピュート(EC2)を、ワークロードに応じて選択
- 同じAZ内のインスタンスとデタッチ / アタッチできる
- ボリュームはひとつのインスタンスとアタッチできる
- 複数のボリュームをひとつのインスタンスにアタッチできる
- ブートボリュームとデータボリュームを分離できる
EBS ボリュームタイプ
- SSD
- gp2 - General Purpose SSD
- io1 - Provisioned IOPS SSD
- HDD
- st1 - Throughput Optimized SDD
- sc1 - Cold HDD
- あなたのワークロードにはどちらが重要か？
- IOPS
- スループット
EBS のタイプを選ぼう
IOPS重視
- 80,000IOPSより上 -> i3系のインスタンスを
- 80,000IOPS以下
- レイテンシ 1ms以下 -> i3系のインスタンスを
- 数ms
- コスト重視 -> gp2
- 性能重視 -> io1
スループット重視
- 小・ランダムI/O
- コスト重視 -> gp2
- 性能重視 -> io1
- 大・シーケンシャル I/O
- （集約後の）スループット 1,750MiB/sより上 -> d2系インスタンスを
- 1,750MiB/s以下
- コスト重視 -> sc1
- 性能重視 -> st1
gp2 - General Purpose SSD
- ベースライン : 100 〜 10,000 IOPS、3 IOPS/GiB
- バースト : 3,000 IOPS（1,000 GiB ボリュームのとき）
- スループット : 最大 160MiB/s
- レイテンシ : 数ms
- 容量 : 1GiB 〜 16TiB
- ブートボリュームや低レイテンシのアプリケーション、バーストアクセスのある DB 向け
io1 - Provisioned IOPS SSD
- ベースライン : 100 〜 20,000 IOPS
- スループット : 最大 320MiB/s
- レイテンシ : 数ms
- 容量 : 4GiB 〜 16TiB
- およそ 400GiB の容量の時に最大 IOPS（20,000）になる
st1 - Throughput Optimized SDD
- ベースライン : TiBあたり 40MiB/s、最大 500MiB/s
- バースト : TiBあたり 250MiB/s、最大 500MiB/s
- 容量 500GiB 〜 16TiB
- ラージブロック・広帯域シーケンシャルアクセスのワークロード向け
sc1 - Cold HDD (Throughput Provisioned)
- ベースライン : TiBあたり 12MiB/s、最大 192MiB/s
- バースト : TiBあたり 80MiB/s、最大 250MiB/s
- 容量 : 500GiB 〜 16TiB
- シーケンシャルなアクセス、ロギングやバックアップなど
もしワークロードがどんなものか知らなかったら？
- gp1 選んどけ
ハイブリッドなユースケース
- Apache Cassandra
- インスタンス : c4系
- データファイル : gp2
- コミットログ : st1
コスト
- gp2 : $0.10 per GiB
- io1 : $0.125 per GiB / $0.065 per PIOPS
- st1 : $0.045 per GiB
- sc1 : $0.025 per GiB
- スナップショット : $0.05 per GiB per month（全タイプ共通）
EBS Elastic Volume
- ボリュームサイズの拡張
- ボリュームタイプの変更（st1 ⇔ gp2 等）
- プロビジョンド IOPS の変更
ボリュームサイズの拡張方法
- ボリュームのスナップショットを取る（念のため？）
- modify-volume
- ステータスを確認
- ファイルシステムを拡張（必要なら）
Elastic Volumeの自動化のアイディア
- Elastic Volume + CloudWatch + Lambda
- 「正しいサイジング」
- "free space"メトリックをCloudWatchで監視してLambdaでresize
- IOPSリミットやバーストバランスを監視するにも使える
- GitHub - awslabs/aws-elastic-volumes: Sample code to help with Elastic Block Store automation with Elastic Volumes feature
Deep Dive : How do volumes attach ?
- AWS CLIでのコマンド
aws ec2 attach-volume ...
- Xenハイパーバイザの場合
- ハイパーバイザを介して EBS（IO ドメイン）とインスタンスはやり取りする
- EC2ハイパーバイザ（nvmeデバイス）
- ハイパーバイザと EBS の間に「EBS ストレージアクセラレータ（ハードウェア）」が介在する
EBSベストプラクティス - セキュリティ
- ブートおよびデータボリュームは暗号化できる
- 暗号化・非暗号化どちらもアタッチ可能
- 多くのインスタンスファミリー
- ボリュームパフォーマンスへの影響は無い
- 全ての EBS タイプでサポート
- スナップショットも暗号化される
- 追加のコストはかからない
- EBS 暗号化のために、KMS でマスターキーを作る
- キーローテーションのポリシーを設定
- CloudTrailを有効に
- 誰がキーを使えるかコントロールする
- 誰が管理者キーを使えるかコントロールする
EBSベストプラクティス - 可用性
- EBS は...
- 99.999% のサービス可用性
- 0.1%〜0.2% の年間平均故障率（AFR）
- スナップショット
- Point-in-time バックアップ
- S3にストアされ、EBSのAPIでアクセスする
- インクリメンタルスナップショット
- Crash Consistent
- Linuxでスナップショットを取るとき
- DB :
FLASH TABLE->LOCK TABLE - ファイルシステム :
sync->fsfreeze - EBSスナップショット取得
CreateSnapshotが完了したら、もう安全にリジュームできる
- DB :
- Windowsの場合
syncが使えたら使う- Volume Shadow Service (VSS) を使う
- NEW! EC2 SSM で VSS サポートしたよ！
AWSEC2-CreateSnapshot- 2017.11.21以降の Windows Server AMI にて対応
ハイブリッドボリュームのユースケース
スナップショットのコスト追跡
- タグ付けする
What can you do with a snapshot?
- 他のリージョンに持って行くこともできる
EBSベストプラクティス - 自動スナップショット
- キー技術
- AWS Lambda
- EC2 RunCommand
- タグ付け
- AWS Ops Automator – AWS Answers
EC2 が落ちたら？
- EC2 auto recovery がある
- DeleteOnTermination
- Faulse だと消えずに残る
- True だと一緒に消える
EBSベストプラクティス - パフォーマンス
- I/Oはどうカウントされる？
- 可能なら、単純にシーケンシャルI/Oをマージする
- ブロックサイズ等との兼ね合いで計算
Burst bucket: gp2
Burst bucket: スループット (sc1,st1)
ワークロードの I/Oパターンを知ろう
- Linux : iostat
- Win : perfmon
Linux: パフォーマンスチューニング (st1, sc1)
読込シェアドバッファの拡張
- 高スループットのREADワークロードで推奨
- ランダムI/Oの時にはパフォーマンスは落ちる
- ボリューム毎の設定
- Amazon Linux のデフォルトは 128KiB (256セクタ)
$ sudo blockdev -setra 2048 /dev/xvdf最大I/Oサイズの拡張
- 全ての高スループットワークロード向け
- インスタンス単位、全てのボリュームに影響
- Amazon Linux のデフォルトは 128 KiB（32ページ）
- ボリューム毎にメモリ消費量が増大する
# 3.10-4.5:
kernel /boot/vmlinuz-4.4.5-15.26.amzn1.x86_64 root=LABEL=/ console=ttyS0 xen_blkfront.max=256
# 4.6+:
kernel /boot/vmlinuz-4.9.20-11.31.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 xen_blkfront.max_indirect_segments=256EBS最適化インスタンスとは？
- EBS I/O 専用に確保されたネットワーク帯域
- 多くの現世代インスタンスタイプでデフォルトで有効
- インスタンスの起動時あるいは起動中のインスタンスに対して有効化可能
- いくつかの 10Gbps インスタンスタイプにはオプションがない
- c3.8xlarge, r3.8xlarge, i2.8xlarge
ベストプラクティス - RAID
- どのようなときに？
- ストレージの要件が 16TiB より上
- スループットの要件が 500MiB/s より上
- IOPSの要件が 20,000 @ 16K より上
- 冗長化（redundancy）のためにすべきではない
- EBSデータは既に多重化されている
- RAID1 にすると EBS の帯域は半分しか利用できない
- RAID5/6 は 20〜30% の I/O を失う（パリティのため）
EBS ボリュームの初期化
初期化（initializing）= 暖機のこと
- 新しいボリュームでは？
- アタッチしてすぐ使える（不要）
- 新しくスナップショットから作成したボリュームは？
- ベストの性能のために初期化が必要
- Amazon EBS ボリュームの初期化 - Amazon Elastic Compute Cloud
まとめ
- ワークロードに合わせた正しい選択を
- ボリューム
- インスタンス
新しいストレージ関連のトレーニング
- エンタープライズストレージエンジニア向け
- www.aws.training オンライントレーニング
- re:Invent内でもやってるよ
最後に
めちゃくちゃ濃い内容のセッションでした！
EC2 を使う上で何気なく使っている EBS ですが、ふだん気になりつつもちゃんとした答えをもっていなかったところがかなり明確になった気がします。自分は特に、下記のようなところが興味深かったです：
- 暗号化ボリュームは性能に影響がない
- スナップショットの取得は、APIの実行が完了したら再利用始めて良い
- EBS のパフォーマンスチューニング
しっかり考えて使い出すととても奥が深いことが分かったので、今後に生かしたいと思います。
14
