【レポート】「Amazon EBS 完全に理解した」あなたに贈る Amazon EBS 再入門 #AWSSummit

AWS Summit Online Japan 2020

#レポート

#Amazon EBS

#AWS

恩塚伸一郎

2020.09.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは！筋トレ大好きオンジーです！

まだまだ AWS Summit Online やってるよ！(〜2020/9/30)

突然ですがEBSはこの2019年1月から現在2020年9月までに24回もアップデートされています。

EBSの概要から最近のアップデート、ベストプラクティスまで分かってしまうセッションに参加してきたのでそのレポートです。

セッションの概要

タイトル：「Amazon EBS 完全に理解した」あなたに贈る Amazon EBS 再入門

スピーカー：AWSJ 河原哲也さん

想定聴講者
- EBSを「完全に理解した」=チュートリアルは終えたレベルの方
ゴール
- EBSの全体像の理解を深める
- 最近のアップデートを踏まえた現在のベストプラクティスを把握する
- 「なにもわからない」と言えるようになるための一歩を踏み出す
- 「チョットデキル」人たちに臆せず質問できるようになる

動画と資料

Amazon EBS を正しく利用するための重要な考慮事項

Amazon EBSとは
- EC2向けの永続的なブロックストレージサービス
- API経由でボリュームを作成、アタッチ、管理
- ネットワーク接続型
  - サーバーのローカルストレージではない
- EBSボリュームの可用性
  - 単体の物理ディスクドライブではない
  - アベイラビリティゾーン内で自動的に複製されており可用性と耐久性が確保されている
  - ただし論理障害に対応するバックアップはユーザーがする必要がある(責任共有モデル)
- ネットワーク接続型でストレージとコンピュートが独立して管理されている
  - EC2に依存しないボリュームライフサイクル
  - ワークロードに基づいてストレージとコンピューティングを選択
  - 同じアベイラビリティーゾーン内のEC2 インスタンス間でデタッチとアタッチが可能
- 1つの EC2 インスタンスに複数のボリュームのアタッチが可能
- ブートとデータのボリュームを別々に用意することを推奨
  - 管理の観点からシステム領域のブートボリュームとユーザーのデータを格納するデータボリュームは別々にすることを推奨
  - データボリュームも例えばデータベースであれば耐障害性の観点からデータファイル、ログファイル、バックアップ領域をそれぞれ構成することを検討しましょう
Amazon EBS マルチアタッチ(2020/2/14新機能)
- 現時点では無条件で共有ストレージとして使えるわけではないので注意が必要
- 単一のプロビジョンドIOPSボリュームを、同じアベイラビリティーゾーン(AZ)内にある最大16のNitroインスタンスにアタッチが可能
- プロビジョンドIOPSは共有
- マルチアタッチが有効なボリュームのボリュームタイプ、サイズ、プロビジョンドIOPSは変更不可
- I/Oフェンシングは未サポート(アプリケーションで同時書き込み操作を制御)

過去ブログでも取り上げていますので参考に貼っておきます。

(補足)NitroインスタンスではNVmeデバイスとして扱われる
- ドライバやデバイスマッピングが変わっている
- 古い世代のインスタンスからNitroインスタンスにタイプを変更するときは注意しておきましょう

EBSとEC2の設計指針

EBSの設計にはIO要求を出すEC2も正しく選択する必要がある

4つのEBSボリューム
- SSDタイプ(トランザクションワークロード向き)
  - gp2(汎用SSD)
    - コストパフォーマンスに優れている
  - io1(プロビジョンドIOPS SSD)
    - IO性能を保証する
- HDDタイプ(スループットワークロード向け)
  - st1(スループット最適化HDD)
  - sc1(コールドHDD)
    - アクセス頻度の低い用途向け
