[awsマイスターシリーズ] elastic block store(ebs)

© 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.

AWSマイスターシリーズ Reloaded

Elastic Block Store ~基本機能から新機能まで~

2013.1.23

アマゾンデータサービスジャパン株式会社

平山毅玉川憲


2

Agenda

Ⅰ）基本編・EBS概要・EC2からのマウント・Brock Device Mapping

Ⅱ）可用性編・Snapshot概要・PublicDataset (新機能編) ・Snapshot Copy (実用編) ・可用性向上・Snapshot自動化

Ⅲ）性能編・EBS基礎性能 (新機能編) ・Provisioned IOPS (実用編) ・性能対策・性能測定

Ⅳ）監視編・Volume Status ・Auto Enable IO (新機能編) ・Volume Status for IO Performance (実用編編) ・状態性能・性能監視・容量監視

Ⅴ）まとめ・EBS価格・EBS/InstanceStore/S3との比較・まとめ


3

Ⅰ）基本編１）Elastic Block Store 概要２）EC2からのマウント３）Block Device Mapping


4

EBSの位置付け

認証 AWS IAM

モニタリング Amazon

CloudWatch

コンテンツ配信 Amazon CloudFront

メッセージ Amazon SNS Amazon SQS

分散処理 Elastic MapReduce

メール配信 Amazon SES

キャッシング Amazon Elasticache

コンピュータ処理 Amazon EC2

Auto Scale

ストレージ Amazon EBS Amazon S3

Amazon Glacier AWS StorageGateway

データベース Amazon RDS

Amazon Redshift Amazon DynamoDB Amazon SimpleDB

AWS グローバルインフラ Geographical Regions, Availability Zones, Points of Presence

ネットワーク & ルーティング Amazon VPC / Amazon Elastic Load Balancer / Amazon Route 53 /AWS Direct Connect

ワークフロー管理 Amazon SWF

Amazon DataPileline

Web管理画面 Management

Console

デプロイと自動化 AWS Elastic Beanstalk

AWS CloudFromation

IDEプラグイン Eclipse

Visual Studio

ライブラリ & SDKs Java, PHP, .NET,

Python, Ruby

Application

Service

Infrastructure

Service

Development &

Administration

AZ Region


5

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

EBS Provisioned

IOPS

EBS Standard

S3 Glacier Ephe meral Disk

IOPSが指定可能なEBS

ブロックレベルのディスク

WEB型のオブジェクトストレージ

アーカイブ専用ストレージ

EC2インスタンスの一時ディスク

揮発性非揮発性（永続化）

コスト効果 (容量あたり)

安価高価


6

Amazon Elastic Block Storeとは

EBSとは、EC2に仮想外付けされる

ブロックレベルのストレージサービス

※各コンピュートサービスのデータ基盤

サイズは1GB単位で～1TBまで

サイズ/期間/IOで課金される

各EC2インスタンスで、複数EBSを使える

詳細

データは永続的に保存される

アベイラビリティゾーン(AZ) に存在

他のEC2インスタンスに付け替え可能

バックアップから、EBSを作成可能 (他のAZに作成できる)

Region

Availability Zone - a

EBS EBS EBS

Availability Zone - b

EBS EBS

Amazon Simple

Storage Service

(S3)

EBS

Snapshot

EC2 EC2


7

EBSの利点

EC2インスタンスとは独立（疎結合）

• インスタンスタイプとディスクサイズが無関係になる

• インスタンスがTerminateされてもEBSボリュームは残る（設定による）

• 別のインスタンスに付け替えることが可能

必要に応じて作成可能（柔軟性）

• 必要になった時に必要なサイズのボリュームを作成し利用できる

スナップショット機能（利便性、耐久性）

• ディスクイメージをそのままS3に保存

• スナップショットからボリュームの複製を作成できる

• １つのボリュームからスナップショットを何度でも取得できる（世代管理）


8

EBSの基本アーキテクチャ

物理インタフェース

ファイアウォール

ﾊｲﾊﾟｰﾊﾞｲｻﾞｰ

… EC2インスタンス

OS

EBSを作成すると、ボリュームが内部的に冗長化されている。

１つのEBSをアタッチすると、EC2インスタンスから１つのデバイスとして見えるようになるが、OS側でファイルシステムで利用できるように設定が必要。

EBSはネットワーク接続型だが、ネットワークを意識しなくても良い。

アベイラビリティゾーン

リージョン

Snapshot

OSからはEBSが1つのSCSIデバイスとして認識される

セキュリティグループは意識せず。全ての通信ポートを閉じてもEBSにアタッチが可能

EBS

内部的に冗長化


9

EBSの適用箇所

OSブートディスク

としての利用

アプリデータ

D:

システムデータ

C:

EBS

EC2

EBS

Windows

OSブートディスクとデータ用ディスクは、別々のEBSを推奨

データ用ディスク

としての利用


10

EC2のOSブートディスクとしてのEBS

EBS ← 通常はこちらを用いる

寿命はインスタンスと独立している

(データは永続的に保存される)

あらゆる種類の永続的データ、ブートデータ、DBのデータ

t1.micro、及び第2世代EC2インスタンスからは必須

インスタンスストレージ (Ephemeral Disk)

寿命はインスタンスと同じ

(インスタンスを落とすとデータは消える)

インスタンスに付属して存在 →別途料金はかからないのがメリット

一時データの書き込み、低料金を活かした高度な利用

Region


Amazon Simple

Storage Service

(S3)

EBS

Snapshot

EB EBS

←Instance

Storage


11

OSによるEBS接続の制約

Linuxの場合

・仮想デバイスが認識できる範囲でアタッチが可能

・ただし、ファイルシステムによっては、総容量上限があるので、

