Amazon RDS for MySQL에서 Amazon Aurora Serverless v2로 전환한 메가MGC커피 모바일 주문 서비스 DB 현대화 사례

메가MGC커피 소개

메가MGC커피는 전국 단위의 매장을 기반으로 빠르게 성장해 온 국내 대표 커피 프랜차이즈 브랜드입니다. 오프라인 매장 주문과 모바일 앱을 통한 주문 서비스도 제공하고 있으며, 고객은 앱을 통해 가까운 매장을 선택하고, 음료를 미리 주문한 뒤 매장에서 픽업할 수 있습니다.

모바일 앱 주문 서비스는 고객 편의성과 매장 운영 효율성을 높이는 핵심 디지털 채널입니다. 특히 출근 시간대와 오전 시간대에는 커피 주문 수요가 집중되며, 이에 따라 애플리케이션과 데이터베이스에도 짧은 시간 동안 높은 트래픽이 발생합니다.

이번 프로젝트는 메가MGC커피 모바일 앱 주문 서비스의 핵심 데이터베이스를 기존 Amazon RDS for MySQL에서 Amazon Aurora MySQL-Compatible Edition 기반의 Amazon Aurora Serverless v2로 전환하여, 오전 피크 트래픽에 대한 안정성과 시간대별 비용 효율성을 함께 확보하기 위해 추진되었습니다.

프로젝트 배경

메가MGC커피 모바일 앱 주문 서비스는 고객이 앱에서 매장을 선택하고, 메뉴를 주문하고, 결제 및 주문 상태를 확인하는 주요 기능을 제공합니다. 이러한 서비스 특성상 데이터베이스는 주문, 결제, 매장, 메뉴, 사용자, 주문 상태 등 다양한 트랜잭션을 처리해야 합니다.

기존 환경에서는 Amazon RDS for MySQL을 사용하고 있었으며, 안정적인 운영을 위해 충분한 사양의 인스턴스를 사용했습니다. 그러나 실제 트래픽은 하루 종일 균등하게 발생하지 않았습니다. 특히 오전 시간대에는 출근 전후로 모바일 앱 주문이 집중되었고, 이 시간대에 데이터베이스 부하가 크게 증가하는 패턴을 보였습니다.

반면, 상대적으로 주문량이 낮은 시간대에는 데이터베이스 리소스 사용률이 낮아졌습니다. 즉, 피크 시간대의 안정성을 위해 높은 사양을 유지해야 하지만, 비피크 시간대에는 동일한 사양이 비용 측면에서 비효율적으로 사용되는 구조였습니다.

이에 메가MGC커피는 다음과 같은 목표를 가지고 데이터베이스 전환을 검토했습니다.

1. 오전 앱 주문 피크 시간대의 데이터베이스 처리 안정성 확보
2. 기존 RDS for MySQL 환경의 운영 안정성을 유지한 상태에서 Aurora로 전환
3. 트래픽 패턴에 따라 유연하게 용량을 운영할 수 있는 Aurora Serverless v2 도입
4. Writer/Reader 구성을 통한 고가용성 및 읽기 확장성 확보
5. 시간대별 ACU 조정을 통한 비용 최적화 기반 마련

기존 환경의 주요 과제

1. 오전 시간대 모바일 주문 집중

메가MGC커피 모바일 앱 주문 서비스의 트래픽은 오전 시간대에 집중되는 특성을 보였습니다. 출근 시간 또는 오전 업무 시작 전후로 고객들이 앱을 통해 커피를 미리 주문하면서, 짧은 시간 동안 주문 관련 트랜잭션이 증가했습니다.

이 구간에서는 주문 생성, 결제 연동, 매장별 주문 상태 변경, 사용자 주문 이력 조회 등 다양한 DB 작업이 집중적으로 발생했습니다. 따라서 데이터베이스는 특정 시간대의 피크 트래픽을 안정적으로 처리할 수 있어야 했습니다.

