AWSの新しいインスタンスタイプというか、新CPUに Graviton2 プロセッサという、表面上は物凄く適用したくなるものがあります。
これを無条件に採用してもよいのか、となると公式のアピール表現に疑り深い私としてはキッチリ調べるしかないわけで、久々に本気出した結果になります。
歴史
Graviton初出としては随分前のようです (2018/11)Graviton2 が発表され (2019/12)
EC2の標準的タイプに適用され (2019/12)
T系でも使えるようになり (2020/09)
そろそろAuroraに適用される雰囲気 (2020/12)
EC2だとAMIをArm用に変更する必要があるけど、出て時間が経つからスポット落ち着いたろうとか、Auroraなら１回停止して変更するだけで改善できるならエェやん。とか大雑把に良さげな風を感じて調査開始。
目的
調査する目的はいたってシンプルで、インスタンスタイプを第５世代から Graviton2 搭載の第６世代へ切り替えるだけで幸せになれるかどうかです。それ次第で、移行計画や適切な料金プランを考えていくことになります。
費用
Amazon EC2 オンデマンド料金 を見ると、たしかに c5 -> c6g や r5 -> r6g を比べると 20% ほど安くなっています。これは単に嬉しい。スポット比率は今現在 c5 が30% で c6g が 40% とちょい高め。
性能
公式のアピールとして、第５世代と比べて、処理によって 24～54% 性能向上しているという。これが本当なら、費用減少と合わせてかなりのコスパ向上になるので、盲目的に信じれば採用の一択です。
でも私はこういうハードウェアやミドルウェアのアピール数値は１～２割しか信じないことにしているので、他人の情報も調べつつ、自分でも調べます。インフラエンジニアとして盲目的に信じて、適用してみたら、あれ遅くなったぞ？じゃお粗末すぎるので。
情報収集
この後に記述する私の調査結果も含めてですが、特にCPUベンチマークは処理内容や並列度で、その測定値の意味合いが各々の環境ごとに変わるので、あくまで参考程度に留めましょう。結果論
あまり他所様に突っ込むのは好きじゃないですが、やたらとブクマがついてたので指摘しておきます。価格差３倍、年間180万円節約、LoadAverage減少 がポイントですが、これは結果論しか記されていないようなものなので、さすがにこれ見てGraviton最高！と思ってはいけないです。
この結果は、第６世代が全体的に20％安くなったことと、m5.large -> t4g.medium と１段階下げたことによる価格差であること。0.1 未満の LoadAverage での出来事であることを鑑みれば、性能に関してはたまたまグラフ上は少し向上したっぽいね、以上は言えません。
こっちも似た感じ。
こういう運用結果だけを抜き出したグラフも参考にする人はいるかもですが、正しく理解したい場合は、んん？ってなるだけなので、私としては避けていきたい系（すいません;-)
ベンチマーク結果
海外の記事を探したら、わらわら見つかりました。- Amazon設計のARMプロセッサ「Graviton 2」の性能はIntel製CPUにどれほど迫っているのか？ – GIGAZINE
- Arm CPU対x86 CPU – クラウドでのパフォーマンス分析
- Amazon’s Arm-based Graviton2 Against AMD and Intel: Comparing Cloud Compute
- SPEC – Single Threaded Performance
- SPEC – Multi-Core Performance Scaling
- SPEC – MT Performance (16xlarge 64vCPU)
- Cost Analysis – An x86 Massacre
- Benchmarking the AWS Graviton2 with KeyDB – M6g up to 65% faster
- Performance Metrics: AWS Graviton2 with Presto, M6g – Treasure Data Blog
- The NEMO Ocean Model on Arm Neoverse – HPC blog – High Performance Computing – Arm Community
- ARM vs Intel – A real-world comparison using EC2 – DEV Community
総合的に雰囲気をまとめると、
といったところでしょうか。
新規環境として用意するならば、最初から新世代で良さそうに見えますが、既存の──特にC5系のCPUは非常に高速なので、その辺との比較が個人的に気になるところです。
検証（初手）
ということで、あんま時間をかけ過ぎない程度に計測しました。計測方法
こちらに別途まとめておきました。OSは AmazonLinux2 の x86 or Armです。第６世代のインスタンスタイプは、Armイメージでのみ選択できて、旧世代は選択できないので、比較検証には２つのAMIが必要になります。
ベンチマークの種類は３つで、姫野・OpenSSL speed・PassMark です。どれも実行時にCPUスレッドが想定通りの数で100%になることを確認してあります。
ベンチマーク結果
画像で失礼:-)傾向を知れればよかったので、軽く 4vCPU までしかやってません。
左２つが旧世代、右２つが新世代で、C5を100%とした比較％を置いてあります。
新世代はCPU型番を見れないので、あえて他も型番を書きませんでしたが、数値からみてわかるとおり、c6g も r6g も同じCPUであることを推測できます。
第６世代は同CPU？
第５世代は、C5が飛び抜けて強く、M5とR5がほぼ同じでした。それだけに、メモリを大量に必要なわけではないアプリケーション・サーバーだとC5に強いメリットがあったわけです。軽くスペックをまとめてみましょう。
| Type | vCPU | ECU | Memory | $/hour |
| c6g.large | 2 | 該当なし | 04 GiB | 0.0856 |
| m6g.large | 2 | 該当なし | 08 GiB | 0.0990 |
| r6g.large | 2 | 該当なし | 16 GiB | 0.1216 |
| c5.large | 2 | 10 | 04 GiB | 0.1070 |
| m5.large | 2 | 10 | 08 GiB | 0.1240 |
| r5.large | 2 | 10 | 16 GiB | 0.1520 |
C5が一歩抜けた強さの割に全部 ECU=10 な時点でアレですが、さらに6g系は該当なしです。で、費用的には c5/m5 の比率と c6g/m6g の比率は同じ 86% です。
第５世代では、C5 はメモリが少ない分、安くCPUが高速だったので強い選択肢でしたが、第６世代ではメモリが少ない分、安い。だけになるので、C系を選ぶメリットがだいぶ弱くなりそうです。
単純に、14％安くしてc6gにするって考えよりも、14％高くしてメモリ倍の方がよくねっていう。そういうパターンのほうが多いんじゃないかと、いうだけで全然絶対じゃないですけど。
考えようによっては、AutoscalingGroupに複数のインスタンスタイプを指定するとき、c6g, m6g, r6g と混ぜてもCPU使用率の格差がAZ以外で起きづらくなるだろうから、扱いやすくなると言えなくもない。
vs C5
あまりに差が付きすぎて、自分のベンチマーク作業を疑っています。大雑把にみても、c5 -> c6g で性能が 50～70% 程度にダウン？ しかし、PassMark の各種結果の落差が激しいのが気になる…… そして標準的な演算に強く、暗号化や圧縮に弱いように見て取れる……
この結果だけだと、『実際のアプリケーションで試験したり、１台だけ本番グループに混ぜて様子見てみないと良くなるかわかんないッスね！』ってクソみてーなテンプレ回答になるので、、ふーーーッ……
これじゃ環境が壊れる……
続行しようぜ…… 久しぶりに…… キレちまったよ……
検証（ガチ）
Arm用イメージを作るのは面倒とはいえ、自社サービスで１台紛れさせてCPU使用率の差を観測してもいいんですよ。でもそれだと結局、「それ、あなたの環境ですよね？」
って言われたら選手生命が終わるんで、より深く潜る方法を探すわけです。
Phoronix Test Suite
Pythonとか軽量言語で網羅的なの探したけど、気に入るのがなくて、わりと昔からあるこれで頑張ってみることにしました。これの取り扱いについては、別途まとめるかもしれません。簡単に説明すると、phoronix-test-suite をインストールすると、様々なベンチマークテストのインストールや実行、ログ取り扱いを補助してくれる基盤のようなものが入ります。
テストは全部で 450 くらいあって、list-recommended-tests で 42 のオススメに絞ってくれるのですが、この時すでにキレちまってたので、可能な限り多く、可能な限り速く済ませてやんぜってことで、結局 90 に絞りました（recommended と近いやんけっていうのすらキレてて見えてない）。
ベンチマークツールによっては、all とか指定したらガーッと全部実行してくれたりするのですが、これはテストごとに必要なパッケージが異なっていたり、複数サーバーが必要だったり、色々なので all という選択はありません。
かといって手で実行してメモってなんてやりたくないので、可能な限りスクリプトにインストールと実行と結果まとめを落とし込んでいき、
- OSに必要パッケージがなければ潔くスルー
- 複数サーバーが必要ならスルー
- 結果の取得が不安定ならスルー
- 必要ストレージ容量が大きすぎるならスルー
- 処理時間が長すぎたらスルー
ベンチマーク結果
イメージは同じく AmazonLinux2 で、インスタンスタイプは 2xlarge (vCPU=8) です。テスト項目が多くて縦長なので、スプレッドシートのHTML版で公開しておきます。各テストの最終結果を記録し、c5 を 100% として性能比率を計算しています。単位(Unit) が時間系そのものの場合は数値が小さい方が良く、それ以外は数値が大きいほうが良い、ということをPercentileから判断し、c5 -> r5 , c5 -> c6g , r5 -> c6g の比較をしています。で、最終的に平均値だの簡単に出せる数値を計算して終わり。
Aurora が気になってたから r5 にしましたが、m5 でもほぼ結果は同じになるはずです。c6g <=> r6g が同じなのもさきほど確認とれてるので、必要に応じて読み替えてください。
平均値
c5 との比較を抜き出してきました。
r5 が c5 の 90% 程度の性能、というのは認識通りです。
c6g が c5 の 110% 前後の性能、と平均値から読み取れますが、いかんせん最小最大の落差が激しいのは PassMark での結果と同じ。極端な上下の結果を除いた平均値だと、ほぼ同じくらいの性能とも読めます。
また、r5 と c6g (= r6g) の比較なら、それなりに期待の持てる上昇率といえます。
落差
さて、これらの結果から言える最も重要なポイントは、平均的な性能比較ではなく、その落差にありそうです。仮に標準的な演算処理が速くとも、暗号化や圧縮／解凍が極端に遅いとしたら、どうなるでしょう。例えば、リソースの暗号化をOFFにしたAuroraの場合、r6g にすることで速くなるかもしれませんが、暗号化ON の場合は逆に遅くなるかもしれません。し、処理量の比率として暗号化が少なければ、さほど悪い影響はないかもしれません。
アプリケーションやデータ解析などでは、圧縮／解凍があったとしても、メイン処理はあくまでメモリ上での平文だとしたら、全体のパフォーマンスとしては良くなるかもしれませんし、仮に圧縮／解凍が遅かったとしても、並列数を増やして解決すればOKという設計思想があるのかもしれません。
結局、効果はサービスによる。というショッパイやつになりそうですが、今回は加えてその良し悪しがより顕著に出やすい。可能性がある。かもしれない。でしょう。
くらいまで Maybe しとけば大丈夫でしょうか。
費用
平均性能を見れば、c5 や r5 から c6g に変更することで同等以上の性能になるので、コストパフォーマンスとしては純粋に価格が抑えられた分の 20% 以上が上昇と捉えてよさげです。あとスポット費用比率が少し高めなので、その分はスポット台数比率に微影響、と。それ以上は……アプリケーションとして動かしてみないと何も言えね。
相性が良いことを祈る;-(
感想戦
もっとテスト数を増やしたり、並列数を増やしたら、比較結果が変わるかもしれないってのはモチロンあるんですけど、とりあえず表面から少し掘り下げた特徴が判明したので良しとします。オンプレ時代からずっとXeonだったせいか、まさかこんなに特徴的な差を観測できるとは思っていませんでした。こういう新世代ハードウェアが登場することは嬉しいですが、やはり公式アピール数値を鵜呑みにするのはちょーっと違うかなってのも確認できました。まぁ技術的見地と広報は別なので、正しく理解したければCPUの設計思想とか、そういうところから調査すべきなのかもですね。さすがに私はそこまでは、ですけども。
現場的には、新規構築なら最初から採用しちゃっても良さそうだと思いますし、旧世代からの入れ替えなら比較試験をキッチリした上でおそらく投入する判断になるのではないか、と思います。
Fargate とかだと今のところ関係ないでしょうけど、上が引き上げられることでサーバーレスに使用されるCPUも強くなるかもですし、今後に期待していきたいですね。
こんな調査を業務中に思いついてやり始め、軽く済ますつもりがキレて膨大な私怨調査になったので、久々に休日全ツッパして完走してやったぜ！
楽しかったからいいけど、ちょっと進行が雑で非効率な部分もあったので、精進の余地がある。頑張ろ:-)
