Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Developer Day
Benchmarking on AWS
パフォーマンスの文句は計測してから言え!
1
C-2
大栗 宗, AWSコンサルティング部
クラスメソッド株式会社
Ⓒ Classmethod, Inc.
2015年03月29...
お前誰よ?
大栗 宗(@maroon1st)
インフラ構築 on AWSやってます
I ❤️ ウィスキー, シガー, パイプ
好きなAWSサービス:
• RDS
• SSM(Simple Systems Manager)
2Ⓒ Classmet...
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)....
つまり
性能比較のための指標
9 #cmdevio2015C
Benchmarkとは?
本日の話題の対象範囲
10Ⓒ Classmethod, Inc.
アプリケーション
サービス
ミドルウェア
OS
{
{ユーザの責任範囲
AWSの責任範囲
仮想化機構
物理ハードウェア
#cmdevio2015C
Benchmarkとは?
本日の話題の対象範囲
Ⓒ Classmethod, Inc.
アプリケーション
サービス
ミドルウェア
OS
{
{ユーザの責任範囲
AWSの責任範囲
仮想化機構
物理ハードウェア
#cmdevio2015C
Benchmarkの目的
システムで使用するインスタンス / サービスで、

必要な性能が出せるか目安を立てる。
コンポーネント単体の性能のみを比較しても、

あまり意味は無い。
AWSのサービスの性能結果を組み合わせて、

システム全体の性能...
Benchmarkの目的
スコアのためのBenchmarkは無意味!
「最適化」や「チート」の結果は無駄!
13Ⓒ Classmethod, Inc. #cmdevio2015C
Benchmarkにおける重要事項
以下の項目を念頭に置きましょう。
1. 計測の目的

→目的によって計測方法が変わる
2. 計測対象の特定

→計測対象を間違えない
3. 計測対象の内容把握

→計測対象のアーキテクチャを知る
14Ⓒ Cl...
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 IO...
Benchmark結果
19Ⓒ Classmethod, Inc.
パターンA パターンB
Dhrystone 2 using register variables(整数演算) 6730.6 6697
Double-Precision Whet...
何故こんな差が
出ているんでしょう?
20 #cmdevio2015C
性能差の原因
仮想化タイプが違っていた。
• PV(準仮想化)

エミュレーションのオーバーヘッドを抑えるPVが高速で
あるが、OS側での対応が必要。
• HVM(完全仮想化)

OS側の対応が不要だがエミュレーションコストが大き
い。CPUの...
性能差の原因
一昔前の資料には PV > HVM という説明が多いが、
現在は逆転している。
特にCPUの仮想化支援機能によるメモリアクセスの高
速化、I/Oアクセスの高速化の影響が大きい。
今はHVMでもPVドライバ(PV on HVM)を使...
余談だが、近い将来に新しい仮想化

タイプがEC2で使用できるかも。
Xen 4.4、Linux 3.14以降でPVHが

使用可能。一言で言うとPVやHVMよ
り高速に動作するらしい。
詳しい方、情報求む!
23Ⓒ Classmethod, ...
新しい仮想化タイプが出てきても

慌てないように環境構築の自動化を

推進する。
秘伝のタレを使い続けると新しい

インスタンスや仮想化タイプが

出てきたときに対応できない!
24Ⓒ Classmethod, Inc. #cmdevio201...
次は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: A...
Benchmark結果
30Ⓒ Classmethod, Inc.
9,722%%
9,499%%
8,953%%
9,635%%
9,710%%
9,737%%
1,544%%
1,544%%
1,536%%
1,522%%
1,515%%
...
Write性能が低い。。。
31 #cmdevio2015C
なぜWrite性能が低いのか?
データブロックに初めてアクセスした場合、IOPS は 5
∼50% 減少 

Amazon EBS ボリュームのパフォーマンス on Linux インスタンス

http://docs.aws.amazon.co...
Write性能が低い原因は、
Pre-Warmingを
していないため!
33 #cmdevio2015C
Pre-Warmingの
実行速度を計測しましょう
34 #cmdevio2015C
Benchmark内容
Benchmarkの目的
• Pre-Warmingに必要な時間はどのくらいか?
Benchmarkの条件
• EBS:(gp2)500GB, 1000GB, 2,000GB, 3000GB
• OS: Amazon L...
Benchmark結果
36Ⓒ Classmethod, Inc.
実行時間 io1 推定完了時間
500GB 738 sec 71.0 MB/sec 2.0 h
1,000GB 734 sec 71.4 MB/sec 4.0 h
2,000G...
16TBのEBSを

Pre-Warmingするのに

約3日(68.9h)必要。。。
本当にPrewarmingを
実施してから使用する?
37 #cmdevio2015C
通常のシステム運用で
Prewarmingを行わないなら、
Benchmarkでも実施しない!
38 #cmdevio2015C
EC2/EBSの計測方法
• 自分が使用するインスタンス、AMI、ユースケースを
把握する。

→現行世代のEC2を使用する。インスタンスタイプ
変更の場合、仮想化タイプの移行が可能か検討。移
行費用とランニングコストを天 にかけて決定。
• ...
Benchmarking
for RDS
#cmdevio2015C
–Mohandas Karamchand Gandhi
人生は速度を上げるだけが
能ではない。
#cmdevio2015C
RDBMSの種類
RDBMSを大きく以下のように分類する。
• OLTP:RDS(MySQL, PostgreSQL, Oracle,
SQL Server)

→通常用途
• DWH:Redshift(PostgreSQL like)

→大...
RDBMSの種類
OLTP VS DWH VS 超高速系
43Ⓒ Classmethod, Inc. #cmdevio2015C
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のEngine
RDSのDB Engineは現在4種類。
• MySQL(GPL v2.0)

OSS。シンプルなクエリが得意。
• PostgreSQL(The PostgreSQL License)

OSS。地理情報やJSONを扱え...
RDSのEngine
話題休閑
AuroraもRDSの1種である。現在Limited Preview中。
MySQLからStorageを独自実装に変更している。
MySQLと同等シンプルなクエリがとくと推定される。
64TBまでのデータに対応可...
RDBMSのBenchmarkの種類
代表的なRDBMSのBenchmarkに以下がある。
• トランザクション処理性能評議会(TPC):

TPC-C:注文・支払い処理業務(OLTP)

TPC-E:証券取引・市場監視(OLTP)

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

49Ⓒ Classmethod, Inc. #cmdevio2015C
RDBMSのBenchmarkの種類
TPC-E:証券取引・市場監視

50Ⓒ Classmethod, Inc. #cmdevio2015C
RDBMSのBenchmarkの種類
TPC-DS:新世代の意思決定支援システム

51Ⓒ Classmethod, Inc.
Store Sales ERD Store Returns ERD Catalog Sales ERD
Catalo...
RDBMSのBenchmarkの種類
TPC-H:旧世代の意思決定支援システム

52Ⓒ Classmethod, Inc. #cmdevio2015C
RDBMSのBenchmarkの種類
TPC-VMS:同一マシンでの複数VM同時実行
• TPC-C、TPC-E、TPC-DS、TPC-Hから1つの指標
を選択。
• 選択した指標を同一マシン上のVMで3インスタンス
稼働し、計測する。
• A...
RDBMSのBenchmarkの種類
SysBench

54Ⓒ Classmethod, Inc. #cmdevio2015C
RDBMSのBenchmarkの種類
• TPC

各々指標が想定している業務モデルがある。

対象業務に近い指標を選択して評価すべき。
• SysBench

特定の業務モデルがない。

RDBMS的な使用をしていない。

KVSと同様のモデ...
RDSの計測方法
• 特性に合わせたDB Engineを選択する。

→ クエリの複雑性、使用する機能。
• 使用するシステムの業務モデルを把握する。

→ 類似の業務モデルの指標で計測。
• Benchmarkの業務モデルを理解する。

→ ...
Benchmarking
for Other Services
#cmdevio2015C
–Mohandas Karamchand Gandhi
人生は速度を上げるだけが
能ではない。
#cmdevio2015C
各種サービスでの注意点
59 #cmdevio2015C
各種サービスでの注意点
• S3(API)
• APIの叩き過ぎは、スロットリングでエラーが発生。
• S3(Static Web Hosting)
• 名前解決によって接続先が変わる。
• AZで異なるレイテンシを考慮。
• 多数のクライアン...
各種サービスでの注意点
• CloudFront
• S3と同様に同一ドメインでもアクセス先エッジサーバが複数
存在。
• WebかStreamingを意識してアクセスする。Webの場合は
rps、Streamingの場合はThroughput...
各種サービスでの注意点
• DynamoDB
• Primary Keyのカーディナリティに注意。パーティション単
位で内部のIOPSが決まっているため、アクセスするKey(正確
にはパーティション)が偏ると性能を発揮できない。
62Ⓒ Cla...
各種サービスでの注意点
スループットの大きな上下により性能低下の可能性がある。

スループットの向上はパーティション分割でIOPSを増やす。低下
はパーティション結合せずに、パーティションのIOPSを低下。
63Ⓒ Classmethod, I...
Summary
#cmdevio2015C
–Hajime Ooguri
測定には前提がある。

前提を見極めよ。
#cmdevio2015C
Benchmarkにおける重要事項
以下の項目を念頭に置く。
1. 計測の目的

使用用途、場面を考える。

ex) Auto Scalingのスパイク、永続的なデータストア
2. 計測対象の特定

使用するサービスの種類

ex) インスタン...
まとめ
• 性能を向上させる方法は把握すべきだが、現
実に即した内容で計測する。
• EC2の仮想化タイプ(HVMが使用可能か?)
• Prewarmingの有無(運用上、準備時間が取れるか?)
• etc
• 自分のユースケースに合う指標を使...
最後に一言
68 #cmdevio2015C
サービス単位の

Benchmark Scoreを

鵜呑みにしないように。
重要なことは
システム全体の性能です!
69 #cmdevio2015C
Any Questions?
70 #cmdevio2015C
Developer Day
ご静聴ありがとうございました。
71
C-2
Ⓒ Classmethod, Inc. #cmdevio2015C
Upcoming SlideShare
Loading in …5
×

Benchmarking on AWS @Developers.io 2015

Classmethodで開催したDevelopers.io 2015のセッション資料です。

Benchmarking on AWS @Developers.io 2015

  1. 1. Developer Day Benchmarking on AWS パフォーマンスの文句は計測してから言え! 1 C-2 大栗 宗, AWSコンサルティング部 クラスメソッド株式会社 Ⓒ Classmethod, Inc. 2015年03月29日 #cmdevio2015C
  2. 2. お前誰よ? 大栗 宗(@maroon1st) インフラ構築 on AWSやってます I ❤️ ウィスキー, シガー, パイプ 好きなAWSサービス: • RDS • SSM(Simple Systems Manager) 2Ⓒ Classmethod, Inc. #cmdevio2015C
  3. 3. Agenda • What is Benchmark ? • Benchmarking for EC2/EBS • Benchmarking for RDS • Benchmarking for Other Services • Summary 3Ⓒ Classmethod, Inc. #cmdevio2015C
  4. 4. What is Benchmark ? #cmdevio2015C
  5. 5. –Tom DeMarco 測定できないものは 制御できない #cmdevio2015C
  6. 6. Benchmarkを
 実施したことがある人 挙手! 6 #cmdevio2015C
  7. 7. Benchmarkツールの 話は一切しません。 7 #cmdevio2015C
  8. 8. コンピュータシステムのハードウェアやソフトウェア の性能を測定するための指標のことを指す。(中略)直 接的な性能比較ができないシステムの間において、様々 な観点で性能を比較する手段を提供する。 (ベンチマーク. (2014, June 26). In Wikipedia. Retrieved 03:20, March 17, 2015) 8Ⓒ Classmethod, Inc. Benchmarkとは? #cmdevio2015C
  9. 9. つまり 性能比較のための指標 9 #cmdevio2015C
  10. 10. Benchmarkとは? 本日の話題の対象範囲 10Ⓒ Classmethod, Inc. アプリケーション サービス ミドルウェア OS { {ユーザの責任範囲 AWSの責任範囲 仮想化機構 物理ハードウェア #cmdevio2015C
  11. 11. Benchmarkとは? 本日の話題の対象範囲 Ⓒ Classmethod, Inc. アプリケーション サービス ミドルウェア OS { {ユーザの責任範囲 AWSの責任範囲 仮想化機構 物理ハードウェア #cmdevio2015C
  12. 12. Benchmarkの目的 システムで使用するインスタンス / サービスで、
 必要な性能が出せるか目安を立てる。 コンポーネント単体の性能のみを比較しても、
 あまり意味は無い。 AWSのサービスの性能結果を組み合わせて、
 システム全体の性能を推測することが重要。 12Ⓒ Classmethod, Inc. #cmdevio2015C
  13. 13. Benchmarkの目的 スコアのためのBenchmarkは無意味! 「最適化」や「チート」の結果は無駄! 13Ⓒ Classmethod, Inc. #cmdevio2015C
  14. 14. Benchmarkにおける重要事項 以下の項目を念頭に置きましょう。 1. 計測の目的
 →目的によって計測方法が変わる 2. 計測対象の特定
 →計測対象を間違えない 3. 計測対象の内容把握
 →計測対象のアーキテクチャを知る 14Ⓒ Classmethod, Inc. #cmdevio2015C
  15. 15. Benchmarking for EC2/EBS #cmdevio2015C
  16. 16. –Jean-Jacques Rousseau 幸福はその人の受ける苦しみ の最小量によって測られなけ ればならない。 #cmdevio2015C
  17. 17. まずはEC2の Benchmarking! 17 #cmdevio2015C
  18. 18. 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 18Ⓒ Classmethod, Inc. #cmdevio2015C
  19. 19. Benchmark結果 19Ⓒ Classmethod, Inc. パターン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 File Copy 256 bufsize 500 maxblocks(ディスクI/O) 486.5 1160.2 File Copy 4096 bufsize 8000 maxblocks(ディスクI/O) 1595.9 4054.8 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. 20. 何故こんな差が 出ているんでしょう? 20 #cmdevio2015C
  21. 21. 性能差の原因 仮想化タイプが違っていた。 • PV(準仮想化)
 エミュレーションのオーバーヘッドを抑えるPVが高速で あるが、OS側での対応が必要。 • HVM(完全仮想化)
 OS側の対応が不要だがエミュレーションコストが大き い。CPUの支援機能(Intel VT-xやAMD-V)が必須。 21Ⓒ Classmethod, Inc. #cmdevio2015C
  22. 22. 性能差の原因 一昔前の資料には PV > HVM という説明が多いが、 現在は逆転している。 特にCPUの仮想化支援機能によるメモリアクセスの高 速化、I/Oアクセスの高速化の影響が大きい。 今はHVMでもPVドライバ(PV on HVM)を使用でき、 拡張ネットワーキングも可能となり、高速化されてい る。 22Ⓒ Classmethod, Inc. #cmdevio2015C
  23. 23. 余談だが、近い将来に新しい仮想化
 タイプがEC2で使用できるかも。 Xen 4.4、Linux 3.14以降でPVHが
 使用可能。一言で言うとPVやHVMよ り高速に動作するらしい。 詳しい方、情報求む! 23Ⓒ Classmethod, Inc. #cmdevio2015C
  24. 24. 新しい仮想化タイプが出てきても
 慌てないように環境構築の自動化を
 推進する。 秘伝のタレを使い続けると新しい
 インスタンスや仮想化タイプが
 出てきたときに対応できない! 24Ⓒ Classmethod, Inc. #cmdevio2015C
  25. 25. 次はEBSの Benchmarking! 25 #cmdevio2015C
  26. 26. 先日のアップデート... 26 #cmdevio2015C
  27. 27. 性能上限が一気に向上! • General Purpose(gp2)
 3,000 → 10,000 IOPS • Provisioned IOPS(PIOPS)
 4,000 → 20,000 IOPS 27 #cmdevio2015C
  28. 28. では計測の実施! 28 #cmdevio2015C
  29. 29. 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回 29Ⓒ Classmethod, Inc. #cmdevio2015C
  30. 30. Benchmark結果 30Ⓒ Classmethod, Inc. 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
  31. 31. Write性能が低い。。。 31 #cmdevio2015C
  32. 32. なぜWrite性能が低いのか? データブロックに初めてアクセスした場合、IOPS は 5 ∼50% 減少 
 Amazon EBS ボリュームのパフォーマンス on Linux インスタンス
 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSPerformance.html パフォーマンスを発揮するためには? • すべてのブロックを対象に、書き込みまたは読み取 りを実行することで、パフォーマンスの低下を回避 • Pre-Warmingの実行が必要 32Ⓒ Classmethod, Inc. #cmdevio2015C
  33. 33. Write性能が低い原因は、 Pre-Warmingを していないため! 33 #cmdevio2015C
  34. 34. Pre-Warmingの 実行速度を計測しましょう 34 #cmdevio2015C
  35. 35. 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 35Ⓒ Classmethod, Inc. #cmdevio2015C
  36. 36. Benchmark結果 36Ⓒ Classmethod, Inc. 実行時間 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
  37. 37. 16TBのEBSを
 Pre-Warmingするのに
 約3日(68.9h)必要。。。 本当にPrewarmingを 実施してから使用する? 37 #cmdevio2015C
  38. 38. 通常のシステム運用で Prewarmingを行わないなら、 Benchmarkでも実施しない! 38 #cmdevio2015C
  39. 39. EC2/EBSの計測方法 • 自分が使用するインスタンス、AMI、ユースケースを 把握する。
 →現行世代のEC2を使用する。インスタンスタイプ 変更の場合、仮想化タイプの移行が可能か検討。移 行費用とランニングコストを天 にかけて決定。 • EBSはPrewarmingが実施可能である場面は少ない。
 →Prewarmingをしないで計測する。 • EBSのユースケースを洗い出す。
 →バックアップやリストアの時間も考慮する。 39Ⓒ Classmethod, Inc. #cmdevio2015C
  40. 40. Benchmarking for RDS #cmdevio2015C
  41. 41. –Mohandas Karamchand Gandhi 人生は速度を上げるだけが 能ではない。 #cmdevio2015C
  42. 42. RDBMSの種類 RDBMSを大きく以下のように分類する。 • OLTP:RDS(MySQL, PostgreSQL, Oracle, SQL Server)
 →通常用途 • DWH:Redshift(PostgreSQL like)
 →大規模データ分析 • 超高速系:インメモリDB等
 (HANA on EC2, MySQL Cluster on EC2, etc)
 →超高トラフィック対策 42Ⓒ Classmethod, Inc. #cmdevio2015C
  43. 43. RDBMSの種類 OLTP VS DWH VS 超高速系 43Ⓒ Classmethod, Inc. #cmdevio2015C
  44. 44. RDBMSの種類 OLTP VS DWH VS 超高速系? ハイブリッド VS トラック VS F1 ? 44Ⓒ Classmethod, Inc. #cmdevio2015C
  45. 45. RDBMSの種類 OLTP VS DWH VS 超高速系? ハイブリッド VS トラック VS F1 ? 45Ⓒ Classmethod, Inc. #cmdevio2015C 意味ある比較にならない!
  46. 46. 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と相性が良い。 46Ⓒ Classmethod, Inc. #cmdevio2015C
  47. 47. RDSのEngine 話題休閑 AuroraもRDSの1種である。現在Limited Preview中。 MySQLからStorageを独自実装に変更している。 MySQLと同等シンプルなクエリがとくと推定される。 64TBまでのデータに対応可能だが集計処理が不得意と 思われるため、DWH用途での使用は難しいであろう。 ライセンスはGPL v2.0だがサービス提供のため、ソー スの配布義務が無く公開されないと思われる。 47Ⓒ Classmethod, Inc. #cmdevio2015C
  48. 48. RDBMSのBenchmarkの種類 代表的なRDBMSのBenchmarkに以下がある。 • トランザクション処理性能評議会(TPC):
 TPC-C:注文・支払い処理業務(OLTP)
 TPC-E:証券取引・市場監視(OLTP)
 TPC-DS:新世代の意思決定支援システム(DWH)
 TPC-H:旧世代の意思決定支援システム(DWH)
 TPC-VMS:同一マシンでの複数VM同時実行 • その他:
 SysBench:単一テーブルへのWrite/Read 48Ⓒ Classmethod, Inc. #cmdevio2015C
  49. 49. RDBMSのBenchmarkの種類 TPC-C:注文・支払い処理業務
 49Ⓒ Classmethod, Inc. #cmdevio2015C
  50. 50. RDBMSのBenchmarkの種類 TPC-E:証券取引・市場監視
 50Ⓒ Classmethod, Inc. #cmdevio2015C
  51. 51. RDBMSのBenchmarkの種類 TPC-DS:新世代の意思決定支援システム
 51Ⓒ Classmethod, Inc. Store Sales ERD Store Returns ERD Catalog Sales ERD Catalog Returns ERD Web Sales ERD Web Returns ERD #cmdevio2015C
  52. 52. RDBMSのBenchmarkの種類 TPC-H:旧世代の意思決定支援システム
 52Ⓒ Classmethod, Inc. #cmdevio2015C
  53. 53. RDBMSのBenchmarkの種類 TPC-VMS:同一マシンでの複数VM同時実行 • TPC-C、TPC-E、TPC-DS、TPC-Hから1つの指標 を選択。 • 選択した指標を同一マシン上のVMで3インスタンス 稼働し、計測する。 • AWS上では通常使用しない。しかし、今後ECS/ Docker on AWSでの計測が必要になるかもしれな い。 53Ⓒ Classmethod, Inc. #cmdevio2015C
  54. 54. RDBMSのBenchmarkの種類 SysBench
 54Ⓒ Classmethod, Inc. #cmdevio2015C
  55. 55. RDBMSのBenchmarkの種類 • TPC
 各々指標が想定している業務モデルがある。
 対象業務に近い指標を選択して評価すべき。 • SysBench
 特定の業務モデルがない。
 RDBMS的な使用をしていない。
 KVSと同様のモデル。 55Ⓒ Classmethod, Inc. #cmdevio2015C
  56. 56. RDSの計測方法 • 特性に合わせたDB Engineを選択する。
 → クエリの複雑性、使用する機能。 • 使用するシステムの業務モデルを把握する。
 → 類似の業務モデルの指標で計測。 • Benchmarkの業務モデルを理解する。
 → TPC-C/TPC-E/TPC-DS/TPC-H/TPC-VMS/ SysBench 56Ⓒ Classmethod, Inc. #cmdevio2015C
  57. 57. Benchmarking for Other Services #cmdevio2015C
  58. 58. –Mohandas Karamchand Gandhi 人生は速度を上げるだけが 能ではない。 #cmdevio2015C
  59. 59. 各種サービスでの注意点 59 #cmdevio2015C
  60. 60. 各種サービスでの注意点 • S3(API) • APIの叩き過ぎは、スロットリングでエラーが発生。 • S3(Static Web Hosting) • 名前解決によって接続先が変わる。 • AZで異なるレイテンシを考慮。 • 多数のクライアントからアクセスして、
 アクセス先を分散させる。 60Ⓒ Classmethod, Inc. ネットワーク的に近い ¦¦ 低レイテンシ ネットワーク的に遠い ¦¦ 高レイテンシ #cmdevio2015C
  61. 61. 各種サービスでの注意点 • CloudFront • S3と同様に同一ドメインでもアクセス先エッジサーバが複数 存在。 • WebかStreamingを意識してアクセスする。Webの場合は rps、Streamingの場合はThroughputに注意。1Gbps or 1,000rpsを超える場合は上限緩和が必要。 • TTLが短い場合や動的コンテンツの場合はアクセス頻度が大 きい場合は、オリジンサーバのボトルネックを考慮する。 61Ⓒ Classmethod, Inc. #cmdevio2015C
  62. 62. 各種サービスでの注意点 • DynamoDB • Primary Keyのカーディナリティに注意。パーティション単 位で内部のIOPSが決まっているため、アクセスするKey(正確 にはパーティション)が偏ると性能を発揮できない。 62Ⓒ Classmethod, Inc. #cmdevio2015C 1パーティション: X IOPS 全体性能: 3X IOPS
  63. 63. 各種サービスでの注意点 スループットの大きな上下により性能低下の可能性がある。
 スループットの向上はパーティション分割でIOPSを増やす。低下 はパーティション結合せずに、パーティションのIOPSを低下。 63Ⓒ Classmethod, Inc. 性能向上: パーティションを分割して 全体性能を上げる 性能低下: パーティション結合をしない 各パーティションの性能を下げる Keyが偏ると通常より性能悪化 #cmdevio2015C
  64. 64. Summary #cmdevio2015C
  65. 65. –Hajime Ooguri 測定には前提がある。
 前提を見極めよ。 #cmdevio2015C
  66. 66. Benchmarkにおける重要事項 以下の項目を念頭に置く。 1. 計測の目的
 使用用途、場面を考える。
 ex) Auto Scalingのスパイク、永続的なデータストア 2. 計測対象の特定
 使用するサービスの種類
 ex) インスタンスサイズ、ディスクの種類 3. 計測対象の内容把握
 内部アーキテクチャの影響
 ex) DynamoDBのKeyパーティショニング 66Ⓒ Classmethod, Inc. #cmdevio2015C
  67. 67. まとめ • 性能を向上させる方法は把握すべきだが、現 実に即した内容で計測する。 • 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 67Ⓒ Classmethod, Inc. #cmdevio2015C
  68. 68. 最後に一言 68 #cmdevio2015C
  69. 69. サービス単位の
 Benchmark Scoreを
 鵜呑みにしないように。 重要なことは システム全体の性能です! 69 #cmdevio2015C
  70. 70. Any Questions? 70 #cmdevio2015C
  71. 71. Developer Day ご静聴ありがとうございました。 71 C-2 Ⓒ Classmethod, Inc. #cmdevio2015C

×