[표1. 오전8시 ~ 오전9시 구간 트래픽 유형]

오전 시간대에는 모바일 앱 진입 이후 다음과 같은 주요 기능에서 트랜잭션이 집중적으로 발생합니다.

• 조회(Select) 트랜잭션: 메인 진입, 매장 조회, 상품 리스트 및 상세 조회
• 주문/처리(DML) 트랜잭션: 주문 생성, 주문 승인, 스탬프 적립

특히 MEGA EVENT와 같은 프로모션 기간에는 이벤트 및 혜택 조회 트래픽이 급증하며, 일반적인 주문 트래픽 외에도 추가적인 조회 부하가 발생하여 전체 데이터베이스 부하 증가에 영향을 미칩니다.

따라서 특정 시간대에 급격히 증가하는 트래픽을 안정적으로 처리하면서도, 사용량 피크시간 외에는 불필요한 리소스를 최소화할 수 있는 유연한 확장/축소 구조의 데이터베이스 아키텍처가 필요했습니다.

2. 피크 기준 인스턴스 운영에 따른 비용 비효율

기존 RDS for MySQL은 고정 인스턴스 기반으로 운영되었습니다. 따라서 오전 피크 트래픽을 안정적으로 처리하기 위해서는 충분한 사양의 인스턴스를 상시 유지해야 했습니다.

그러나 모바일 주문 트래픽은 오전 시간대에 집중되고, 그 외 시간대에는 상대적으로 낮아지는 패턴을 보였습니다. 이로 인해 실제 부하가 낮은 시간대에도 피크 기준의 컴퓨팅 비용이 지속적으로 발생하는 구조였습니다.

Aurora Serverless v2는 ACU 기반으로 용량을 조정할 수 있기 때문에, 메가MGC커피의 시간대별 트래픽 편차가 있는 워크로드에 적합한 대안으로 검토되었습니다.

[표2. 오전/오후 트래픽에 따른 처리량 비교]

3. Cut-Over 전 고려사항 및 운영 서비스 중단 최소화 필요

메가MGC커피 모바일 앱 주문 서비스는 고객의 주문, 결제, 주문 상태 조회와 직접 연결되는 핵심 B2C 서비스입니다. 따라서 데이터베이스 전환 과정에서 장시간의 서비스 중단이 발생하거나, 전환 시점의 데이터가 누락 또는 불일치하는 상황은 서비스 신뢰도에 직접적인 영향을 줄 수 있었습니다.

이번 전환에서는 단순 Snapshot 복원 방식보다, 기존 Amazon RDS for MySQL과 Amazon Aurora MySQL 간 복제를 유지한 상태에서 최종 전환 시점에 짧은 점검 시간 내 Cut-over를 수행할 수 있는 방식이 필요했습니다. 이에 따라 Aurora Read Replica 기반의 마이그레이션 방식을 선택하고, 사전 리허설과 단계별 전환 시나리오를 통해 서비스 중단 시간을 최소화하는 방향으로 계획을 수립했습니다.

서비스 운영 관점의 주요 고려사항

서비스 운영팀은 전환 과정에서 다음 사항을 중점적으로 검토했습니다.

첫째, 서비스 중단 시간 최소화입니다. 모바일 앱 주문 서비스는 고객 주문이 실시간으로 발생하는 서비스이므로, 전환 작업은 사전에 합의된 점검 시간 내에서 수행되어야 했습니다. 이를 위해 실제 전환 절차와 동일한 방식으로 리허설을 수행하고, 각 단계별 담당자와 확인 항목을 포함한 Cut-over 시나리오를 수립했습니다.

둘째, 전환 시점의 데이터 정합성 보장입니다. 주문, 결제, 주문 상태 변경 데이터가 전환 과정에서 누락되거나 불일치하지 않도록 기존 RDS와 Aurora 간 복제 상태를 지속적으로 확인했습니다. 최종 전환 시점에는 신규 주문 유입을 통제하고, Replica Lag가 0인 상태를 확인한 뒤 Aurora Replica를 Promote하는 방식으로 데이터 정합성을 확보했습니다.

