「AWS Black Belt Tech Webinar 2014 – Amazon Elastic Block Store」レポート

AWS Black Belt Tech Webinarレポート

#Amazon EC2

#Amazon EBS

#AWS

虎塚

2014.09.03

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

こんにちは、虎塚です。

本日夕方に開催された「AWS Black Belt Tech Webinar 2014 - Amazon Elastic Block Store -」を聴講したので、レポートします。WebinarでEBSを扱うのは1年半ぶりとのことで、楽しみにしていました。AWSサミットのTech Deep DiveのEBSセッションも聴いて、予習はバッチリです。

（参考）AWS Summit 2014 Tokyo「Amazon EBS ボリュームの性能特性と構成方法を習得する！」レポート｜ Developers.IO

講師は、アマゾン・データサービス・ジャパンの平山毅さんです。

はじめに

30以上あるAWSサービス群のうち、EBSはストレージサービスに当たる。

EC2とEBSは、EC2の利用者には一体のサービスとして捉えられがちだが、CPUとメモリがEC2、ディスクがEBSという違いがある。

1.Amazon Elastic Block Store とは？ -基本編-

基本機能

AWSのストレージサービスの分類

ストレージには、大きく分けて3つのタイプのサービスがある。

揮発性のディスク: Ephemeral Disk（EC2に付いているデフォルトのディスク）
永続的な保存が可能なディスク: Elastic Block Store (EC2に接続して使う)
StrageGatewayを介して使えるもの: S3, Glacier

Amazon Elastic Block Store とは

1GB〜1TBまで1GB単位で伸縮自在
容量と期間で課金される

EBSはEC2に付けたり外したりできるので、別のEC2に付け変えることができる
データは永続的に保存されるので、EC2が落ちても保持される
スナップショットからボリュームをいくつでも作ることができる（別のAvailability Zoneに作ることもできる）
現在3種類のストレージがある

EBSの基本アーキテクチャ

EC2からEBSは1つのデバイスのように見える
OSのファイル領域として指定することで、データ領域として使えるようになる
EC2とは独立しているので、ネットワークを介して接続する

EBSを共有ディスクとして利用する場合の制約

複数のEC2インスタンスから同時に1つのEBSボリュームをアタッチすることはできない
- 逆に、1つのEC2インスタンスから複数のEBSボリュームをアタッチすることはできる
共有ディスク型のクラスタソフトやOracle RACをそのまま使うことはできない
Shared Nothing型のクラスタソフトは使える

EBS、Instance Storeの適用箇所

Windowsの場合、次のような使い方が考えられる。

Cドライブ: OSのブートディスクとしてEBSを利用
Dドライブ: データ格納ディスクとしてEBSを利用
Eドライブ: データ計算用の一時ディスクとしてインスタンスストアを利用

Delete on Terminationの無効化

デフォルトでは、EC2にアタッチされたEBSは、EC2がTerminateされると削除される。この機能を無効化すると、EC2を削除した時にディスクが消えない。

Snapshot機能概要

EBSスナップショットとは？

EBSの特定時点のスナップショットをバックエンドでS3に保存
- バックエンドの意味: S3に保存されたスナップショットは、EC2のSnapshotsメニューから見える。S3からは見えない。
容量に対して課金される
2回目以降のバックアップは差分バックアップ
- 複数個のバックアップを保存できるので、世代管理ができる
スナップショットからAvailabilityZoneをまたいでEBSの作成や復元ができる
アカウント間でEBSを共有することができる
スナップショットは、AvailabilityZoneに固定された機能ではないため、耐久性が高い（※Q＆Aを参照）
スナップショットを活用することでEBSのサイズを変更できる

EBSスナップショットの取得処理方式

S3への保存時の処理では、「ブロックレベル」の変更差分が保存される
- 前回よりも減った場合、減った分が削除される
保存されているスナップショットは、1つで各時点の全分となる（この単位でリストア可能）
S3に格納される実ファイルは、スナップショットに紐づくファイルが差分管理される
- 各スナップショットの全分のファイルが、S3に保存される

EBSスナップショットのリストア処理方式

戻したい時点のスナップショットに、全分方式でリストアできる
- 差分を1つずつ当てていく作業は不要。その時点の状態にいきなり戻せる

