RDS Auroraのネットワーク速度上限

Aurora が強いのは今さらな話ですが、その中でもネットワーク・パフォーマンスについては公式数値を信じて扱っているところがありました。

本当に大丈夫か知っておきたい機会があったので、オラオラ検証をしてみたいと思います。

インスタンスのスペック

Aurora のスペック表はここです。

Aurora DB インスタンスクラス – Amazon Aurora

今回、扱うのはこの辺です。

クラス	vCPU	メモリGiB	ストレージMbps	ネットワークGbps
db.r6i.large	2	16	最大 10,000	最大 12.5
db.r6i.xlarge	4	32	最大 10,000	最大 12.5
db.r6i.2xlarge	8	64	最大 10,000	最大 12.5
db.r6i.4xlarge	16	128	最大 10,000	最大 12.5

r6g より r6i の方が若干高いですが、その分、性能が若干良いっぽいのと、スペック的にもネットワークGbps が高いので、こちらを検証対象としています。

果たして『最大 12.5 Gbps』という数値はどこまで本当なのか、【最大】という魔法の言葉・ベストエフォートで軽くあしらわれるのか、簡易的ではありますが検証していきましょう。

クライアントとDBデータの準備

まずは Aurora を起動します。バージョンは最新の【Aurora MySQL 3.04.0 compatible with MySQL 8.0.28】で、インスタンスタイプは【db.r6i.large】です。

次にクライアントをスポットで起動します。イメージは【Amazon Linux 2】でインスタンスタイプは【c6i.large】です。とりあえず mysql コマンドだけ入れます。

sudo yum -y install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022
sudo yum -y install mysql-community-client

sudo yum -y install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm

sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

sudo yum -y install mysql-community-client

データ生成ツールにお世話になります。

コマンドを用意して（arm64用が無いので c7g はやめた）

mkdir tmp; cd tmp
wget https://github.com/Percona-Lab/mysql_random_data_load/releases/download/v0.1.12/mysql_random_data_load_0.1.12_Linux_x86_64.tar.gz
tar xzf mysql_random_data_load_0.1.12_Linux_x86_64.tar.gz

mkdir tmp; cd tmp

wget https://github.com/Percona-Lab/mysql_random_data_load/releases/download/v0.1.12/mysql_random_data_load_0.1.12_Linux_x86_64.tar.gz

tar xzf mysql_random_data_load_0.1.12_Linux_x86_64.tar.gz

テーブルを作ります。容量を大きくするためにカラム数を増加、これでだいたい１行１KB になります。

MYSQL_HOST="gedow-test-01.cluster-aqwsedrftgyhuj.ap-northeast-1.rds.amazonaws.com"
MYSQL_USER="admin"
export MYSQL_PWD="********"

mysql -h $MYSQL_HOST -u $MYSQL_USER

mysql>
CREATE DATABASE test;
use test

