메가MGC커피, Aurora Serverless v2로 DB 전환 성공!
모바일 주문 트래픽이 오전 시간대에 집중되는 트래픽 패턴(Traffic Pattern)으로 인해 기존 RDS for MySQL의 고정 인스턴스(Fixed Instance) 운영에 비용 비효율 발생
Amazon Aurora Serverless v2 도입으로 트래픽에 따른 ACU 자동 확장/축소(ACU Auto Scaling) 기능을 활용하여 피크 시간대 안정성 및 비피크 시간대 비용 최적화 목표 달성
Aurora Read Replica 기반 마이그레이션 전략으로 서비스 중단 시간(Downtime) 최소화 및 데이터 정합성(Data Consistency) 보장을 통해 성공적인 DB 전환 완료
전환 후 비용 효율성(Cost Efficiency) 및 운영 유연성(Operational Flexibility) 향상으로 비즈니스 민첩성 강화
Aurora Serverless v2의 ACU 기반 탄력적 확장/축소
메가MGC커피는 시간대별 트래픽 편차가 큰 모바일 주문 서비스의 특성을 고려하여 Amazon Aurora Serverless v2를 선택했습니다. 기존 RDS for MySQL의 고정 인스턴스 방식은 피크 시간대 안정성을 위해 비싼 사양을 상시 유지해야 했으나, Aurora Serverless v2는 ACU(Aurora Capacity Unit) 기반으로 워크로드에 따라 DB 용량을 자동으로 조절합니다.
자동 확장/축소: 오전 피크 시간대에는 ACU를 높여 높은 처리량(High Throughput)을 보장하고, 트래픽이 낮은 시간대에는 ACU를 낮춰 비용을 최적화합니다.
세밀한 조정: Min/Max ACU 설정을 통해 비용과 성능 사이의 균형점을 찾고, EventBridge와 Lambda를 활용한 자동화로 운영 부담을 줄였습니다.
이러한 탄력적인 용량 운영(Elastic Capacity Management)은 트래픽 변동성이 큰 서비스에 이상적인 아키텍처입니다.
Aurora Read Replica 기반의 안정적인 마이그레이션 전략
핵심 B2C 서비스인 모바일 주문 시스템의 DB 전환에서 서비스 중단 시간 최소화와 데이터 정합성 보장은 최우선 과제였습니다. 메가MGC커피는 이를 위해 Aurora Read Replica 기반의 마이그레이션 방식을 채택했습니다.
지속적인 복제: 기존 Amazon RDS for MySQL에서 Aurora MySQL Read Replica로 변경 데이터를 지속적으로 복제하여 실시간 데이터 동기화를 유지했습니다.
단계적 Cut-over: 전환 시점에 애플리케이션 쓰기 작업을 중지하고, Replica Lag가 0이 된 것을 확인한 후 Aurora Replica를 독립 클러스터로 Promote하는 방식으로 전환 시간을 단축했습니다.
사전 리허설: 실제 전환 절차와 동일한 리허설을 통해 Cut-over 시나리오를 검증하고, 각 단계별 담당자와 확인 항목을 명확히 하여 운영 위험을 줄였습니다.
이 전략은 대규모 데이터베이스 전환 시 발생할 수 있는 위험을 효과적으로 관리하는 모범 사례입니다.
DB 엔진 전환 및 쿼리 성능 영향 검토
기존 Amazon RDS for MySQL에서 Amazon Aurora MySQL로 엔진을 전환하면서 발생할 수 있는 쿼리 성능 변화에 대한 사전 검증이 중요했습니다. DBA는 운영 RDS의 Snapshot을 활용해 Aurora 테스트 환경을 구축하고, 핵심 쿼리의 실행 계획을 비교 분석했습니다.
실행 계획 비교: Aurora는 MySQL과 다른 최적화 로직(Optimization Logic)을 가질 수 있으므로, 주요 SQL의 실행 계획 변화를 면밀히 모니터링했습니다.
병목 지점 완화: 기존 RDS에서 관찰된 Binlog 경합과 같은 병목 요소가 Aurora의 분리된 컴퓨팅/스토리지 아키텍처에서 완화되는지 부하 테스트를 통해 검증했습니다.
응답 시간 저하 쿼리 개선: 부하 테스트 중 발견된 응답 시간 저하 쿼리는 추가 점검 및 개선 작업을 수행하여 전환 후 서비스 성능 저하를 방지했습니다.
이러한 철저한 사전 검증은 안정적인 성능 유지를 위한 필수 과정입니다.
Aurora Serverless v2의 캐시 및 메모리 관리 전략
Aurora Serverless v2는 ACU 조정에 따라 물리 메모리와 Buffer Pool 크기가 변동될 수 있습니다. 비피크 시간대에 ACU가 낮아지면 캐시된 데이터가 제거되어, 피크 시간대 재접근 시 디스크 I/O 증가로 인한 응답 지연 가능성이 존재합니다.
적정 Min ACU 산정: DBA는 시간대별 트래픽 패턴을 기반으로 최소 ACU(Min ACU) 값을 반복 테스트하여 산정했습니다.
캐시 워밍업(Cache Warming-up): 오전 피크 시간대 이전에 주요 테이블 데이터를 미리 캐싱하는 전략을 검토하여 콜드 스타트(Cold Start) 현상을 완화했습니다.
점진적 ACU 축소: ACU를 한 번에 크게 낮추기보다 단계적으로 축소하여 Buffer Pool 리사이즈 과정에서의 성능 저하를 방지했습니다.
이러한 전략은 비용 최적화와 성능 안정성 사이의 균형을 맞추는 데 기여했습니다.
Reader Endpoint 활용을 통한 읽기 부하 분산 가능성
모바일 주문 서비스는 주문 생성과 같은 쓰기 작업뿐만 아니라, 메뉴 조회, 주문 이력 조회 등 다수의 읽기 요청(Read Traffic)도 발생합니다. Aurora 클러스터는 Reader 인스턴스를 추가하여 이러한 읽기 트래픽을 분산할 수 있는 기반을 제공합니다.
읽기 확장성 확보: 향후 애플리케이션 구조 변경 시 Reader Endpoint를 활용하여 읽기 부하를 분산하고 Writer의 부담을 줄일 수 있습니다.
Connection Pool 관리: Aurora 클러스터 환경에서는 Failover 발생 시에도 애플리케이션이 Cluster Endpoint를 올바르게 사용하고 있는지, DNS 캐시 설정이 적절한지 점검하는 것이 중요합니다.
복제 지연 검토: 기존 RDS Read Replica 대비 Aurora 환경에서의 Reader 복제 지연(Replica Lag) 가능성을 부하 테스트를 통해 사전에 확인했습니다.
Reader 활용은 향후 서비스 확장에 따른 성능 및 가용성 향상에 기여할 수 있는 잠재력을 가집니다.