셋째, 오전 피크 트래픽에 대한 안정성 검증입니다. 메가MGC커피 모바일 앱 주문 서비스는 오전 시간대에 주문 트래픽이 집중되는 특성이 있습니다. 이에 따라 전환 전 기존 RDS 환경의 메모리 사용 패턴, 주요 업무 로직별 부하, 캐시 사용 특성을 분석하고, Aurora Serverless v2 환경에서도 오전 피크 트래픽을 안정적으로 처리할 수 있는지 사전 검증을 수행했습니다.

넷째, 비용 효율성 확보입니다. 기존 RDS 환경은 피크 트래픽을 기준으로 고정 인스턴스 사양을 운영해야 했지만, Aurora Serverless v2는 ACU 기반으로 용량을 유연하게 조정할 수 있습니다. 서비스팀은 시간대별 트래픽 패턴을 기반으로 피크 시간대에는 충분한 용량을 확보하고, 비피크 시간대에는 불필요한 리소스를 줄일 수 있는 운영 방향을 함께 검토했습니다.

데이터베이스 관점의 주요 고려사항

DBA는 엔진 전환과 Aurora Serverless v2 도입이 데이터베이스 성능과 안정성에 미칠 수 있는 영향을 중심으로 사전 검증을 수행했습니다.

첫째, DB 엔진 변경에 따른 쿼리 성능 영향을 검토했습니다. 기존 RDS for MySQL에서 Aurora MySQL로 전환되면서 최적화 동작이나 실행 계획이 달라질 가능성이 있었습니다. 특히 오전 피크 시간대에 사용되는 핵심 쿼리의 실행 계획이 변경될 경우 서비스 응답 지연으로 이어질 수 있기 때문에, 운영 RDS의 Snapshot을 활용해 Aurora 테스트 환경을 구성하고 주요 SQL의 실행 계획을 비교했습니다. 이후 부하 테스트를 통해 응답 시간이 저하되는 쿼리를 추가로 점검하고 개선했습니다.

둘째, 기존 RDS 환경에서 확인된 병목 요소가 Aurora 환경에서 완화되는지를 검증했습니다. 기존 RDS for MySQL 환경에서는 DML이 집중되는 구간에서 Binlog 관련 경합이 주요 병목 지점으로 관찰되었습니다. Aurora는 컴퓨팅 계층과 스토리지 계층이 분리된 구조를 기반으로 동작하기 때문에, 동일한 부하 조건에서 경합이 완화될 수 있을 것으로 기대했습니다. DBA는 부하 테스트를 통해 Aurora 전환 후 주요 병목 지표와 응답 시간을 비교했습니다.

셋째, Reader 사용 시 복제 지연 가능성을 검토했습니다. 모바일 주문 서비스는 읽기 요청도 함께 발생하기 때문에 향후 Reader를 활용한 읽기 부하 분산 가능성을 고려했습니다. 기존 RDS Read Replica 구성에서는 Binlog 기반 복제 특성으로 인해 특정 부하 상황에서 복제 지연이 발생할 수 있었으나, Aurora 환경에서는 부하 테스트를 통해 Reader 사용 시 복제 지연이 서비스에 미치는 영향을 사전에 확인했습니다.

넷째, Aurora Serverless v2의 ACU 변경에 따른 메모리 및 캐시 영향을 검토했습니다. Aurora Serverless v2는 워크로드에 따라 DB 용량을 유연하게 조정할 수 있는 장점이 있지만, ACU가 줄어들면 물리 메모리와 Buffer Pool 크기도 함께 감소할 수 있습니다. 이 경우 비피크 시간대에 캐시 된 데이터가 제거되고, 이후 오전 피크 시간대에 다시 디스크에서 데이터를 읽어야 하면서 응답 지연이 발생할 수 있습니다.

