AWS EC2 と GCE(Google Compute Engine)を徹底的にベンチマークしてみた

AWS EC2 と GCE(Google Compute Engine)を徹底的にベンチマークしてみた
あぱーブログ
2017年4月5日  カテゴリー:WEB  タグ: , , ,
Pocket
LINEで送る

WEBサイト用にサーバーを1台用意しようと思うのですが、使いなれた AWS EC2 にするか、ここのところ勢いがある Google Cloud Platform の Compute Engine にするかで迷ってます。サーバー費用は少ないお小遣い(^^;) から出さなければならないので、慎重に選びたいところです。そこで今回は、AWS EC2 と GCE(Google Compute Engine)を「徹底的」にベンチマークして性能を比較してみました。

比較するサーバーのスペックと月額料金

アクセス数があまりないWEBサイトなので、実際に使おうと思っている小さめのサーバーで比較してみます。月額料金は、どちらも東京リージョン2017年4月5日時点の料金での概算です、同じくらいのスペックでも Google Compute Engine には継続利用割引があるため多少安くなります。

AWS EC2

  • マシンタイプ:t2.small(vCPU x 1 + メモリ 2.0 GB)オンデマンドインスタンス
  • ストレージ:SSD 10GB
  • 月額料金:$24.56(730時間利用)
  • インターネットへのデータ送信:$0.14/GB

Google Compute Engine

  • マシンタイプ:g1-small(vCPU x 1 + メモリ 1.7 GB)
  • ストレージ:SSD 10GB
  • 月額料金:$18.66(730時間利用)
  • インターネットへのデータ送信:$0.12/GB(香港以外の中国とオーストラリアを除く)

ベンチマーク概要

以下のベンチマークテストを1時間ごとに行い、1日(24時間)の結果を比較します。各ベンチマークテストは、同じ時間帯に実行されないようにスケジュールしています。ベンチマークの詳細な手順はこの記事の後半「ベンチマーク設定手順」をご参照ください。

  • CPU性能(UnixBench の System Benchmarks Index Score)
  • Read ディスク性能(hdparm を10回実行した結果の平均値)
  • Write ディスク性能(ddコマンドで512MBのデータを10回書き込んだ結果の平均値)
  • MySQLのTPS「トランザクション毎秒」(SysBench の transactions の値)

ベンチマーク結果

ベンチマークテストを実施した期間は 2017-03-29 06:00 〜2017-03-31 04:00 です。丸一日のデータがとれた3月30日のベンチマーク結果で比較します。

CPU性能(UnixBench)

定番のベンチーマークツール UnixBench の System Benchmarks Index Score です。この値が大きいほどCPUの性能が高いと言えます。

(System Benchmarks Index Score)

日時AWS EC2Google Compute Engine
2017/3/30 0:00518.2869.5
1:00524.0877.3
2:00528.7874.0
3:00518.7878.1
4:00523.9877.5
5:00523.4847.0
6:00518.6906.8
7:00519.9967.4
8:00517.9957.6
9:00522.2953.3
10:00521.0933.4
11:00519.2937.5
12:00511.5949.2
13:00644.4950.2
14:00518.6949.5
15:00517.6928.6
16:00515.5892.6
17:00516.9895.9
18:00514.5904.9
19:00514.6937.1
20:00512.9941.4
21:00514.4936.0
22:00519.7942.3
23:00514.1946.5
平均523.8918.9

上の計測結果では Google Compute Engine があきらかにCPU性能がよさそうですが、AWS EC2 の t2.small インスタンスには「CPUクレジット」という仕組みがあり、このクレジットに残りがあれば、CPU性能が一定時間のあいだ高くなります。詳しくは以下の公式ガイドを参照してください

T2 インスタンス - Amazon Elastic Compute Cloud

UnixBench の計測を開始した直後の System Benchmarks Index Score です。2回目の計測までは CPUクレジットが残っていたので Google Compute Engine よりも高い性能が出ています。短時間にアクセスが集中するWEBサイトなどに「CPUクレジット」は便利な仕組みですね。

日時AWS EC2Google Compute Engine
2017/3/28 6:001414.1851.2
7:001395.0895.3
8:00804.7901.1
9:00690.5887.3
10:00701.1856.7

