RDS Graviton2 インスタンスを試してみた（MySQL 編）

4476 ワード
RDS AWS MySQL MySQL8.0 MySQL テキストリンク

先に、こちらの記事で Amazon RDS の PostgreSQL 12.4-R1 を使って Graviton2 インスタンスと Intel x86_64 インスタンスを比較してみたところ、判断が難しい微妙な結果が出ました。

結果の概要は以下の通りです。

  • m6g.xlarge(Graviton2) vs m5.xlarge(Intel x86_64)
    • 4vCPU・メモリ 16GiB
  • 最初に試した「3 種類の主キーでひたすらINSERT対決」では「引き分け」
  • 追加で試したpgbenchでは m6g.xlarge に軍配が上がる
    • ただしインスタンスを m6g.4xlarge・m6.4xlarge（いずれも 16vCPU・メモリ 64GiB）に上げてpgbenchしてみたところ、SSD（汎用 IOPS）の書き込み IOPS の上限に突き当たって判断が難しい状況に
  • 先に MySQL 8.0.22 on EC2(gp3) でサーバローカルからmysqlslapを実行して試したときはｖCPU 数が少ないうちは Graviton2 が高速だが、vCPU 数が多い環境で高い負荷を掛けるほど Intel x86_64 が高速という結果が出ていた

そこで今回、RDS MySQLを使って「追試」を行ってみました。

追試の内容

  • RDS MySQL 8.0.21 (m6g.4xlarge / m5.4xlarge・700GiB SSD) を使ってmysqlslapを実行
    • mysqlslapのmixedで、スレッド数 150・300・450・600・750・900 で負荷を掛けて所要時間を比較
      • この範囲ならpgbenchとは違って 10,000 IOPS 以下の範囲で収まる
    • パラメータグループはデフォルト
    • バックアップを無効化してバイナリログを出力しないように
  • MySQL 8.0.22 on EC2 (m6g.4xlarge / m5.4xlarge・200GiB gp3 SSD 16,000IOPS) に対してもネットワーク越しにmysqlslapを実行してあらためて RDS と比較
    • CentOS 8.3
    • innodb_log_writer_threadsは有効（デフォルト）
    • バイナリログは ON / OFF の 2 通りで
mysqlslapの内容
mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=【スレッド数】 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=mixed -u mysqluser -h 【RDSエンドポイントまたはEC2のIPアドレス】 -p

※MySQL on EC2 ではinnodb_dedicated_server=ONでバッファプールサイズ等を調整・max_connections=1000に設定

結果 1 : RDS MySQL 8.0.21

縦軸は所要時間（秒）。値が低いほど高速です。

RDS PostgreSQL の結果（書き込み IOPS の上限に突き当たる前）と同様、Graviton2 インスタンスのほうが高速という結果に。スレッド数を増やして負荷を上げるほど差が大きくなりました。

結果 2 : MySQL 8.0.22 on EC2

  • バイナリログ ON

  • バイナリログ OFF

RDS MySQL の結果とは逆に、バイナリログ ON / OFF とも Intel x86_64 インスタンスのほうが高速になりました。vCPU 数の多いインスタンスを使ってサーバローカルでmysqlslapを実行したときと同じですね。

まとめ

それぞれで真逆の結果が出ました。

汎用的な CentOS 8.3・MySQL Community Server 8.0.22 rpm パッケージと比べて、RDS 環境では Graviton2 向けに何らかのチューニング・最適化が行われているのかもしれません。