【セッションレポート】『Benchmarking on AWS』というニッチな内容で発表しました #cmdevio2015C

Developers.IO 2015

#AWS

#イベントレポート

#ベンチマーク

Guri / Hajime Oguri

2015.03.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウィスキー、シガー、パイプをこよなく愛する大栗です。

先日弊社で開催したDevelopers.io 2015のセミナーに「Benchmarking on AWS」と銘打ってAWSに置けるBenchmarkの内容をお話いたしましたので、内容の紹介と解説を致します。

Benchmarking on AWS

[slideshare id=46410427&doc=cmdevio-2015benchmarking-on-awspublic-150329022151-conversion-gate01]

What is Benchmark ?

Benchmarkとは何でしょうか？『性能比較のための指標』です。一般的な性能比較ができないと意味がありません。結果を良くするために特殊なことをしても比較に意味がなくなります。今回のセッションでは、ユーザ独自のアプリケーションについては対象外とし、AWSのサービス自体の性能測定について述べています。特に、以下の3項目を念頭に置いています。

計測の目的
計測対象の特定
計測対象の内容把握

Benchmarking for EC2/EBS

まずは、AWSの中心サービスであるEC2/EBSについてです。

EC2一般的な性能を計測する目的でUnixBenchでBenchmarkを行っても仮想化タイプによって大きく性能差が発生します。一昔前(2010年頃)までの資料では性能がPV ＞ HVMとなっていましたが、現在はHVM ＞ PVとなっています。現在PVで使用しているEC2があれば、HVMへの移行を検討すべきです。

先日EBSにアップデート（Amazon EBSが最大16TB、20000IOPSをサポートしました）があったので、Benchmarkを実施しました。しかし、Benchmark結果でWrite性能が奮いません。EBSではPreWarmingを行っていない場合、IOPSが5〜50%減少します。Readの場合は一旦書き込んだ後に読み込みますが、Writeの場合は事前に何もなく書き込みを行う為に性能を発揮しないようです。ではEBSのPre-Warmingを実施すればいいのですが、実施時間を推測すると16TBで3日程度必要でした。通常の運用でPre-Warmingの実施ができない場合には、Benchmarkでも実施すべきでないです。

EC2/EBSでは、以下のことに注意してBenchmarkを行いましょう。

現行世代のEC2を使用するため、仮想化タイプの移行を検討する。実施可否は移行費用とランニングコストを考慮して決定する
EBSはPre-Warmingをしないで計測する
EBSのユースケールを洗い出して、バックアップやリストアの時間も考慮する

Benchmarking for RDS

RDBMSをOLTP、DWH、超高速系と3種類に分類して考えました。各々は使用用途が異なるため比較対象とすることはナンセンスです。また、DB Engineも特性に合わせて採用を検討する必要があります。

RDBを対象としたBenchmarkは色々な指標があり、各指標のデータモデルが大きく異なります。対象システムの業務に近いものを選択して計測する必要が有ります。

RDSでは、以下のことに注意してBenchmarkを行いましょう。

システムで使用するクエリの複雑性や使用する機能にに合わせてDB Engineを選択する
システムの業務モデルを把握して、炊事の業務モデルの指標を使用する
Benchmarkの業務モデルを理解して、使用する指標を決定する

Benchmarking for Other Services

その他のサービスについて説明します。

S3は地理的に離れた3箇所にレプリケーションされるため、Static Website Hostingでアクセスする場合にアクセス先によってレイテンシが異なります。アクセス先は同じドメイン名でアクセスしますが、DNSの問い合わせ結果により異なるので1箇所のクライアントからBenchmarkを行っても、一般ユーザのアクセス状況と一緒とは限りません。多数のクライアントから分散させてアクセスすると実態に即した計測となります。

CloudFrontもS3と同様に同一ドメイン名でも複数のエッジサーバが存在します。そのため複数のクライアントから分散させて計測するべきです。また、CloudFrontの上限もあるため、目標値が上限を超えている場合は緩和申請が必要になります。 TTLを短くすると、オリジンサーバへのアクセス頻度が大きくなり、Benchmarkでの計測対象がオリジンサーバになってしまうことがあります。ボトルネックがどこになるかを意識しましょう。

DynamoDBはPrimary Keyを分散させることが重要です。パーティション毎に性能が決まっているのでパーティションをうまく分散させるべきです。また、IOPSを大きく上下させる場合には1パーティションのIOPSが低下することがあるので特に注意が必要です。パーティションが分割したら再結合がないため、元の状態に戻すためにはテーブルの再作成が必要になります。