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 パターンBDhrystone 2 using register variables（整数演算） 6730.6 6697

Double-Precision Whetstone（浮動小数点） 2322.1 2313.7Execl Throughput（システムコール） 858.6 2477.2

File Copy 1024 bufsize 2000 maxblocks（ディスクI/O） 790.4 1957.6File Copy 256 bufsize 500 maxblocks（ディスクI/O） 486.5 1160.2

File Copy 4096 bufsize 8000 maxblocks（ディスクI/O） 1595.9 4054.8Pipe Throughput（パイプ） 726 2687.3

Pipe-based Context Switching（パイプ） 411.4 1727.6Process Creation（プロセスフォーク） 586.4 2841

Shell Scripts (1 concurrent)（シェルのテキスト処理：1並列） 1480.1 3221.9Shell Scripts (8 concurrent)（シェルのテキスト処理：8並列） 1388.4 3149

System Call Overhead（システムコール） 640.5 3416.9System 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: fio 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* oflag=direct bs=1M count=50000“oflag=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 ？44Ⓒ Classmethod, Inc. #cmdevio2015C

RDBMSの種類

OLTP VS DWH VS 超高速系？

ハイブリッド VS トラック VS F1 ？45Ⓒ Classmethod, Inc. #cmdevio2015C

意味ある比較にならない！

RDSのEngineRDSの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


RDBMSのBenchmarkの種類TPC-C：注文・支払い処理業務


RDBMSのBenchmarkの種類TPC-E：証券取引・市場監視


RDBMSのBenchmarkの種類TPC-DS：新世代の意思決定支援システム


Store Sales ERD Store Returns ERD Catalog Sales ERD

Catalog Returns ERD Web Sales ERD Web Returns ERD

#cmdevio2015C

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


RDBMSのBenchmarkの種類TPC-VMS：同一マシンでの複数VM同時実行 • TPC-C、TPC-E、TPC-DS、TPC-Hから1つの指標を選択。

• 選択した指標を同一マシン上のVMで3インスタンス稼働し、計測する。

• AWS上では通常使用しない。しかし、今後ECS/Docker on AWSでの計測が必要になるかもしれない。


RDBMSのBenchmarkの種類SysBench


RDBMSのBenchmarkの種類• TPC各々指標が想定している業務モデルがある。対象業務に近い指標を選択して評価すべき。

• SysBench特定の業務モデルがない。RDBMS的な使用をしていない。KVSと同様のモデル。


RDSの計測方法• 特性に合わせたDB Engineを選択する。→ クエリの複雑性、使用する機能。

• 使用するシステムの業務モデルを把握する。→ 類似の業務モデルの指標で計測。

• Benchmarkの業務モデルを理解する。→ TPC-C/TPC-E/TPC-DS/TPC-H/TPC-VMS/SysBench


Benchmarking for Other Services

#cmdevio2015C

–Mohandas Karamchand Gandhi

“人生は速度を上げるだけが能ではない。”

#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

Summary

#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

Software