なんと前回の続きになります、懐疑的な漢ですよろしくおねがいします。
半分は掘り下げるべき部分があったこと、もう半分は試験方法の最適化をしたくなった欲望によるものございます。
目的
検証の掘り下げ
前回の結論を要約すると、こんな感じだったのですが- Good 😄
- 平均的な性能は第6世代(Graviton2)は第5世代より1割ほど高い
- 費用が第5世代より20％ほど安い
- 多数スレッド数になるほど性能を発揮するっぽい（情報収集より）
- Bad 😧
- 第6世代は処理の得手不得手の差が激しい
- 特に暗号化の性能が低い
- 第5から第6に切り替える場合、向上するかどうかは処理内容による
自分AWSの犬じゃないですけど、こう見ると期待が大きめだった分、少しネガティブな印象を残してしまったかなと。思ったので一部を深堀りすることで、もう少し特徴を捉えていくことにしました。
試験の最適化
前回はキレて Phoronix Test を駆け足気味で実行しました。それによって、テスト数が少なめになったこと、テスト手法が半自動・半手動みたいになってしまい、再試行性が薄めの処理内容になりました。具体的にはBashで書いたのですが、テスト方法がコマンドベースだからとBashにしてしまうと、正規表現などの文字操作や自動応答がやはり弱く、コーディング的にもアーキテクチャ的にもいまいちでした。
それをPython3で書き直しつつ、並列化して試験時間を短縮したり、可能な限り再試行を不要にして無駄を省いたり、していくことで改善しました。その結果、少しのコーディングとポチリで別カテゴリの試験を容易くできるようになったので、今回は２つほど調査結果を追加しました。
この辺の試験アーキテクチャ？のようなものは別途記事にしたいと思います。
Phoronix Test Suite
で、前回は 90/450 テストしかできなかったので、あまり手間のかからない範囲でテスト数を増やすぞと意気込んだのですが、改めて整理してみても、そもそも Arm で動かないテストが多かったり、何かが足りなかったり複雑だったり。結局 124 までしか増えませんでした。結果はこちら。
集計を抜き出すとこう。
傾向は前回と変わらず。数が増えた分、性能差のMax/Minが広がりました。
速いのは現場的にはヤッターで終わるのですが、遅いのはマズいことになるので、そのへんを見ていくと項目も結果もわかりやすいところではやはり暗号化、次いで圧縮あたりになりそうです。
この多数あるベンチマーク、ものによってはオプション的な選択があるのですが、自動化のために全部 1 を選択しているので多くが１スレッドでの処理となっているはずであり、多数スレッドを得意とするらしい Graviton2 にとってはフェアじゃないなと思った部分もあります。
なので、ここから注目した２つを並列化込みで検証していきます。
OpenSSL Speed
Phoronix を疑うわけではないですが、まだ５％くらいは暗号化が遅いというのは幻想かもしれないんですよ。前回のSSLは手動で１種類しか採らなかったので、アルゴリズムの種類を増やしつつ並列数を変化させて採取していきます。結果はこちら。
一応集計を貼っておきますけど、これは結果リストを見たほうが考察が進みます。
傾向
読み取れる傾向としては、第5世代と比べて- Good 😄
- 速い暗号化アルゴリズムがある（5/21）
- 速い復号がある（2/21）
- 速い暗号化はとても速い（150～300％）
- Bad 😧
- 遅い暗号化アルゴリズムが多い（16/21）
- 復号はほとんど遅い（19/21）
- 遅い暗号化はとても遅い（30～40％）
- 今回の選択肢では、平均的に1割超は遅い
- Special 🤔
- 最大vCPU数になると性能差が縮まる傾向が点在する
基本的に遅い
ほとんどの暗号化／復号が遅く、アルゴリズムによっては致命傷に近い差があります。暗号化に明るくないので比較だけですが、sha1, そしてsha2の内のsha256 は爆速なのに、sha512 は遅いので、名前は似てても取り扱い長さ以上に中身は全く別物とかでしょうか。もし暗号化に特化、または処理割合が多いシステムの場合、アルゴリズムを選べるなら速いものを。──とかそういうんじゃないですよね……暗号化って。
サーバー内の処理割合として、暗号化／復号が少なければ向上した他処理と平均すると気にしない程度になるでしょうが、もし比率が多くて第5世代から切り替える場合は、アルゴリズムと性能をチェックしてみるとよさげです。
最大スレッド数の問題
ここではまだ暫定ですが、最大スレッド数（vCPU=8 のサーバーで並列数=8）でのみ第6世代が伸びる傾向があります。これは第6世代が伸びるというよりは、第5世代がスレッド数に比例できずに伸び悩むことによって性能差が縮まる、という数値になっています。
CPUスレッドを使い切ろうとすると伸び悩む・天井にぶつかるとしたら、Software Interrupt や Context Switch あたりでしょうか。各種メトリクスも採取すれば何かしらわかるかもしれませんが、
異なるスレッド数で検証
さきほどのインスタンスは vCPU=8 だったので、vCPU=32 で全く同じ試験を回したものになります。正確には c5.x9large だけは vCPU=36 なのでフルパワーではない負荷となりますが……第5世代の vCPU=8 では 1 → 2 → 4 での倍々数値が → 8 で伸び悩みましたが、vCPU=32 では 4 → 8 で倍プッシュできているためスレッド数そのものが問題ではないとわかります。ところが、やはり 16 → 32 で倍付けできていなく、最大スレッドに近づくほど伸び悩む傾向にあります。
ところが、第6世代ではそのような傾向が低く、ほぼ 16 → 32 でも倍付けできています。
これを、第5世代が貧弱と捉えるか、第6世代が太陽を克服したと捉えるか、難しいところですが、第6世代の並列性能が強そうであるという片鱗は味わえたと仮定できます。
圧縮と解凍
最後に、AmazonLinux2にパッケージで簡単に入るものを使って、並列圧縮／解凍です。1GB のランダムテキストデータを元データにしています。圧縮も解凍も、アウトプットデータは /dev/null に捨てることで、ストレージの影響を排除しています。インプットデータもオンメモリのハズなので余計なブレは多分無し。
解凍は基本1スレッドになるので、そのまま記載した多並列の分は平均値によくない影響となりますが、集計値はそこまで重要じゃなさそうだったので、残しておきましたのご愛嬌。
集計も貼り貼り。
傾向
読み取れる傾向としては、第5世代と比べて- Good 😄
- 暗号化よりマシ。速くなるアルゴリズムもありそうと判明
- Bad 😧
- 一般的なアルゴリズムだと少し遅い（83～97％）
- Special 🤔
- 暗号化同様、最大vCPU数になると性能差が縮まる傾向にある
gzip や bzip2 はやや遅い
気にするほどではない遅さかもですが、少なくとも速くなる期待はしない方向がよさげです。例えばS3 Putをトリガーとして圧縮処理だけ起動、みたいな専用リソースならば、無難に c5系 を選ぶのが良いとは言えそうではあります。
xz がちょい速い
あんま使わないけど xz が速かったので、他にも速いのがある可能性。Phoronix の結果だと lz4 や zstd の数値が良いので、圧縮が遅いと断定するのではなく、モノによると言えそうです。
最大スレッド数の謎
暗号化同様、最大スレッド数に近いほど第5世代の伸び悩みが強く、第6世代もスレッド数の倍々に対して時間半々とまではいかなくとも良い数値を出しています。元容量が1GBなので、より大きくしたらよりハッキリした数値が見れるかもしれませんが、傾向としては十分存在しうる事象であると判断してよさそうです。
フルパワーの恩恵
仮定として、第5世代は全スレッド・フルパワーに近くなるほど伸び悩む傾向があり、第6世代はその弱点がほぼないかもしれない、とします。スレッド数をさらに 64, 128 と増やすとどうなるか、の情報は前回のリンク集にあったので参考にしてもよいかもですが、現実的には 128以上 とかほぼ使わないのでここではスルーでよいでしょう。
システムの種類として、ジョブやトリガーのような、データの出し入れだけで済むような類の場合、サーバー・リソースをフルに活用しても良い、というか活用したほうが早く終わるので、第6世代は適している可能性があります。ただし、苦手な処理の割合が少なければ、という注意事項付き。
WEBサーバーのような複数のクライアントがいるサーバー・リソースの場合、CPUフルになると処理待ち時間が発生してレスポンスタイムに影響するので、そもそも40～60％程度を上限としてスケールアウトします。こういう種類だと、戸愚呂100％の実力を見ることなく利用することになり、処理の得手不得手だけが比較対象となります。
DBサーバーのような即座のスケールアウトが難しいリソースの場合、想定外のトラフィックでフルパワーになったとき、第5世代より第6世代の方が土俵際に強いかもしれません。しれません、というだけで多分、WEBの想定外トラフィックは余裕ですぐ貫通してくる程度の耐久力差なので、平時の性能差の方を重要視すべきだと思われます。
その恩恵を受ける機会が少なかったり、恩恵を受けてるか認識するにはキッチリ試験しないといけない、という意味では日陰の地味な、でも確実な性能向上とすれば嬉しい特徴であると言えます。
感想戦
大枠の傾向や特徴が判明したので、やってよかった外道式。他にはエンコードとかも数値がそれなりに悪いので、全般的な印象として、データの変換処理に注意しつつ採用トライしましょう、という感じ。
一般的にはWEB・APP・DB あたりで性能を発揮してくれれば幸福度が高いので、平均値的にはおそらく期待に応えてくれるだろう、でも油断はしないでおこう。くらいになると思います。
多くの現場では、新しいし安いので採用しよう、でも十分通用するでしょうし、本試験としては向上・悪化の可能性の思考を広げられれば成果として十分でしょう。
どちらかというと、自分の突貫試験が気に食わなくて手直しできたのが満足で、それを今後に応用して役立てていきたい感じがするので、そのへんのアプローチなど整理していきたいと存じます:-)