容量上限に抵触する場合は、XFS等を活用する。

Windowsの場合

・仮想デバイスの関係でアタッチできるEBSが16までという上限制約がある

EBSをEC2にアタッチさせる際に、デバイス名を指定するが、

OSタイプとEBSタイプによって、命名の制約がある。


12

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

複数のインスタンスから同時に1つのEBSボリュームをアタッチできない

（逆に、１つのインスタンスから複数のEBSのアタッチは可能）

共有ディスク型のクラスタソフトや Oracle RACといったソリューションをそのまま利用はできない

共有ディスク構成は、NFS、GlusterFS等を活用（詳細はAppendix参照）

Region


Region


EC2:N → EBS:1 EC2:1 → EBS:N

EBS EBS EBS


13

EC2のブロックデバイスマッピング

ブロックデバイスマッピングとは、EC2のデバイスとEBSやその作成元となるスナップショットのIDを関連付けする機能

起動中のEC2に関しては、以下画面の通り、Brock Devicesで対象のデバイス名を指定することで確認が可能


14

AMIのブロックデバイスマッピング

AMIの場合は、以下画面の通り、スナップショットとのマッピングになる

外付けのデータを変更したい場合には、AMIのブロックデバイスマッピングを、AMIからEC2起動時に無効化することも可能


15

AMIのブロックデバイスマッピングの変更

AMIのルートデバイス以外のマッピングは変更可能

変更方法をAMIをLaunchする際に、Storage Device Configrationの「EBS Volumes」を変更することで実現可能

変更する対象データはスナップショットの中から選択する

EC2起動後OS側の設定も必要（例：fstabの修正、resizefsでサイズ変更）

AMIの設定・sdh→snapshot1 (40GB) ・sdj→snapshot2 (100G) ・sdc→ephemeral1

変更したい設定・sdh→snapshot1 (80G) ・sdb→ephemeral0

AMIのブロックデバイスマッピングを変更する例


16

Delete on Terminationの無効化

デフォルトでは、EC2にアタッチされたEBSは、EC2が「Stop」の場合は保持されるが、EC2が「Terminate」された際は削除されてしまう

これを防止するためには、EC2ラウンチやAMI作成の際に、Storage Device Configurationの「Delete on Termination」のチェックを外すことで実現が可能（Management Consoleにも対応）

Root VolumeのEBS 外付けのEBS

外す外す


17

Ⅱ）可用性編１）Snapshot概要２）PublicDataSet (新機能) 3）Snapshot Copy (実用編) 4) 可用性向上 5) Snapshot自動化


18

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

スナップショットとは？

• EBSボリュームの特定時点のスナップショットをS3に保存

• 2回目移行のスナップショットは差分のみS3に保存する差分バックアップ

• スナップショットの世代管理が可能

• 安価に長期保存が可能

• スナップショットからいくつでもAZ間でもEBSボリューム作成・復元可能

• 他アカウントと共有設定も可能

• AZ固定ではない

• EBSのサイズ変更もスナップショット活用により実現可能


19

まず伝統的差分バックアップのおさらい

障害発生時のリカバリでは、DISK交換し全分をまず戻して、

差分を順番にリストアしていきます

初回 2回目 3回目

A A B C

A B C

バックアップストレージ 10G

1G

1G

計2G ←変更差分

←変更差分

計2G

初回は全分１Gが取得 2回目は差分１Gのみが取得

3回目は2回目との差分１Gのみが取得

A

1G 1G

障害

Diskを物理交換

A B C

全分差分差分


20

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

S3への連携は差分で、格納は全分で行われる

EBS 10G

EBS 10G

EBS 10G 初回

Amazon Simple Storage Service (S3) に実ファイルが格納

2回目 3回目

A

A

B B

B

C

C

A B B C

スナップショットの概念

1G

1G

1G 1G 1G

計1G

計1G 計2G

←変更差分

←変更差分

計2G

初回は全分１Gが取得 2回目は差分１Gのみが取得

3回目は2回目との差分１Gのみが取得

スナップショットの概念として、各時点の全分が確保される。

S3に格納される実ファイルベースではスナップショットに紐づくファイルを差分で管理される。 (利用容量ベースで合計3G)

連携は差分


21

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

戻したいスナップショット時点に全分方式でリストアすることが可能

(当然Diskの物理交換も不要で、EBSの特徴的な機能)

EBS 10G

EBS 10G

EBS 10G 初回

Amazon Simple Storage Service (S3) に実ファイルが格納

2回目 3回目

A

A

B B

B

C

C

A B B C

スナップショットの概念

1G

1G

1G 1G 1G

計1G

計1G 計2G

例えばこのスナップショットを削除

計2G

障害 EBS

10G

B 計1G

2回目スナップショットの取得時点に戻したい場合

残りのスナップショットに無いデータAは削除される

2回目時点


22

EBSボリュームのサイズ変更

一度作成したEBSボリュームのサイズ変更は動的には変更できない。

ただし、スナップショットを取得して、ボリュームサイズを変更してEBSを作成することで実現可能。

■具体的な手順（EBS付け替えパターン）

EBSスナップショット取得

スナップショットから新ボリューム複製。その際に、新たなボリュームサイズを指定。アベイラビリティゾーンは変更前のEBSボリュームと合わせる

変更前のEBSボリュームをインスタンスからデタッチ

新ボリュームをアタッチ

OS内でファイルシステムのリサイズ処理、マウント

（ext4の場合、resize2fsでリサイズが可能。）

不要であれば、旧ボリュームを削除

Region


Amazon Simple

Storage Service

(S3)

Snapshot

EB EBS

EBS


23

EBSスナップショットにおける OSオペレーションの留意点

