[レポート] Deep dive on Amazon EBS #STG303 #reinvent
はじめに
みなさま Xin chao !
本記事は、AWS re:Invent 2019 のセッション 「STG303 Deep dive on Amazon EBS」 のレポートです。
セッション概要
セッション概要を和訳したものです。
この人気のあるセッションでは、Amazon Elastic Block Store (Amazon EBS) が、リレーショナルおよび非リレーショナルデータベース、エンタープライズアプリケーション、ビッグデータ分析エンジン、ファイルシステム、メディアワークフローなど、Amazon EC2 のワークロードのパフォーマンスとコストを最適化する方法をつかみます。 Amazon EBS の新機能、機能と利点、セキュリティ技術、パフォーマンスとボリュームタイプの詳細について学びます。 対象読者には、セキュリティ管理者、アプリケーション開発者、アプリケーション所有者、およびアプリケーションインフラストラクチャまたはストレージエリアネットワーク (SAN) を構築または管理する運用担当者が含まれます。
スピーカー
- Ashish Palekar - Director of Product Management , Elastic Block Store, Amazon Web Services
- Marc Olson - Principal Software Engineer, Amazon Web Services
- Mahesh Subramanian - Sr. Director of Engineering, Teradata
レポート
アジェンダ
- EBS におけるセキュリティと暗号化
- EBS でのパフォーマンスベストプラクティス
- EBS における可用性と耐久性
- EBS におけるコスト低減
Amazon EBS における暗号化
- Amazon KMS との統合 - AES-256 暗号化
- カスタマーマスターキー (CMK)
暗号化済み EBS は、以下も含めて暗号化されている。
- EBS 内に保存されたデータ
- ボリュームーインスタンス間のデータ転送
- ボリュームから作成されたスナップショット
- スナップショットから作成されたボリューム
EBS におけるセキュリティと暗号化
EBS ボリュームの暗号化
EBS のための AWS KMS マスターキーの作成
- キーローテーションポリシー
- AWS CloudTrail の有効化
- キー利用者のコントロール
- キー管理者のコントロール
EBS パフォーマンスの最適化と EBS 暗号化
EBS 暗号化は最適化された EBS の性能劣化を伴うか?
- 第 4・第 5 世代インスタンスファミリーにおいてはパフォーマンスの違いはない
- つまり、第 4・第 5 世代インスタンスファミリーにおいては、暗号化は性能劣化を伴わない
EBS スナップショットの暗号化
- 暗号化済み EBS ボリュームのスナップショットは、自動的に暗号化される
- 暗号化済みスナップショットから作成されたボリュームは、自動的に暗号化される
- スナップショットコピー時に、暗号化されていないスナップショットを作成することも可能
- スナップショットコピー時に、所有している異なるキーを使って再暗号化も可能
スナップショットおよび AMI の共有
- パブリック共有 : マーケットプレースでの AMI 提供に使用
- 特定アカウントとの (AMI でない) スナップショットの共有
スナップショットからのボリュームの作成には、リージョン内でのスナップショットの複製が必要。
リージョン間でのスナップショットの複製
- スナップショットを、リージョンおよびアカウントをまたいで複製する
- 対象のスナップショットの複製に対して、リソースレベルでの権限をロックダウンする
- マルチリージョン = リージョン内のイベントから守ることが可能
- 権限のロックダウン = 悪意のある、または不測の削除 (を防ぐ)
暗号化されていないスナップショットまたは AMI の暗号化
暗号化を容易に行うための 3 つの新機能
暗号化されていないスナップショットまたは AMI からの暗号化済みボリュームの展開 (異なる CMK を使用した暗号化済みスナップショットまたは AMI の再暗号化)
これまでは、暗号化されていないスナップショットまたは AMI を暗号化するために 1 度コピーしてから、ボリュームを作成する必要があったが、現在では、暗号化されていないスナップショットから直接暗号化済みボリュームを作成することが可能になった。
CMK を使った暗号化済みスナップショットのクロスアカウント共有
これまでは、CMK による暗号化済みスナップショットまたは AMI をクロスアカウントで 1 度コピーしてからボリュームを作成する必要があったが、現在では、スナップショットのクロスアカウント共有により、直接ボリュームを作成することが可能になった。
リージョン内の単一の設定による EBS のデフォルト暗号化設定
これまでも、IAM ポリシーにより、暗号化されていないボリュームの展開を防ぐことができたが、現在では、アカウントレベルでのリージョン内設定により暗号化を設定できるようになった。
アプリケーションの構築
まず、アプリケーションの目的を理解し、ワークロードにとって適切なボリュームを選択する。
以下のような場合は SSD を推奨。 1000 GiB 未満の場合、バーストの枯渇に留意する。
- 高パフォーマンスが要求される
- ほとんどがランダム I/O
- シーケンシャルな (DB の) ジャーナル
- ワークロードへの高い依存
性能劣化や機能停止がシステムに影響しないか? についても検討する。
以下のような場合は スループット最適化 HDD (st1) を推奨。
- 高パフォーマンスが要求される
- ほとんどがシーケンシャルな I/O
- 持続した I/O
以下のような場合 Cold HDD を推奨
- 高パフォーマンスが要求される
- ほとんどがシーケンシャルな I/O
- 日次 (での処理)
インスタンスには複数の EBS ボリュームがアタッチできるので、組み合わせでの使用+適切なボリュームタイプの使用により、パフォーマンスを最適化する。
EC2 インスタンスの選択
- C 系 ・・・ コンピュート最適化
- M / A / T 系 ・・・ 汎用
- R 系 ・・・ メモリ最適化
Nitro 世代の 3 つのパーツ
- Nitro Card
- Nitro Security Chip
- Nitro Hypervisor
最適化 EBS
- EBS 専用の帯域
- インスタンスあたり 最大 14 Gbps (1,750 MiB/s) → 19 Gbps (2,375 MiB/s) ※ アップデート
- 小さいインスタンスでバースト利用可能
試用と計測
- 科学的手法を用いる
- ベンチマークの類はよいベースラインとなるが、パフォーマンスについては実際の環境とは異なる
- CloudWatch 等でモニターする
EBS の可用性と耐久性
EBS の設計思想
99.999% の可用性として設計されている = 0.1% ~ 0.2% の年間故障率 (annual failure rate = AFR)
EBS スナップショット
- ボリュームデータの更新のポイントタイムバックアップ
- 更新されたブロックは S3 上に保管される
- 増分 (での取得) およびクラッシュ時の一貫性
- インスタンスにアタッチされている、すべてのボリュームの一貫したスナップショットを取得することが可能
Amazon Data Lifecycle Manager
- スナップショットライフサイクルの自動化
- CloudFormation との統合
- EBS ボリュームまたは、インスタンスレベルでのポリシー
EBS Fast Snapshot Restore ※ 11/20 リリースの新機能
Recovery Time Objective (=RTO) が 1/6 に
EBSでのコスト低減
EBS ボリュームの適切なサイズへの変更
- 事前に将来分のすべてのサイズの確保ではなく、必要に応じたサイズ、IOPS の増加を行う
- ファイルシステムでのサイズ拡張を忘れない
必要に応じた適切なインスタンスサイズの選択
EBS ボリュームの性能だけを高めても、インスタンス側の性能が十分でない場合、適切なパフォーマンスは発揮できない
例) EBS が 16,000 IOPS に対して、EC2 インスタンスは以下の通り。
- 2x large = 8,000 IOPS
- 4x large = 16,000 IOPS
Nitro の EBS 最適化バースト
- Nitro インスタンス ("5" 世代, I3n, t3, z1d) のサイズが 4x large より小さい場合、EBS 最適化バーストをサポート
- バースト IOPS および スループットは、24 時間ごとに最大 30 分間可能
- ワークロードが 30 分未満のバーストで十分な場合、より小さいサイズを利用可能
例) C5 large の場合
- ベースライン : 4,000 IOPS, 65.525 MB/s
- バースト : 20,000 IOPS, 437.5 MB/s
新規作成時のボリュームおよびスナップショットへのタグ付け
- インスタンスおよびアプリケーションのターミネート時、ボリュームを削除可能
Data Lifecycle Manager によるスナップショットコストの管理
- スナップショットの取得および保持数をポリシーで設定
- コスト配分タグによるスナップショットコストの追跡
時間ベースでのスナップショットの Lifecycle Manager ポリシー
- スナップショット世代管理ポリシー
- 日, 週, 月ベースの保持期間設定
- ビジネスコンプライアンスおよび DR 要件への対応
使用されていないボリュームの低コストボリューム化
デタッチされてから以下の場合に低コストボリューム化
- 6h (EV time limit) または
- ボリューム変更時からの時間
さいごに
Amazon EBS は、初期のころから存在するサービスですが、様々な機能アップデートが今も行われています。
うまく活用して、最適な可用性とパフォーマンスを、最適なコストで維持していきたいですね。