이를 방지하기 위해 DBA는 시간대별 트래픽 패턴을 기준으로 적정 Min/Max ACU 값을 반복 테스트를 통해 산정했습니다. 또한 오전 피크 전에 Min ACU를 미리 상향하고, 주요 테이블의 데이터를 사전에 캐싱하는 방식으로 캐시 워밍업 전략을 검토했습니다.

마지막으로, ACU 축소 시점의 안정성도 함께 검증했습니다. 부하가 낮아지는 시간대에는 Min ACU를 낮춰 비용을 최적화할 수 있지만, 큰 폭으로 한 번에 ACU를 낮출 경우 Buffer Pool 리사이즈 과정에서 순간적인 성능 저하가 발생할 수 있습니다. 이에 따라 ACU를 단계적으로 낮추는 스케줄링 방식을 적용하여, 비용 최적화와 서비스 안정성 사이의 균형을 맞추는 방향으로 운영 전략을 수립했습니다.

이와 같은 사전 검토를 통해 메가MGC커피는 단순한 데이터베이스 마이그레이션이 아니라, 애플리케이션 영향도, 데이터 정합성, 피크 트래픽 대응, 쿼리 성능, 복제 지연, ACU 운영 전략까지 함께 고려한 전환 계획을 수립할 수 있었습니다.

Cut-Over 전략

메가MGC커피의 모바일 앱 주문 서비스 DB 전환은 Aurora Read Replica 기반 마이그레이션 방식으로 수행되었습니다.

기존 Amazon RDS for MySQL을 Source DB로 두고, Amazon Aurora MySQL-Compatible Edition Read Replica를 생성했습니다. 이후 기존 RDS에서 발생하는 변경 데이터를 Aurora Replica로 지속적으로 복제하면서, 전환 시점에는 애플리케이션 쓰기 작업을 중지하고 Replica Lag가 0이 된 것을 확인한 후 Aurora Replica를 독립 Aurora Cluster로 Promote했습니다.

이후 Aurora Cluster를 Aurora Serverless v2 기반으로 구성하고, Writer와 Reader를 추가하여 운영 서비스에 적용했습니다.

[그림1. Cut-Over 전환 과정]

Cut-Over 절차

실제 전환은 다음과 같은 순서로 진행되었습니다.

1. 기존 RDS for MySQL 상태 점검
2. Aurora MySQL 호환 버전 검토
3. Aurora Read Replica 생성
4. Replica Lag 모니터링
5. 전환 일정 및 점검 절차 확정
6. 모바일 앱 주문 서비스 점검 페이지 전환
7. WAS 중지
8. 기존 RDS에 추가 DML이 발생하지 않는지 확인
9. Aurora Replica Lag 0 확인
10. Aurora Read Replica Promote
11. Aurora Serverless v2 구성 적용
12. Reader 인스턴스 추가
13. Aurora Cluster Endpoint 및 Reader Endpoint 확인
14. 애플리케이션 DB 접속 정보 변경
15. WAS 기동
16. 주문/결제/조회 기능 검증
17. CloudWatch 및 Performance Insights 기반 안정화 모니터링

전환 절차 수립 및 검증

메가MGC커피 모바일 앱 주문 서비스는 주문 생성, 결제, 주문 상태 조회, 주문 이력, 매장별 주문 관리 등 데이터베이스 의존도가 높은 기능을 중심으로 운영되고 있습니다. 특히 오전 시간대에는 모바일 앱 주문이 집중되면서 쓰기 트랜잭션과 조회 트랜잭션이 동시에 증가하는 특성을 보였습니다. 이에 따라 전환 과정에서는 서비스 중단 시간을 최소화하고, 주문 데이터의 정합성을 안정적으로 보장하는 것이 가장 중요한 기준이었습니다.

