hero_picture
Cover Image for AWS Graviton2 (EC2) を検証した結果、採用しています

AWS Graviton2 (EC2) を検証した結果、採用しています

2022/05/24
# AWS

クラウドソリューション事業部の原口です。

近年ARM(アーム)と呼ばれる種類のCPUが人気です。

低電力、低発熱で安定したスペックを発揮できるという事で主にモバイルなどが主戦場だったCPUでしたが、最近ではサーバやパソコンなどさまざまな場所で見るようになりました。

一般の認知度が高くなったキッカケとしてはAppleが発表したM1チップの影響ではないかと思います。これまでパワーが必要なパソコンにおいてはIntel製のCPUが主流だったのですが、AppleのM1チップがその性能を上回るというニュースが飛び出した事でARMのCPUの認知度が上がった気がしています。

そんなARMについて我らがAWSもCPUを出しています。それが表題の Gravitonプロセッサーになります。

AWSで利用するには c6g.large、t4g.medium のようにインスタンスファミリー名に「g」のついたインスタンスを使えばGraviton2チップを使っている事となります。インスタンスタイプのアーキテクチャを aarch64を選択する事で選択可能となります。

Graviton2が登場したのは今から2年も前であり、そろそろGraviton3もGAとなりそうな中ではあるのですが、シーズでは積極的にGraviton2を利用しているところもあり、その採用についての検証過程を公開したいと思います。

Phoronix Test Suiteでのベンチ結果

まずは検証結果です。

今回、さまざまな種類のベンチマークが可能なPhoronix Test Suiteを利用して、「openssl(sha256)」「gcrypt」「stress-ng(cpu)」「phpbench」「php(zend bench)」「apache (20)」「java-jmh」「perf-bench(memcopy)」の種類のベンチマークを各インスタンスタイプに対して行なってみました。

参考にベンチマークを行ったコマンドは以下となります。

1sudo amazon-linux-extras enable php8.0
2sudo yum install -y php-cli php-xml php-json
3sudo yum install -y perl-IPC-Cmd
4
5wget https://phoronix-test-suite.com/releases/phoronix-test-suite-10.8.3.tar.gz
6tar zxvfpa phoronix-test-suite-10.8.3.tar.gz
7cd phoronix-test-suite
8sudo ./install-sh
9
10phoronix-test-suite benchmark openssl gcrypt stress-ng phpbench apache java-jmh perf-bench php

ここまでの結果を見ると、なにがなんでもgraviton2の方が性能が良い！というわけではない事がわかります。ある特定の分野ではIntel製の3倍以上の性能を発揮していますが、またある分野ではIntel製の1/3程度しか性能が出ていない事がわかります。

全体的な傾向としてはgraviton2はメモリの利用効率がとても高いように思えます。単純なメモリのINではIntel製を大きく上回っていました。また、ビルドを行なってバイナリとして動かすプログラム言語(javaやGo言語など)においてはかなりの速度が上昇する傾向にあるようです。ApacheやnginxなどのWEBサーバーとしての処理能力も優位性が見れました。性能が高い分野ではマルチスレッドであればあるほどその性能の伸びが顕著であるという傾向が見られます。

反面、CPUに計算をガリガリさせるような事には向いてなさそうな印象です。ハッシュ処理などはかなりの速度低下が見られましたし、PHPなどのスクリプト言語においては速度低下が見られました。

PHP遅くなるの…?

はい、、ベンチ結果としてはyesとなります。我々はPHPを使ったシステム開発をしている中でこの結果は無視できないところになります。

結局のところGraviton2にして良いのかどうか、というのはこう言ってはなんですがその動かす用途/システムによる、という話になってしまうのですね。

実際のところPHP単体でのベンチでは低めの性能でしたが、これはシングルスレッドでの結果差ですし、Apacheを含めた統合的な形ではどうなるのかという所になってくるのではないかと思います。

ですので！追加検証として、WordPressをインストールしたApache(2.4) + phpfpm(8.0) + MariaDB におけるApache Benchの値を検証してみました。

この結果がこちら。(大変だったのでCPU性能を求めるc系のみ検証)

参考に以下のコマンドでセットアップした環境にベンチした結果となります