CREATE TABLE `test`.`test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) DEFAULT NULL,
  `text01` text,
~snip~
  `text25` text,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

MYSQL_HOST="gedow-test-01.cluster-aqwsedrftgyhuj.ap-northeast-1.rds.amazonaws.com"

MYSQL_USER="admin"

export MYSQL_PWD="********"

mysql -h $MYSQL_HOST -u $MYSQL_USER

mysql>

CREATE DATABASE test;

use test

CREATE TABLE `test`.`test` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`user_id` int(11) DEFAULT NULL,

`text01` text,

~snip~

`text25` text,

PRIMARY KEY (`id`)

) ENGINE=InnoDB;

ツールを実行して完了です。残り時間の予測が出るのが素敵。

$ time ./mysql_random_data_load test test 1000000 \
>   --host gedow-test-01.cluster-aqwsedrftgyhuj.ap-northeast-1.rds.amazonaws.com --user=root --password=******
INFO[2023-08-24T06:50:29Z] Starting
2m54s [===>----------------------------------------------------------------]   8%

real    35m12.410s
user    58m22.249s
sys     2m14.349s

$ time ./mysql_random_data_load test test 1000000 \

> --host gedow-test-01.cluster-aqwsedrftgyhuj.ap-northeast-1.rds.amazonaws.com --user=root --password=******

INFO[2023-08-24T06:50:29Z] Starting

2m54s [===>----------------------------------------------------------------] 8%

real 35m12.410s

user 58m22.249s

sys 2m14.349s

だいたい 1GB ということを確認。

$ mysql -h $MYSQL_HOST -u $MYSQL_USER -e "SELECT * FROM test.test" > test.log

$ ls -lh test.log
-rw-rw-r-- 1 ec2-user ec2-user 975M Aug 24 07:31 test.log

$ mysql -h $MYSQL_HOST -u $MYSQL_USER -e "SELECT * FROM test.test" > test.log

$ ls -lh test.log

-rw-rw-r-- 1 ec2-user ec2-user 975M Aug 24 07:31 test.log

１クライアントでの消費リソース

一気に限界突破しようとせず、まずは１クライアントでの消費リソース量を記録します。

シンプルにテーブルを全件取得し、すぐ捨てる処理を永久ループさせるだけです。１回あたりだいたい８秒でした。

while true
do
  date
  mysql -h $MYSQL_HOST -u $MYSQL_USER -e "SELECT * FROM test.test" > /dev/null
done

while true

date

mysql -h $MYSQL_HOST -u $MYSQL_USER -e "SELECT * FROM test.test" > /dev/null

done

これで３分後にはメトリクスが天井に張り付くので記録します。

Client	c6i.large	CPU	45～100%
Server	r6i.large	CPU	31%
		NetworkReceiveThroughput	0.4 MB/s
		NetworkTransmitThroughput	146 MB/s = 1168 Mbps

Client がタイミング次第で CPU 100% であることから、この１：１の処理では Client 起因で限界がくることがわかり、その時の Aurora は 1168 Mbps となります。

Client は１台１ループ処理でほぼ限界とわかったので、２処理目を追加せず、複数台を用意することでさらなるトラフィックを発生させることにしました（※スケールアップだけだとEC2にも１台あたりの上限があるのでダメ）

Auroraインスタンスクラスごとのネットワーク性能値

最大12.5 Gbps と謳っているので、１クライアント 1.168 Gbps 出るから、それを超えるために 12台起動しました。特に想定外の症状が起きなければ、14 Gbps まで出せるリソース量なので、Aurora が先に音を上げるはず。

で、実際に EC2 c6i.large 12台でぶん回しつつ、Aurora のインスタンスクラスを上げていった結果がこちらになります。

r6i.large	CPU	100%
	NetworkReceiveThroughput	1.3 MB/s
	NetworkTransmitThroughput	426 MB/s = 3408 Mbps
r6i.xlarge	CPU	98%
	NetworkReceiveThroughput	2.8 MB/s
	NetworkTransmitThroughput	898 MB/s = 7184 Mbps
r6i.2xlarge	CPU	71%
	NetworkReceiveThroughput	3.8 MB/s
	NetworkTransmitThroughput	1540 MB/s = 12320 Mbps
r6i.4xlarge	CPU	29%
	NetworkReceiveThroughput	3.7 MB/s
	NetworkTransmitThroughput	1555 MB/s = 12440 Mbps

large, xlarge では CPU 上限が先に来てしまうので、今回の処理が最強のネットワーク・トラフィック発生方法と仮定すると、これらクラスでのネットワーク上限値に不安を感じる必要はない、ということになります。

2xlarge, 4xlarge はともに、CPU使用率に余力がある状態で、ネットワーク転送量が 12.5 Gbps弱となったので、これらの結果はネットワーク上限値がボトルネックになったと言っていいでしょう。

結論

以上の結果から、Aurora のネットワーク・パフォーマンスは、表記通り 12.5 Gbps 出る と結論づけて良さそうです。

だからといって必ずしも保証されるかというと現実的には違う気がしますし、それは 8xlarge 以上の『最大』表記がなくなっても同様です。物理的なネットワーク機やケーブルがある以上、近隣のリソースも大量転送していたら速度は出なくなるからです。

とはいえ、db.r6i.32xlarge で 50 Gbps と表記されているので、それと同等かそれ以上に全力で転送できるくらいの太いネットワークになっているかもですし、クラスの大きさによって構成や場所が変わるかもなのでわかりませんが、もし転送量がボトルネックになるとしても、スケールアップで逃げれる環境である、というのは素晴らしいことです。

r6g, r7g は上限が 16xlarge ですが、r6g.16xlarge は 25 Gbps に対して、r7g.16xlarge は 30 Gbps と高く、世代交代ごとにCPUだけでなく周辺も強化されていってそうな雰囲気が伺えます。

まぁ普通はCPU使用率の方が先にボトルネックになるし、ネットワークがボトルネックになる処理はかなり限定的だろうけど、安心材料としてお納めいただければと思います:-)