【レポート】 EBS 詳解 (Deep Dive on Amazon Elastic Block Store (Amazon EBS)) #reinvent #STG306

はじめに

本記事は 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) には以後も一切触れずでした。旧世代だから？

• Amazon Elastic Block Store (Amazon EBS) – 旧世代のボリューム – アマゾン ウェブ サービス (AWS)

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 ストレージアクセラレータ（ハードウェア）」が介在する

参考 : 【レポート】 CMP332: EC2仮想基盤の進化 (C5 Instances and the Evolution of Amazon EC2 Virtualization) #reinvent #CMP332 ｜ Developers.IO

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が完了したら、もう安全にリジュームできる
• Windowsの場合
  • syncが使えたら使う
  • Volume Shadow Service (VSS) を使う
• NEW! EC2 SSM で VSS サポートしたよ！
  • AWSEC2-CreateSnapshot
  • 2017.11.21以降の Windows Server AMI にて対応

ハイブリッドボリュームのユースケース

• Infor EBS Case Study - Amazon Web Services (AWS)

スナップショットのコスト追跡

• タグ付けする

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)

• Linux インスタンスの Amazon EBS ボリュームのパフォーマンス - Amazon Elastic Compute Cloud

読込シェアドバッファの拡張

• 高スループットの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=256

EBS最適化インスタンスとは？

• 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 のパフォーマンスチューニング

しっかり考えて使い出すととても奥が深いことが分かったので、今後に生かしたいと思います。