Read ディスク性能

SSDの読み取り速度、1回の計測値は hdparm(ディスクの読み取り性能を計測するためのコマンド)を10回実行した結果の平均です。

(単位:MB/秒)

日時AWS EC2Google Compute Engine
2017/3/30 0:4079.7179.39
1:4081.1979.17
2:4081.1479.36
3:4081.1979.13
4:4081.1479.10
5:4081.0878.96
6:4079.5479.26
7:4081.1279.21
8:4081.1479.22
9:4080.1179.28
10:4081.1479.27
11:4081.1479.23
12:4081.1479.06
13:4081.0879.38
14:4081.1479.25
15:4081.1379.30
16:4081.1479.32
17:4081.1479.17
18:4081.0879.22
19:4081.1479.41
20:4081.1479.24
21:4081.1779.21
22:4081.1479.21
23:4081.1379.08
平均80.9779.23

ディスクの読み取り性能は同じように見えますが、特性が大きく異なります。上の計測結果は、1時間ごとに hdparm を10回実行してその計測結果の平均値をとっていますが、hdparm の実行1回ごとの計測結果は以下のようになっています。(100回連続して実行した計測結果です)

(単位:MB/秒)

NoAWS EC2Google Compute Engine
181.23245.95
281.47164.68
380.5847.93
481.4547.77
581.1447.28
(省略)
9681.1447.36
9781.1447.77
9881.1447.39
9981.1448.00
10081.1447.36

2回目の計測までは Google Compute Engine が、かなり高い読み取り性能を出していますが3回目以降は、AWS EC2 の半分くらいの性能になります。ディスクの読み取りが少ないWEBサーバーなどでは Google Compute Engine が有利ですが、ファイルサーバーなど継続的にディスクの読み取りがある場合は AWS EC2 が有利になります。

(参考資料)永続ディスクとローカル SSD のパフォーマンスの最適化 | Compute Engine ドキュメント

Write ディスク性能

SSDの書き込み速度、1回の計測値はddコマンドで512MBのデータを10回書き込んだ結果の平均です。

ディスクの書き込み性能については、AWS EC2 が Google Compute Engine の倍くらいの性能があるようです。

(単位:MB/秒)

日時AWS EC2Google Compute Engine
2017/3/30 0:4575.536.7
1:4575.836.4
2:4575.736.5
3:4578.836.2
4:4574.336.9
5:4579.037.9
6:4578.136.4
7:4575.536.4
8:4573.937.1
9:4578.637.1
10:4575.837.4
11:4575.538.8
12:4575.938.5
13:4575.237.4
14:4580.837.8
15:4579.237.0
16:4581.936.4
17:4574.436.5
18:4575.237.6
19:4578.936.4
20:4579.337.7
21:4575.436.8
22:4579.137.6
23:4574.437.5
平均76.937.1

MySQLのTPS(トランザクション毎秒)

MySQLのTPS(トランザクション毎秒)一般的にデータベース管理システムの性能はこのTPSで評価します。計測値は、SysBench の transactions の値です。

データベース管理システムの実行性能は、若干 Google Compute Engine の方が良さそうですね。

(単位:per sec)

日時AWS EC2Google Compute Engine
2017/3/30 0:50269.90290.29
1:50276.52288.12
2:50271.59294.17
3:50280.83300.38
4:50280.01280.66
5:50277.29292.35
6:50271.62311.67
7:50283.28315.34
8:50278.96307.93
9:50274.42310.14
10:50281.76308.17
11:50274.73314.11
12:50273.94322.92
13:50275.73310.41
14:50270.38308.11
15:50274.74328.54
16:50271.06301.50
17:50272.45306.71
18:50269.97325.68
19:50272.27334.13
20:50275.61331.80
21:50267.36330.82
22:50273.38338.21
23:50272.41332.39
平均274.59311.86

まとめと結論

各ベンチマーク結果の平均値をまとめました。性能と費用だけででみれば、早くて安い Google Compute Engine に軍配が上がりそうです。

ベンチマークAWS EC2Google Compute Engine
CPU性能 - System Benchmarks Index Score523.8918.9
Read ディスク性能(MB/秒)80.9779.23
Write ディスク性能(MB/秒)76.937.1
MySQLトランザクション毎秒(per sec)274.59311.86
月額費用(概算)$24.56$18.66