데이터베이스 전환 시 사용자 영향을 줄이기 위해 점검 페이지를 사전에 구성하고, 모바일 앱 API 서버, 관리자 서버, 배치 서버, 외부 연동 서버 등 데이터베이스 Endpoint를 사용하는 모든 시스템의 전환 대상을 식별했습니다. 전환 시에는 점검 페이지를 통해 신규 주문 유입을 먼저 통제한 뒤, 서비스 컴포넌트를 단계적으로 제어하는 방식으로 Cut-over 절차를 수립했습니다.

Amazon RDS for MySQL 8.0.42에서 Aurora MySQL 8.0.mysql_aurora.3.10.3으로 전환하기 위해 Snapshot 복원, AWS DMS, Aurora Read Replica 방식 등을 검토했습니다. 운영 데이터베이스는 대용량 데이터를 보유하고 있었으며, Snapshot 복원 방식은 복원 시간뿐만 아니라 복원 시점 이후 발생하는 트랜잭션 반영까지 고려해야 했기 때문에 운영 서비스 전환 방식으로는 부담이 있었습니다. AWS DMS도 대안으로 검토했으나, 이번 환경에서는 Aurora Read Replica 방식이 전환 시간, 데이터 정합성, 운영 복잡도 측면에서 가장 적합하다고 판단했습니다.

최종적으로 기존 RDS for MySQL을 Source DB로 유지한 상태에서 Aurora Read Replica를 생성하고, Replica Lag를 지속적으로 확인한 뒤, 서비스 중단 시점에 쓰기 트랜잭션이 더 이상 발생하지 않는 것을 확인하고 Promote를 수행하는 방식으로 전환했습니다. 이를 통해 초기 데이터 복제는 서비스 운영 중 수행하고, 실제 Cut-over 시점의 작업 시간을 최소화할 수 있었습니다.

전환 이후에는 주문 생성, 결제, 주문 상태 조회 등 핵심 기능을 우선 검증하고, 주요 업무 쿼리 기반의 캐시 워밍업을 수행했습니다. 또한 실제 앱 사용 시나리오 기반 QA와 APM 로그를 통해 고객 체감 성능을 확인했습니다. 데이터베이스 측면에서는 CPUUtilization, ServerlessDatabaseCapacity, DatabaseConnections, Replica Lag, ACUUtilization 등의 지표를 모니터링하여 전환 직후의 안정성을 점검했습니다.

전환 직후 일부 캐시에 포함되지 않은 로직에서 일시적인 지연이 관찰되었으나, 서비스 영향은 제한적이었으며 워밍업 스크립트 보완을 통해 단기간 내 안정화할 수 있었습니다. 결과적으로 메가MGC커피는 Aurora Read Replica 기반 전환을 통해 서비스 중단 시간을 최소화하면서 Aurora Serverless v2 기반의 탄력적인 데이터베이스 운영 구조로 전환할 수 있었습니다.

Aurora Serverless v2 도입 효과

전환 이후 메가MGC커피는 기존 고정 인스턴스 기반 RDS for MySQL 환경에서 Aurora Serverless v2 기반의 탄력적인 데이터베이스 운영 구조로 전환했습니다.

특히 모바일 앱 주문 서비스의 트래픽이 오전 시간대에 집중된다는 점을 고려하여, 피크 시간대에는 높은 Min ACU를 유지하고, 상대적으로 주문량이 낮은 시간대에는 Min ACU를 낮추는 방식의 운영 전략을 검토했습니다.

이를 통해 오전 피크 시간대의 안정성을 확보하면서도, 비피크 시간대의 비용 최적화 가능성을 확보했습니다.

• Aurora Serverless v2의 Max ACU는 피크 트래픽 대응 기준으로 유지
• Min ACU는 시간대별 부하에 따라 Max 대비 약 10~40%범위로 유동적으로 조정
• EventBridge + Lambda 기반 자동 조정