Snapshotの公開

スナップショットにはPermissionを設定できる。

Public: すべてのAWSユーザが利用可能
Private: 指定した特定のAWSアカウントのみ利用可能

Snapshot Copy

スナップショットは、リージョン内、リージョン間でコピーできる。次のような用途を想定している。

新しいリージョンでアプリケーションをローンチするため（地理的な拡大・グローバル展開）
アプリケーションの移行のため
ディザスタリカバリ対応

Snapshot Copyの操作

Management Consoleから操作する場合、コピー対象のスナップショットを選択して、コピー先のリージョンを選択するだけ。

画面で実行する場合は送信元リージョンから送信先を指定する
コマンドラインで実行する場合は、送信先リージョンの処理としてpullする

スナップショット処理の自動化

コマンドラインからスケジュール化して自動実行するのがオススメ。

OSのスケジュール管理機能を使う
- Linux: cron, Windows: タスクスケジューラ
ジョブスケジューラに組み込む

IAM Roleを活用することで、スクリプト自体に認証情報を埋め込むことを避けられる。

Provisioned IOPS機能概要

Provisioned IOPS

IOPS=1秒あたりのInput/Output数、という意味
- 計算式: 1 / (回転待ち時間 + シーク時間 + データ転送時間)
EBS-Optimizedを有効にしたインスタンスから使うことを前提としている
Volume作成時に、Volume TypeにProvisioned IOPS (SSD) を指定すると利用できる
OSからはEBSの種類にかかわらず同じようにディスクに見える
指定したIOPS値の±10%が99.9%保証される

EBS-Optimized Instance

EBS用にネットワーク帯域を最適化するためのEC2の機能
Provisioned IOPSタイプのEBSと組み合わせることで最適化が実現される

EBS-Optimized Instance有効化

EC2起動時の設定項目で、Launch as EBS-Optimized Instanceを選択する

PIOPSとEBS-Optimizedの組合せ

-	EBS-optimized なし	EBS-optimized あり
P-IOPSを利用しない	（通常）ネットワーク性能がぶれる	帯域を分けることで、IOが安定する
P-IOPSを利用する	効果がないので推奨しない	高速なIOが安定する

Auto Enable IO機能

EBSのデータ整合性が取れなくなっても、EBSへのI/O処理を中断せず継続する機能。データ整合性よりディスク可用性を優先する場合に使用する。

この設定をするとステータスチェックの結果が常に「OKay」になるが、整合性が損なわれると「Auto I/O enable」とうイベントが生成される。

設定方法: EBSのStatus Checksタブの「Auto-Enabled IO」の「Edit」をクリックすると、この設定のためのチェックが現れる。

EBS Volume Status機能

よくある質問: 何を基準にEBSのチェックは「Okay」になるのか？どこを見ればよいのか？

Status: ディスクシステムとして正常に機能しているかのチェック
- Statusがimpaired: 致命的なエラーがある状態
State: HDD障害などのエラーチェック
- StateがError: EBSをまったく使えない状態

この結果は、ec2-describe-volume-status APIで確認できる。EBSの状態監視では、上記のとおりStatusのimpairedとStateのErrorに注意する。

（参考）ボリュームのステータスのモニタリング

前回(2013年1月)のWebinar以降の重要なアップデート

EBS 暗号化機能

EBSをAES-256で暗号化できるようになった。キー情報はAWS側で管理される。

設定方法は、ボリューム作成時にEncriptionにチェックを入れるだけ。次の点に留意する。

従来の非暗号化EBSから暗号化EBSをダイレクトに作成することはできない
ブートボリュームへの暗号化適用は未サポート
暗号化したEBSのスナップショットをアカウント間で共有しても、他のアカウントから復号できない
アタッチできるインスタンスタイプは限定的（旧世代インスタンスは適用対象でない）

EBS非暗号化からEBS暗号化への移行方法（例）

まず、EBS暗号化の適用対象外の旧タイプのインスタンスを使っている場合は、EBS暗号化に対応したインスタンスタイプに切り替える
次に、新規の暗号化EBSをインスタンスにアタッチする
最後に、従来のEBSから新規のEBSにファイルをコピーする
- 従来のEBSのスナップショットから暗号化EBSを作成することはできない
- ドライブを合わせるには、この手順の後、暗号化EBSをスナップショット化して再構成する