確実に最新のスナップショットを取得するには、 OSのメモリ上のデータをEBSディスクに同期した後に、静止点を保った形で、実行するようにする。（更新の多いEC2インスタンスの場合）

デバイスに対して、ファイルシステムを作成（フォーマット）するとEBS内のデータが消えてしまうので、Snapshotのデータを戻す場合は、フォーマット済のデバイスにアタッチ後、マウントする。

OS EBS Snap

shot

①Sync等でメモリデータを EBSに書き出し

②データ更新されない状態を保つ（Detach等）

③Snapshot の実行

OS

/dev/sdf フォーマット済

Snapshot

/dev/sdg フォーマット未

EBS

Snapshot からEBS作成

data data

EBSをアタッチ後、マウント実行

EBSをアタッチ後、フォーマットをかけるとデータが消えてしまう。


24

Create Image from EBS snapshot

SnapshotからAMIを作成する機能

Snapshot画面の「Create Image」を選択し、EC2（OS）に関連するCPUアーキテクチャ、Kernel、Ramdisk、を正しく入力することで完成する

注）LinuxのAMIは起動可能ですが、WindowsのAMIは起動できません


25

スナップショットとAMI化のフロー

EBSベースAMIの場合、AMIはEBSのスナップショットと何が違うのか？

→ データの概念としては同じ。違いはEC2インスタンスとの関連有無。

EBS Root

EBS Data

EBS Root

EBS Data

AMIの場合 →EC2起点

AMI化

EBS Root

EBS Data

Launch

EBS Root

EBS Data

Snapshotの場合 →EBS起点

Snapshot

Snapshot

Root

Data

Create Volume

Create Volume

EBS Root

EBS Data

Create Image

そのままEC2が起動

Root Data


26

パブリックデータセット

AWSエコシステムを活用したパブリックドメインと著作権が無い利用可能データの共有サービス

