Amazon Elastic Block Storage

Amazon EBS tech black belt aws Amazon EC2

# Amazon Elastic Block Storage

https://d1.awsstatic.com/webinars/jp/pdf/services/20190320_AWS-BlackBelt-EBS.pdf

## 概要

  • EC2にアタッチして使用するブロックレベルのストレージサービス
  • SnapshotでS3へのバックアップや、ディスク暗号化機能の提供
  • 99.999%(five nine) の可用性
  • 1GiB から 16TiB
  • AZごとに独立している（同一AZのEC2からしか利用できない）
  • 複数のインスタンスで共用はできない
  • S3に取得したSnapshotを別のAZに復元できる

 

  • アーキテクチャ
    • データはAZ内で複数のHWにレプリケートされている
    • ネットワーク接続型のストレージ
    • EC2のセキュリティグループの通信制御の対象外。なのでインスタンスと常に通信できる
  • EBS最適化インスタンス
    • 最適化されていると、通常の通信とEBSとの通信を別々に行う
    • 大きいインスタンスほど、使える帯域が広い
  • Nitro System
    • 第五世代のインスタンス
    • 書き込みの処理や暗号化の処理を専用ハードウェアへオフロード
  • ストレージの種類
    • 一時記憶
    • 永続記憶
      • EBS SSD-backed volumes
        • 汎用SSD(gp2): ブーとボリュームなど
          • バーストバケットモデル
          • アクセスパターンが読めない場合にgood
        • プロビジョンドIOPS(io1)： DBのストレージなど
          • 最適なレイテンシーを実現する為に容量とIOPSの比率を2:1以上にする
      • EBS HDD-backed volumes
        • スループット最適化HDD（st１）： ビックデータなどの大量かつそこまでレスポンス速度がいらないもの
        • コールドHDD： ログデータなどの低頻度アクセスの大量データ
  • パフォーマンス
    • 律速する要素(帯域、スループット、バースト時に対応可能かに注目)
      • インスタンス側のスループット上限
      • EBS自体が処理できるIOの量
        • IOPSを確認する
        • タイプ(gp2など)やスペック(容量やIOPS値) を変更すると変更することで改善
      • EBS単体としてのスループット上限
        • EBSボリュームのスループットを確認する
        • 上限に達していればボリュームタイプを変更
    • ちなみにEC2とEBSを最大パフォーマンスでした時にはEC2の方がパフォーマンスが出るのでEC2 + 2*EBSという組み合わせが最速になる
  • 監視
    • OS
    • CloudWatch
      • CPU
      • ネットワーク
      • EB
      • 性能（スループット・IOPS）
      • 容量
      • バーストクレジット
  • NVMe SSD
    • NitroベースのインスタンスではVNMeブロックデバイスを認識
    • 旧世代から移行したい場合はNVMeドライバが必要なので、難しい場合はインスタンスの変更はしないことも視野に入れる

 

## EBSの機能

  • Elastic Volume
    • EC2にアタッチ中もサイズやIOPSを変更可能（拡大のみで、縮小はできない）
    • ボリュームタイプも変更可能
    • 容量拡張後はOS側でファイルシステムの拡張を行う
    • IOPSの拡張は徐々に行われる(1TB で 6時間)
  • EBS Snapshot
    • Snapshot 作成時にはデータ整合性を保つため静止点を設けることを推奨
    • レスポンスが返ってきた時点からIOを再開しても良い
      • EBSのIOを停止 -> Snapshot 作成指示 -> 作成指示レスポンス（バックグラウンドでSnapshotが作成される、この時にEBSのIOを再開してよい）
    • 世代管理の仕組みは最初がフルバックアップで、その後が増分バックアップ。フルバックアップが削除されても増分1がフルバックアップの情報を保持し続ける
    • リージョン間のコピーをサポート
      • Snapshot 取得の完了をCloudWatch Events のトリガーにして、バックアップを他リージョンにコピーすることができる
    • リストア
      • Snapshot からEBSを作成し、EC2にアタッチする
      • EBSを別リージョンに移したい場合はSnapshot 経由で行う
    • Snapshot 作成方法
      • CLI / SDK / コンソール
      • Systems Manager / CloudWatch Events
        • Windows と Linux が混在している場合にgood
        • SSMのRun Command を利用して実行
        • CloudWatch Events の EC2 Create Snapshot API を利用して実行
      • Amazon Data Lifecycle Manager (Amazon DLM)
        • タブ付けしたEBSを定期的にSnapshotを取得
        • スナップショットの管理、世代管理を自動化したい場合
        • 静止点を設ける必要がある
        • EC2 の状態は考慮せず、指定した開始時間から1時間以内に開始
      • AWS Backup
        • EBSだけでなく、EFS、RDS、DynamoDB、Storage Gateway をサポート
        • EBSだけでなく他のAWSサービスも含めて自動化したい場合にgood
  • 暗号化
    • ボリュームを暗号化すると、保存データ、インスタンス間で移動されるデータ、Snapshot が全て暗号化される
    • 暗号化・復号化の処理はハードウェア機能を利用して実施
    • 暗号化されたSnapshotからは暗号化されたボリュームが作成される
    • 暗号化したい場合にはSnapshot を行なった後に暗号化を有効化してSnapshot をコピーしEBSを作成しなおす
    • 暗号化を解除したい場合にはOS側でデータのコピーを行う

 

## 雑感

EBSって単にネットワークのブロックストレージを提供するだけのものかと思っていたが、色々と機能が付いている。タイプやIOPSの変更は動かしたまま変更ができるのは運用する側からは嬉しい（容量は迫っているがインスタンスを止めたくないということはありそう）。暗号化に付いてはSnapshot のコピーの段階で変更を行う。

パフォーマンスの最適化のところが特に興味深かった。EC2のスループットや帯域、EBS自体のパフォーマンスを見ながら、どこが律速する要素なのかを見極めるのが大切。