20140315 jawsdays i2 instance io performance

© 2014 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.

Jaws DAYS 2014 AWS Technical Deep Dive

「I/Oを極めろ！」I2インスタンスパフォーマンス

2014年3月15日

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

ソリューションアーキテクト松尾康博

パートナーソリューションアーキテクト松本大樹


自己紹介

• 名前

– 松尾康博

• 所属

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

– ソリューションアーキテクト

– ビッグデータ、HPCのお客様を担当

• 経歴等

– 1994 九州大学計算機センターのジョブスケジューラ改良

– 2001 SI企業にて基幹系向け分散ミドルウェアの開発・導入

– 2006 Webベンチャー(CTO)

– 2009 SI企業にて仮想化基盤の研究・調査・構築・運用

– 2011 現職


Agenda

ブロックデバイスの概要I2 のI/O性能検証結果エフェメラルディスクの応⽤例

1

2

3

© 2014 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.5

ところで・・・AWS上でストレージはいくつある？1. Simple Queue Service2. Instance Store3. Elastic Block Store(EBS)4. AWS Storage Gateway5. Amazon Simple Storage Service(S3)6. Amazon Glacier7. Amazon ElastiCache8. Amazon SimpleDB9. Amazon DynamoDB10.Amazon Relational Database Service(RDS)11.Amazon Redshift12.Amazon Kinesis


ブロックストレージのサービスAWS上でストレージはいくつある？

1. Simple Queue Service2. Instance Storage3. Elastic Block Store(EBS)4. AWS Storage Gateway5. Amazon Simple Storage Service(S3)6. Amazon Glacier7. Amazon ElastiCache8. Amazon SimpleDB9. Amazon DynamoDB10.Amazon Relational Database Service(RDS)11.Amazon Redshift12.Amazon Kinesis

EC2で利⽤可能な基本的なEC2で利⽤可能な基本的なブロックストレージ


EC2からの接続方法から見たストレージ分類

EBSProvisioned

IOPS

EBSProvisioned

IOPS

EBSStandard

EBSStandard

S3 GlacierEphemeralDiskEphemeralDisk

IOPSが指定可能なEBS

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

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

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

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

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

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

安価高価

EC2EC2 StorageGatewayStorageGateway

選定するEC2により起動時にマッピングアタッチ VTLStored

Cached

i-SCSI接続

無料！(Instance料⾦内に含まれる)


Instance Storeとは• 特徴

– EC2の物理筐体のローカルディスク

– EC2インスタンスタイプにより、サイズと個数、HDD/SSD、が予め決まっている。

• 利点

– 無料！無料！無料！無料！

– 任意のファイルシステムが利用可能

– ローカルディスクのため、ネットワークの影響を受けにくい(レイテンシ・帯域)

• 注意

– インスタンスを停止(Stop)すると、データが消去さ

れる

※[重要］再起動（Reboot)では消えない。

– スナップショット機能はない

– 別のEC2に付替えができない

EC2/dev/xvdg

/dev/xvdf

揮発性EC2へマウント


Ephemeral Disk の Cloudwatch 監視

• EC2に紐づいているため、EC2インスタンスのDisk Metricを確認します。

（EBSの場合は、EBSのDisk Metricを確認します。）

• 注）複数のEphemeral Diskを利用の場合は、合計値が表示されます。

（EBSの場合は、VolumeごとにMetricが分かれます。）


EC2インスタンスタイプによる

選択可能な Instance Store• EC2のタイプによって、選択できるInstance Storeは以下の通り。

Instance Type Instance Store Volumesm1.small 1 x 160 GB†m1.medium 1 x 410 GBm1.large 2 x 420 GB (840 GB)m1.xlarge 4 x 420 GB (1680 GB)m2.xlarge 1 x 420 GBm2.2xlarge 1 x 850 GBm2.4xlarge 2 x 840 GB (1680 GB)m3.medium 1 x 4 GB SSDm3.large 1 x 32 GB SSDm3.xlarge 2 x 40 GB SSD (80 GB)m3.2xlarge 2 x 80 GB SSD (160 GB)t1.micro None

(use Amazon EBS volumes)c1.medium 1 x 350 GB†c1.xlarge 4 x 420 GB (1680 GB)

