[セッションレポート]RustとAWS Gravitonによるクラウドでの持続可能性 (DOP315) #reInvent

AWS認定トレーニング講師の平野@おんせん県おおいたです。

今日は「Sustainability in the cloud with Rust and AWS Graviton」というタイトルのセッションについてレポートします。

セッション紹介

AWSは、グローバルなインフラストラクチャの効率化と革新に注力しており、その注力は、開発者が下す決定がエネルギー消費とグリーンイニシアチブにどのような影響を与えるかを浮き彫りにしています。このセッションでは、エネルギー消費を削減し、生産性を向上させることができるRustとAWS Gravitonの利点について学びます。

オンデマンド動画

概要

• Rust とサステナビリティ
  • パフォーマンス
    • より速いコード / より少ないリソース
  • 信頼性
    • 再試行回数が減る / リソースが減る
  • 生産性
    • コーディングの高速化 / テストの削減 / リソースの削減

• AWS Graviton
  • クラウド用に設計された最新世代のAWS設計のプロセッサ
  • AWS Graviton3ベースのAmazon EC2インスタンスは、同等のインスタンスと比較して、同じパフォーマンスで最大60%少ないエネルギーを使用します。
  • Graviton3サーバーデザインは、他のAmazon EC2サーバーよりもソケット/ラックを50％増加させます。

他のプログラミング言語と比較したチャートを作りました。この背景には数字があるのですが、あまり具体的になりすぎないようにしました。

この表を見る限りでは、3つの主要なカテゴリーに分類されると思います。C#、Go、Javaはすべて、コンパイルして中間状態にした後、さらにランタイムの助けを必要とする言語です。コンパイル時に行われる部分と、実行時に行われる部分があります。そのため、コンパイル時に行われる部分と、プラットフォームライブラリやプラットフォームランタイム、あるいはチートされた中間コードなど、ランタイムに行われる部分があります。ですから、いくつかのワークロードを見ると、これらの言語では、悪くはないのですが、最高の持続可能性を得ることはできないことがわかります。

次に紹介するNode、Python、Rubyの3つは、いずれもインタプリタ型言語です。つまり、最終的にはソースコードからマシンコードに変換する必要があります。この3つの言語では、この変換をすべて実行時に直接行っています。インタプリタを本番環境にインストールしてからコードを実行すると、持続可能性の観点からパフォーマンスが低下しますし、他の言語ではそのためにパフォーマンスが低下します。

最終的にはマシン・コードを本番サーバーにコピーして実行すると、サステナビリティの観点から見た場合、Rustが最も優れた特性を発揮します。

• RustとJava
  • Rust
    • ランタイムなし
    • デフォルトでモノモーフィック
    • デフォルトでスタックアロケーション、ヒープにアロケートする場合はボックスが必要
    • AOTのみ
    • ハイジェニックマクロ
    • 非同期Rust
    • セーフ/アンセーフ
  • Java
    • Java仮想マシン - CG
    • 動的ディスパッチ (vtable)
    • ヒープ割り当て (プリミティブ型を除く)
    • プライマリJIT
      • インタプリタ、C1、C2
      • グラールAOT
    • リフレクション
    • Project Loom

• メモリレイアウト
  • Rust
    • デフォルトでスタックを確保
    • ヒープ割り当てオプトイン
    • ヒープ上の型消去された特徴的なオブジェクト(opt-in)
    • コストゼロの抽象化
  • Java
    • オブジェクトはヒープに割り当てられる
    • JITはエスケープ解析を行い、オブジェクトフィールドをCPUレジスタまたはローカルスタックにホイストできる
    • ヒープに割り当てられたオブジェクトにはヘッダ・オーバーヘッドがある

• Rustのトレードオフ
  • ヒープへの割り当ては安価でも自由でもない
  • Rustの型システムは一意な所有権を保証する
    • 同じメモリをエイリアスすることは推奨されない
    • 所有権に基づく新しいプログラミングスタイルが必要 - 古いパターンではうまくいかないこともある
  • ランタイムリフレクションの欠如
  • 動的ライブラリの読み込みが非常に限定的
  • 「難しい」言語

• JVMのトレードオフ
  • ガベージコレクション
    • オブジェクトの割り当ては非常に高速
    • メモリ管理が容易だが、万能ではない
  • ネイティブ・コンパイル
    • バイトコードを出荷し、JVMを持つあらゆるプラットフォームで実行可能
    • C2 はプロファイル誘導型の最適化コンパイラです。
    • コンパイルは起動時間に寄与する
    • Graal-native - 完全にネイティブなプリコンパイルパスを提供します。

• 実験
  • 私たちは、「マジックワームホール」アプリケーションを再現することにしました。
    • あるシステムから別のシステムへ安全かつ簡単にファイルを移動するために使用される
  • 原理
    • 開発者に好きなアプリを選ばせ、それを再実装し、測定し、プリプロセスを観察する。
  • 開発者の経験を捕捉する
    • どんなツールが使えるか？
    • 言語の意味的な違いは？
    • どんなライブラリが使えるか？
  • それぞれの性能はどうだったのか？

※以下実験の詳細がレポートされましたが、このブログでは割愛します。ご興味のある方は、ぜひ動画をご覧ください。

• エコシステム全体を考える
  • アプリケーションはどちらの言語でも簡単に書けることがわかった
  • ホットスポットのJVMは、起動が遅かったが、ウォームアップすると速くなった
  • 遅延ディスクI/Oの影響を無視してはいけない
  • Rustと比較して、Javaのパフォーマンスは予想以上に高速だった
    • 非同期TokioによるFSのパフォーマンスには驚いたが、予想されたトレードオフである
  • Rust は Java よりもメモリ使用率がかなり高かったが、マルチスレッド・アプリではもっと償却が進むと思われる
  • Javaはより成熟したライブラリを提供

• クラウドにおけるRustとGraviton
  • AWS Lambda 上で Rust と Graviton を使用すると、どのような違いが見られるか？
    • パフォーマンス
    • エネルギー効率
    • コスト
  • AWSのサンプルアプリケーションでは、複数の言語で同一のアプリケーションを実証
  • Javaサンプルは、Rustに合わせて128MBの関数に変更
  • x86とGravitonの切り替えの際、どちらのサンプルもマイナーチェンジが必要

• RustとGravitonのクラウド利用。まとめ
  • Rust （今日/このアプリケーション上）
    • Javaより速い
    • Java よりも経済的
  • Lambda/Graviton （今日/このアプリケーション上）
    • x86と同程度の性能
    • x86よりエネルギー効率が良い
    • x86より安価
  • 注意点
    • アプリケーションによって異なるかもしれません
    • 開発コストを無視してはいけない。特に書き換えはROIが上がらないかもしれない。
    • Lambdaの内部は常にパフォーマンスを向上させるために進化している

まとめ

持続可能性の視点でGravitonとRustを利用するメリットについてのセッションを紹介しました。ご興味があれば上記のリンクよりセッション動画をご覧ください。