クラウドソリューション事業部の原口です。
先日
AWS Graviton2 (EC2) を検証した結果、採用しています
という記事を書いて「そろそろGraviton3もGAになりそう」なんて書いてたら記事公開のその日にGraviton3がGAになりました笑
AWS Graviton3 プロセッサを搭載した新しい Amazon EC2 C7g インスタンスを発表
ですのでこの勢いで、Graviton3 であるc7gシリーズのベンチも回してみました。OSはamazon linux 2 です。
(2022/06/16追記) java-jmh の追加検証を行いページ下部に追記しました
Graviton3
ベンチ結果の前に、Graviton3の公式性能は以下のような形でした。
・Graviton2(c6g)に比べて最大 25% 優れたパフォーマンス
・浮動小数点パフォーマンスが最大 2 倍
・暗号化パフォーマンスの速度が最大 2 倍
・機械学習パフォーマンスが最大 3 倍
・DDR5 メモリを採用していて、 DDR4 と比較して 50% 広いメモリ帯域幅
・同等の EC2 インスタンスと比較して、エネルギーが最大 60% 抑えられる
・Twitterにおいてc6g よりも最大 80% 優れたパフォーマンス
・Twitterにおいてc6g よりもテールレイテンシーが 35% も減少
・ARMv8 Neoverse-V1ベース (graviton2はARMv8 Neoverse-N1)
これを見る限りでは性能はGraviton2の完全な上位互換ですね！
ただしコストについては us-east-1でc6gと比較したところオンデマンド価格で全体的に6-7%ほど価格が上がっていました。
それでもc5系と比べたら随分とお安いお値段になっています。
結果
現在、c7gはUS East (N. Virginia) と US West (Oregon) のみですのでバージニア(us-east-1)で試していきました。
初めに行ったベンチはphoronix-test-suiteでして、その結果が以下になります！
(ベンチコマンドなどは前回の記事 ( AWS Graviton2 (EC2) を検証した結果、採用しています )と同じです)
※金額は東京リージョンのものはわからないのでus-east-1のものを入れています。
この結果をざっと見てもわかりますとおり、今まで苦手だったgcryptなどc6gよりも大幅に性能があがっておりc5にかなり迫ってきている事がわかりました！今回はちょっと詳細に見ていきたいと思います。
詳細
openssl組み込みのopensslspeedを使ったベンチマークで、SHA256での暗号化スピードのベンチマークです。
c6gの時点でc5より大きなパフォーマンス向上してましたが、c7gではさらにパフォーマンスが伸びています。
このベンチはシングルコアでのベンチであるため、1インスタンスタイプで比較します
GnuPGプロジェクトの一部として開発された汎用暗号ライブラリであるLibgcryptにて、暗号化/マック/ハッシュ化を50回繰り返すのにかかる時間を測定するベンチマークです。ですのでかかった秒数がが短ければ短いほど高性能です。
乱数生成に難があると言われていたgraviton2ですが、c7gではその弱点をかなり改善している印象です。依然としてc5の性能が高い状態ですがかなり追いついてきている印象です。
このベンチはシングルコアでのベンチであるため、1インスタンスタイプで比較します
perf-benchと呼ばれるベンチマークを使って、メモリへのデータコピー速度のベンチマーク結果です。こちらはc7gがc6gの頃に比べて2倍以上のパフォーマンス向上が見られました。メモリ利用効率はかなりあがってそうです。
stress-ngはcpuに負荷をかけさせる事ができるツールですが、「1秒あたりの偽オペレーション」のスループットを計測する事ができ、そちらの値となります。
stress-ngのドキュメントには「あまりベンチマークには使わないで」、という事でしたが、結果としてはc5の圧勝の状態です。c7gも確かに進化してますが、c5にはまだまだ及ばない状態でした。
このベンチはシングルコアでのベンチであるため、1インスタンスタイプで比較します
PHPのベンチマークスイートです。さまざまな簡単なテストを実行してスコアを出してくれるベンチだそうです(詳細を知らない…)。graviton2ではc5に対して見劣りする性能となっている事が否めない結果でしたが、graviton3となって、その差はほとんどなくなりました。phpをメインで使ってる弊社としてはとても嬉しい結果ですね。
このベンチはシングルコアでのベンチであるため、1インスタンスタイプで比較します
PHPマイクロベンチマークというものも実行してみました。
こちらは秒数が少ないほど良い結果というベンチですが、こちらもかなりc5に近づく結果となっていますね。
こちらはApache Benchかと思ったのですがGolangの「Bombardier」というプログラムを使用して設定した同時接続で一定時間接続し続ける、といったベンチマークのようです。1秒間に処理できるクライアント数という結果ですが、こちらはgraviton3の性能が際立って良い結果になりました。(c5.4xlargeの結果は何かの間違いじゃないかなと思いますが…)
javaのマイクロベンチマークである JMHの結果です。
これは、、、結果としてはc7gだけすごく低いという結果が出てしまいました。
というよりc6gだけがとても高い結果に。。何度かやってみましたが同じ結果でしたので、うーん、なんでだろう。
こちらのようなチューニングを行う事で大きく結果が変わってきそうではありますが、、c6gだけが高いというのは、、うーん。
https://github.com/aws/aws-graviton-getting-started/blob/main/java.md
WordPressを入れたLAMPへApache Bench
今回も実際にLAMPを組んでWordPressを入れた状態でApache Benchを走らせても見ました。前回同様に Apache2.4 PHP8.0 MariaDBです。
graviton自体の設計思想が
クラウドで実行されるの現実のワークロードにフォーカスして開発したのがGravitonプロセッサ。
という事なのでやはり実際の利用環境でみないとですね。
(ベンチコマンドなどは前回の記事 ( AWS Graviton2 (EC2) を検証した結果、採用しています )と同じです)
※金額は東京リージョンのものはわからないのでus-east-1のものを入れています。
参考に100同時接続数で総リクエスト数10,000の状態のグラフです
気持ちがいいくらいの右肩あがりですね笑
こちらも全体的にgraviton3ではこれまでのインスタンスタイプに比べてパフォーマンスがかなり伸びています。
特にc7g.4xlargeのようにコア数が多いほど高負荷での処理能力の伸びが大きい感じがしました。
まとめ
公表の通りc6gから全体的にスペックアップしているのは間違いなさそうです。
これで低電力にもなったというのだからどんな魔法なんだよ、、、という感じです。c6gからコストも若干上がってはいますがこのパフォーマンス上昇であれば納得でしょう。
また、既存のミドルウェアをgravitonへ最適化するtipsはAWSがまとめたgithubがありますのでこちらを参考にチューニングするとまた結果が大きく変わるかもしれないです。
これからGravitonを採用していこうと考えている方は一読しておいて損はなさそうです。
https://github.com/aws/aws-graviton-getting-started
ただ、java-jmhの結果がc7gだけがダントツで低くなったのが若干気になります。計測の仕方の問題であればいいのですが。。
早く東京リージョンで使いたいです。
(2022/06/16追記) java-jmh の追加検証
これまでの検証結果ではjava-jmhによるベンチマークではc7gのパフォーマンスが著しく下がっているという結果でした。
こちらの件につきまして確認していたところ、すでに紹介させていただいた以下の資料に原因に関するヒントがありました。
https://github.com/aws/aws-graviton-getting-started/blob/main/java.md
While Java 8 is fully supported on Arm processors, some customers haven’t been able to obtain Graviton’s full performance benefit until they switched to Java 11.Amazon Corretto is continuing to improve performance of Java workloads running on Graviton processors and if you have the choice of a JDK to use we recommend using Corretto as it provides the fastest way to get access to the performance improvements AWS is making.
要約すると、「gravitonで最大のパフォーマンスを得るにはJava11以上で、Amazon Corretto の JDKを使うのがよいよ」、ということです。
Phoronix Test Suiteでのjava-jmhのベンチマークではデフォルトではOpenJDK 1.8がインストールされて使用されますので、javaのバージョンと利用JDKを変えて再度ベンチしてみました。
利用したインスタンスタイプは
c5.4xlargec6g.4xlargec7g.4xlargeで、利用したJDKはopenJDK 1.8openJDK 11Amazon Corretto 8Amazon Corretto 11Amazon Corretto 17となります。
ベンチ結果を見ると java8か、Openjdkを利用した場合はやはりgraviton3の性能は著しく下がってしまっているようですが、
java11以降のAmazon Corretto を利用した場合はこの結果が逆転し、graviton3の性能がダントツになってきます。
このベンチの結果をまとめると、javaの利用においては
・java8であれば graviton2を利用・java11以降でAmazon Correttoを利用できるならgraviton3を利用が最もよい、ということとなります。java環境においてはgravitonに加えてAmazon Correttoの使用も積極的に検討するとよさそうですね！最後にこちらのベンチマークの再現方法を記述しますのでご参考ください。
1# phoronix-test-suite のインストール
2sudo amazon-linux-extras enable php8.0
3sudo yum install -y php-cli php-xml php-json
4sudo yum install -y perl-IPC-Cmd
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
10# 各種jdkのインストール
11sudo amazon-linux-extras enable java-openjdk11
12sudo amazon-linux-extras enable corretto8
13sudo yum install openjdk
14sudo yum install java-1.8.0-amazon-corretto
15sudo yum install java-11-amazon-corretto
16sudo yum install java-17-amazon-corretto
17
18# 利用jdkの変更
19sudo alternatives --config java
20
21# ベンチ実行
22phoronix-test-suite benchmark java-jmh