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

WEBサイト用にサーバーを１台用意しようと思うのですが、使いなれた 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）

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

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

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

Read ディスク性能

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

（単位：MB/秒）

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

（単位：MB/秒）

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

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

Write ディスク性能

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

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

（単位：MB/秒）

MySQLのTPS（トランザクション毎秒）

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

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

（単位：per sec）

まとめと結論

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

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

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

ベンチマーク設定手順

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

今回のベンチマーク結果

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

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

CPU性能（UnixBench）

UnixBench のインストール

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

#!/bin/sh -
LOG='/var/log/bench/unixbench.log'

cd /usr/local/bin/UnixBench
echo '==================== START ' `date` '====================' >> $LOG
./Run >> $LOG 2>&1
echo '==================== END ' `date` '====================' >> $LOG
echo '' >> $LOG

exit 0

実行権限を設定

・crontab に登録
crontab -e

Read ディスク性能（hdparm）

hdparm のインストール

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

#!/bin/sh -
LOG='/var/log/bench/io_read.log'

#
# ディスクのデバイス名を指定
#
DISK='/dev/sda1'

echo '==================== START ' `date` '====================' >> $LOG
for i in `seq 10`
do
    echo 1 > /proc/sys/vm/drop_caches 
    /sbin/hdparm -t $DISK >> $LOG 2>&1
done
echo '==================== END ' `date` '====================' >> $LOG
echo '' >> $LOG

exit 0

実行権限を設定

・crontab に登録
crontab -e

Write ディスク性能（dd）

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

#!/bin/sh -
LOG='/var/log/bench/io_write.log'
OF='/tmp/io_write'

/bin/mkdir $OF
echo '==================== START ' `date` '====================' >> $LOG
for i in `seq 10`
do
    /bin/dd if=/dev/zero of=${OF}/${i} bs=1M count=512 >> $LOG 2>&1
done
echo '==================== END ' `date` '====================' >> $LOG
echo '' >> $LOG

/bin/rm -r $OF
exit 0

実行権限を設定

・crontab に登録
crontab -e

MySQLのTPS（SysBench）

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

SysBench のインストール

MySQL のインストールと起動

MySQL の初期設定

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

計測用テーブルの作成

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

#!/bin/sh -
LOG='/var/log/bench/sysbench.log'

echo '==================== START ' `date` '====================' >> $LOG
/bin/sysbench \
--test=oltp \
--db-driver=mysql \
--oltp-table-size=1000000 \
--mysql-password=＜パスワード＞ \
--num-threads=1 \
--max-requests=0 \
--max-time=300 \
--oltp-read-only=off \
run >> $LOG 2>&1
echo '==================== END ' `date` '====================' >> $LOG
echo '' >> $LOG

exit 0

実行権限を設定

・crontab に登録
crontab -e

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

おわりに

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

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