RDS Proxy에서 Maxscale 오픈소스로 전환

Aurora MySQL의 Cluster Endpoint는 RW/RO 엔드포인트를 제공하지만, DNS TTL 5초 때문에 순간적인 트래픽이 몰리면 RO 노드 분산이 깨졌다. 이를 해결하려고 Hikari connection pool → Aurora Protocol → RDS Proxy까지 거쳤지만, RDS Proxy는 custom endpoint가 없어 scale-in 시 활용이 어렵고 엔드포인트 변경 작업도 운영 리소스를 잡아먹었다.

검토 목적은 크게 세 가지였다.

• 밸런싱 깨짐 현상 해소
• 엔드포인트 변경 작업 최소화로 인한 리소스 낭비 방지
• RDS Proxy 대비 낮은 비용 확보

기존 환경에서는 평소 DB CPU 사용률이 30% 이하였지만, 트래픽이 급증하면 AutoScaling과 scale-in이 반복되는 구조였다. 그 과정에서 일부 RO 노드로만 트래픽이 몰려 노드 간 CPU 차이가 70% 이상 벌어졌고, RDS Proxy를 써도 scale-in 시점의 제약은 해결되지 않았다. 여기에 VCPU 기반 비용까지 더해져, 최종적으로 Maxscale 전환을 검토하게 됐다.

Maxscale은 데이터베이스 프록시로서 Query Routing & Splitting, High Availability, Scalability, Security를 제공한다. 테스트는 별도 테스트 장비 → 작은 모듈 → 본 적용 순으로 진행했고, 이후에는 RDS뿐 아니라 설치형 MySQL에도 적용 가능한 구조로 확장했다.

검토와 테스트에서는 다음을 확인했다.

• 라이선스: 2.2.21까지 GPL 전환, 2.1부터 Aurora 지원
• TPS: RDS Proxy 가이드와 유사하게 약 5% 차이 수준으로 큰 격차 없음
• 밸런싱 성능: CPU와 connection 분배가 안정적으로 개선
• scale-in 대응: Maxscale로 밸런싱은 유지됐지만, Cluster Endpoint는 지원하지 않음
• Failover: 자동화 기능을 별도 구현해 대응
• 포트 제약: RDS Proxy의 3306 제한과 달리 다른 포트도 사용 가능
• 가용성 스펙: 처음엔 m5.2xlarge → m5.xlarge → c5.xlarge로 줄였고, 최종적으로는 네트워크 트래픽까지 고려해 c5n.xlarge로 적용

Aurora 대응은 auroramon 모듈과 aurora_server_id, information_schema.replica_host_status를 활용해 모니터링하고, Autoscaling 트리거를 캐치하는 아키텍처와 자동화 스크립트를 별도로 구성해 보완했다. 그 결과 DB에 들어오는 트래픽을 Maxscale이 받아 주면서 CPU와 connection이 더 일정해졌고, RDS Proxy 제거로 연간 비용 절감도 달성했다.

이 방식은 기존 설치형 MySQL의 트래픽 쏠림과 세션 지연 문제에도 적용됐다. 한쪽으로 몰리던 Active Session과 CPU를 트래픽 분산으로 완화하면서, 운영 중인 DB의 병목을 줄이는 방향으로 확장 가능성을 확인했다.

마지막으로, 이번 전환은 단순한 프록시 교체가 아니라 WAS 설정값, 스펙 산정, POC 시 고려사항까지 다시 점검하는 계기가 됐다. Aurora의 밸런싱 깨짐을 겪는 환경이라면, Maxscale은 충분히 검토할 만한 오픈소스 대안으로 정리된다.