MySQL HeatWave를 멀티클라우드로 배포하는 아키텍처는 어떻게 구성하나요?
핵심 요약: HeatWave on OCI와 on AWS 배포 옵션을 비교하고, Cloud Connect 기반 멀티클라우드 설계 기준을 정리해요. 1–5ms 레이턴시, 데이터 주권, 전송 비용을 함께 판단하는 방법을 배울 수 있어요.
왜 고객사는 AWS와 OCI를 함께 사용할까요? 단순히 벤더 종속을 피하려는 것만은 아니에요. 실제로 저희가 만난 고객사들의 이유는 더 구체적이었어요. 기존 애플리케이션은 AWS에서 운영하면서, 분석 워크로드는 HeatWave의 성능이 필요한 상황. 또는 그룹사 정책으로 특정 데이터는 반드시 국내 리전에 두어야 하는 규정. 이런 현실적인 제약 조건들이 멀티클라우드 아키텍처를 선택하게 만들어요.
이 글에서는 HeatWave on OCI와 HeatWave on AWS의 배포 옵션을 비교하고, Cloud Connect를 통한 하이브리드 구성 방법, 그리고 멀티클라우드 설계 시 반드시 고려해야 할 네트워크 레이턴시, 데이터 주권, 비용 최적화 전략을 다룰게요.
HeatWave 배포 옵션, OCI와 AWS의 차이
MySQL HeatWave는 두 가지 배포 모델을 제공해요. OCI 네이티브 배포와 AWS 크로스클라우드 배포예요.
HeatWave on OCI는 Oracle Cloud Infrastructure 위에서 네이티브로 실행돼요. OCI Object Storage와 직접 연동되고, Oracle 에코시스템(Autonomous DB, Oracle Database 등)과의 통합이 긴밀해요. 전체 기능을 제한 없이 사용할 수 있고, 가격 대비 성능이 가장 좋은 옵션이에요.
HeatWave on AWS는 2022년에 출시된 크로스클라우드 서비스예요. 사용자의 AWS VPC 내에서 MySQL 프로토콜로 접속하지만, 실제 HeatWave 처리는 OCI 인프라에서 수행돼요. 기존 AWS 워크로드와의 근접성이 장점이에요. 애플리케이션 코드 변경 없이 기존 Aurora MySQL에서 전환할 수 있어요.
| 항목 | HeatWave on OCI | HeatWave on AWS |
|---|---|---|
| 실행 환경 | OCI 네이티브 | AWS VPC + OCI 처리 |
| Object Storage 연동 | OCI Object Storage | Amazon S3 (Lakehouse) |
| 네트워크 레이턴시 | 최소 (co-located) | 추가 발생 (크로스클라우드) |
| 기능 범위 | 전체 (OLTP+OLAP+ML+GenAI) | 동일 |
| 가격 효율성 | 높음 | OCI 대비 약간 높음 |
| 기존 AWS 앱 연동 | VPN/FastConnect 필요 | 네이티브 VPC 연결 |
운영하면서 계속 느낀 건, 배포 모델 선택이 기술적 우열보다는 고객사의 기존 인프라 투자와 조직 구조에 더 크게 좌우된다는 거예요. AWS에 수백 개의 서비스를 운영 중인 고객사가 분석 워크로드만을 위해 OCI로 전면 이전하는 건 현실적이지 않아요.
Cloud Connect를 통한 하이브리드 구성
멀티클라우드 아키텍처에서 가장 중요한 건 클라우드 간 네트워크 연결이에요. 퍼블릭 인터넷을 경유하면 레이턴시가 불안정하고 보안 리스크가 커져요. 그래서 전용 네트워크 연결(Cloud Connect)이 필수예요.
한국에서 OCI-AWS 간 전용 연결을 제공하는 주요 벤더는 세 곳이에요.
KT Cloud Connect
KT의 MPLS 백본 네트워크를 활용한 전용 연결 서비스예요. 고객 사이트에서 KT PoP까지 전용회선(Access Line)을 설치하고, KT 백본을 거쳐 OCI FastConnect와 AWS Direct Connect에 동시 접속할 수 있어요.
대역폭은 50Mbps부터 10Gbps까지 선택 가능하고, 서울 리전 기준 1–3ms 수준의 낮은 레이턴시를 제공해요. 기존에 KT 전용선을 보유한 고객사라면 추가 회선 설치 없이 빠르게 연결할 수 있다는 게 장점이에요.
KINX 클라우드허브
KINX의 IX(Internet Exchange) 인프라 위에 구축된 서비스예요. 가산 또는 도곡 IDC에서 하나의 물리 포트로 OCI, AWS, Azure, GCP에 동시 접속할 수 있어요. VLAN 태깅으로 트래픽을 분리하는 공유형 포트 방식이에요.
OCI FastConnect 1Gbps 기준으로 월 100만원 수준이에요. Cloud Hub Port 50만원 + OCI FastConnect 연결 50만원 구성이에요. 최소 계약 기간은 1년이고, 99.9% 가용성 SLA를 보장해요.
Equinix Fabric
글로벌 데이터센터 사업자인 Equinix의 소프트웨어 정의 네트워크 서비스예요. 서울 데이터센터(SL1)에서 OCI와 AWS를 포함한 글로벌 CSP에 직접 연결할 수 있어요. 글로벌 멀티리전 구성이 필요한 고객사에 적합해요.
| 벤더 | 특징 | 적합한 고객사 |
|---|---|---|
| KT Cloud Connect | MPLS 백본, 기존 KT 회선 활용 | KT IDC 입주 고객, 전국 거점 필요 |
| KINX 클라우드허브 | IX 기반, 멀티CSP 동시 연결 | 서울 IDC 중심, 비용 효율 중시 |
| Equinix Fabric | 글로벌 SDN, 멀티리전 | 글로벌 서비스, 해외 리전 연결 필요 |
처음엔 "가장 싼 옵션"을 찾으려 했는데, 실제로는 고객사의 기존 IDC 위치와 이미 보유한 전용선이 선택을 결정하는 경우가 대부분이었어요.
멀티클라우드 아키텍처 설계 패턴
실제 고객사에서 구성한 멀티클라우드 HeatWave 아키텍처는 크게 세 가지 패턴으로 나뉘어요.
패턴 1. AWS 애플리케이션 + OCI HeatWave (분석 분리형)
기존 애플리케이션은 AWS에서 그대로 운영하면서, 분석 워크로드만 OCI의 HeatWave로 처리하는 구조예요. AWS VPC와 OCI VCN을 Cloud Connect로 연결하고, 애플리케이션이 MySQL 프로토콜(3306 포트)로 HeatWave에 직접 쿼리를 보내요.
이 패턴은 기존 AWS 투자를 유지하면서 HeatWave의 분석 성능을 활용하고 싶을 때 적합해요. 다만 크로스클라우드 네트워크 레이턴시가 추가되므로, 실시간 OLTP보다는 배치 분석이나 리포팅 워크로드에 적합해요.
패턴 2. HeatWave on AWS 단독 (AWS 네이티브형)
모든 인프라를 AWS에서 운영하면서 HeatWave on AWS를 사용하는 구조예요. 애플리케이션과 HeatWave가 같은 AWS VPC 안에 있으므로 네트워크 구성이 단순해요. Cloud Connect 비용도 발생하지 않아요.
다만 HeatWave 처리 자체는 OCI에서 수행되므로, 대용량 데이터 로딩 시 크로스클라우드 전송이 발생해요. TPC-H 벤치마크 기준으로 쿼리 성능은 OCI 네이티브와 동등한 수준이에요.
패턴 3. OCI 전면 배포 + AWS 연동 (OCI 중심형)
HeatWave를 포함한 데이터 레이어 전체를 OCI에 배치하고, AWS의 특정 서비스(예: SageMaker, Lambda)만 연동하는 구조예요. 데이터 처리 성능이 최우선인 고객사에 적합해요. OCI FastConnect로 AWS와 연결하되, 데이터 이동을 최소화하는 설계예요.
네트워크 레이턴시, 무시하면 안 되는 현실
멀티클라우드에서 가장 과소평가되는 요소가 네트워크 레이턴시예요. 같은 클라우드 내에서는 sub-millisecond 수준이지만, 클라우드 간 전용 연결을 사용해도 1–5ms가 추가돼요.
이게 왜 중요하냐면, OLTP 워크로드에서 단일 트랜잭션이 수십 번의 DB 호출을 하는 경우가 흔해요. 호출당 3ms가 추가되면 30번 호출 시 90ms가 누적돼요. 사용자 체감 응답 시간에 직접 영향을 줘요.
그래서 저희가 권장하는 원칙은 이래요.
OLTP(트랜잭션 처리)는 애플리케이션과 같은 클라우드에 배치하고, OLAP(분석 처리)은 HeatWave가 있는 곳에서 처리해요. 분석 쿼리는 한 번 호출에 대량 데이터를 처리하므로 레이턴시 영향이 상대적으로 작아요.
Lakehouse 기능을 활용하면 S3에 있는 데이터를 OCI로 이동하지 않고도 HeatWave에서 직접 쿼리할 수 있어요. 데이터 이동 없이 분석하는 구조가 레이턴시와 비용 모두를 줄여줘요.
데이터 주권과 컴플라이언스
한국 엔터프라이즈 환경에서 멀티클라우드를 설계할 때 반드시 부딪히는 문제가 데이터 주권이에요. 금융보안원 규정, ISMS-P 인증, 그룹사 보안 정책 등이 데이터의 물리적 위치를 제한해요.
OCI 서울 리전(춘천)과 AWS 서울 리전을 사용하면 데이터가 국내에 머물러요. Cloud Connect도 국내 IDC 간 전용선이므로 데이터가 해외로 나가지 않아요. 이 구조라면 대부분의 국내 규정을 충족할 수 있어요.
다만 주의할 점이 있어요. HeatWave on AWS를 사용할 때, HeatWave 처리 자체는 OCI 인프라에서 수행돼요. 쿼리 처리 과정에서 데이터가 일시적으로 OCI 노드에 로드된다는 점을 보안 감사 시 설명할 수 있어야 해요. Oracle은 처리 완료 후 데이터를 영구 저장하지 않는다고 명시하고 있지만, 규정 해석에 따라 이슈가 될 수 있어요.
실무에서 만난 해결 방법은 이래요. 민감 데이터(개인정보, 금융 거래)는 OCI 서울 리전의 HeatWave on OCI에 배치하고, 비민감 분석 데이터만 HeatWave on AWS로 처리하는 이원화 구조예요.
비용 최적화 전략
멀티클라우드 구성에서 비용은 크게 세 가지로 나뉘어요. HeatWave 서비스 비용, Cloud Connect 비용, 데이터 전송 비용이에요.
HeatWave 자체는 OLTP+OLAP을 하나로 통합하므로 Aurora+Redshift 조합 대비 최대 50% 비용 절감이 가능해요. 하지만 Cloud Connect 비용이 추가되므로, 전체 TCO를 계산해야 해요.
Cloud Connect 비용은 벤더와 대역폭에 따라 월 50만원(KINX 100Mbps)에서 수백만원(10Gbps 전용)까지 다양해요. 분석 워크로드의 데이터 전송량을 먼저 산정하고, 필요한 대역폭을 역산하는 게 맞아요.
비용 최적화를 위해 저희가 실제로 적용한 방법들이에요.
HeatWave Lakehouse를 활용해서 S3 데이터를 OCI로 복제하지 않고 직접 쿼리해요. 데이터 전송 비용을 줄이는 가장 효과적인 방법이에요. AutoPilot 기능으로 HeatWave 노드 수를 워크로드에 맞게 자동 조절하면 과잉 프로비저닝을 방지할 수 있어요. 분석 쿼리가 집중되는 시간대에만 HeatWave 클러스터를 활성화하는 스케줄링도 가능해요.
설계 시 체크리스트
멀티클라우드 HeatWave 아키텍처를 설계할 때 저희가 사용하는 체크리스트예요.
| 검토 항목 | 확인 내용 |
|---|---|
| 워크로드 분류 | OLTP와 OLAP 워크로드가 어디에 위치해야 하는가 |
| 데이터 위치 규정 | 민감 데이터의 물리적 위치 제한이 있는가 |
| 기존 인프라 | 현재 IDC 위치, 보유 전용선, CSP 계약 현황 |
| 레이턴시 요구사항 | 애플리케이션-DB 간 허용 가능한 레이턴시 |
| 데이터 전송량 | 클라우드 간 일일/월간 데이터 전송 예상량 |
| 이중화 요구사항 | Cloud Connect 이중화 필요 여부 |
| 보안 감사 대응 | 크로스클라우드 데이터 처리에 대한 감사 대응 방안 |
핵심 요약
- HeatWave는 OCI 네이티브와 AWS 크로스클라우드 두 가지 배포 모델을 제공하며, 선택은 기존 인프라 투자와 조직 구조에 따라 결정돼요
- Cloud Connect(KT, KINX, Equinix)를 통해 1–3ms 수준의 전용 네트워크 연결이 가능하고, 월 100만원 수준부터 구성할 수 있어요
- OLTP는 애플리케이션과 같은 클라우드에, OLAP은 HeatWave에 배치하는 것이 레이턴시 최적화의 핵심이에요
- 데이터 주권 이슈는 민감/비민감 데이터를 이원화하여 배치하는 구조로 해결할 수 있어요
- Lakehouse와 AutoPilot을 활용하면 데이터 전송 비용과 과잉 프로비저닝을 동시에 줄일 수 있어요
FAQ
Q. HeatWave on AWS를 사용하면 데이터가 OCI로 이동하나요?
HeatWave on AWS에서 쿼리를 실행하면, 처리 과정에서 데이터가 OCI의 HeatWave 노드에 일시적으로 로드돼요. 하지만 영구 저장은 AWS 측에서 이루어지고, 처리 완료 후 OCI 노드의 데이터는 유지되지 않아요. 원본 데이터는 AWS에 그대로 남아 있어요.
Q. Cloud Connect 없이 멀티클라우드 HeatWave를 구성할 수 있나요?
HeatWave on AWS를 사용하면 Cloud Connect 없이도 AWS 내에서 HeatWave를 활용할 수 있어요. 다만 OCI의 HeatWave와 AWS 애플리케이션을 직접 연결하려면 Cloud Connect 또는 VPN이 필요해요. VPN은 비용이 낮지만 대역폭과 레이턴시 안정성이 떨어져요.
Q. KINX와 KT Cloud Connect 중 어떤 걸 선택해야 하나요?
기존에 KT IDC에 입주해 있거나 KT 전용선을 보유하고 있다면 KT Cloud Connect가 추가 비용 없이 빠르게 연결할 수 있어요. 서울 가산/도곡 IDC에 장비가 있다면 KINX가 비용 효율적이에요. 글로벌 리전 연결이 필요하면 Equinix를 검토하세요.
Q. 멀티클라우드 구성 시 HeatWave 성능이 떨어지나요?
HeatWave 엔진 자체의 쿼리 처리 성능은 배포 위치와 무관하게 동일해요. TPC-H 벤치마크 기준으로 OCI 네이티브와 AWS 배포 간 분석 쿼리 성능 차이는 거의 없어요. 차이가 나는 건 데이터 로딩 시간과 네트워크 레이턴시 부분이에요.
Q. 금융권에서도 멀티클라우드 HeatWave를 사용할 수 있나요?
OCI 서울 리전과 AWS 서울 리전을 사용하고, 국내 Cloud Connect로 연결하면 데이터가 국내에 머물러요. 금융보안원의 클라우드 이용 가이드라인을 충족할 수 있는 구조예요. 다만 HeatWave on AWS의 크로스클라우드 처리 부분은 보안 심의 시 별도 설명이 필요할 수 있으므로, 사전에 규정 해석을 확인하는 걸 권장해요.