- ボリュームタイプを選ぶ上で大事なポイント
  - 「ボリューム毎の最大IOPS」「ボリューム毎の最大スループット」
    - 各タイプで違うので選ぶ際の基準になる
  - 「月額料金」
    - 特にio1は容量に加えてプロビジョニングしたIOPSに基づいて課金される
  - 性能と要件に合わせて最適なタイプを選択しよう
  - gp2とst1とsc1にはバーストという考え方がある(後述)

バースト
- ベースラインIOPS(1GiBあたり3IOPSでリニアにスケール)がある
- ベースラインに加えて小さいボリュームでも突発的なIO負荷に対応できるよう3000IOPSまでバーストする
  - 例)300GiBボリュームだと本来は900IOPSまでだが3000IOPSまでバースト(画像参照)

- バーストは常時利用できるわけではない
  - バーストバケットという考え方
    - バケツに水を貯めておいて必要な時に開放するようなイメージ
    - 毎秒3IOPS/GiBのクレジットを補充
    - バケット毎に最大540万IOクレジットを貯めることができる
- バースト期間の計算
  - 例)最大の3000IOPS必要でgp2を使っている(画像を参照)

ここまでの情報を整理したボリュームタイプの選択基準

- EBSだけを適切に選択してもIO要求を出すEC2側があっていないとストレージを生かせなかったりコストに無駄が出たりします(大事なので2回目)
EBS最適化EC2インスタンス
- AmazonEBSI/Oに専用の帯域幅を提供
- 現行世代のインスタンスはデフォルトで有効
- インスタンスの起動時または実行後に有効化
- 一部の10Gbpsインスタンスタイプは未サポート(c3.8xlarge,r3.8xlarge,i2.8xlarge)
- 帯域幅の性能向上(2020/2/26)
  - インスタンスあたり最大19Gbps(2,375MiB/秒)に
  - HighMemoryインスタンスは38Gbps(4,750MiB/秒)に
  - 小さいインスタンスタイプのバーストが可能に
適切なEC2インスタンスの選択
- EBSボリュームに対しそれを生かしきれるEC2を選択する(画像1枚目)
- IO負荷が一時的に高まるケースはNitroシステムのEBS最適化のバーストが利用できないかを検討(画像2枚目)
  - 常時大きいサイズのEC2を起動しておく必要がないのでコストの最適化が図れる

EBSエラスティックボリュームの活用
- オンプレミスでは事前に予測してサイズを決めつける必要があった・・・→クラウドでは考え方を変える！
  - 「最初から完璧を目指すのではなく、必要に応じて変える」
- EBSエラスティックボリュームを活用してアプリケーションに影響を出さずに後から以下のことができる
  - ボリュームタイプの変更
  - ボリュームサイズの増加
  - プロビジョンドIOPSの調整
- ただしボリュームサイズを増やした場合はOSファイルシステムの拡張を忘れずに実施
- E2もインスタンスタイプを変えることができる
- 未使用のボリュームの保持を活用
  - 使ってないボリュームのタイプを変えておき、使う時に元に戻すことで節約
  - 次のようなことに注意して検討しましょう
    - 操作の頻度(エラスティックボリュームの6時間の制約)
    - 再度変更後の利用用途(新しい設定が有効になるまで最大24時間)
    - ボリュームサイズ(sc1は500GiB~)

データライフサイクル管理

EBSスナップショット

- スナップショットを素早く作成(画像の②)し非同期でS3に保存される(画像の③)
- スナップショットは別のリージョンに保存して耐障害性を高めることができる
- 別アカウントに共有して誤った削除を防いだり、監査要件に対応することができる
EBSスナップショットは増分になっている
- 変更のあったブロックだけが保存されていくことで
  - スナップショット作成時間が短縮される
  - 全てを複製するわけではないのでストレージコストを抑えられる
EBSスナップショットからボリュームの作成
- データの初回アクセス時にS3から読み込む「初期化」の処理が必要になる
  - 全てのブロックを読み込むまで性能に影響が出る可能性を考慮しておく
