Benchmarking on AWS @Developers.io 2015

Developer Day
Benchmarking on AWS
パフォーマンスの文句は計測してから言え！
1
C-2
大栗宗, AWSコンサルティング部
クラスメソッド株式会社
Ⓒ Classmethod, Inc.
2015年03月29日
#cmdevio2015C

お前誰よ？
大栗宗（@maroon1st）
インフラ構築 on AWSやってます
I ❤️ ウィスキー, シガー, パイプ
好きなAWSサービス：
• RDS
• SSM（Simple Systems Manager）
2Ⓒ Classmethod, Inc. #cmdevio2015C

Agenda
• What is Benchmark ?
• Benchmarking for EC2/EBS
• Benchmarking for RDS
• Benchmarking for Other Services
• Summary

What is Benchmark ?
#cmdevio2015C

–Tom DeMarco
測定できないものは
制御できない
#cmdevio2015C

Benchmarkを 
実施したことがある人
挙手！
6 #cmdevio2015C

Benchmarkツールの
話は一切しません。
7 #cmdevio2015C

コンピュータシステムのハードウェアやソフトウェア
の性能を測定するための指標のことを指す。(中略)直
接的な性能比較ができないシステムの間において、様々
な観点で性能を比較する手段を提供する。
（ベンチマーク. (2014, June 26). In Wikipedia.
Retrieved 03:20, March 17, 2015）
8Ⓒ Classmethod, Inc.
Benchmarkとは？
#cmdevio2015C

つまり
性能比較のための指標
9 #cmdevio2015C

