こんにちは。日本仮想化技術株式会社の水野です。
クラウドの魅力は必要に応じてサーバーのスペックを自由に変更できる柔軟さと、使ったぶんだけの従量課金のため、コスト最適化がしやすい所ですよね。そして当然ですが、インスタンスのコストは高スペックなものほど高くなります。そのため必要以上に高スペックなインスタンスを使うのは、コスト削減の面から避けたい所です。とはいえコストを意識しすぎて、パワー不足なインスタンスを選定してしまっては本末転倒でしょう。
必要な性能要求を満たし、かつ無駄なコストは減らす。このように、運用するシステムにとって最適なリソースを見積り、確保することを「サイジング」と呼びます。そしてサイジングを行うためには、なんらかの指標が必要です。その指標のひとつとして役立つのが「ベンチマーク」です。様々なテストを行ってサーバーの性能を可視化してみましょう。
Phoronix Test Suiteとは
今回は有名なベンチマークスイートであるPhoronix Test Suiteを使って、FJcloud-Vのインスタンスの性能を比較してみました。またクラウドだけではなく、弊社内のベアメタルのサーバーでも同じテストを行いました。ハードウェアの世代が異なるなど、前提が違うため単純な比較はできませんが、オンプレミスとクラウドのサーバーの性能差について参考にしていただけると思います。
OSはすべて、Ubuntu 22.04を使用しています。Phoronix Text Suiteは以下のコマンドを実行して、GitHubから最新のリリース(v10.8.4)をインストールしました。
$ wget https://github.com/phoronix-test-suite/phoronix-test-suite/releases/download/v10.8.4/phoronix-test-suite_10.8.4_all.deb $ sudo apt install ./phoronix-test-suite_10.8.4_all.deb
CPUのベンチマーク
比較するインスタンスとして、高コスパのc2、標準的なe2、ハイスペックなh2から、それぞれCPUが4コアのlargeタイプをチョイスしました。また比較用にオンプレミスのサーバーと、そのサーバーと同じだけのvCPU(32個)を持つh2-olarge256を用意しました。
インスタンスタイプ | CPU | CPUクロック | (v)CPU数 | 料金 |
---|---|---|---|---|
c2-large | Intel(R) Xeon(R) CPU E5-2697A v4 | 2.60GHz | 4 | 21円/時 |
e2-large | Intel(R) Xeon(R) Platinum 8168 | 2.70GHz | 4 | 31円/時 |
h2-large | Intel(R) Xeon(R) Platinum 8168 | 2.70GHz | 4 | 56円/時 |
h2-olarge256 | Intel(R) Xeon(R) Platinum 8280 CPU | 2.70GHz | 32 | 528円/時 |
metal(オンプレミス) | Intel(R) Xeon(R) CPU E5-2620 v4 | 2.10GHz | 32 | n/a |
Coremark
それではまず、CPUのベンチマークを取ってみましょう。それぞれのインスタンスで以下のコマンドを実行し、Coremarkを行いました。
$ phoronix-test-suite benchmark pts/coremark
結果はこのようになりました。グラフは1秒間のイテレーション数を表しており、グラフが長いほど高性能だと考えてください。
スペックがそもそも異なるので当然なのですが、やっぱりCPUコア数は正義です。それとCPU自体の違いや古さはあるとはいえ、h2-olarge256が、オンプレミスにダブルスコアで圧勝したのは意外でした。クラウドの仮想マシンは遅い、などと言うことはないのがよくわかります。またドキュメントにあるように、c2系とe2系の性能差はほとんどないようです。
Zstandardの圧縮
Coremarkではプロセッサの性能を数値化して比較できますが、その数値の差が、実際のワークロードでも同じような差になるとは限りません。そこでもう少し、現実的なシナリオに沿ったベンチマークも行ってみましょう。まずはZstandard(zstd)形式の圧縮です。以下のコマンドを実行します。
$ phoronix-test-suite benchmark pts/compress-zstd
結果がこちらです。1秒間に処理できたサイズを表しており、これもグラフが長いほど高性能です。h2largeが思ったほど伸びませんでしたが、おおむねCoremarkの性能比と似た結果になりました。
Linuxカーネルのビルド
続いて、Linuxカーネルのビルドにかかる時間を計測してみましょう。アプリケーションのビルドなどは何度も繰り返し行う作業でしょうから、実際のワークロードに即した指針になるのではないでしょうか。
$ phoronix-test-suite benchmark pts/build-linux-kernel
グラフはビルドにかかった時間を表しているため、短いほど高性能ということになります。h2-olarge256圧勝。
例えばCI/CDを行うような場合、ビルドやテストにかかる時間は生産性に直結します。コードをマージする度に10分待たされていては、仕事にならないでしょう。こうしたユースケースでは、高性能なインスタンスを投入するだけの価値があると言えるのではないでしょうか。
Apacheのベンチマーク
最後にApacheを使用して、毎秒どれだけのリクエストを捌けるかを計測してみましょう。同時接続数は1000としています。
$ phoronix-test-suite benchmark pts/apache
CPU性能だけに結果が左右されるテストではないため、傾向としては似ているものの、中身は少し変わってきました。やはり高性能なサーバーであればあるほど性能が出せるのは当たり前なのですが、c2largeでも毎秒6000リクエスト以上を投げられているわけです。この性能で十分な用途であれば、無駄にハイスペックなインスタンスよりも、安価なインスタンスを選択するのが正解でしょう。そのあたりの見極めが肝心です。
ストレージのベンチマーク
今度はストレージのベンチマークを取ってみましょう。
純粋にストレージの性能差を知りたかったため、今回はh2-largeのインスタンスを1台だけ用意しました。そこにFJcloud-Vが提供している、標準フラッシュドライブ、高速フラッシュドライブ、標準ディスク、高速ディスク、フラッシュドライブの5種類のストレージをそれぞれマウントしています。なお各ストレージの特徴と価格は以下の通りとなっています。
ストレージ | 特徴 | 価格 |
---|---|---|
ローカルディスク | サーバーのルートファイルシステムとなる、標準搭載のストレージ | n/a |
標準フラッシュドライブ | 一般的なWebサービスや開発環境など、汎用用途向け | 3円/時 |
高速フラッシュドライブ | 高いI/O性能が必要なシステム向け | 8円/時 |
標準ディスク | 【旧世代ディスク】一般的なWebサービスや開発環境など、汎用用途向け | 3円/時 |
高速ディスク | 【旧世代ディスク】高いI/O性能が必要なシステム向け | 8円/時 |
フラッシュドライブ | 瞬間的により高いI/O性能が必要なシステム向け | 40円/時 |
マウントした各ディレクトリと、インスタンスに標準で用意されているローカルディスクに対して、以下のコマンドでPhoronix Test SuiteのFioベンチマークを実施しました。エンジンにはPOSIX AIO、O_DIRECTを有効、ブロックサイズは8MBを指定しています。なおオンプレミスのサーバーは年式が古いこともあり、とんでもなくSSDが遅かったため、今回は比較対象にはしていません。
$ phoronix-test-suite benchmark pts/fio
リード性能
まずはシーケンシャルリードの結果を見てみましょう。
どれも2000MB/s越えと、十分に高速なようです。高価なフラッシュドライブが最高性能を出しているのは納得なのですが、インスタンスに標準搭載のローカルディスクがそれに迫る性能を持っているのは驚きでした。とはいえローカルディスクは、OS以外のデータ置き場としての使い方は推奨されていません。コンテンツを配置するのであれば、別途ストレージを用意することをお勧めします。
続いてランダムリードの結果を見てみましょう。
ランダムリードも似たような結果となりました。結果がほぼ横ばいである点から、リードに関してはストレージの性能を引き出し切っており、プランごとの性能差はほぼないと見てよいのではないでしょうか。しかし、標準フラッシュと高速フラッシュでは2倍以上の価格差がありますから、コンテンツを読み込む系のワークロードにおいては、安価な標準フラッシュで十分だと言えそうです。
ライト性能
続いてライト性能を見ていきましょう。まずはシーケンシャルライトの結果です。
ライトでは標準系のストレージと高速系のストレージの間に、圧倒的な差が出ました。最も高価なフラッシュドライブのスコアが伸び悩んだ点が気になりますが、これは計測誤差や条件によるものかもしれません。もっと小さなブロックサイズで、書き込みスレッド数を増やしたりすると、また違った結果が出るかもしれませんね。
最後にランダムライトの結果です。
こちらもだいたい同じ結果となりました。このことから、頻繁にライトが発生するデータベースのようなワークフローにおいては、これはもう高速フラッシュ一択……というより、標準フラッシュを使うのはアンチパターンだと言い切ってもよいのではないでしょうか。
なお、「○○フラッシュドライブ」と「○○ディスク」のように、同じ価格のものがラインアップされているのを不思議に思ったかもしれません。「○○ディスク」系は旧世代に該当するストレージで、古くから利用されている方のための互換性維持のために残っているようです。
新規に利用する場合は「○○フラッシュドライブ」系、つまり「標準フラッシュドライブ」「高速フラッシュドライブ」のいずれかを選択すれば問題ないと思います。
ベンチマークだけでなく、総合的な負荷試験も行おう
ここまでサーバーのCPUとストレージのベンチマークを見てきました。演算やデータの読み書きにおける、そのサーバーの"生"の性能は、なんとなく把握できたのではないでしょうか。
しかしながら、ITシステム全体のパフォーマンスは、個々のサーバーの能力だけで決まるわけではありません。
今回は紹介しませんでしたが、ネットワーク性能も重要ですし、ロードバランサーなど、ボトルネックになりえる他の要因も存在します。ベンチマーク結果は、サーバー調達の目安にはなりますが、これだけを根拠にせず、きちんとシステム全体に対しての負荷試験も行いましょう。