- この初期化におけるパフォーマンスへの影響を許容できない場合
  - fioやddを使ってブロックを強制的に読み込むことで最大のパフォーマンスを発揮できるにしておく
  - しかし手間も時間もかかる・・・
高速スナップショット復元(FSR)(2019/11/20新機能)
- 有効にしておくことで完全に初期化が済んだ状態でボリュームを使用することができる
- ただしクレジットバケットと料金については考慮しておく必要があります(画像参照)
  - 考慮した上でFSRとfioなどを使った即時初期化を天秤に掛ける

- FSRを使うケースは次のようなものを想定
  - 計画的な復元
    - 仮想デスクトップイメージの展開
    - Auto Scalingのインスタンス追加
    - 夜間バッチ処理の失敗時への備え
    - テストや開発用のボリュームコピー

過去ブログで実際に試しているので参考に貼っておきます。

EBS direct APIs(2019/12/3新機能)
- スナップショットを直接読み取って二つのスナップショットの差異を特定する
- EBS ダイレクト API を使用して任意のブロックストレージからスナップショットを作成する(2020/7/9新機能)

こちらも過去ブログで(略

EBSスナップショットはクラッシュ整合性
- スナップショットコマンドを実行した時点のボリュームに書き込まれているデータのみを補足
- アプリケーションやOSによってローカルにキャッシュされているデータは除外される可能性あり
- データの整合性を保つためにはトランザクションを全て終了させたり、一旦ボリュームを取り外すなど静止点を設けるなど検討
マルチボリュームスナップショット(2019/5/29新機能)
- 複数のEBSを対象に1回のAPIコールと最小限のIO停止でスナップショットが作成できる

VSS連携によるアプリケーション整合性
- Run Commandを使用してVSSに対応したアプリケーションで整合性のあるEBSスナップショットを作成可能

データセキュリティ

Amazon EBS 暗号化
- KMSと連携することで鍵管理のインフラストラクチャを構築・運用する必要なくEBSボリュームとスナップショットを暗号化できる
- EC2インスタンスをホストするサーバーサイド側で暗号化が行われているのでEC2とボリューム間の移動の際もデータは暗号化されている

暗号化のベストプラクティス
- KMSでEBS用に新しいCMKを作成推奨
- キーローテーションのポリシーを定義
- AWSCloudTrailの証跡を設定
- 適切なキーの管理アクセス許可
- 適切なキーの使用アクセス許可
暗号化されていないスナップショットから暗号化されたボリュームの作成(2019/5/10機能改善)
- 以前は間にスナップショットをコピー&暗号化する必要があった
暗号化されたスナップショットの共有(2019/5/10機能改善)
- アカウント間でスナップショットの共有ができるようになった
新規EBSボリュームのデフォルト暗号化(2019/5/23機能改善)
- リージョン毎に一回の設定で暗号化をデフォルトに設定可能に

監視とコスト最適化

EBSのパフォーマンスはIO特性やインスタンスやボリュームの設定などいくつかの要因に左右されます。

最適な構成を決定するにはベンチマーク結果や実際の性能情報を元に判断することを推奨。

Amazon EBS の CloudWatchメトリクス

- 例)バーストによるクレジットの消費を可視化
CloudWatchエージェントの導入

- 例)ディスク使用率を監視しておき閾値を超えたらエラスティックボリュームで自動拡張する実装も可能
料金の考え方
- EBSボリュームの料金
  - ギガバイト/月単位での請求
    - 月の途中で消された場合は秒単位で計算
  - ストレージを使用しているか否かにかかわらず、プロビジョニングされたストレージの合計量に基づいて計算
- EBSスナップショットの料金
  - ギガバイト/月単位での請求
  - スナップショットは変更されたブロックだけを保存するため、変更されたブロック分を計算
- AWS Pricing Calculator で料金試算できる
- AWS Cost Explorer で可視化できる
- AWS Trusted Advisor の活用
  - 利用頻度の低いEBSボリュームを表示してくれる