Benchmarkとは？
本日の話題の対象範囲
アプリケーション
サービス
ミドルウェア
OS
{
{ユーザの責任範囲
AWSの責任範囲
仮想化機構
物理ハードウェア
#cmdevio2015C

Benchmarkとは？
本日の話題の対象範囲
Ⓒ Classmethod, Inc.
アプリケーション
サービス
ミドルウェア
OS
{
{ユーザの責任範囲
AWSの責任範囲
仮想化機構
物理ハードウェア
#cmdevio2015C

Benchmarkの目的
システムで使用するインスタンス / サービスで、 
必要な性能が出せるか目安を立てる。
コンポーネント単体の性能のみを比較しても、 
あまり意味は無い。
AWSのサービスの性能結果を組み合わせて、 
システム全体の性能を推測することが重要。

Benchmarkの目的
スコアのためのBenchmarkは無意味！
「最適化」や「チート」の結果は無駄！

Benchmarkにおける重要事項
以下の項目を念頭に置きましょう。
1. 計測の目的 
→目的によって計測方法が変わる
2. 計測対象の特定 
→計測対象を間違えない
3. 計測対象の内容把握 
→計測対象のアーキテクチャを知る

Benchmarking
for EC2/EBS
#cmdevio2015C

–Jean-Jacques Rousseau
幸福はその人の受ける苦しみ
の最小量によって測られなけ
ればならない。
#cmdevio2015C

まずはEC2の
Benchmarking！
17 #cmdevio2015C

Benchmarkの内容
Benchmarkの目的
• 特定のインスタンスタイプの性能を知りたい。
Benchmarkの条件
• Instance Type: c3.xlarge
• EBS: gp2 500GB (1,500/3,000 IOPS)
• Region: Tokyo(ap-northeast-1)
• OS: CentOS 6.5
• Benchmark tool: UnixBench 5.1.3

Benchmark結果
パターンA パターンB
Dhrystone 2 using register variables（整数演算） 6730.6 6697
Double-Precision Whetstone（浮動小数点） 2322.1 2313.7
Execl Throughput（システムコール） 858.6 2477.2
File Copy 1024 bufsize 2000 maxblocks（ディスクI/O） 790.4 1957.6
Pipe Throughput（パイプ） 726 2687.3
Pipe-based Context Switching（パイプ） 411.4 1727.6
Process Creation（プロセスフォーク） 586.4 2841
Shell Scripts (1 concurrent)（シェルのテキスト処理：1並列） 1480.1 3221.9
Shell Scripts (8 concurrent)（シェルのテキスト処理：8並列） 1388.4 3149
System Call Overhead（システムコール） 640.5 3416.9
System Benchmarks Index Score（総合スコア） 1054.8 2716.7
#cmdevio2015C

何故こんな差が
出ているんでしょう？
20 #cmdevio2015C

性能差の原因
仮想化タイプが違っていた。
• PV(準仮想化) 
エミュレーションのオーバーヘッドを抑えるPVが高速で
あるが、OS側での対応が必要。
• HVM(完全仮想化) 
OS側の対応が不要だがエミュレーションコストが大き
い。CPUの支援機能(Intel VT-xやAMD-V)が必須。

性能差の原因
一昔前の資料には PV ＞ HVM という説明が多いが、
現在は逆転している。
特にCPUの仮想化支援機能によるメモリアクセスの高
速化、I/Oアクセスの高速化の影響が大きい。
今はHVMでもPVドライバ(PV on HVM)を使用でき、
拡張ネットワーキングも可能となり、高速化されてい
る。

余談だが、近い将来に新しい仮想化 
タイプがEC2で使用できるかも。
Xen 4.4、Linux 3.14以降でPVHが 
使用可能。一言で言うとPVやHVMよ
り高速に動作するらしい。
詳しい方、情報求む！

新しい仮想化タイプが出てきても 
慌てないように環境構築の自動化を 
推進する。
秘伝のタレを使い続けると新しい 
インスタンスや仮想化タイプが 
出てきたときに対応できない！

次はEBSの
Benchmarking！
25 #cmdevio2015C

先日のアップデート...
26 #cmdevio2015C

性能上限が一気に向上！
• General Purpose(gp2) 
3,000 → 10,000 IOPS
• Provisioned IOPS(PIOPS) 
4,000 → 20,000 IOPS
27 #cmdevio2015C

では計測の実施！
28 #cmdevio2015C

Benchmark内容
Benchmarkの目的
• 想定した性能をEBSが発揮するか？
Benchmarkの条件
• EBS 
gp2：4,000GB（10,000IOPS） 
io1 ：4,000GB（20,000IOPS）
• OS: Amazon Linux 2014.09.2
• Benchmark tool: ﬁo 2.1.5
• block size: 16 KB
• 計測回数: 3回

Benchmark結果
9,722%%
9,499%%
8,953%%
9,635%%
9,710%%
9,737%%
1,544%%
1,544%%
1,536%%
1,522%%
1,515%%
1,526%%
20,152%%
20,115%%
19,682%%
19,761%%
19,993%%
20,108%%
1,523%%
1,528%%
1,540%%
1,496%%
1,492%%
1,501%%
0"" 5,000"" 10,000"" 15,000"" 20,000"" 25,000""
16"jobs"
32"jobs"
64"jobs"
16"jobs"
32"jobs"
64"jobs"
16"jobs"
32"jobs"
64"jobs"
16"jobs"
32"jobs"
64"jobs"
seq"read"rand"read"seq"write"rand"write"
IOPS
gp2" io1"
155.5%%MB/s%
152.0%%MB/s%
143.2%%MB/s%
154.2%%MB/s%
155.4%%MB/s%
155.8%%MB/s%
24.7%%MB/s%
24.7%%MB/s%
24.6%%MB/s%
24.4%%MB/s%
24.2%%MB/s%
24.4%%MB/s%
322.4%%MB/s%
321.8%%MB/s%
314.9%%MB/s%
316.2%%MB/s%
319.9%%MB/s%
321.7%%MB/s%
24.4%%MB/s%
24.5%%MB/s%
24.6%%MB/s%
23.9%%MB/s%
23.9%%MB/s%
24.0%%MB/s%
0.0""MB/s" 100.0""MB/s" 200.0""MB/s" 300.0""MB/s" 400.0""MB/s"
16"jobs"
32"jobs"
64"jobs"
16"jobs"
32"jobs"
64"jobs"
16"jobs"
32"jobs"
64"jobs"
16"jobs"
32"jobs"
64"jobs"
seq"read"rand"read"seq"write"rand"write"
bandwidth
gp2" io1"
#cmdevio2015C

Write性能が低い。。。
31 #cmdevio2015C

なぜWrite性能が低いのか？
データブロックに初めてアクセスした場合、IOPS は 5
∼50% 減少  
Amazon EBS ボリュームのパフォーマンス on Linux インスタンス 
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSPerformance.html
パフォーマンスを発揮するためには？
• すべてのブロックを対象に、書き込みまたは読み取
りを実行することで、パフォーマンスの低下を回避
• Pre-Warmingの実行が必要

Write性能が低い原因は、
Pre-Warmingを
していないため！
33 #cmdevio2015C

Pre-Warmingの
実行速度を計測しましょう
34 #cmdevio2015C

Benchmark内容
Benchmarkの目的
• Pre-Warmingに必要な時間はどのくらいか？
Benchmarkの条件
• EBS：(gp2)500GB, 1000GB, 2,000GB, 3000GB
• OS: Amazon Linux 2014.09.2
• コマンド：time sudo dd if=/dev/zero of=/dev/
xvd* oﬂag=direct bs=1M count=50000 
oﬂag=direct ：OSのキャッシュを使用しない。
Amazon EBS ボリュームの事前ウォーミング 
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-prewarm.html

Benchmark結果
実行時間 io1 推定完了時間
500GB 738 sec 71.0 MB/sec 2.0 h
1,000GB 734 sec 71.4 MB/sec 4.0 h
2,000GB 782 sec 67.0 MB/sec 8.5 h
3,000GB 858 sec 61.1 MB/sec 14.0 h
平均 778 sec 67.6 MB/sec ー
#cmdevio2015C

16TBのEBSを 
Pre-Warmingするのに 
約3日(68.9h)必要。。。
本当にPrewarmingを
実施してから使用する？
37 #cmdevio2015C

通常のシステム運用で
Prewarmingを行わないなら、
Benchmarkでも実施しない！
38 #cmdevio2015C

EC2/EBSの計測方法
• 自分が使用するインスタンス、AMI、ユースケースを
把握する。 
→現行世代のEC2を使用する。インスタンスタイプ
変更の場合、仮想化タイプの移行が可能か検討。移
行費用とランニングコストを天にかけて決定。
• EBSはPrewarmingが実施可能である場面は少ない。 
→Prewarmingをしないで計測する。
• EBSのユースケースを洗い出す。 
→バックアップやリストアの時間も考慮する。

Benchmarking
for RDS
#cmdevio2015C

–Mohandas Karamchand Gandhi
人生は速度を上げるだけが
能ではない。
#cmdevio2015C

RDBMSの種類
RDBMSを大きく以下のように分類する。
• OLTP：RDS(MySQL, PostgreSQL, Oracle,
SQL Server) 
→通常用途
• DWH：Redshift(PostgreSQL like) 
→大規模データ分析
• 超高速系：インメモリDB等 
(HANA on EC2, MySQL Cluster on EC2, etc) 
→超高トラフィック対策

RDBMSの種類
OLTP VS DWH VS 超高速系

RDBMSの種類
OLTP VS DWH VS 超高速系？
ハイブリッド VS トラック VS F1 ？

RDBMSの種類
OLTP VS DWH VS 超高速系？
ハイブリッド VS トラック VS F1 ？
意味ある比較にならない！

RDSのEngine
RDSのDB Engineは現在4種類。
• MySQL（GPL v2.0） 
OSS。シンプルなクエリが得意。
• PostgreSQL（The PostgreSQL License） 
OSS。地理情報やJSONを扱える。
• Oracle（License Include, BYOL） 
プロプライエタリ。エンタープライズの実績多数。
• SQL Server（License Include, BYOL） 
プロプライエタリ。WIndowsと相性が良い。

RDSのEngine
話題休閑
AuroraもRDSの1種である。現在Limited Preview中。
MySQLからStorageを独自実装に変更している。
MySQLと同等シンプルなクエリがとくと推定される。
64TBまでのデータに対応可能だが集計処理が不得意と
思われるため、DWH用途での使用は難しいであろう。
ライセンスはGPL v2.0だがサービス提供のため、ソー
スの配布義務が無く公開されないと思われる。

RDBMSのBenchmarkの種類
代表的なRDBMSのBenchmarkに以下がある。
• トランザクション処理性能評議会（TPC）： 
TPC-C：注文・支払い処理業務(OLTP) 
TPC-E：証券取引・市場監視(OLTP) 
TPC-DS：新世代の意思決定支援システム(DWH) 
TPC-H：旧世代の意思決定支援システム(DWH) 
TPC-VMS：同一マシンでの複数VM同時実行
• その他： 
SysBench：単一テーブルへのWrite/Read

TPC-C：注文・支払い処理業務 

TPC-E：証券取引・市場監視 

TPC-DS：新世代の意思決定支援システム 
Store Sales ERD Store Returns ERD Catalog Sales ERD
Catalog Returns ERD Web Sales ERD Web Returns ERD
#cmdevio2015C

TPC-H：旧世代の意思決定支援システム 

TPC-VMS：同一マシンでの複数VM同時実行
• TPC-C、TPC-E、TPC-DS、TPC-Hから1つの指標
を選択。
• 選択した指標を同一マシン上のVMで3インスタンス
稼働し、計測する。
• AWS上では通常使用しない。しかし、今後ECS/
Docker on AWSでの計測が必要になるかもしれな
い。

SysBench 

• TPC 
各々指標が想定している業務モデルがある。 
対象業務に近い指標を選択して評価すべき。
• SysBench 
特定の業務モデルがない。 
RDBMS的な使用をしていない。 
KVSと同様のモデル。

RDSの計測方法
• 特性に合わせたDB Engineを選択する。 
→ クエリの複雑性、使用する機能。
• 使用するシステムの業務モデルを把握する。 
→ 類似の業務モデルの指標で計測。
• Benchmarkの業務モデルを理解する。 
→ TPC-C/TPC-E/TPC-DS/TPC-H/TPC-VMS/
SysBench

Benchmarking
for Other Services
#cmdevio2015C

各種サービスでの注意点
59 #cmdevio2015C

• S3（API）
• APIの叩き過ぎは、スロットリングでエラーが発生。
• S3（Static Web Hosting）
• 名前解決によって接続先が変わる。
• AZで異なるレイテンシを考慮。
• 多数のクライアントからアクセスして、 
アクセス先を分散させる。
ネットワーク的に近い
¦¦
低レイテンシ
ネットワーク的に遠い
¦¦
高レイテンシ
#cmdevio2015C

• CloudFront
• S3と同様に同一ドメインでもアクセス先エッジサーバが複数
存在。
• WebかStreamingを意識してアクセスする。Webの場合は
rps、Streamingの場合はThroughputに注意。1Gbps or
1,000rpsを超える場合は上限緩和が必要。
• TTLが短い場合や動的コンテンツの場合はアクセス頻度が大
きい場合は、オリジンサーバのボトルネックを考慮する。

• DynamoDB
• Primary Keyのカーディナリティに注意。パーティション単
位で内部のIOPSが決まっているため、アクセスするKey(正確
にはパーティション)が偏ると性能を発揮できない。
1パーティション：
X IOPS
全体性能：
3X IOPS

スループットの大きな上下により性能低下の可能性がある。 
スループットの向上はパーティション分割でIOPSを増やす。低下
はパーティション結合せずに、パーティションのIOPSを低下。
性能向上：
パーティションを分割して
全体性能を上げる
性能低下：
パーティション結合をしない
各パーティションの性能を下げる
Keyが偏ると通常より性能悪化
#cmdevio2015C

–Hajime Ooguri
測定には前提がある。 
前提を見極めよ。
#cmdevio2015C

Benchmarkにおける重要事項
以下の項目を念頭に置く。
1. 計測の目的 
使用用途、場面を考える。 
ex) Auto Scalingのスパイク、永続的なデータストア
2. 計測対象の特定 
使用するサービスの種類 
ex) インスタンスサイズ、ディスクの種類
3. 計測対象の内容把握 
内部アーキテクチャの影響 
ex) DynamoDBのKeyパーティショニング

まとめ
• 性能を向上させる方法は把握すべきだが、現
実に即した内容で計測する。
• EC2の仮想化タイプ（HVMが使用可能か？）
• Prewarmingの有無（運用上、準備時間が取れるか？）
• etc
• 自分のユースケースに合う指標を使って
Benchmarkする
• Disk I/O→Read/Write, Sequential/Random
• RDB→TPC-C/TPC-DS/TPC-E/TPC-H/TPC-VMS/SysBench
• etc

最後に一言
68 #cmdevio2015C

サービス単位の 
Benchmark Scoreを 
鵜呑みにしないように。
重要なことは
システム全体の性能です！
69 #cmdevio2015C

Any Questions？
70 #cmdevio2015C

Benchmarking on AWS @Developers.io 2015

Recommandé

Recommandé

Contenu connexe

Similaire à Benchmarking on AWS @Developers.io 2015

Similaire à Benchmarking on AWS @Developers.io 2015 (20)

Plus de 宗大栗

Plus de 宗大栗 (18)