Instance Type Instance Store Volumesc3.large 2 x 16 GB SSD (32 GB)c3.xlarge 2 x 40 GB SSD (80 GB)c3.2xlarge 2 x 80 GB SSD (160 GB)c3.4xlarge 2 x 160 GB SSD (320 GB)c3.8xlarge 2 x 320 GB SSD (640 GB)cc2.8xlarge 4 x 840 GB (3360 GB)cg1.4xlarge 2 x 840 GB (1680 GB)cr1.8xlarge 2 x 120 GB SSD (240 GB)hi1.4xlarge 2 x 1024 GB SSD (2048 GB)hs1.8xlarge 24 x 2048 GB (49 TB)i2.xlarge 1 x 800 GB SSDi2.2xlarge 2 x 800 GB SSD (1600 GB)i2.4xlarge 4 x 800 GB SSD (3200 GB)i2.8xlarge 8 x 800 GB SSD (6400 GB)

※2014年3月15日時点


I2 Instance での Instance Store

Size ECUsvCPU

s

Memory

(GiB)

Instance Storage

(GiB)

EBS-

Optimized

Network

Performance

i2.xlarge 14 4 30.5 1 x 800 (SSD) Yes Moderate

i2.2xlarge 27 8 61 2 x 800 (SSD) Yes High


i2.8xlarge 104 32 244 8 x 800 (SSD) - 10 Gigabit

･高I/Oを実現するインスタンスタイプ･高速なSSD(Instance Store)を内蔵･ネットワークも高速(最大10Gbps)

※2014年3月15日時点


クラスタネットワーク( Placement Group)高性能インスタンス間の通信を高速化するための機構

I2の他にC3,CG1,G2,CC2,Hi1,HS1も利⽤可能

論理クラスターを構築するネットワークの単位１プレイスメントグループで220ノードを収容可能アベイラビリティゾーンを跨げない

従来のEC2と比べ、約10倍の帯域と1/10のレイテンシ帯域最大10GbpsHPCインスタンス間は、JumboFrameを使用ノンブロッキング

Full bisection の帯域Placement Group内のインスタンス間の通信帯域は 10Gbps full bisectionのネットワーク

Full bisection bandwidthFull bisection bandwidth

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html


Agenda


1

2

3

自己紹介

保有している主なIT資格• SAP 認定テクノロジコンサルタント (NW Oracle/UNIX)• ORACLE MASTER Platinum (9i), Gold (10g)• BEA WebLogic Server System Administrator認定• HP-UXシステムエンジニア認定資格

好きなAWSサービス• Provisioned IOPS (PIOPS)