しかしサーバーの導入は、性能と費用以外に「実績・サポート・エコシステム」なども考慮する必要があります。このあたりはクラウドサービスの先駆者だけあってAWSが圧倒的に有利です。(あくまで私個人の見解です)

 AWS EC2Google Compute Engine
実績
サポート
エコシステム

もし仕事でサーバーを導入するのであれば、このくらいの性能と費用の差であれば AWS EC2 を選びます。ただ、今回は私個人のWEBサイトなのであまり「実績・サポート・エコシステム」を気にする必要がありません。費用をおさえられて性能もよさそうなので Google Compute Engine を使うことにしました。

ベンチマーク設定手順

AWS EC2 と Google Compute Engine どちらもまったく同じ手順で、ベンチマークを設定し計測しました。サーバーOSは CentOS7.3 (1611) です。

今回のベンチマーク結果

はじめに、インストール済みのパッケージを最新版にアップデートし、開発ツールなど基本的なパッケージをインストールします。

yum -y update
yum -y groupinstall base
yum -y groupinstall development
yum -y groupinstall network-tools

ベンチマーク結果ログの保存先を作成

mkdir /var/log/bench

CPU性能(UnixBench)

UnixBench のインストール

yum -y install perl-Time-HiRes
cd /usr/local/bin/
wget https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/byte-unixbench/UnixBench5.1.3.tgz
tar zxvf UnixBench5.1.3.tgz
cd UnixBench
make

・ベンチマーク実行スクリプトの作成
vi /usr/local/bin/unixbench.sh

実行権限を設定

chmod 700 /usr/local/bin/unixbench.sh

・crontab に登録
crontab -e

00 * * * * /usr/local/bin/unixbench.sh

Read ディスク性能(hdparm)

hdparm のインストール

yum -y install hdparm

・ベンチマーク実行スクリプトの作成
vi /usr/local/bin/io_read.sh

実行権限を設定

chmod 700 /usr/local/bin/io_read.sh

・crontab に登録
crontab -e

40 * * * * /usr/local/bin/io_read.sh

Write ディスク性能(dd)

・ベンチマーク実行スクリプトの作成
vi /usr/local/bin/io_write.sh

実行権限を設定

chmod 700 /usr/local/bin/io_write.sh

・crontab に登録
crontab -e

45 * * * * /usr/local/bin/io_write.sh

MySQLのTPS(SysBench)

SysBench についての詳細は「SysBench で MySQL の性能測定(ベンチマーク)」をご参照ください。

SysBench のインストール

rpm -ivh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm
rpm --import http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-7
yum -y install sysbench

MySQL のインストールと起動

rpm -ivh http://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm
yum -y install mysql-server
systemctl start mysqld

MySQL の初期設定

grep password /var/log/mysqld.log ← root のパスワード確認
mysql_secure_installation

SysBench用のDBとユーザーの作成

mysql -p
CREATE DATABASE sbtest;
GRANT ALL ON sbtest.* TO 'sbtest'@'localhost' IDENTIFIED BY '<パスワード>';

計測用テーブルの作成

sysbench \
--test=oltp \
--db-driver=mysql \
--oltp-table-size=1000000 \
--mysql-password=<パスワード> \
prepare

・ベンチマーク実行スクリプトの作成
vi /usr/local/bin/sysbench.sh

実行権限を設定

chmod 700 /usr/local/bin/sysbench.sh

・crontab に登録
crontab -e

50 * * * * /usr/local/bin/sysbench.sh

以上で各ベンチマークテストが1時間ごとに実施され、結果が /var/log/bench/ ディレクトリ以下に出力されます。

おわりに

まったくの余談ですが、ふとしたきっかけから『キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論』という本を読んでいます。内容をざっくり要約すると「商品をブレイクさせるには "キャズム" (深い溝という意味)を超えなければならない」というものです。

この記事を書いていて、キャズムを見事に超えた AWS と、それを追いかけて今まさにキャズムを越えようとしている Google Cloud Platform の姿が思い浮かびました。

スポンサーリンク
Pocket
LINEで送る

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です