2018/01/13追記：
「AWSが再度パッチを当てたみたい」という情報があったので、3度目のベンチマークを行ったところ、db.r4.largeおよびdb.r4.xlargeについて、2017/10/末頃とほぼ同じ速度に戻ったことを確認しました。
（以下、古い情報なので現在とは状況が異なります。）
以前、R4インスタンスが使えるようになったときにmysqlslapで性能テストをしたので、今回、同じ条件で再度R4インスタンスだけmysqlslapしてみました。
- Amazon AuroraでR4インスタンスを試してみる ※2017/10/30～31に実施
mysqlslapの内容
前回と同じです。
$ mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=mixed -u 【ユーザ名】 -h 【クラスタエンドポイント】 -p
結果
結構、衝撃的です…。
なお、暗号化の有無での性能差はわずかしかありませんでしたので、今回は暗号化ありの結果のみ掲示しておきます。
また、参考として、今回はdb.r4.2xlargeインスタンスの結果も加えておきます。
| 実施時期 | db.r4.large・バイナリログなし | db.r4.large・バイナリログあり | db.r4.xlarge・バイナリログなし | db.r4.xlarge・バイナリログあり | db.r4.2xlarge・バイナリログなし | db.r4.2xlarge・バイナリログあり |
|---|---|---|---|---|---|---|
| 前回(2017/10/末・Ver.1.15) | 48.860 | 57.737 | 33.133 | 37.857 | - | - |
| 今回(2018/01/上・Ver.1.16) | 74.779 | 91.679 | 45.433 | 54.413 | 34.180 | 39.621 |
| 性能比 | 65.3% | 63.0% | 72.9% | 69.6% | - | - |
※単位は秒。すべて暗号化ありの結果。
ちょうどインスタンスタイプ1段階分ぐらい遅くなっています。
もしかして前回インスタンスタイプの指定を1段階間違えたか？と思って請求情報を見たら、間違っていませんでした。
もちろん、クライアント側に問題がないか確認するためにクライアント側のEC2インスタンスもタイプを色々変えて試しましたが、結果は誤差の範囲でした（AZも一致していることを確認）。
ただ、実際のワークロードはmysqlslapとは違うので、プロダクト環境でどうなるかは実際の環境で確認・検証してください。
※明日から私もプロダクト環境と同等のステージング環境で性能テストです…つらいことになる予感。
追記：
参考までに記しておくと、db.r4.large・バイナリログありの今回（2018/01/上）分がピーク時CPU使用率90～100%程度、でした。
より大きなインスタンスタイプに対しても同じ負荷を掛けて計測しているため、（ディスク／ネットワークI/O側がネックにならないと仮定すれば）インスタンスタイプが大きいほど性能低下の程度が小さい、という結果が出るのは当然といえます（db.r4.xlarge以上に対しては100%の負荷を掛けていないので）。