MySQL HeatWave와 Aurora 성능 차이는 실제로 얼마나 되나요?
핵심 요약: Sysbench와 TPC-H 기준으로 HeatWave가 Aurora 대비 OLTP 최대 3.4배, OLAP 평균 54배 빠른 이유를 분석해요. Thread Pool과 인메모리 컬럼 처리의 차이를 실측 수치로 확인할 수 있어요.
"Aurora MySQL이면 충분하지 않나요?" 고객사 미팅에서 가장 많이 받는 질문이에요. 실제로 OLTP 워크로드만 놓고 보면 Aurora도 훌륭한 선택이에요. 하지만 분석 쿼리가 섞이기 시작하면, 그리고 동시 접속자가 수백 명을 넘어가면 이야기가 달라져요.
저희가 직접 벤치마크를 수행하고 고객사 환경에서 검증한 결과를 정리했어요. Oracle 공식 벤치마크 데이터와 Sysbench 실측 결과를 함께 다루면서, 어떤 조건에서 얼마나 차이가 나는지, 그리고 그 차이가 어디서 비롯되는지를 설명할게요.
OLTP 성능 비교, Sysbench로 측정한 실제 수치
OLTP 성능을 비교할 때 가장 신뢰할 수 있는 도구가 Sysbench예요. 24개 테이블, 각 1,000만 Row, 8부터 1,024 스레드까지 단계적으로 부하를 올리면서 600초간 측정한 결과예요.
테스트 환경
| 항목 | MySQL HeatWave (OCI) | Amazon Aurora MySQL |
|---|---|---|
| 인스턴스 | BM.Standard.E4.128 | db.r5.24xlarge |
| CPU | 128 OCPUs (AMD EPYC 7J13) | 96 vCPUs |
| 메모리 | 2,048 GB | 768 GB |
| 스토리지 | NVMe 로컬 | Aurora 분산 스토리지 |
여기서 주의할 점이 있어요. 하드웨어 스펙이 동일하지 않아요. HeatWave는 OCI에서 권장하는 Bare Metal 인스턴스를 사용하고, Aurora는 AWS에서 제공하는 최대 스펙 인스턴스를 사용했어요. 이건 "동일 하드웨어에서의 소프트웨어 성능 비교"가 아니라 "각 클라우드에서 권장하는 최적 구성에서의 성능 비교"라는 점을 먼저 짚어둘게요.
Read-Write 혼합 워크로드
| 동시 스레드 | HeatWave TPS | Aurora TPS | HeatWave 우위 |
|---|---|---|---|
| 8 | 5,765 | 2,498 | 2.3배 |
| 32 | 20,579 | 8,098 | 2.5배 |
| 128 | 54,733 | 18,039 | 3.0배 |
| 256 | 68,347 | 21,249 | 3.2배 |
| 512 | 73,498 | 22,098 | 3.3배 |
| 1,024 | 74,098 | 21,598 | 3.4배 |
운영하면서 계속 느낀 건, 동시 접속자가 늘어날수록 성능 격차가 벌어진다는 거예요. 8 스레드에서 2.3배 차이가 1,024 스레드에서는 3.4배까지 벌어져요. 이건 단순히 CPU 코어 수 차이만으로는 설명이 안 돼요.
95th Percentile 레이턴시 (Read-Write)
| 동시 스레드 | HeatWave (ms) | Aurora (ms) | 차이 |
|---|---|---|---|
| 64 | 2.57 | 7.30 | 2.8배 낮음 |
| 256 | 5.37 | 17.63 | 3.3배 낮음 |
| 512 | 10.09 | 33.72 | 3.3배 낮음 |
| 1,024 | 20.00 | 69.29 | 3.5배 낮음 |
레이턴시 관점에서도 동일한 패턴이에요. 고동시성 환경에서 Aurora의 p95 레이턴시가 급격히 올라가는 반면, HeatWave는 상대적으로 완만하게 증가해요.
고동시성에서 차이가 벌어지는 이유, Thread Pool
성능 격차의 핵심 원인은 Thread Pool이에요. 놀이공원에서 패스트트랙을 산 사람이 일반 대기줄보다 먼저 탈 수 있는 것과 비슷한 원리예요. Thread Pool은 들어오는 커넥션을 효율적으로 스케줄링해서, 수백 개의 동시 요청이 들어와도 CPU 컨텍스트 스위칭 오버헤드를 최소화해요.
MySQL HeatWave는 Oracle MySQL Enterprise Thread Pool을 내장하고 있어요. 커넥션이 폭증해도 Thread Group 단위로 작업을 분배하고, 대기 중인 커넥션은 큐에서 관리해요.
Aurora MySQL은 Thread Pool을 지원하지 않아요. 커넥션 하나당 스레드 하나를 할당하는 전통적인 one-thread-per-connection 모델을 사용해요. 동시 접속이 수백 개를 넘어가면 OS 레벨에서 컨텍스트 스위칭 비용이 급격히 올라가요.
이 차이가 벤치마크에서 명확하게 드러나요. 8 스레드에서는 Thread Pool의 효과가 크지 않지만, 256 스레드를 넘어가면 Aurora의 처리량이 정체되는 반면 HeatWave는 계속 올라가요. 1,024 스레드에서 Aurora의 TPS가 오히려 256 스레드보다 떨어지는 현상도 이 때문이에요.
실제 프로젝트에서 이 차이를 체감한 사례가 있어요. 400명 동시 사용자 환경에서 실제 워크로드를 돌렸을 때, HeatWave가 응답시간 40% 빠르고 처리량 79% 높게 나왔어요. Thread Pool이 없는 Aurora에서는 커넥션 풀 설정을 아무리 튜닝해도 한계가 있었어요.
OLAP 성능 비교, TPC-H 벤치마크 결과
OLTP에서의 차이도 크지만, 분석 쿼리(OLAP)에서의 격차는 차원이 달라요. Aurora MySQL은 InnoDB 기반 행 스토리지로 분석 쿼리를 처리하는 반면, HeatWave는 인메모리 컬럼 스토리지에서 MPP로 처리하니까요.
TPC-H 100GB 쿼리 성능 (주요 쿼리)
| 쿼리 | HeatWave (초) | Aurora (초) | 차이 |
|---|---|---|---|
| Q1 (집계) | 1.2 | 64.8 | 54배 |
| Q5 (조인+집계) | 0.9 | 52.1 | 58배 |
| Q9 (복합 조인) | 1.5 | 72.3 | 48배 |
| Q21 (서브쿼리) | 1.4 | 68.2 | 49배 |
Aurora 대비 평균 54배 빠른 성능이에요. Aurora에서 1분 넘게 걸리는 분석 쿼리가 HeatWave에서는 1–2초 안에 끝나요.
이건 당연한 결과이기도 해요. Aurora는 분석 전용 엔진이 아니니까요. Aurora에서 분석 쿼리를 처리하려면 Redshift나 Athena로 데이터를 보내야 해요. 그래서 실질적인 비교 대상은 Aurora가 아니라 Redshift, Snowflake, BigQuery예요.
전용 분석 서비스 대비 성능 (TPC-H 100GB)
| 비교 대상 | HeatWave 대비 속도 | 가격대비성능 |
|---|---|---|
| Amazon Redshift (ra3.xlplus 4노드) | 6.5배 느림 | 8배 비쌈 |
| Snowflake (Small warehouse) | 4.5배 느림 | 6배 비쌈 |
| Google BigQuery (On-demand) | 3.5배 느림 | 5배 비쌈 |
TPC-H 400GB 규모에서도 비슷한 패턴이에요. Redshift 대비 6.3배, Snowflake 대비 4.2배, BigQuery 대비 3.3배 빠른 결과가 나왔어요.
OLTP + OLAP 통합 성능, 진짜 차이는 여기서 나와요
개별 벤치마크 수치보다 더 중요한 건 "OLTP와 OLAP을 동시에 처리할 때" 성능이에요. 실제 엔터프라이즈 환경에서는 트랜잭션 처리와 분석 쿼리가 동시에 돌아가니까요.
Aurora 환경에서 이 문제를 해결하려면 아키텍처가 복잡해져요.
HeatWave 환경에서는 단일 시스템으로 처리해요.
이 아키텍처 차이가 만드는 실질적인 효과는 세 가지예요.
ETL 제거로 인한 실시간 분석이 가능해져요. Aurora + Redshift 구조에서는 ETL 파이프라인 지연(수십 분–수 시간)이 불가피해요. HeatWave는 InnoDB 변경사항이 실시간으로 HeatWave 클러스터에 반영되니까 항상 최신 데이터를 분석할 수 있어요.
운영 복잡도가 줄어요. 두 시스템의 스키마 동기화, 파이프라인 모니터링, 데이터 정합성 검증 로직이 전부 사라져요.
비용 구조도 단순해져요. Aurora + Redshift + Glue/Lambda 비용을 합산하면, HeatWave 단일 시스템보다 비싼 경우가 많아요.
IO 성능 비교, 스토리지 레이어의 차이
Sysbench fileio 벤치마크로 스토리지 레이어 성능도 측정했어요. 이 결과는 데이터 로딩 속도와 대용량 스캔 성능에 직접적으로 영향을 줘요.
| 항목 | HeatWave (BM) | Aurora | 차이 |
|---|---|---|---|
| Sequential Read (16 스레드) | 22,498 MiB/s | 4,898 MiB/s | 4.6배 |
| Sequential Write (16 스레드) | 7,498 MiB/s | 1,998 MiB/s | 3.8배 |
| Random Read IOPS (16 스레드) | 598,498 | 138,498 | 4.3배 |
| Random Write IOPS (16 스레드) | 228,498 | 55,498 | 4.1배 |
HeatWave가 Bare Metal 인스턴스의 NVMe 로컬 스토리지를 사용하는 반면, Aurora는 네트워크 기반 분산 스토리지를 사용해요. 이 아키텍처 차이가 IO 성능에서 4–5배 격차를 만들어요.
다만 Aurora의 분산 스토리지는 내구성과 가용성 측면에서 장점이 있어요. 6개 복제본을 3개 AZ에 분산 저장하는 구조라 데이터 유실 위험이 매우 낮아요. HeatWave도 HA 구성을 지원하지만, 스토리지 아키텍처 자체가 다르다는 점은 인지해야 해요.
실제 고객 환경 테스트 결과
벤치마크 수치는 통제된 환경에서의 결과예요. 실제 고객 워크로드에서는 어떨까요?
400명 동시 사용자 환경에서 실제 애플리케이션 워크로드를 돌린 결과예요.
| 측정 항목 | HeatWave | Aurora | 차이 |
|---|---|---|---|
| 평균 응답시간 | 기준 | 40% 느림 | HeatWave 40% 빠름 |
| 처리량 (TPS) | 기준 | 44% 낮음 | HeatWave 79% 높음 |
처음에는 이 정도 차이가 나올 거라고 예상하지 못했어요. 벤치마크에서 3–4배 차이가 나더라도 실제 워크로드에서는 캐시 히트율, 쿼리 패턴, 인덱스 활용도에 따라 격차가 줄어드는 경우가 많거든요. 하지만 Thread Pool 효과가 고동시성 환경에서 확실하게 작동했어요.
TPC-C 기준으로는 고동시성 환경에서 Aurora 대비 10배 높은 처리량을 보였어요. 이건 Thread Pool + Enterprise Edition의 쿼리 최적화가 결합된 결과예요.
벤치마크 해석 시 주의할 점
성능 수치를 볼 때 반드시 고려해야 할 맥락이 있어요. 공정한 비교를 위해 한계점을 명시할게요.
하드웨어 비대칭이 가장 큰 변수예요. HeatWave는 128 OCPUs + 2,048GB RAM, Aurora는 96 vCPUs + 768GB RAM이에요. CPU 코어 수 1.3배, 메모리 2.7배 차이가 있어요. 순수 소프트웨어 성능 비교라고 보기 어려운 부분이 있어요.
벤치마크 수행 주체도 고려해야 해요. 이 벤치마크는 Oracle이 수행하고 발표한 자료예요. 각 벤더는 자사 제품에 유리한 설정으로 테스트하는 경향이 있어요. 독립적인 제3자 검증이 추가되면 더 신뢰할 수 있어요.
워크로드 특성에 따라 결과가 달라져요. TPC-H는 분석 쿼리 벤치마크이고, Sysbench는 단순 OLTP 패턴이에요. 실제 애플리케이션의 쿼리 패턴은 이보다 복잡하고 다양해요. 특정 쿼리 패턴에서는 격차가 줄어들 수 있어요.
가격대비성능 비교도 단순하지 않아요. HeatWave의 시간당 비용(약 $3.22/hour, 16노드 클러스터)과 Redshift(약 $4.56/hour, ra3.xlplus 4노드)를 단순 비교하면 HeatWave가 저렴하지만, 실제 운영에서는 데이터 전송 비용, 스토리지 비용, 예약 인스턴스 할인 등을 종합적으로 계산해야 해요.
| 고려 항목 | 설명 |
|---|---|
| 하드웨어 스펙 차이 | HeatWave BM(128 OCPU, 2TB RAM) vs Aurora(96 vCPU, 768GB RAM) |
| 벤치마크 수행 주체 | Oracle 공식 자료. 독립 검증 권장 |
| 워크로드 대표성 | TPC-H/Sysbench는 표준이지만 실제 워크로드와 다를 수 있음 |
| 비용 계산 복잡성 | 시간당 비용 외 데이터 전송, 스토리지, RI 할인 고려 필요 |
| 측정 시점 | 각 서비스는 지속적으로 업데이트됨. 최신 버전에서 재검증 필요 |
어떤 상황에서 HeatWave를 선택해야 하나요?
벤치마크 결과를 종합하면, HeatWave가 확실한 우위를 보이는 시나리오가 있어요.
고동시성 OLTP 환경이 첫 번째예요. 동시 접속자가 200명 이상이고 Thread Pool 효과가 필요한 서비스라면 HeatWave의 이점이 커요.
OLTP + OLAP 통합이 필요한 환경이 두 번째예요. 별도 분석 DB 없이 실시간 분석을 원한다면, ETL 파이프라인을 제거하고 아키텍처를 단순화할 수 있어요.
비용 최적화가 필요한 환경이 세 번째예요. Aurora + Redshift + Glue 조합의 총 비용이 부담된다면, HeatWave 단일 시스템으로 전환하는 게 경제적일 수 있어요.
반면 Aurora가 더 적합한 경우도 있어요. AWS 생태계에 깊이 통합된 환경(Lambda, Step Functions, EventBridge 등과의 연동), 동시 접속자가 100명 미만인 소규모 서비스, 또는 OCI 환경으로의 전환이 조직적으로 어려운 경우에는 Aurora를 유지하는 게 현실적이에요.
핵심 요약
- Sysbench OLTP Read-Write 벤치마크에서 HeatWave는 Aurora 대비 최대 3.4배 높은 TPS를 보였어요. 동시 접속자가 늘수록 격차가 벌어져요.
- 고동시성 환경에서의 성능 차이는 Thread Pool 지원 여부에서 비롯돼요. Aurora는 one-thread-per-connection 모델이라 256 스레드 이상에서 성능이 정체돼요.
- OLAP(TPC-H 100GB) 기준으로 HeatWave는 Redshift 대비 6.5배, Snowflake 대비 4.5배, BigQuery 대비 3.5배 빠른 성능을 보였어요.
- 실제 고객 환경(400명 동시 사용자)에서 HeatWave가 응답시간 40% 빠르고 처리량 79% 높게 측정됐어요.
- 벤치마크 해석 시 하드웨어 비대칭(HeatWave 128 OCPU vs Aurora 96 vCPU), 벤치마크 수행 주체(Oracle), 워크로드 대표성을 함께 고려해야 해요.
FAQ
Q. HeatWave와 Aurora의 성능 차이가 실제 운영에서도 동일하게 나타나나요?
벤치마크 수치 그대로 재현되지는 않아요. 실제 워크로드는 캐시 히트율, 인덱스 활용도, 쿼리 복잡도에 따라 결과가 달라져요. 다만 400명 동시 사용자 실제 테스트에서 응답시간 40% 개선, 처리량 79% 향상이 확인됐으니, 고동시성 환경에서는 유의미한 차이가 나타난다고 볼 수 있어요.
Q. Aurora에서 HeatWave로 전환하면 기존 쿼리를 수정해야 하나요?
MySQL 호환이라 대부분의 쿼리는 수정 없이 동작해요. 다만 Aurora 전용 기능(Aurora Serverless v2의 자동 스케일링, Aurora Global Database 등)을 사용 중이라면 대체 방안을 검토해야 해요. HeatWave 전환 시 가장 큰 변경은 인프라 레이어(OCI 또는 HeatWave on AWS)이지 SQL 레이어가 아니에요.
Q. Thread Pool이 없는 Aurora에서 고동시성 문제를 해결하는 방법은 없나요?
Aurora에서는 RDS Proxy를 사용해서 커넥션 풀링을 할 수 있어요. 하지만 RDS Proxy는 커넥션 관리를 효율화할 뿐, 내부적으로는 여전히 one-thread-per-connection 모델이에요. 근본적인 Thread Pool과는 다른 접근이에요. 애플리케이션 레벨에서 커넥션 풀 크기를 제한하고, Read Replica를 활용해 읽기 부하를 분산하는 게 Aurora 환경에서의 현실적인 대안이에요.
Q. TPC-H 벤치마크에서 HeatWave가 Redshift보다 빠른 이유는 뭔가요?
HeatWave는 인메모리 컬럼 스토리지에서 MPP로 처리하고, 데이터 인코딩과 압축을 ML 기반으로 자동 최적화해요. Redshift도 컬럼 스토리지를 사용하지만, 디스크 기반(ra3 노드는 관리형 스토리지)이라 IO 바운드가 발생할 수 있어요. 또한 HeatWave의 Autopilot이 쿼리 플랜을 자동으로 개선하는 효과도 있어요.
Q. 벤치마크에서 하드웨어 스펙이 다른데, 공정한 비교라고 볼 수 있나요?
엄밀히 말하면 동일 조건 비교는 아니에요. HeatWave(128 OCPU, 2TB RAM)와 Aurora(96 vCPU, 768GB RAM)는 스펙 차이가 있어요. 다만 이 벤치마크의 의도는 "각 클라우드에서 제공하는 최적 구성에서의 실질적 성능"을 비교하는 거예요. 동일 비용 대비 성능(가격대비성능)으로 비교하면 HeatWave가 유리하다는 게 Oracle의 주장이에요. 도입 검토 시에는 자사 워크로드로 직접 PoC를 수행하는 걸 권장해요.