松本大樹 (まつもとひろき）パートナーソリューションアーキテクト

簡単な経歴• 某ハードウェアベンダーにて11年間、H/Wインフ

ラを中心にベンチマークセンターエンジニアや、Java, Database, ERP パッケージなどの提案などを実施

今回の検証環境今回の検証環境今回の検証環境今回の検証環境

i2インスタンスに付属するSSDのエフェメラルディスクに対して、

FIOを利用した性能測定を実施した。

複数ディスクに対してはmdadmを利用したRAIDを構成して実施。

rw=“*1”

blocksize=“*2”

direct=1

loops=1runtime=1800

*1: "randrw randread randwrite read write“

*2: “2k 4k 8k 16k 32k 64k 128k 256k 512k 1m 2m"

i2.8xlarge

SSD x8

FIOのパラメータ

検証料金概算検証料金概算検証料金概算検証料金概算

アクセスパターン: Random read/write, Random read, Random write, Sequential read, Sequential write

Blocksize

• 2KB, 4KB, 8KB, 16KB, 32KB, 64KB, 128KB, 256KB, 512KB, 1MB, 2MB

Disk本数: SSD 1, 2, 4, 6, 8本

多重度: 16, 24, 32, 40, 56のIO負荷プロセスを起動

各構成が数パターン

全部で 2,658 パターンを計測。

負荷の多重度&

I/O Blocksize

検証条件検証条件検証条件検証条件

多重度

• 1 Disk当り16, 24, 32, 40, 56のIO負荷プロセスを起動

Blocksize

• 各負荷に対して2KB, 4KB, 8KB, 16KB, 32KB, 64KB, 128KB, 256KB, 512KB, 1MB, 2MBとブロックサイズを変えて計測

各アクセスパターンの特性は似ていたので、ここでは

Random Read/Writeを利用して説明

I/O負荷

Random Read/Write多重度多重度多重度多重度/Blocksize毎毎毎毎ののののMB/sec

0

500

1,000

1,500

2,000

2,500

3,000

3,500

2k 4k 8k 16k 32k 64k 128k 256k 512k 1m 2m

128 jobs

192 jobs

256 jobs

320 jobs

384 jobs

Blocksize 16KB辺り

からサチッって来てい

るのが分かる。

本セミナーではBlocksizeは2KB, 16KB, 128KBを基準に説明を実施します。

Random Read/Write多重度多重度多重度多重度/Blocksize毎毎毎毎ののののIOPS

IOPSでは分かりずらいので、ここでは省略。。

0

50,000

100,000

150,000

200,000

250,000

300,000

350,000

400,000

2k 4k 8k 16k 32k 64k 128k 256k 512k 1m 2m

128 jobs

192 jobs

256 jobs

320 jobs

384 jobs

Random Read/Write -多重度毎の多重度毎の多重度毎の多重度毎のMB/sec

多重度毎に見ると

Blocksize毎に優劣が異なる。

利用される頻度が高い

と思われる8KB, 16KBでは192jobsが最も良い性能となっている。

本計測では、今後

192jobs(1Disk辺り24多重)にて実施することとした。

1,000

1,200

1,400

1,600

1,800

2,000

2,200

2,400

2,600

2,800

3,000

4k 8k 16k 32k

128 jobs

192 jobs

256 jobs

320 jobs

384 jobs

I2 インスタンスタイプ毎(Disk数毎)

I2 Instance Type のののの Instance Store

I2 インスタンス

• 高速なSSD(Instance Store)を内蔵• 高いDisk I/O性能を実現

Instance

Type

ECU

s

vCP

Usメモリ

(GiB)

Instance Storage

(GiB)

EBS-

Optimized

Network

Performance

i2.xlarge 14 4 30.5 1 x 800 (SSD) Yes Moderate



i2.8xlarge 104 32 244 8 x 800 (SSD) - 10 Gigabit

※2014年1月29日時点

i2 インスタンスにおけるインスタンスにおけるインスタンスにおけるインスタンスにおける

Random Read/Writeの最速構成は？の最速構成は？の最速構成は？の最速構成は？

0

500

1,000

1,500

2,000

2,500

3,000

1 disk 2 disk 4 disk 6 disk 8 disk

128KB - MB/sec

8xlarge

4xlarge

2xlarge

xlarge

0

50,000

100,000

150,000

200,000

250,000

300,000

350,000


2KB - IOPS

8xlarge

4xlarge

2xlarge

xlarge

Blocksize = 128KB

2.58GB/sec(2,582MB/sec)

Blocksize=2KB

318,129 IOPS

i2 インスタンスにおけるインスタンスにおけるインスタンスにおけるインスタンスにおける

全てアクセスパターンでの最速構成全てアクセスパターンでの最速構成全てアクセスパターンでの最速構成全てアクセスパターンでの最速構成

Sequential Read

Blocksize = 128KB

3.71GB/sec(3,710MB/sec)

Sequential Read

Blocksize=2KB

373,786 IOPS

0

500

1,000

1,500

2,000

2,500

3,000

3,500

4,000


128KB - MB/sec

8xlarge

4xlarge

2xlarge

xlarge

0

50,000

100,000

150,000

200,000

250,000

300,000

350,000

400,000


2KB - IOPS

8xlarge

4xlarge

2xlarge

xlarge

スタンドアローン構成でのまとめスタンドアローン構成でのまとめスタンドアローン構成でのまとめスタンドアローン構成でのまとめ

多重度を上げると性能が上がるが、最適数があるのでほど

ほどに。

SSDのディスクを追加するたびに性能は向上する。

SSDのディスク 1本当りの性能は下記。各インスタンスタイプ毎の平均値を算出。

# of SSD AccessBlocksize

2KBBlocksize

128KB

SSD x 1Random R/W 53,654 IOPS 336 MB/sec

Sequential Read 64,980 IOPS 473 MB/sec

参考までに、EBSの性能は？

EBSの検証構成の検証構成の検証構成の検証構成

去年末に4000 IOPSに設定したProvisioned IOPSを8個並べて負荷を掛けてみたので参考までに。

PIOPS

4000

PIOPS

4000

PIOPS

4000

PIOPS

4000

PIOPS

4000

PIOPS

4000

PIOPS

4000

PIOPS

4000

CC2 Instance

4000 IOPS x 8 = 32,000 IOPS

ESBの参考性能値の参考性能値の参考性能値の参考性能値

CC2.8xlarge + PIOPSx8 での検証結果での検証結果での検証結果での検証結果

Sequential Read

Blocksize = 64KB

523MB/sec

Sequential Read

Blocksize=2KB

32,011 IOPS

0

100

200

300

400

500

600


64KB - MB/sec

0

5,000

10,000

15,000

20,000

25,000

30,000

35,000


2KB - IOPS

EBS PIOPS vs SSD Ephemeral

当然ながら性能値の比較ではSSDの方が早い。

ただしどちらも期待した性能値が出ているのが確認できる。

EBSの永続化やスナップショット、AZ/Region間コピーなどのメリットもあるので、性能値以外の要件でどちらのディスクが最適かを検討する。

Disk Type AccessBlocksize

2KBBlocksize

64KB

4000 IOPS EBS x8

Sequential Read

32,011 IOPS 523 MB/sec

SSD x 8Sequential

Read373,786 IOPS 3,484 MB/sec

DRBDの性能特性は

どうなのか？


ネットワークミラーリングの例: DRBD

AZ-A AZ-B

DRBDを使った検証環境を使った検証環境を使った検証環境を使った検証環境

下記の様に2つのI2.8xlargeインスタンスを起動し、DRBDのProtocol-Bとして設定した。Versionは8.3.11。

I2.8xlarge I2.8xlargeデータ転送

ネットワーク経由

アクセス

Primary Secondary

DRBD Sync方式方式方式方式特徴特徴特徴特徴

Protocol – A 非同期シンク

Protocol – B Secondaryへの転送完了まで保障

Protocol – C 同期シンク

Standalonevs

DRBD(Placement Group)

Blocksize=16KB時の時の時の時のMB/sec

Random RWとRandom Writeのオーバーヘッドが非常に高い。

同じWriteでもSequential Writeに関しては55%程度の性能劣化だった。

Random RW Sequential

Read

Sequential

Write

Random

Read

Random

Write

Standalone

PG

55%

Blocksize=2MB時の時の時の時のMB/sec

Blocksizeが大きくなるほど、DRBDによるオーバーヘッドは小さくなって来る。

2MBの場合はRandom RWでは60%程度の性能劣化だった。


Read

Sequential

Write

Random

Read

Random

Write

Standalone

PG

55%60% 80%

DRBD Protocol比較(Placement Group)

DRBD Protocolとは？とは？とは？とは？

Primary, Secondary間のデータシンクの方式としてProtocol-A, B, Cの3種類がある。

I2.8xlarge I2.8xlargeデータ転送

ネットワーク経由

Primary Secondary

DRBD Sync方式方式方式方式特徴特徴特徴特徴

Protocol – A 非同期シンク

Protocol – B Secondaryへの転送完了まで保障

Protocol – C 同期シンク


Read関連の処理に関してはどのProtocolでも性能差はほとんど無い。

Sequential Writeに関してはProtocol-Cだとオーバーヘッドが目立つ。

Random RW, Random Writeに関しては性能値が小さい為かほとんど差が見られない。

Sequential

Read

Sequential

Write

Random Read

Protocol-A

Protocol-B

Protocol-C

Random RW Random Write

Protocol-A

Protocol-B

Protocol-C

70%

Blocksize=2MB時の時の時の時のMB/sec

Blocksizeが大きくなるとDRBDによるオーバーヘッドが少なくなってくる。


Read

Sequential

Write

Random

Read

Random

Write

Protocol-A

Protocol-B

Protocol-C

50%

45%

Placement Groupvs

Multi-AZ


やはり同一Placement Group内で設置した方が性能劣化は少ない。特にSequential Writeでは顕著な差がみられた。

Sequential

Read

Sequential

Write

Random Read

PG

AZ

Random RW Random Write

PG

AZ

PG

5倍

PGが1.8倍

SR-IOV(PG)の効果


SR-IOVを有効にした方が性能が向上していることが確認できる。

特にSequential Writeでは顕著に性能向上が確認できる。

問題が無ければSR-IOVを有効にすべきである。

Sequential

Read

Sequential

Write

Random

Read

SRIOV on

SRIOV off

Random RW Random

Write

SRIOV on

SRIOV off

SR-IOV

4倍

SR-IOV

1.25倍

DRBD構成でのまとめ構成でのまとめ構成でのまとめ構成でのまとめ

DRBD構成にするとネットワークを介することになるため、SSDへのダイレクトアクセスに比べると当然性能は落ちる。

ただRead系のアクセスに関してのオーバーヘッドはほとんど見られなかった。

Sequential WriteもRandom Writeと比較すると性能劣化も限定的であった。

性能劣化を最小限にするためにはPlacement GroupやSR-IOVを有効にすることが効果的であることも確認できた。

検証のまとめ

I2ならスループットもIOPSも速い！

現状、AWS上では最速の性能を発揮！

SSDのディスクを増やせば性能が向上！

冗長化をするとオーバーヘッドがあるが限定的！

次はDRBDの新しいバージョンや商用ソフトの実力

を確認したい！


Agenda


1

2

3


Instance Storageを使うべきなのは

• 消えても良い一次データの置き場として使う場合

• 高IOPS、高帯域なストレージが必要な場合

• ストレージ冗長化を自分で作りこめる場合

S3


Instance Store の適用箇所 (シングルノード)

OSブートディスクブートディスクブートディスクブートディスク

としての利用としての利用としての利用としての利用

アプリデータ

/mount

システムデータ

/

EBS

EC2

EBS

データ格納ディスクとしての利⽤

Ephemeral

/tmp

データ計算用一時ディスクとしての利⽤


• ネットワーク冗長化

– DRBD

– ClusterPro

– DataKeeper

• 分散FS

– GlusterFS (OSS)

– OrangeFS

– Lustre

– Windows Distributed File System (DFS)

– HDFS

ストレージ冗⻑化


分散ファイルシステムの例 GlusterFS

GlusterFS

NFS

GlusterFS

NFS

GlusterFS

NFS

GlusterFS

NFS

GlusterFS

NFS

GlusterFS

NFS

GlusterFS

NFS

GlusterFS

NFS

GlusterFS

NFS

GlusterFS

NFS

GlusterFS

AZ-A

AZ-B


RDBMSの冗長化 (ログシッピング)

– MySQL + replication (+ MHA)

– PostgreSQL + streaming replication

– Oracle + Data Guard

– SQL Server + AlwaysOn

分散DB

– MySQL Cluster

– MongoDB

– Cassandra

– (Redshift)

DB冗⻑化


RDBMS冗長化

トランザクションログ転送トランザクションログ転送トランザクションログ転送トランザクションログ転送

Ephemeral

Ephemeral

Ephemeral

Ephemeral

Master Slave


MongoDB Sharded Replica sets

複数のAZに跨ってレプリカセットを配備することで高可用性を実現


Cassandra on SSD

例えば、どっちがよい！？Read, Writeの性能や可用性、コストなどを考慮するとトータルとしてどちら良いか？

Placement Group

i2.8xlarge

DRBD

32vCPU (104ECU)244 GB Memory

SSD 800GB x8

32vCPU (88ECU)244 GB Memory

PIOPS 4000 IOPS/800GB x8

cr1.8xlargePIOPS

3年 Reserved Instance

$ 4049.43年 Reserved Instance

$ 5814.3

2014年3月15日時点の価格

まとめまとめまとめまとめ

SSDのエフェメラルディスクはAWS上では最速の性

能を発揮！如何に使いこなすかがキモ！

構成次第では、エフェメラルも実用に耐えれる！

更に上級を目指すAWSエンジニアはエフェメラル

ディスクも選択肢に入れて、トータルな要件を踏まえ

て最適なアーキテクトを！

SSD

20140315 jawsdays i2 instance io performance

Technology

Transcript of 20140315 jawsdays i2 instance io performance