1sudo su -
2sudo amazon-linux-extras enable php8.0
3sudo yum install -y php-cli php-pdo php-fpm php-mysqlnd mariadb-server httpd
4sudo systemctl start httpd
5sudo mysqld_safe --skip-grant-tables --skip-networking &
6sleep 5;
7sudo curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
8sudo chmod +x wp-cli.phar
9sudo mv wp-cli.phar /usr/local/bin/wp
10sudo mysql -u root -e "create database wp_sample;"
11
12wp core download --locale=ja --path=/var/www/html
13wp core config --dbname=wp_sample --dbuser=root --dbhost=localhost --dbprefix=wp_ --path=/var/www/html
14wp core install --url=http://localhost/ --title=test --admin_user=admin --admin_password=admin1234 --admin_email=admin@example.com --path=/var/www/html

ベンチは以下

1ab -n 100 -c 100 http://localhost/
2ab -n 1000 -c 100 http://localhost/
3ab -n 10000 -c 100 http://localhost/

結果としては全体的にc5系に比べると10%から20%の性能向上が見られます。また、これはベンチ中に気づいた事なのですが、同じ負荷をかけてもc6g系の方がCPU使用率が低い傾向にありました。

> c6g.4xlargeは最大CPU使用率43%

> c5.4xlargeは最大CPU使用率63%

これらの結果から、性能部分においても問題がない(むしろ優位性がある)として採用を決定しています。

AWSによるZend OptimizerのARM64実装 なども行われていますので今後も期待していきたいですね。

Graviton2のメリット

それでは性能面を全面に出しましたがその他の選定の理由などについて。

c5系に比べて純粋にコストが安い

なんといってもコストメリットは抜群です。基本的に20%ほど金額がやすくなっています。これは純粋にメリットです。(但し、後述のスポットインスタンスにおいては割高になるので注意！)

利用用途に刺されば大幅な性能増加が見込める

こちらは今回のベンチ通り。

基本的なOSSのパッケージがARMに対応している

現在のところARM64用パッケージはかなり揃えられています。

c6g.medium がある

これまでのc5系はc5.largeが最低ラインでしたが、Graviton2にはc6g.mediumがあります。

サステナブルなCPUである

ARMプロセッサはこれまでのCPUに比べて低消費電力で少ないメモリでも必要十分な処理能力を確保できるといったものでした。今回の検証結果からGraviton2は弱点であった性能を引き上げつつ、エネルギー使用量削減を実現しているCPUといえます。

つまり、Graviton2を利用したシステムとするだけで、サステナブルな環境への取り組みをしっかりと実施してる事となるのです。これはこれからの企業の経営課題であるSDGsの目標達成への大きなメリットとなる感じがします。

(AWSはオンプレミスのデータセンターとの比較で、CO2排出量を最大93%削減できる可能性があると見込んでいるそうです）

AWSが提案するCO2排出量削減策

Graviton2のデメリット

Saving Planやスポットインスタンスでのコストメリットはあまり受けられない

Saving Planではコストメリットが少なくなる、くらいでしたが、スポットインスタンスにおいては割高になってしまうので、このようなワークロードで利用している場合はコストメリットはあまりありません。

システムの利用用途によってはc5系世代よりスペックが下がってしまう事がある

こちらは検証結果通りです。利用用途によっては思ったより性能が出ない、となってしまう事がありますのでベンチマークにて検証が推奨されます。(それ以上のコストメリットを感じている場合は除きます)

ニッチなパッケージやソースインストールのモジュールなどでARM64に対応していないものがあるかも

これまであった事例としてとあるウィルス対策ソフトがARMに対応していなかった事なども、、、

既存インスタンスの置き換えはかなり大変

インスタンスタイプの変更ではなく作り直しとなるため、結構な作業となってしまう。

まとめ

以上、弊社がGraviton2の採用を行なっている理由でした。

結局のところ「システムによる」という検証結果であった事は申し訳ないのですが、第一歩として、これからの新規の構築においては間違いなく享受できるコストメリットとサステナビリティへの対応がありますので、積極採用を検討してみてもいいのではないかと思います。

次回はRDSについても検証していきたいと思います！