2018/01/13 추가:
「AWS가 다시 패치를 하고 싶다」라는 정보가 있었으므로, 3번째의 벤치마크를 실시했는데, db.r4.large 및 db.r4.xlarge에 대해서, 2017/10/말 무렵과 거의 같은 속도로 돌아왔음을 확인했습니다.

「AWS, 또 패치 맞추고 있어」라고 들었으므로 3번째의 Aurora(MySQL 호환) R4 테스트(mysqlslap)

(이하, 낡은 정보이므로 현재와는 상황이 다릅니다.)

이전에, R4 인스턴스를 사용할 수 있게 되었을 때에 mysqlslap 로 성능 테스트를 했으므로, 이번, 같은 조건으로 다시 R4 인스턴스만 mysqlslap 해 보았습니다.

Amazon Aurora에서 R4 인스턴스를 사용해 보기 ※2017/10/30~31에 실시

mysqlslap의 내용

전회와 같습니다.

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%의 부하를 걸지 않기 때문에).

Qiita에 게시한 Amazon Aurora 관련 기사