新しいEBS General Purpose (SSD) - GP2

EBS Volumeに3つ目のタイプとして登場した。現在デフォルトの推奨設定になっている。

容量に対する課金あり（従来と同じ）
IOPSキャパシティに対する課金なし（従来と同じ。PIOPSはあり）
IOリクエストに対する課金なし（従来と違う。PIOPSもなし）
高性能バーストというこのVolume Type独自の機能がある

GP2の詳細と特徴

ベースパフォーマンスとして1GBあたり3IOPSを保証
- 100GBの場合、300IOPS
最大3000IOPSまでバーストする
初期にバーストするので、システムの起動ボリュームなどでの利用に適する
バースト可能時間はI/O Credit残高とベースパフォーマンスに依存する
料金体系がシンプル
- 1GBあたり0.12ドル/月
- IOPSあたりの課金やIOリクエストの課金がなく、容量に対してのみ課金

容量に比例したベースパフォーマンス

どの容量を選んでも最初はMAXの3000IOPSが出る
バースト後はベースパフォーマンス（容量の3倍）になる
- 1TBを選ぶと、バーストした後も（3倍の）3000IOPSが維持される

GP2の3000IOPSにバーストする期間の算出式

計算式: 期間=クレジットバランス / (Burst IOPS - 3 x ボリュームサイズ)

容量が増えれば、バースト期間は長くなる。

コスト感を含めた3つのEBSタイプの比較

IOが低負荷のとき

GP2はMagneticに近いコストで、3000IOPSまでバーストする

IOが高負荷のとき: バースト時性能に対するコストでは、GP2が最も安い; PIOPSを使うと安定した3000IOPSが保証される

EBSの最大スループットの改善

先週発表されたEBSの改善内容について。

最大転送速度の倍増: EC2からEBSへの転送速度が倍になった: ディスク単位で最大128MB/sec（従来64MB/sec）; EBS-Optimizedで確保される帯域はEBS全体に対するものだが、この改善はディスクの単位の話
IOP（操作）の16倍増: ブロックサイズが最大256kBまで可能になった（従来16kB）; 1 IOPSで256kBの処理が可能に（従来はチャンクされて8 IOPS必要だった）

（参考）Amazon Web Services ブログ: 【AWS発表】プロビジョンドIOPS(SSD)および汎用(SSD) EBSボリュームのスループットを強化

3. コスト、まとめ

コスト

GP2: 容量課金のみ
PIOPS: 容量課金（少し高め）＋プロビジョニング課金
従来：容量課金＋IOリクエスト課金

総まとめ

EBSはEC2のデータ格納基盤
スナップショットは、バックアップだけでなく、リージョンやAZ間のデータ移行にも活用できる
GP2とスループットの改善で、ハイエンドな負荷の処理が安くできるようになった
EBSのAES-256暗号化機能によってセキュアに利用できる

Q＆A

受講者からの質問と講師の回答を、一部抜粋します。

Q: 「EBSスナップショットとは？」のページで「AvailabilityZone固定ではないため、耐久性が高い」とありましたが、具体的にどういう意味ですか？: A: EBSのディスクはAvailabilityZoneに所属するので、AvailabilityZoneに障害が起きた時、消える可能性がある。しかし、スナップショットはS3に保存されるので、S3の耐久性を持つ。という意味です。
Q: データコピーの方法はどのように使い分けるのでしょうか？: A: 移行の仕方に依存すると考えられます。マシンイメージをそのまま移行する場合は、AMI化するのがよいでしょう。マシンがすでにあって外付けデータだけをコピーする場合は、スナップショットでディスク単位に細かく刻んで移動した方が便利でしょう。
Q: EBSを暗号化した場合と通常の（暗号化していない）場合とで、性能にどれくらい違いが出ますか？: A: ~~暗号化によるオーバーヘッドは存在しません。~~Provisioned IOPSボリュームに暗号化を適用した場合、プロビジョンされる性能は、暗号化していないボリュームとほとんど変わりません。（コメントでご指摘いただき、修正いたしました）

以上です。