이번에 Aurora MySQL을 운영하면서 겪기 쉽지 않은 상황을 경험하여 해당 내용을 공유하겠습니다. MySQL innodb 엔진의 경우 innodb_buffer_pool_size 값은 성능에 큰 영향을 미칠 수 있습니다.
서비스에서 운영하는 DB 스펙은 아래와 같습니다.
db.r5.4xlarge
vCPU 16 / RAM 128
엄청나게 많이 기록되고 있는 Slow Query와 IOPS 수치와 50GB의 가용 메모리... 문제가 있음을 느끼고 버퍼 풀 설정을 확인합니다. 설마 했지만 128 RAM에 innodb_buffer_pool_size 값이 5GB가 박혀있었습니다... 누가 대체 왜... 어떻게 이런 일이 발생했는지 퇴사한 기존 담당자들에게 연락을 해보지만 다들 자기는 하지 않았다는... 제가 이곳에 오기 전까지 최소 2년 이상 이 상태로 RDS가 운영되어왔습니다.
Aurora의 경우 innodb_buffer_pool_size 값은 DB 메모리 값의 75% 가 디폴트 설정인데 잘 못 설정된 기존 파라미터 그룹을 복제해 생성하면서 이러한 사태가 발생한 것으로 추측됩니다.
버퍼 풀 사이즈를 늘리는 것은 크게 문제가 되지 않으나 CW 상의 가용 메모리는 약 46GB 정도로 표시되고 있었습니다. 설정된 5GB 대비 60GB의 메모리를 Aurora 프로세스가 점유하고 있었기에 천천히 버퍼 풀 크기를 늘려가며 메모리 모니터링을 진행하기로 합니다.
운영 환경에서 진행하기에 유입량이 적은 새벽 시간대에 Failover를 통해 버퍼 풀 변경 작업을 진행합니다.
1. 버퍼풀 사이즈 32GB로 변경
기존 메모리가 46 -> 84GB로 올라온 것을 확인할 수 있었습니다. Failover로 기존 인스턴스의 재부팅이 진행되면서 할당된 프로세스 메모리가 해제된 것으로 보입니다.
2. 버퍼 풀 사이즈 80GB로 변경
84GB의 여유 메모리가 있기에 기존보다 약 50GB의 버퍼 풀을 추가로 할당하기로 합니다. (약 RAM 60%) 진행 이후 메모리는 약 22GB 정도로 내려갑니다.
해당 DB는 최종적으로 버퍼풀 사이즈를 80GB로 유지하기로 합니다. 기존에 Aurora 프로세스 메모리가 과하게 할당된 문제도 존재하고 6000 QPS가 발생하는 것 대비 최적화되지 않은 무거운 쿼리가 많이 발생하기 때문입니다. 우선 쿼리 최적화를 진행하고 메모리에 여유가 있을 경우 버퍼풀을 더 할당하기로 하였습니다.
이후 한 달이 지난 지금 트래픽은 약 10% 늘어난 것 대비 많은 지표가 개선되었습니다.
IOPS 최고점 대비 97% 감소
Slow Query 대부분 해소
Buffer Cache Hit Ratio 감소 해결 (기존 97%까지 떨어짐)
Select latency 16% 감소
어느정도 트래픽이 있는 환경에서 버퍼풀이 잘못 설정될 경우 성능에 큰 영향이 있을 수 있으니 주의해야합니다. 또한 버퍼 풀 이외에도 Aurora를 운영하는 파라미터 그룹의 가변 변수를 임의로 설정한 후 복사할 경우 다른 인스턴스에 적용하기 전에 반드시 확인합시다!