キーポイント
- Arm-based systems and instances are readily available in public clouds such as AWS.
- The computational performance of AWS’s Arm EC2 instances is similar to that of the x86_64 instances.
- Considering that Arm instances are significantly cheaper, the cost effectiveness of Arm instances are better than x86_64 instances.
- Arm instances perform better with “close to metal” applications. We hypothesize that the operating systems have received more engineering efforts to optimize for Arm than high level application frameworks.
- WebAssembly VMs outperform Docker and Node.js significantly for computational applications.
ハイパフォーマンスなArmベースCPUの、モバイルデバイス以外での採用が増えている現在、一般的なサーバ側ソフトウェアスタックでのArmのパフォーマンス特性を理解することは、開発者にとって非常に重要です。今回の記事では、AWSのArm(Graviton2)とx86_64(Intel) のEC2インスタンスを使用して、DockerやNode.js、WebAssemblyなど、さまざまなソフトウェアランタイムにおける演算パフォーマンスを評価します。結論として、Armはクラウドにおいて、特に基盤となるオペレーティングシステムに近い軽量なランタイムでは、より費用対効果の高いことが分かりました。
背景
先日Scienceに掲載された研究論文で、MIT教授のLeiserson氏、Thompson氏らが、今日のコンピュータエンジニアリングにおける最も重要な問題 — Mooreの法則の終焉について論じています。CPUやGPUといったコンピュータハードウェアは、すでに量子的限界に達していて、これ以上速く、あるいは小さくすることはできません。この事実が、テクノロジの革新に支えられた40年間の生産性向上と経済的成長の脅威となっているのです。私たちの知っているテクノロジ革命は終わりを告げたのでしょうか？しかし論文は、テクノロジの将来を楽観的に見ています。
ソフトウェアの向上がMooreの法則に置き換わって、今後の生産性向上を主導する、と著者らは提言します。その説明として著者らは、マシンラーニングアルゴリズムをPythonからCなどのネイティブコードで書き直すことによって、パフォーマンスを60,000倍(!)に改善した例を挙げています。
しかしながら、最新のソフトウェアランタイムや、それらによって実現した開発生産性を放棄して、Java登場以前の1990年代に戻り、すべてのアプリケーションをコンパイルされたネイティブコードで実行するというのは、とても受け入れられる話ではありません。今日の開発者たちは、ハイレベルなプログラミング言語やツーリング、特にメモリ安全性やポータブルなランタイムの力を借りて、高品質なソフトウェアプロダクトを提供しているのです。
Scienceの論文の著者らの提案する、ソフトウェアパフォーマンスエンジニアリングのアプローチは、ソフトウェアをスリム化し(膨張部分を取り除き)、よりハードウェア効率のよいものにする、というものです。
今回の記事では、クラウドコンピューティングのシナリオにおいて、軽量で効率的なソフトウェアとハードウェアのインフラストラクチャを採用することによるパフォーマンス向上を評価します。具体的には、いくつかの軽量ソフトウェアランタイムを、エネルギ効率のよいArmベースのCPU(AWS Graviton2)と、Intel x86 CPUの両方で実行します。
この調査の目的上、対象とするのは単一スレッドのパフォーマンスです。Webアプリケーションの大部分は、デフォルトとして"要求毎に1スレッド"で動作している、というのがその理由です。ユーザの視点から見たWebサービスのパフォーマンスは、単一のCPUが実行可能な速度によって事実上制限されますから、これは、生のパフォーマンスを表現するための、意図的に単純化したテストケースであると言えます。
ベンチマークには、以下のものを選択しました。
- 次の２つのベンチマークは、コールドスタートのパフォーマンスを評価します。
- nopテスト — アプリケーション環境を開始して終了します。
- cat-syncテスト — ローカルファイルをオープンして128KBのテキストを書き込み、終了します。これによって、オペレーティングシステムコールのパフォーマンスを評価します。
- 次の4つはComputer Languages Benchmarks Gameからのものです。このベンチマークは、クラウドソースされたベンチマークプログラムを25以上のプログラミング言語で提供するもので、起動後のランタイムパフォーマンスを評価します。
- nbody — n-bodyシミュレーションを5,000万回繰り返します。
- fannkuch-redux — 12回の繰り返しで、整数シーケンスへのインデックスアクセスを測定します。
- manderlbrot — Mandelbrot集合のポータブルなビットマップファイル生成を15,000回繰り返します。
- binary-tree — 大量のバイナリツリーの獲得と解放を21回実行します。
次に、詳細なテストのセットアップと、いくつかのパフォーマンス値を見ていきましょう！すべてのテストケースのソースコードとスクリプトはGitHubから入手可能です。
ソフトウェアのスリム化
ソフトウェアの安全性、セキュリティ、クロスプラットフォームなポータビリティを維持するために、ベンチマークはコンテナおよびVM内で実行します。最もポピュラーなコンテナランタイムのひとつはDockerですが、これにはすでにパフォーマンス面での最適化が施されています。ソフトウェアスタックのパフォーマンスを評価するために、以下のテストケースをAWS t3.smallインスタンス上で実行しました。このインスタンスは、2つのvCPUで構成される物理的CPUコアを備えています。パフォーマンステストを通じて100パーセントのCPUバーストを維持するのに必要なCPUクレジットを獲得するため、インスタンスは十分に長い時間、アイドル状態を保つようにしました。
テストケース #1: Webアプリケーションのパフォーマンスをシミュレートするために、Docker内で動作するNode.jsのJavaScriptアプリケーションとしてベンチマークテストを実行します。
テストケース #2: C/C++ネイティブアプリケーションのベンチマークテスト、これも同じく、Ubuntu Server 20.04 LTSのDocker内で実行します。アプリを単一のバイナリ実行ファイルにコンパイル可能なケースは稀であるという意味から、このシナリオには多少非現実的な部分がありますし、Node.jsのようなランタイムの提供するツールやライブラリのエコシステムを無視している、という面はありますが、Docker下で達成可能なパフォーマンスの比較点は提供してくれます。
テストケース #3: Second State WebAssembly VM (SSVM)内でベンチマークテストを実行します。プログラムはRustで記述され、WebAssemblyバイトコードにコンパイルされます。SSVMは安全性、ケーパビリティベースのセキュリティ、ポータビリティ、Node.jsとのインテグレーション、といったものを提供してくれます。
ケーパビリティベースのセキュリティでは、保護されたリソースにアクセスするために、アプリケーションは認証トークンを所有し提示する必要があります。またSSVMでは、アプリケーションは、ファイルシステムフォルダなどアクセスの必要なリソースを、スタートアップ時に明示的に宣言しなければなりません。このような設計はWebAssembly System Interface (WASI)と呼ばれます。
私たちがテストケースに使用したソフトウェアスタックは、次のようなものです。
- EC2インスタンス上で動作するAmazon Linux 2
- Docker 19.03.6-ce
- Docker上のUbuntu Server 20.04 LTS
- Docker上のNode.js v14.7.0
- ネイティブ実行ファイルは、LLVM 10.0.0とClangツールチェーンを使ってコンパイルされています。Intelアーキテクチャでは、Clangの -O3 フラグを使用しました (このセクション参照)。Graviton 2では、AWSが推奨するLLVM最適化設定を使用しています。
- AOT(Ahead-of-Timeコンパイラ)最適化を有効にした、Second State WebAssembly VM(SSVM) 0.6.4。
Intelアーキテクチャでの実行結果は次図のとおりです。実行時間の単位はすべて秒で、数値の小さいほどパフォーマンスが優れています。なお、SSVMのコールドスタートはDockerよりも数桁高速なため、このグラフで表示できるようにコールドスタート時間を50倍しています。コールドスタートの問題は、実行回数の少ないマイクロサービスにおいて特に重要です。例えばサーバレス関数では、大部分が散発的なイベントに応答するものであることから、関数呼び出し毎にランタイムのコールドスタートが実行されるようになるのです。
注目される点:
- SSVMのコールドスタートが20ms未満であるのに対して、Dockerは700ms以上を要しています。SSVMは30倍以上高速である、ということになります。
- 計算集約的なランタイムタスクでは、Docker+ネイティブとSSVMは、Docker+Node.jsより約2倍高速です。
- Docker+ネイティブはSSVMにパフォーマンス面で劣る上に、Node.jsやJavaScriptのエコシステムによるメリットを放棄することから、賢明な選択肢ではありません。
SSVMのプログラムはネイティブコードよりもさらに高速に実行されています。なぜこのようなことが可能なのでしょう？SSVMでは、実行時にAhead-of-Time(AOT)コンパイル技術を採用しています。これによってコンパイラは、CPUアーキテクチャのクラス全体を対象にした汎用的な最適化ではなく、現在実行されているマシンに特化した最適化が可能になるからです。
OSレベルのコンテナ(Dockerなど)からアプリケーションレベルのVM(SSVMなど)にスイッチすることで、パフォーマンスの大幅な向上が実現することが分かりました。SSVMで実行するためには、Node.jsアプリケーションを多少変更する必要がありますが、実行時の安全性やセキュリティ、ポータビリティに加えて、Node.jsのエコシステムすべてを活用できるメリットがあります。
効率的なハードウェア
Leiserson、Thompson両教授らの提唱する、ソフトウェアによるパフォーマンスエンジニアリングソリューションでは、既存のソフトウェアをスリムにするというだけではなく、ハードウェアデバイスのソフトウェア利用効率の向上も求めています。高度に制限されたコンピューティング環境(モバイル機器上など)で長年にわたって設計されてきたことにより、Armアーキテクチャは、汎用ソフトウェアプログラムを高い効率で実行するための、ユニークな機会を提供しています。Armをサーバ側仮想化に最適化するというAWSの先駆的開発によって、AWS Graviton2ベースのAmazon EC2インスタンスは、Webアプリケーションのパフォーマンスを大幅に向上する可能性を私たちに提供してくれるのです。このセクションでは、同じベンチマークテストをAWS t3.small(x86)とt4g.small(ArmベースGraviton2)の各インスタンスで実行しました。構成はほぼ同じですが、時間当たりコストではt4g.small(Arm)の方が約24パーセント安価です。
- t3.smallインスタンスタイプは、最高3.1GHzのTurbo CPUクロック速度を備えた、Intel Xeon Platinum 8000シリーズプロセッサ(x86_64)を備えています。ひとつの物理コアと2GB RAM上で動作する2つのvCPUを提供して、料金は0.0208ドル/時間です。
- t4g.smallインスタンスタイプは、クロック速度2.5GHzのAWS Graviton2 CPU (Arm64あるいはaarch64)を備えます。2つの物理コアと2GB RAM上で動作する2つのvCPUを提供して、料金は0.0168ドル/時間です。
従ってマルチスレッドアプリケーションでは、AWS Graviton2プロセッサの方が高いパフォーマンスを提供するのですが、前述のように今回の記事では、ベンチマークアルゴリズムの単一スレッド実装のみでテストを行います。
IntelおよびGraviton2によるベンチマークの結果を下図に示します。実行時間の単位はすべて秒で、数値が小さいほどパフォーマンスに優れています。
次の図は、CPU時間とEC2のそれぞれのCPUタイプの時間料金を考慮して、費用対効果の側面からベンチマークを示したものです。すべての数値は、0.001米セントを単位としたベンチマークオペレーションの実行コストで、数値が小さいほどコスト当たりのパフォーマンスに優れています。
注目される点:
- SSVMはこちらでも最高のパフォーマンスを達成していて、いずれのCPUプラットフォーム上でも、起動時間はDockerより100倍、実行時パフォーマンスはDocker + Node.jsの5倍(mandelbrotベンチマークの場合)の速度を示しています。
- ボードの比較ではGraviton2の方が、Intel x86 CPUよりもコスト/パフォーマンスで優れています。
- 特にネイティブバイナリの実行時には、Itelを大幅に上回るパフォーマンスを示しています。
- Node.jsとSSVMのパフォーマンス比較では、Graviton2とIntelは拮抗していますが、Graviton2インスタンスが24パーセント安価であることを考えれば、コスト/パフォーマンスでは優位に立っています。
この結果は、ベースラインにあるLinuxオペレーティングシステムがすでにARM CPU用に最適化されていることにより、ネイティブバイナリがGraviton2のパフォーマンス能力を最大限に発揮できているためだと思われます。ただし、Node.jsやSSVMといったスタック上位のフレームワークやランタイムソフトウェアに関しては、サーバやクラウド環境におけるArmの使用が比較的新しいものであるため、Arm CPU用の明確な最適化は行われていません。サーバサイドソフトウェアのArm版に関しては、改善の余地はまだまだ残っています。
分かったこと
今回の記事では、一般的に使用されるアルゴリズムやWebアプリケーションタスクを異なる計算アーキテクチャ上で比較しました。さらに、レガシスタックのDockerおよびNode.jsと、新しいスタックであるSSVM(WebAssembly)を比較し、コールドスタート時で最大100倍、ウォームランタイムで最大5倍のパフォーマンス改善を確認しました。改善の余地は、特にArmベースCPU用のソフトウェア最適化に関して、まだ大幅にあると思われます。
ポストMooreの時代において、テクノロジが引き続き社会の生産性をリードするためには、ソフトウェアスタックの改善が不可欠です。その頂上には、成長の余地がまだまだあるのです！
著者について
Michael Yuan博士は、ソフトウェアエンジニアリングに関する5つの書籍の著者です。最新刊である"Building Blockchain Apps"は2019年12月、Addison-Wesleyより出版されました。博士はまた、WebAssemblyとRustテクノロジのクラウド、ブロックチェーン、AIアプリケーションへの適用を目指すスタートアップである、Second Stateの共同設立者でもあります。Second Stateは高速で安全でポータブルな、サーバレスのRust関数をNode.js上でデプロイ可能にします。WebAssembly.Todayニュースレターを購読して、最新情報を手にいれてください。