Aurora + Redshift 조합을 HeatWave 하나로 통합할 수 있나요?

핵심 요약: Aurora와 Redshift 이중 구조를 HeatWave 단일 시스템으로 통합해 분석 쿼리 평균 225배, 비용 최대 50% 절감을 검증한 PoC예요. ETL 제거가 성능보다 더 큰 운영 효과를 만든다는 점을 설명해요.

국내 대형 게임 데이터 플랫폼을 운영하면서 계속 느낀 건, OLTP와 OLAP을 분리해서 운영하는 구조가 생각보다 많은 숨은 비용을 만든다는 거예요. Aurora MySQL로 트랜잭션을 처리하고, Redshift로 분석 쿼리를 돌리는 구조는 겉보기엔 깔끔하지만, 그 사이를 연결하는 ETL 파이프라인이 운영팀의 가장 큰 부담이 되는 경우가 많아요.

이번 글에서는 실제 고객사의 PoC 결과를 바탕으로, Aurora + Redshift 이중 구조를 MySQL HeatWave 단일 시스템으로 통합한 과정과 그 결과를 공유할게요.

OLTP와 OLAP 분리가 만든 복잡성

대부분의 데이터 집약적 서비스는 비슷한 패턴을 따라요. 운영 DB는 Aurora MySQL, 분석은 Redshift. 처음에는 이렇게 역할을 나누면 각자 최적화된 환경에서 동작하니까 효율적이라고 생각했어요.

하지만 실제로 운영해 보니 현실은 기대와 달랐어요.

문제 영역	구체적 증상
ETL 파이프라인 유지보수	Aurora에서 Redshift로 데이터를 복제하는 파이프라인이 장애 포인트가 됨
데이터 정합성	ETL 지연으로 분석 데이터와 운영 데이터 간 불일치 발생
비용 이중 지출	동일 데이터를 두 곳에 저장하고, 두 시스템을 각각 운영
인력 분산	DBA가 Aurora와 Redshift를 별도로 관리해야 하는 부담

놀이공원에서 같은 놀이기구를 타려고 두 줄에 동시에 서 있는 것과 비슷해요. 결국 한쪽은 낭비가 되는 구조예요.

국내 대형 게임 데이터 플랫폼의 AS-IS 환경

이번 PoC를 진행한 고객사는 일일 수억 건의 게임 데이터를 처리하는 플랫폼이에요. 기존 아키텍처는 다음과 같았어요.

• OLTP 레이어: Aurora MySQL db.r6g.4xlarge (16 vCPU, 128GB RAM), 약 2TB 스토리지
• OLAP 레이어: Amazon Redshift 클러스터 (분석 쿼리 전용)
• 데이터 파이프라인: Kafka → ETL → Redshift (실시간 스트리밍 + 배치 적재)
• 월간 인프라 비용: Aurora만 $2,728/월 (Redshift 별도)

문제는 분석 쿼리가 Aurora에서 수십 초에서 수 분이 걸렸고, 이를 해결하려고 Redshift를 도입했지만 ETL 파이프라인의 복잡도가 계속 증가했다는 점이에요.

HeatWave 통합 아키텍처 설계

MySQL HeatWave는 하나의 MySQL 인스턴스에서 OLTP와 OLAP을 동시에 처리할 수 있어요. 기존 MySQL 쿼리를 수정 없이 그대로 사용하면서, 분석 쿼리는 HeatWave 인메모리 엔진이 자동으로 가속 처리해요.

TO-BE 아키텍처의 핵심 변경점은 세 가지예요.

첫째, Aurora MySQL이 MySQL HeatWave DB 노드로 대체돼요. MySQL 8.0 완전 호환이라 스키마 변경이 필요 없어요.

둘째, Redshift가 HeatWave 클러스터로 대체돼요. 별도 데이터 웨어하우스 없이 동일 DB 엔진 내에서 분석 쿼리를 처리해요.

셋째, ETL 파이프라인이 제거돼요. Kafka에서 직접 HeatWave로 적재하는 단순화된 구조로 전환돼요.

Lakehouse PoC 결과. 분석 쿼리 225배 빨라졌어요

PoC에서 가장 인상적이었던 건 분석 쿼리 성능이에요. HeatWave 2노드 클러스터(16 OCPUs, 512GB RAM)로 테스트한 결과예요.

쿼리 유형	Aurora MySQL	HeatWave	성능 향상
단순 집계	38.5초	0.12초	320배
조인 + 집계	72.3초	0.34초	212배
서브쿼리 분석	125.7초	0.58초	216배
복합 분석	210.4초	1.2초	175배
대규모 스캔	45.2초	0.09초	502배

