RDS Proxy!! Maxscale 오픈소스 전환

문제 상황

• Aurora MySQL Cluster Endpoint의 5초 수준 DNS TTL로 인한 순간 트래픽 편중
• RDS Proxy 적용 이후에도 scale-in 시 밸런싱 유지가 어렵고 엔드포인트 변경이 필요
• RDS Proxy 비용과 운영 리소스 낭비 부담

원인 분석

• Aurora의 클러스터 엔드포인트가 RO 노드 분배를 즉시 안정화하지 못하는 구조
• RDS Proxy는 custom endpoint 부재로 scale-in 활용에 제약
• 운영 중 엔드포인트 변경이 즉시 어려워 리소스 회수 지연

해결 방법

• RDS Proxy 대신 오픈소스 MaxScale로 전환
• aurora monitor와 information_schema.replica_host_status를 활용한 노드 모니터링 구성
• Autoscaling 및 failover 대응을 위한 별도 아키텍처와 자동화 스크립트 구현

성능/운영 포인트

• TPS와 CPU, connection 분배가 비교적 고르게 유지
• scale-in 중에도 밸런싱 유지 가능
• 설치형 MySQL에도 적용 범위 확장 가능

적용해볼 점

• Aurora 밸런싱 편중과 운영 비용을 함께 검토할 때 프록시 대안 비교
• 엔드포인트 제약이 있는 환경에서는 자동화 구성까지 포함한 전환 검토
• 작은 모듈부터 POC로 스펙과 트래픽 패턴을 단계적으로 검증