Amazon AuroraがARMベースのGraviton2プロセッサを搭載したインスタンスタイプのプレビューを開始 #reinvent

Amazon AuroraでARMベースのGraviton2プロセッサがプレビュー提供されました。

#Amazon Aurora

#ARM

#AWS Graviton

#AWS

quiver

2020.12.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSはARMベースの独自プロセッサGravition2を採用したインスタンスタイプをEC2/RDS/Elasticacheなどで提供しています。

このたび、Amazon AuroraでもGravition2を搭載したR6gインスタンスタイプがパブリックプレビューとして提供されました。東京リージョンもプレビュー対象です。

Introducing Amazon Aurora R6g instance types, powered by AWS Graviton2 processors, in preview

AWS Graviton2-based database instances are now available in preview for Amazon Aurora with PostgreSQL compatibility and Amazon Aurora with MySQL compatibility. Graviton2 instances are already generally available for Amazon RDS for MySQL, Amazon RDS for PostgreSQL, and Amazon RDS for MariaDB.

プレビュー対象

エンジン

MySQL : 2.09.1 以降
PostgreSQL : 11.9 以降

リージョン

US East (N. Virginia, Ohio)
US West (Oregon), Europe (Ireland, Frankfurt)
Asia Pacific (Mumbai, Singapore, Sydney, Tokyo)

パブリックプレビューのため、プレビュー申請は不要です。

R6g インスタンスを使うには?

R6g はパブリックプレビューで提供されています。

プレビューが有効なリージョンでプレビュー提供されているDBエンジンバージョン(MySQL : 2.09.1以降、PostgreSQL : 11.9以降)を選択し、R6g 系インスタンスサイズを選択するだけで利用できます。

くれぐれも、プロダクション環境では利用しないでください。

データベースにとって R6g は R5 よりもどこが優れているのか?

開催中の re:Invent 2020 のセッション[DAT301]Deep dive on Amazon Aurora with PostgreSQL compatibility では、R6g の R5 に対するメリットとして以下の3点があげられていました。

R6Gはソケットが一つのため(NUMAノード数は一つ)、メモリアクセスが常にローカル
R6GはすべてのvCPUは物理コアでSMTを使っていないため、各コアをフル稼働するようなワークロードでも性能が劣化しない
パフォーマンスに対するコストが安い

順に解説します。

※以下のキャプチャーはすべて同セッションのもの

メモリアクセスが常にローカル

1つ目がNUMAノード数の違いです。

NUMA について Wikipedia から引用します。

NUMA（Non-Uniform Memory Access、ヌマ）とは、共有メモリ型マルチプロセッサコンピュータシステムのアーキテクチャのひとつで、複数プロセッサが共有するメインメモリへのアクセスコストが、メモリ領域とプロセッサに依存して均一でないアーキテクチャである。

このプロセッサとメモリのペアを NUMAノードと呼びます。

R5 の場合、複数のソケットとメモリーのペアがあり、ノード間はインターコネクトでつながっています。 vCPU(コア)が同じノードのメモリにアクセスする場合、ローカルアクセスと呼び、インターコネクトを経由して別ノードのメモリにアクセスする場合、リモートアクセスと呼びます。

ローカルアクセスがリモートアクセスより速いという直感は正しいです。

ワークロードによっては、メモリーアクセスが一様でないために、性能が思ったほど伸びない事がありました。

Gravition2を使ったR6gは1ノードで常にローカルアクセスとなるため、このようなことは起こりません。

SMT を使っていない

2つ目がSMTの違いです。

SMT について Wikipedia から引用します。

同時マルチスレッディング（どうじマルチスレッディング、英: Simultaneous Multi-Threading、SMT）とは、単一CPUにより複数の実行スレッドを同時に実行するプロセッサの機能。

Intelのハイパースレッディング(HT)などが該当します。

SMT の有無による違い

R5 はSMTを使っているため、実行リソースをペアになった2つのvCPU間で共有します。 R6g は SMT を使っておらず、各vCPUは物理コアに対応し、コア専有の実行リソースが割り当てられています。

vCPU を使い切っていない場合は、SMT を採用していても問題になりません。 SMT のペアとなるコアがアイドルのタイミングで、共有リソースを使用します。

R5 で SMT ペアのコアが両方ともフル稼働すると、専有したい実行リソースを2コアでシーケンシャルに共有しないといけないため、実行時間が長くなります。

R6では SMT は使わず各コアに専有リソースが割り当てられているため、このようなことは起こりません。

CPUバウンドなワークロードでの性能差

vCPUが2個の large インスタンスタイプに対して CPU バウンドな負荷をかけて性能を比較します。

1 vCPUだけを専有するような負荷をかけると(Connections=1)、R5.largeはSMTをつかっていないため、R5/R6に性能差はありません。

2 vCPUに対して同時に負荷をかけると(Connections=2)、SMTで2 vCPUを実現しているR5は1vCPU時と同じ性能なのに対し、R6は1.7倍の性能で処理します。

R6.large は 2接続(2 vCPU)でインスタンスに割り当てられたコアを使い切っているため、3 接続以上の場合は性能は伸びません。

自然なワークロードでの性能差

実際に近いワークロードの場合は、先程のような極端な差は出ませんが、それでも15%の性能差が出ました。

その上、R6g.xlarge($0.62/H@東京)はR5.xlarge($0.70/H@東京)よりも遥かに安価です。

大きいインスタンスタイプでの性能差

多くの CPU を同時に利用するようなユースケースで性能を比較します。

インスタンスサイズ	vCPU	メモリ(GiB)	$/H@東京リージョン
r5.16xlarge	64	512	$11.2
r5.24xlarge	96	768	$16.8
r6g.16xlarge	64	512	$10.024

グラフから以下を読み取れます。

r6g.16xlarge は最大 vCPU を使い切る64接続まではきれいに性能が向上
r6g.16xlarge は r5.24xlarge よりもvCPU数は少ないにもかかわらず、わずかに性能が良い

単純化のためr6g.16xlargeとr5.24xlarge の処理能力が同じと仮定すると、東京リージョンでの時間あたりでのオンデマンド費が 10.024/16.80 ≒ 0.60 のため、r5.24xlarge と同等の性能が r6.16xlarge を利用するよりも40%も安く手に入ることになります。

r5.24xlarge の潤沢なメモリーが不要な場合は、使わない手はないですよね。

Gravition2 をもっと知りたい！

re:Invent 2020 には当然のごとく、 Graviton2 のセッションもあります。

CMP302:Deep dive on AWS Graviton2 processor-powered EC2 instances

AWS Graviton2-based Amazon EC2 instances enable up to 40 percent better price performance than comparable x86-based instances for a broad spectrum of workloads, including application servers, microservices, high-performance computing, CPU-based ML inference, electronic design automation, gaming, open-source databases, and in-memory caches. This session dives into Graviton2-based EC2 instances, ideal workloads, benchmarks, and ecosystem support from AWS services, OSVs, and ISVs. It includes a demo of getting started with Graviton2-based instances for containerized workloads.

ぜひ、ご視聴ください。

各社のチップを比較した次の AnandTech の次の記事もおすすめです。

Amazon's Arm-based Graviton2 Against AMD and Intel: Comparing Cloud Compute