TPC-H 10GB 스케일 벤치마크에서 평균 225배 성능 향상을 확인했어요. 동시 사용자 10명이 분석 쿼리를 실행해도 HeatWave는 1.2배 이내의 성능 저하만 보인 반면, Aurora는 3–5배까지 응답 시간이 늘어났어요.

여기서 주의할 점은, 이 수치가 OLAP 쿼리에 한정된다는 거예요. 단순 OLTP 트랜잭션(INSERT, UPDATE)은 기존 MySQL과 동일한 InnoDB 엔진이 처리하기 때문에 성능 차이가 크지 않아요.

HeatWave Lakehouse로 콜드 데이터까지 통합 분석

HeatWave Lakehouse는 Object Storage에 있는 CSV, Parquet, Avro, JSON 파일을 ETL 없이 직접 쿼리할 수 있는 기능이에요.

기존에는 히스토리 데이터를 분석하려면 S3에서 Redshift로 COPY 명령을 실행하거나, Athena를 별도로 구성해야 했어요. Lakehouse를 사용하면 Object Storage의 파일을 외부 테이블로 정의하고, HeatWave 클러스터 메모리에 병렬 로딩해서 SQL로 바로 분석할 수 있어요.

실무에서 가장 유용했던 부분은 OLTP 데이터와 Lakehouse 데이터를 조인할 수 있다는 점이에요. 예를 들어, 현재 운영 중인 유저 테이블과 Object Storage에 보관된 3년치 게임 로그를 하나의 SQL로 분석할 수 있어요.

비용 비교. AutoStop 적용 시 50% 절감

비용 비교는 PoC에서 가장 관심이 높았던 영역이에요.

항목	Aurora MySQL	HeatWave on AWS
컴퓨트	$2,188/월	$744/월 (DB 노드) + $1,488/월 (HeatWave 2노드)
스토리지	$500/월 (2TB, I/O Optimized)	$80/월 (2TB) + $46/월 (Object Storage)
백업	$40/월	포함
합계	$2,728/월	$2,358/월
절감률	기준	13.6% 절감

기본 구성만으로도 13.6% 절감이지만, 실제 운영에서는 HeatWave AutoStop을 적용할 수 있어요. 분석 워크로드가 업무 시간(8시간/일)에만 사용되는 경우, HeatWave 클러스터 비용이 1/3로 줄어들어요.

AutoStop 적용 시 총 비용은 $1,366/월로, 기존 대비 약 50% 절감이에요. 여기에 Redshift 클러스터 비용까지 제거하면 실질 절감 효과는 더 커져요.

스토리지 단가도 차이가 커요. Aurora의 I/O Optimized 스토리지가 GB당 $0.25인 반면, HeatWave는 $0.04로 84% 저렴해요.

마이그레이션 단계별 접근법

이 고객사에서 설계한 마이그레이션은 3단계로 진행돼요.

Phase 1. OLTP 전환 (2–3주)

MySQL 8.0 완전 호환이기 때문에 스키마 변경 없이 mysqldump 또는 DMS로 데이터를 이관해요. 2TB 기준 약 4–6시간이면 전체 데이터 이관이 완료돼요. Replication 기반 전환으로 다운타임을 최소화할 수 있어요.

Phase 2. OLAP 전환 (1–2주)

HeatWave 클러스터를 활성화하고, 분석 대상 테이블을 인메모리에 로딩해요. 기존 Redshift SQL을 MySQL 호환 SQL로 변환하는 작업이 필요하지만, 대부분의 표준 SQL은 그대로 동작해요. MySQL 옵티마이저가 자동으로 HeatWave 엔진으로 쿼리를 오프로드하기 때문에 애플리케이션 코드 변경이 거의 없어요.

Phase 3. Lakehouse 구성 및 ETL 제거 (2–3주)

Object Storage에 히스토리 데이터를 적재하고, 외부 테이블을 정의해요. 기존 ETL 파이프라인을 단계적으로 제거하면서, Kafka에서 HeatWave로 직접 적재하는 구조로 전환해요.

전체 마이그레이션 기간은 약 5–8주예요. 실수하기 쉬운 부분이 있어요. Redshift 전용 함수(LISTAGG, GETDATE 등)를 사용하는 쿼리는 MySQL 호환 함수로 변환해야 하고, 이 작업이 예상보다 시간이 걸릴 수 있어요.

운영 복잡도는 얼마나 줄어드나요

ETL 파이프라인 제거가 가져오는 운영 효과는 비용 절감보다 더 클 수 있어요.