전환 후 운영 고려사항

1. 오전 피크 시간대 ACU 안정성 확인

전환 후에는 오전 주문 피크 시간대에 Aurora Serverless v2가 충분한 용량을 확보하고 있는지 확인했습니다. CloudWatch의 ServerlessDatabaseCapacity, ACUUtilization, DatabaseConnections, CPUUtilization 등의 지표를 통해 피크 시간대의 DB 상태를 모니터링했습니다.

Aurora Serverless v2의 ACU 사용량과 실제 CPU 사용률을 비교 분석한 결과, 트래픽 패턴 및 부하 변화에 맞추어 ACU가 자동으로 유연하게 확장 및 축소되고 있으며, CPU 사용률 또한 안정적으로 유지되는 것을 확인하였습니다. 이를 통해 현재 서비스 사용량 대비 ACU 정책이 적절하게 적용되어 비용 효율성과 성능 안정성을 동시에 확보하고 있는 것으로 판단됩니다.

[그림2. Aurora Serverless V2 ACU Utilization]

[그림3. Aurora Serverless V2 CPU Utilization]

2. 주문 서비스 특성상 Connection Pool 관리 중요

모바일 앱 주문 서비스는 짧은 시간 동안 다수의 API 호출이 집중될 수 있습니다. 따라서 Application의 Connection Pool 설정, Idle Connection 관리, Validation Query, DNS Cache TTL 등을 함께 점검했습니다.

Aurora Cluster 환경에서는 Failover 또는 Writer 변경 상황이 발생할 수 있으므로, Application이 Cluster Endpoint를 사용하고 있는지, DNS 캐시가 과도하게 길게 유지되지 않는지 확인하는 것이 중요했습니다.

3. Reader Endpoint 활용 가능성

전환 후 Aurora Reader를 추가함으로써 읽기 트래픽을 분산할 수 있는 기반을 마련했습니다. 모바일 앱 주문 서비스에서는 주문 생성과 같은 Write 트래픽뿐만 아니라, 메뉴 조회, 매장 조회, 주문 이력 조회, 주문 상태 조회와 같은 Read 트래픽도 발생합니다.

향후 Application 구조에 따라 Reader Endpoint를 활용하면 읽기 부하를 분산하고 Writer의 부담을 줄일 수 있습니다.

비즈니스 효과 및 Next Step

1. 오전 주문 피크 대응력 강화

메가MGC커피는 Aurora Serverless v2 전환을 통해 모바일 앱 주문이 집중되는 오전 시간대에 보다 유연하게 DB 용량을 운영할 수 있는 기반을 마련했습니다.

기존에는 피크 시간대를 기준으로 고정 인스턴스를 운영해야 했지만, 전환 후에는 ACU 기반으로 용량 범위를 설정하고, 트래픽 패턴에 맞춰 운영 정책을 조정할 수 있게 되었습니다.

2. 비용 최적화 기반 확보

모바일 주문 서비스의 트래픽은 하루 종일 동일하지 않고 시간대별 편차가 존재합니다. Aurora Serverless v2는 이러한 워크로드 특성에 맞춰 비피크 시간대의 최소 용량을 낮출 수 있는 구조를 제공합니다. 이를 통해 메가MGC커피는 안정성과 비용 효율성을 동시에 고려한 데이터베이스 운영 모델을 확보했습니다.

3. 운영 유연성 향상

전환 후에는 CloudWatch 지표를 기반으로 실제 DB 사용량을 관찰하고, Min/Max ACU 정책을 조정할 수 있게 되었습니다. 또한 EventBridge와 Lambda를 활용하면 시간대별 ACU 조정을 자동화할 수 있어, 반복적인 운영 작업을 줄이고 정책 기반 운영이 가능합니다.

더 빠르고 편리해진 메가MGC커피 모바일 주문, 지금 경험해보세요!

• App Store 바로가기
• Google Play Store 바로가기

저자 소개