(詳細：http://aws.amazon.com/jp/publicdatasets/)

AMIがEBS snapshotベースでソフトウェアをPublicに共有するのに対して、パブリックデータセットはEBS snapshotベースで価値のある“データ”をPublicに共有する。

代表的なデータは以下の通り。

生化学（ヒトゲノム計画）、化学（PubChem）、

経済学 (国勢調査、労働統計、等）、百科事典（Wikipedia等）

オペレーションは、Snapshot画面からVeiwの「Public Snaphosts」を選択すると利用可能なパブリックデータセットが表示される

http://aws.amazon.com/datasets から取得でも可

http://aws.amazon.com/datasets

http://aws.amazon.com/datasets


27

Snapshotの公開方法

EBSタブで対象のSnapshotを選択し「Permission」で変更が可能。

公開範囲は、以下の2通り

①全公開の場合「Public」を選択

↓ 全てのAWSユーザーが利用可能

②特定AWSアカウントのみ公開の場合「Private」を選択し、公開する

AWSアカウントを指定する ↓

指定したAWSユーザーのみ利用可能


28

新機能Snapshot Copyとは？

作成したSnapshotをコピーする機能

※Region内コピー、Region間コピー、の両方可能（初のRegion間機能）

対象はEBS、MarketPlace、VM import経由のAMI、StorageGateway

のスナップショットを含む

※RDSのスナップショット、AMIのコピーは不可 (2013年1月23日時点)

「Create Image from EBS snapshot」を使えばLinuxのAMI化後の起動は可能

Region : A

Availability

Zone - a

Snapshot

EBS

Availability

Zone - b

Region : B

Availability

Zone - a Availability

Zone - b

Internet

Snapshot

Copy

Snapshot Copy

EBS

AMI

Create EBS

from Snapshot

Create AMI

from Snapshot


29

Snapshot Copyの操作

Snapshotを選択し「Copy」をクリック後、「Copy Snapshot」でコピー先のリージョンを選択し実行が可能

複数スナップショットの並行コピー処理も可能

ManagementConsloleでは送信元リージョンからPush

コマンドラインでは送信先リージョンからPullで実行する点に注意

$ ec2-copy-snapshot -r 送信元リージョン -s 送信元スナップショットID

（-region 送信先リージョン）←カレントが送信先リージョンでは無い場合

送信元からPush

送信先からPull

リージョン間コピーの進行状況が確認できる


30

リージョン間Snapshot Copy の用途

地理的な拡大・グローバル展開

新しいリージョンでアプリケーションをローンチしたい場合

移行

あるリージョンから別のリージョンにアプリケーションを移行したい場合

DR(ディザスタリカバリ)

データの消失や復旧時間を最小化するために、一定の間隔で地理的に

異なる場所にデータやログファイルをバックアップしたい場合


31

EBSスナップショット取得による可用性の向上

EBSボリュームの持続性は、①ボリュームのサイズと②最後にスナップショットを作成してから変更されたデータ量、の2要素に依存。

変更データ量に対して、定期的にスナップショットを取得することで

可用性は向上する

■故障率の指標

Amazon EBS スナップショットを撮ってから 20 GB 以下の変更データを処理するボリュームでは、0.1％～0.5％の年間故障率（AFR）が予測

（※商用のハードディスクでは4％程度が標準）


32

可用性を向上する構成

EBSは内部的に冗長化しているため、RAID構成を組んだとしても、可用性は大きく向上しない

OSレベルのソフトウェアRAIDを組むこと自体は可能

スナップショットの頻度を上げた方が可用性は向上（運用面の考慮が必要）

$ mdadm --create /dev/md0 --level=M --chunk=64 --raid-devices=N N個のデバイス名

LinuxでRAIDを組むコマンド例 RAIDタイプを指定

EBS

EC2

OS

EBS

EBS

EBS

EBS

EBS

EBS

EBS

Act

RAID5

内部冗長化

Act Act

Stanby (Parity) Stanby Stanby Stanby Stanby


33

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

EBSはクラウドサービスのため、ストレージ運用で最も頻度が高く面倒なDiskの物理交換が不要なため、運用負荷は大きく軽減される

ただし、スナップショット定期取得等の運用は発生するため、以下のような自動化設定を組み込むと運用が効率化される

自動化設定例

#認証情報

AWS_PRIVATE_KEY=**

AWS_CERTIFICATE_KEY=** ← IAM-ROLEを活用し簡素化しても良い #起動条件（任意）・・・・・ ← 先行処理やファイル連携契機等の条件を入れても良い #スナップショット作成 ec2-create-snapshot “volume-ID” ← IDはパラメータ渡しでも良い

SDK対応プログラム言語でプログラム作成

①OSのスケジュール管理機能でスケジュール化（Linux：Cron 、Windows：タスクスケジューラに組込） ②ジョブスケジューラに組み込みスケジュール化


34

Ⅲ）性能編１）EBS基礎性能（新機能編）２）Provisioned IOPS （実践編） 3）性能改善 4）性能測定


35

EBS基礎性能

EBSのIOPS値は100を目標に定められているが、クラウドはリソースシェアリングモデルのため、IOPSの確保が難しい。

物理インタフェース

ファイアウォール

ハイパーバイザー

Smallタイプ

Large タイプ

…

Smallタイプ

Linux Linux Windows

EBS

EBS

EBS

Net

work

物理的に確保されるネットワーク帯域

帯域をシェアするため、ピーク性を考慮した帯域確保が難しい


36

新機能Provisioned IOPSとは？

IOPS数が指定できるEBS

EBS-Optimizedインスタンスを前提としている

Volume作成時にStandardかPIOPSを指定する

IOPS値の指定は100～2000で1刻みが可能

(StandardなEBSのIOPSは、約100程度)

Root VolumeのEBSもPIOPSを使用可能

OSからは通常のEBSと同じように見える

EC2の作成時に、合わせて作成可能

合計20TB, 10,000IOPSの制限がある

申請にて制限解除可能

36

EBS

IOPSとは？

Input Output per Second の略で、「1秒あたりのディスクI/O数」を意味し、DISK性能の指標値の1つ（算出式） 1 回転待ち時間＋シーク時間＋転送時間

Volume TypeにProvisioned IOPSを指定

IOPSの値を指定


37

Provisioned IOPSの利用上留意点

IOPSはDiskサイズの10倍を超える高い比率を指定できない

現状、一部使えないAZがある場合があるので、事前に確認しておく

EBS 10G

Region

Availability

Zone - a

EBS

EBS 200G

IOPS 100まで

IOPS 上限値の 2000まで

Availability

Zone - b

PIOPS EBS

Availability

Zone - c

PIOPS EBS

Multi-AZ構成

PIOPS 不可

PIOPS 可

PIOPS 可

×10

×10


38

EBS-Optimized Instanceとは？

EBS用にネットワーク帯域を最適化

確保される帯域は、500Mbpsと1000Mbpsが選択可能

Standard EBS使用時も効果がある

“EBS-Optimized Instance” と “Provisioned IOPS”を組み合わせることで、I/O値の最適化が可能

現在、下記の3つのInstance Typeのみ使用可能

M1.large [2 ECU x 2core, 7.5GB]

M1.xlarge [2 ECU x 4core, 15GB]

M2.4xlarge [3.25 ECU x 8core, 68.4GB]

EC2

EC2 normal

Net

work

PIOPS EBS

PIOPS EBS

EC2

通常 EBS-Optimized-Instance

EC2 EBS-

Optimized Net

work

PIOPS EBS

PIOPS EBS

EC2

ストレージエリアネットワーク

通常ネットワーク



EBS向け帯域と競合 EBS向け帯域を専用に確保


39

EBS-Optimized Instance有効化

対応するInstance Typeを選択すると、チェックボックスが有効になる。


40

PIOPSとEBS-Optimizedの組合せ

EC2 normal

Net

work

EBS EBS

EC2



EC2 EBS-

Optimized

Net

work

EBS EBS

EC2



EC2 normal

Net

work

PIOPS EBS

PIOPS EBS

EC2

EC2 EBS-

Optimized

Net

work

PIOPS EBS

PIOPS EBS

EC2





①通常 ②EBS-optimized

③PIOPS ④PIOPS＋EBS-optimized

P IOPS

EBS-optimized

安定性の向上

高速推奨しない

（※PIOPSがEBS-Optimizedを前提とするため）

高速なIO の安定化

IOの安定化


41

Provisioned IOPS の確保範囲

（前提条件）

EBS-optimizedを有効化（PIOPSはEBS-optimizedインスタンスを前提）

ブロックサイズは16K以下

1年間で、指定のIOPSの±10％の範囲を99.9％の確率で確保

IOPS 1000

IOPS 900

IOPS 1100

確率的に1000回のI/Oリクエストで999回はこの範囲に納まる

-10％ +10％


42

16Kバイトを超えるブロックサイズの場合のIPOS換算

16KバイトまでのIOPSの保障になるため、ブロックサイズが16Kバイトを超える場合は、IOPS値を16Kバイトに換算する必要がある。

ブロックサイズ

4K 8K 16K 32K 64K

指定のIOPS

1000 1000 1000 1000 1000

実際のIOPS

1000 （900-1100）

1000 （900-1100）

1000 （900-1100）

500 （450-550）

250 （225-275）

PIOPS値がそのまま反映 16÷指定のブロックサイズ値をPIPOS値に掛けて換算する


43

複数EBSのRAID０構成によるIOPSの向上

複数のPIOPSタイプのEBSでストライピングでRAID構成（RAID0）を組めば、指定したIOPS値の合計の性能が確保される。

PIOPS EBS

200G

PIOPS 上限値 2000

PIOPS EBS

200G

PIOPS EBS

400G



EC2 EBS-

Optimized

EC2 EBS-

Optimized

RAID0 構成を組む

合計 2000 IOPS 合計 4000 IOPS

1 EBS（400G×１） 2 EBS（200G×2）

Provisioned IOPSと組合せすることでI/Oの安定化が可能


44

性能対策～基本編～

EC2とEBS間のネットワーク帯域幅が高速化要因

①EC2インスタイプ

インスタンスタイプが大きいほど総合的なI/O性能は上がる

アタッチ数が多いほど総合的なI/O性能は上がる

②アタッチ数

EC2 Small/ Medium

詳細は以下のインスタンスタイプのI/O性能を参照

http://aws.amazon.com/jp/ec2/instance-types/

EC2 Large/

ExaLarge

EBS

EBS

低I/O

高I/O

EC2

EC2

低I/O

高I/O

EBS 40G

EBS 10G

EBS 10G

EBS 10G

EBS 10G


45

性能対策～応用編～

ただし、クラウドのネットワークはリソースシェアード型なので、ネットワーク帯域保障が難しい

EBS-OptimizedとProvisioned IOPSを利用し帯域確保

①平均キューの長さ

Provisioned IOPSの性能効率化TIPS

②初回アクセス時のIOPS

IOPSが上がるほど、ある程度待ちキューがあった方が性能が出る

IOPS 平均キュー

200 1

400 2

：：

2000 10

性能指標

Cloudwatchの「Ave Queue Length (Ops)」で確認可能

デバイスに初回にアクセスする際は5~50％程度IOPSが落ちる ↓ 【対策】予め全てのブロックデバイスに読み書きを行っておくPre-warmが可能

LinuxでのPre-warm例

③Snapshot時のIOPS

スナップショット取得時は、IOPSが落ちる ↓ 【対策】更新処理の無い時間帯に取得する運用対処

$ dd if=対象デバイス of=/dev/null


46

性能測定方法

詳細については、実際にベンチマーク測定頂くのがベスト

各プラットフォーム向けに以下のベンチマークツールを推奨している

・OS(Linux,Windows) : Fio

・Oracle Databese(Linux,Windows) : Oracle ORION

・Microsoft SQLserver(Windows) ： SQLIO

各種ツールでの検証方法

http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/EBSPerformance.html#benchmark_piops

FIOによる分析方法

https://www.linux.com/learn/tutorials/442451-inspecting-disk-io-performance-with-fio/

http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/EBSPerformance.html

http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/EBSPerformance.html
















47

Ⅳ）監視編１）EBS Volume Status機能概要２）Auto Enable IO機能 (新機能編) ３） EBS Volume Status for I/O performance (実用編) 4）状態監視 5）性能監視 6）容量監視


48

EBS Volume Status機能とは？

EBSのデータ整合性という観点でEBSの状態を内部的に自動で確認する機能

Status Checksタブの「Volume Status」で確認可能

成功時は「OKay」、失敗時は「impaired」が表示され

デフォルトでEBSへのI/Oが中断される

Linuxの場合fsck、Windowsの場合chkdsk、でOS側

からもデバイスの整合性を確認することを推奨

■留意点

EBSディスクのハードエラーの検知（内部的なミラー

ディスクも利用不可）は、Status Checksではなく

Stateの「Error」で確認する

ハードエラー時はStatus Checksはできない

↓エラー ↓整合性


49

Auto Enable IO 機能とは？

EBSのデータの整合性が取れなくなっても、 EBSへのI/O処理を中断しないで継続する機能

データの整合性よりディスクの可用性を優先する場合に使用する

この設定の場合、ステータスチェックは常に「Okay」になるが、整合性が取れなくなった場合には「Auto I/O enable」のイベントが生成される

チェックを入れる


50

新機能EBS Volume Status for I/O performanceとは？

従来の整合性チェックのみではなく、I/Oのパフォーマンス状態もチェックする機能（2012年11月後半に追加）

Provisioned IOPSに対してのみ有効

I/O performance で発行されるイベントは以下の4種類

・「Normal」 IOPS値が指定IOPSの90％以上の場合

・「Degraded」 IOPS値が指定IOPSの90％を下回る場合

・「Severely Degraded」 IOPS値が指定IOPSの50％を下回る場合

・「Stalled」 I/Oが発生しない状態の場合


51

IOPS用メトリックの追加

Provisioned IOPSに対してのみ有効なCloudwatchメトリックを2つ追加

Volume Throughput Percentage

EBSボリュームのプロビジョンされたIOPSに対して実際に出たIOPSの割合

（理論上は、90%以上の値に年間99.9％以上の確率で確保される）

Volume Consumed Read Write Ops

一定期間に実行された読み込みと書き込みの操作の合計量


52

Status Checksのイベント確認

Status Checks で発生するイベント一覧は、以下の通りで確認できる

(※Cloudwatchのアラート設定とは別)

$ ec2-describe-volume-status （ボリューム名）

■コマンドライン Status情報とイベントをまとめて見ることが可能

■Management Console EC2の「Event」タブで、EC2のイベントと合わせて表示される


53

Status Checksとイベントの関係性

Performance I/O Eventが追加されたことにより、Enable I/O Eventも含めた総合的なStatusは以下のような関係になる

Status Enable I/O Event

Performance I/O Event

Okay Enabled Normal

Warning Enabled Degrated (<90%) Severely Degrated(<50%)

Impaired Disabled Not Avaibable

Enabled Stalled(I/O無)

Insufficient-Data Enabled Insufficient-Data

Insufficient-Data

PIOPS向けに新設 →

※Insufficient-Dataとは、Status Check処理中の意味


54

状態監視

Amazon Web Services

Guest OS

PIOPS EBS

Middleware

Application

EC2 EBS-

Optimized

Hypervisor

EC2

OSまたはミドルウェアのファイルシステム


通常イーサネットネットワーク

■基本的な考え方 ■業務的な監視 OS・Middleware・Application から監視が必要

■AWS内監視 AWSの機能で監視

State 意味

Creating EBS作成中

Available EBS利用可

In-use EBS使用中

Deleting EBS削除中

Deleted EBS削除済

Error EBS利用不可

Status 意味

Okay EBS I/O正常

Warning EBS I/O劣化

Impaired EBS I/O不可

Insufficient-Data

EBS I/O測定中

①EBS生死監視の観点の監視

②EBS I/O可否の観点の監視

ここを監視

Consoleの「State」、 ec2-describe-volumesで確認

Consoleの「Status」、 ec2-describe-volume-statusで確認


55

性能監視

EC2→EBS間の性能については、Cloudwatchを利用する。

EC2のディスク監視項目はインスタンスストアを示しているので、EBSについては、EBSボリュームのディスク監視項目を確認すること！（よく勘違いする部分）

「Read（読み取り）」と「Write（書き込み）」で項目が分かれているので、ボトルネックの洗い出しには有効的であるが、全体的には合計値で評価すると良い

要件に沿って閾値を決めてアラート設定すると検知が可能

PIOPS EBS

EC2 EBS-

Optim ized

Attribute 単位意味 Read Write

Bandwidth KiB/s 実際に消費した帯域幅 ○ ○

Throughput Ops/s 1秒あたりに処理回数 ○ ○

Size KiB/op 1リクエストあたりのデータ量 ○ ○

Latency ms/op 1リクエストあたりの遅延 ○ ○

Queue Length Ops キュー滞留数 ○

Time Spend Idle % 処理待ち比率 ○

Throughput Percentage ％ PIOPSに対して実際に出たIOPSの割合 ○

Consumed R/W OPs Count PIOPSに対しての読み書き回数 ○

Read

OS

Write


56

容量監視

現状はCloudwatchから監視ができない

OSやDBの標準の監視機能を用いて監視することを推奨

そもそも業務視点からOSやDBが利用サイズを決めるため、

OSやDBにおける論理的な監視できれば充足

EBS

100G

EC2

OS

Write

Directry Size：50G

50G

50G

エラー

OS上のディレクトリにおけるバーティション容量を超えればエラー ↓ OSを監視

EBS

100G

EC2

OS

Write

表領域 Size：50G

50G

50G

エラー

OS上で容量監視ができれば、Disk 側から不要

①OSの場合 ②DBの場合

DBMS DB上の表領域における記憶領域の容量を超えればエラー ↓ DBを監視

OS上で容量監視ができれば、Disk 側から不要

論理論理

物理物理


57

Ⅴ）まとめ１）EBSの価格２）EBS/Instance Store/S3との使い分け３）総まとめ


58

EBSの価格１）EBSのデータ量月あたりの作成されたEBS容量･EBS内の実データ量ではない･EC2アタッチされたEBS容量ではない･月内での容量変更は1時間単位で反映例１）３ヶ月間を100G利用例２）1か月で1時間のみ2倍に拡張３）S3 Snapshotデータ量実データの総量になる例５）初回に20G、月末に更新差分２G

100G

12＄ 12＄ 12＄

100G

12＋12×1/30/24=12.015＄

200G

2＄ 2.2＄ 2.4＄

20G 22G 24G

2） IOPS 通常EBS月間の総累積I/O。PIOPSはIOPS期間累計例３）通常のEBS ・月間で10億I/O → $12 ・15日で10億I/O → $12 例4）PIOPS ・月間100IOPS のPIOPS利用 → 100×0.12=$12 ・15日200IOPS のPIOPS利用 → 200×0.12×15/30＝$12

I/O数はCloudwatchやIostatで取得しても良いが「利用レポート」のCSVが実測I/O値 (※この値を元に課金される）


59

EBS/Instance Store/S3の使い分け

Elastic Block Store

Instance Store (Ephemeral Disk)

Simple Storage Service (S3）

パフォーマンス高高中

データの永続性中低高

弾力性/拡張性手動無自動

可用性中～高(snapshot) 低高

冗長性 AZ内無 Region内

インターフェース OS(files system) OS(file system) HTTP(REST/SOAP)

サイズ制限 1EBS：1GB – 1TB 160G – 3.3TB 1オブジェクト：5TB

価格高（EC2内に含む）安

※価格についてはEBSはアサインされたディスク量に課金されるため、ディスク内のデータは低い利用率を前提とする。


60

Elasitc Block Store 総まとめ

EBSは、EC2のAMIやRoot Deviceにも使われており、各種コンピュートサービスのデータ格納基盤である

スナップショットは、バックアップだけでなく可用性向上やリージョン間やアベイラビリティゾーン間のデータ移行にも活用可能

性能を上げたい場合は、インスタンスタイプを上げるか、EBSの並列化、を検討する

性能を更に高度に上げた状態でI/Oを安定化させたい場合は、PIOPSをEBS-Optimizedインスタンスと合わせて活用する

Status Checkを活用することでEBSのデータ整合性やIOPSの監視が実現できる


61

Appendix Material

参考資料

• Amazon Elastic Brock Store Developer Guide http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AmazonEBS.html

• Amazon EBS FAQ http://aws.amazon.com/jp/ec2/faqs/

Elastic Brock Store の箇所

• Amazon EBS 価格 http://aws.amazon.com/jp/ec2/pricing/

Elastic Brock Store の箇所

http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AmazonEBS.html



http://aws.amazon.com/jp/ec2/faqs/

http://aws.amazon.com/jp/ec2/faqs/

http://aws.amazon.com/jp/ec2/pricing/




62

Appendix


63

AMIを構成するEBS

・通常はこちらを用いる

(2009年後半に追加)

・ EC2に停止/終了のオプ

ション有

・停止しても、ファイル

システムは永続する

EBS-Backed AMI

AMI (Amazon Machine Image EC2のコピーをとりテンプレート化

することで、再利用可能

S3-Backed AMI • EC2開始当初からある

• EC2に停止のオプションはない

• EC2を終了するとデータは消える


64

Root DeviceがEBSであるかの確認方法

EC2の場合 AMIの場合

「Describe」タブの「Root Device Type」を確認

AMI選択一覧画面の「Root Device」を確認

若しくは、画面右上の「Show/Hide」で「Root Device」を表示させる


65

EBSをEC2にアタッチさせるデバイス名

OS インスタンスストア用

ルート用EBS 外付用EBS

Linux / x86版Solaris

/de[b-e]

/dev/sda (推奨)/dev/sd[f-p] /dev/sd[f-p][1-6] (可能)/dev/sd[a-z] /dev/sd[a-z][1-15] /dev/hd[a-z] /dev/hd[a-z][1-15]

Windows xvd[a-e]

/dev/sda[1-2]

(推奨) xvd[f-p] (可能) xvd[a-p] /dev/sda[1-2] /dev/sd[b-e]


66

EBS AMIの作成方法

該当のEC2イスタンスを選択し「Create Imange(EBS AMI)」を選択することで、EBS AMIの作成が可能

AMI取得の際は、EBS内のデータが更新されない静止点を確保する必要があるため、EC2インスタンス状態を「Stop（停止）」にすることを推奨


67

EBSをNFS経由で利用する場合

NFSのような共有ストレージとして使う場合には、別途EC2上にNFSサーバを構成することで実現可能

Region


NFS サーバ

EBS

NFS クライアント

NFS クライアント

参考：クラウドデザインパターン NFS sharing pattern NFS replica pattern

①NFSクライアントに共有したいディレクトリにEBSをマウント ②/etc/exportsファイルで共有したいディレクトリを設定し、 NFSクライアントに公開

③共有ディレクトリをNFSマウント

NFS マウント

NFS構成の課題

１）大容量共有ファイルの場合、ネットワーク帯域の消費からレイテンシーの発生

→・NFSサーバのインスタンスを大きいものにする

・頻度の高いデータはクライアントEBSに同期する。

２）NFSサーバがSPOF（単一障害点）

→・NFSサーバのEBSスナップショットを定期的取得

・障害時運用の整理も必要。

（※詳細理由は、後ページで説明）

共有データ

↑ ↑

実質的な共有ディスク

EBS

EBS (ﾚﾌﾟﾘｶ)

EBS EBS

EBS

↑ レプリカ

対応する場合


68

EBSをリプリケーションして利用する場合

それぞれのEBSをマウントしたEC2からソフトウェアベースでEBSのデータを一方向リプリケーションして、データ同期を実現

この場合、AZを跨いだ構成も可能

代表的なソフトウェア

・DRBD → ブロックデバイスレベルでのミラーリングを実現

・GlusterFS → AWS上でレプリカ設定によるミラーリングをサポート

・ClusterPro → NEC社がAWS上でのミラーリング及びHAをサポート

Region


EBS EBS

（参考資料）AWSで始めるGlusterFS http://www.slideshare.net/c95029/awsgluster-fs-20120726public-14045270 （参考資料）CLUSTERPRO3.1ｘ AWS向けHAクラスタ構築ガイド http://www.nec.co.jp/pfsoft/clusterpro/clp/doc/material/X31_PP_AWS_JP_01.pdf


Replication

http://www.slideshare.net/c95029/awsgluster-fs-20120726public-14045270









http://www.nec.co.jp/pfsoft/clusterpro/clp/doc/material/X31_PP_AWS_JP_01.pdf





69

EBSボリュームの確認手順

EC2タブ->Volumesで確認

• リージョンに注意

• サイズ、アタッチされているインスタンス、アベイラビリティゾーンを確認


70

EBSボリュームの新規作成手順

「Create Volume」で新規ボリューム作成

• サイズ、アベイラビリティゾーンを指定

• Snapshotは ---No Snapshot ---を選択

• 作成後、ボリューム一覧に、指定したサイズのボリュームが表示される

• State が「available」になれば作成完了


71

EBSボリュームのアタッチ手順

Available状態のボリュームを右クリック->「Attach Volume」

アタッチ情報を入力

• アタッチ先インスタンス (ボリュームと同じゾーンのインスタンスから選択）

• アタッチ先デバイス (例： Windows : xvdf, xvdg, … ,

Linux : dev/sdf, dev/sdg, … )


72

EBSボリュームのアタッチ確認手順

アタッチ後のボリュームを確認

• Attachment ：インスタンスIDとデバイスパス(例： xvdf )

• State ： in-use に変わっていること

アタッチ後の設定

• ボリュームを使用するには、アタッチ先インスタンスで各種設定が必要

• フォーマット（新規ボリュームの場合）、マウント等


73

EBSボリュームのアタッチ確認手順

アタッチ後の設定完了後

• アタッチ先インスタンスの詳細情報「Block Devices」に追加したデバイスパスの情報が表示される


74

コマンドラインでのEBSアタッチ手順

EBSのAPIは、EC2のAPIツールの中に含まれていますので、必要に応じてダウンロードしてセットアップをしてください。http://aws.amazon.com/developertools/351

EBSを作成します。

作成されたEBSがあることを確認します。

EBSを指定のEC2にアタッチします。

$ ec2-create-volume –z リージョン名 –s サイズ

$ ec2-describe-volumes (ボリュームID)

$ ec2-attach-volume ボリュームID –i インスタンス名 –d デバイス名

注）describeコマンドでは、Volumeが複数形になるので注意してください。

http://aws.amazon.com/developertools/351




75

$ df

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/xvda1 8361916 1167464 7110588 15% /

tmpfs 304800 0 304800 0% /dev/shm

/dev/xvdf 31381340 593696 29214780 2% /mnt

Linuxからのマウント手順

アタッチされたボリュームのデバイスパスを確認（例：/dev/sdf)

ボリュームをフォーマット

最新版のLinuxを利用の場合は、ファイルシステムに最新のext4を選択をお勧め

ext4に対応していない古いバージョンのLinuxを利用の場合はext3を利用

※基本的には任意のファイルシステムを選択可能。mkfs –tオプションを利用しても可能。

フォーマットしたボリュームをマウント(例： /mntにマウントする場合)

マウントされたこと、およびサイズ等をdfコマンドで確認

$ ls /dev/sd*

/dev/sdf

$ mount /dev/sdf /mnt

$ mkfs.ext4 /dev/sdf

$ mkfs.ext3 /dev/sdf

注）AmazonLinux等、管理者権限ではない実行ユーザーで実行する場合はSudoを付けた実行が必要


76

Windowsからのマウント手順

アタッチされたディスクを確認し、プライマリパーティションを作成

パーティションをフォーマットし、ドライブレターをアサイン

（この場合、ファイルシステムはデフォルトのNTFSになります。）

パーティションが作成されたこと、およびサイズ等をコマンドで確認

DISKPART > SELECT PARTITION 1

DISKPART > FORMAT QUICK

DISKPART > ASSIGN LETTER=d

C:\Diskpart

DISKPART > LIST DISK

DISKPART > SELECT DISK 1

DISKPART > ONLINE DISK

DISKPART > ATTRIBUTES DISK CLEAR READONLY

DISKPART > CREATE PARTITION PRIMARY

DISKPART > LIST VOLUME

Volume ### Ltr Label Fs Type Size Status Info

---------- --- ----------- ---- ---------- ------- --------- ------

Volume 0 C NTFS Partition 29 GB 正常システム

* Volume 1 D NTFS Partition 19 GB 正常

参考）GUIの「スタート」→「管理ツール」→「サーバマネージャー」で設定しても可能


77

EBSスナップショット取得

スナップショットを作成したいボリュームを右クリックし「Create Snapshot」を選択

スナップショット名を入力して作成


78

EBSスナップショット確認

作成したスナップショットが表示されていることを確認

スナップショット元の Volume IDとCapacityも確認

Completed になれば取得完了


79

EBSボリュームの復元

「Create Volume 」を選択

スナップショットID, スナップショットのサイズ、復元したいアベイラビリティゾーン(重要)を指定

Volumesに該当ボリュームが作成されていることを確認


80

コマンドラインでの EBSスナップショット手順

EBSのAPIは、EC2のAPIツールの中に含まれていますので、必要に応じてダウンロードしてセットアップをしてください。http://aws.amazon.com/developertools/351

指定のEBSのスナップショットを作成します。

作成されたスナップショットがあることを確認します。

スナップショットから新たにEBSボリュームを作成します。

$ ec2-create-snapshot ボリューム名

$ ec2-describe-snapshots (スナップショットID)

$ ec2-create-volume –z リージョン名 –s サイズ –-snapshot スナップショットID

注）describeコマンドでは、Snapshotが複数形になるので注意してください。





81

EBSスナップショットによるリストア例

①デバイスをマウント

②dataファイルに「snapshot before」と追記

③snapshot 取得

④dataファイルに「snapshot after」と追記

⑤snapshot 取得

⑥beforeのみのsnapshotからEBS作成

⑦before状態のEBS をアタッチ

⑧スナップショットから戻されたデバイスをマウント

⑨dataファイルが「snapshot before」のみであることを確認


82

EBSボリュームの復元（リカバリ）・複製

※事前にEBSスナップショット取得

①復元スナップショット元のボリュームに問題があった場合、スナップショットからボリュームを復元することで、バックアップからのリカバリを実現

②複製スナップショットからボリューム作成。その際に、アベイラビリティゾーンを指定。複製したボリュームは任意のインスタンスにアタッチして利用可能アベイラビリティゾーンを指定することで、別アベイラビリティゾーンに複製を作成することも可能

Region


Amazon Simple

Storage Service

(S3)

Snapshot

EB EBS


EBS EBS

①復元 ②複製


83

ファイル単位でのバックアップ

EBSは内部的にミラーリングされているため、遠隔地バックアップは物理的に違うAZ（アベイラビリティゾーン）への格納が要件となる

基本的にはスナップショットの取得を推奨となるものの、定時点におけるEBS単位でのブロックレベルのバックアップになってしまう

対策

①ファイル単位でのバックアップ ②最新時点のオンラインバックアップ

Region : A

Availability

Zone - a

EBS

Availability

Zone - b 障害

EBS

Amazon Simple

Storage Service

(S3)

File File

File

Region : A

Availability

Zone - a

EBS

Availability

Zone - b 障害

Amazon Simple

Storage Service

(S3)

EBS EBS EBS

Rsync Scp Backup

Replicaion

(Backup Server)

OSの転送・同期機能やBackupソリューションを活用し、対応する

サードパーティのレプリケーション機能等を活用し、対応する

[awsマイスターシリーズ] elastic block store(ebs)

Documents