기존에는 Aurora → Redshift 간 데이터 동기화가 실패하면 분석 데이터가 수 시간 지연되고, 이를 복구하는 데 DBA의 시간이 소모됐어요. HeatWave 통합 구조에서는 단일 MySQL 시스템만 관리하면 되기 때문에 장애 포인트가 줄어들어요.

DBA 입장에서 가장 큰 변화는 모니터링 대상이 하나로 줄어든다는 점이에요. Aurora 클러스터, Redshift 클러스터, ETL 스케줄러를 각각 모니터링하던 것이 MySQL HeatWave 하나로 통합돼요.

고려해야 할 트레이드오프

통합이 항상 정답은 아니에요. 몇 가지 고려사항이 있어요.

첫째, HeatWave 클러스터 메모리에 로딩할 수 있는 데이터 크기에 제한이 있어요. 노드 수를 늘려서 확장할 수 있지만, 수십 TB 규모의 데이터를 전부 인메모리에 올리는 것은 비용 효율적이지 않을 수 있어요. 이 경우 Lakehouse를 활용해서 콜드 데이터는 Object Storage에 두는 전략이 필요해요.

둘째, Redshift의 Spectrum이나 ML 기능을 깊게 사용하고 있다면 전환 시 기능 매핑을 꼼꼼히 확인해야 해요.

셋째, HeatWave on AWS는 OCI 기반 서비스이기 때문에, 순수 AWS 환경만 사용하는 조직에서는 멀티클라우드 거버넌스 관점의 검토가 필요해요.

핵심 요약

• Aurora MySQL + Redshift 이중 구조를 MySQL HeatWave 단일 시스템으로 통합할 수 있어요
• PoC 결과 분석 쿼리 175–502배 성능 향상, 평균 225배 가속을 확인했어요
• AutoStop 적용 시 기존 대비 약 50% 비용 절감이 가능해요
• ETL 파이프라인 제거로 운영 복잡도가 대폭 감소해요
• 마이그레이션은 OLTP → OLAP → Lakehouse 3단계로 5–8주 내 완료 가능해요

FAQ

Q. Aurora에서 HeatWave로 마이그레이션할 때 다운타임이 발생하나요?

Replication 기반 전환을 사용하면 다운타임을 수 분 이내로 최소화할 수 있어요. 2TB 기준 전체 데이터 이관은 4–6시간이지만, 이 시간 동안 기존 Aurora는 정상 운영되고 최종 전환 시점에만 짧은 다운타임이 발생해요.

Q. HeatWave on AWS는 기존 AWS VPC 내에서 동작하나요?

HeatWave on AWS는 AWS 리전 내에서 동작하며, 기존 VPC와 프라이빗 연결이 가능해요. 애플리케이션 입장에서는 MySQL 엔드포인트만 변경하면 되기 때문에 네트워크 아키텍처 변경이 최소화돼요.

Q. Redshift에서 사용하던 SQL을 HeatWave에서 그대로 쓸 수 있나요?

표준 SQL은 대부분 호환되지만, Redshift 전용 함수(LISTAGG, CONVERT_TIMEZONE, GETDATE 등)는 MySQL 호환 함수로 변환이 필요해요. GROUP_CONCAT, CONVERT_TZ, NOW() 등으로 대체할 수 있고, 대부분의 분석 쿼리는 수정 없이 동작해요.

Q. HeatWave Lakehouse와 Amazon Athena의 차이점은 뭔가요?

Athena는 Object Storage 데이터를 서버리스로 쿼리하는 독립 서비스예요. Lakehouse는 MySQL HeatWave 내에서 OLTP 데이터와 Object Storage 데이터를 하나의 SQL로 조인할 수 있다는 점이 가장 큰 차이예요. 별도 서비스를 오가지 않고 단일 엔드포인트에서 모든 분석이 가능해요.

Q. HeatWave로 통합하면 기존 ETL 파이프라인을 완전히 제거할 수 있나요?

Aurora에서 Redshift로 데이터를 옮기던 ETL 파이프라인은 제거할 수 있어요. HeatWave는 Aurora MySQL과 동일한 스토리지를 공유하기 때문에, 별도 데이터 복제 없이 OLTP 데이터를 실시간으로 분석할 수 있어요. 다만 외부 데이터 소스(S3, 타 DB)를 통합하는 파이프라인은 Lakehouse Auto Parallel Load로 대체하는 방식으로 재설계가 필요해요. 실제 운영에서는 Airflow나 AWS Glue로 관리하던 DAG 수가 평균 60–70% 줄어드는 경우가 많아요.