MySQL HeatWave 고가용성 설계, Aurora와 어떻게 다른가요?

핵심 요약: HeatWave HA의 InnoDB Cluster, Group Replication, MySQL Router 구조를 Aurora와 비교해요. RPO 0, 수 초 RTO, 99.995% SLA가 어떤 운영 차이를 만드는지 확인할 수 있어요.

지난 글에서 HeatWave 운영 모니터링 체계를 다뤘어요. 이번에는 한 단계 더 들어가서, 고가용성(HA) 아키텍처를 다룰게요.

운영하면서 계속 느낀 건, HA 설계는 "장애가 나면 어떻게 복구하는가"보다 "장애가 나도 서비스가 계속 돌아가는가"를 먼저 설계해야 한다는 거예요. 그 차이가 RTO 30초와 RTO 수 초의 차이를 만들어요.

AWS Aurora에서 HeatWave로 전환을 검토하는 고객사들이 가장 많이 묻는 질문 중 하나가 "HA 수준이 Aurora만큼 되나요?"예요. 이 글에서는 두 시스템의 HA 아키텍처를 구체적으로 비교하고, 실제 운영에서 어떤 차이가 생기는지 정리했어요.

HeatWave HA의 기반, InnoDB Cluster

HeatWave의 고가용성은 MySQL InnoDB Cluster 위에 구축돼요. 핵심은 3-Node Group Replication이에요.

3개 노드가 하나의 그룹을 형성하고, 쓰기 트랜잭션은 과반수(2개 이상) 노드의 동의를 받아야 커밋돼요. 이 방식을 Paxos 기반 합의 프로토콜이라고 해요. 마치 중요한 결정을 내릴 때 3명 중 2명 이상이 동의해야 통과되는 위원회 구조와 비슷해요. 한 명이 자리를 비워도 나머지 두 명이 결정을 내릴 수 있어요.

OCI에서는 이 3개 노드를 서로 다른 Availability Domain(AD) 또는 Fault Domain에 배치해요.

복제 방식은 동기(Synchronous) 복제예요. Primary에서 트랜잭션이 커밋되기 전에 Secondary 노드들에도 반영이 완료돼요. 이 덕분에 RPO(Recovery Point Objective)가 0이에요. Primary가 갑자기 죽어도 데이터 손실이 없어요.

Failover가 실제로 어떻게 동작하나요?

Primary 노드에 장애가 발생하면 다음 순서로 자동 복구가 진행돼요.

Group Replication이 Primary 노드 장애를 감지해요.
남은 Secondary 노드들 사이에서 새 Primary 선출(Election)이 진행돼요.
선출된 노드가 Primary로 승격돼요.
MySQL Router가 새 Primary로 연결을 자동 전환해요.
애플리케이션은 재연결 후 정상 동작을 재개해요.

이 전체 과정이 수 초 안에 완료돼요. 애플리케이션 입장에서는 잠깐의 연결 끊김 후 자동으로 새 Primary에 연결되는 경험을 해요.

여기서 MySQL Router의 역할이 중요해요. Router는 애플리케이션과 DB 사이에 위치해서 읽기/쓰기 트래픽을 자동으로 라우팅해요. Primary에는 Read/Write 요청을, Secondary에는 Read-Only 요청을 보내요. Failover 시에도 Router가 새 Primary를 자동으로 감지하기 때문에 애플리케이션 코드를 바꿀 필요가 없어요.

한 가지 주의할 점이 있어요. Router 자체가 단일 장애점(SPOF)이 되지 않도록 여러 인스턴스를 배포해야 해요. 운영하면서 발견했던 문제 중 하나가 Router를 단일 인스턴스로만 운영하다가 Router 서버에 문제가 생겼을 때 DB는 멀쩡한데 서비스가 중단된 케이스예요.

Switchover와 Failover의 차이

HA 운영에서 자주 혼동하는 개념이 Switchover와 Failover예요.

Failover는 예상치 못한 장애 상황에서 자동으로 발생해요. Primary 노드가 갑자기 다운되면 Group Replication이 자동으로 새 Primary를 선출해요.

Switchover는 계획된 작업이에요. 패치 적용, 하드웨어 교체, 유지보수 작업 전에 수동으로 Primary를 전환해요. 데이터 손실 없이 다운타임 없이 Primary를 바꿀 수 있어요.

실무에서 Switchover를 제대로 활용하면 운영 부담이 크게 줄어요. 패치 작업을 할 때 Secondary를 먼저 패치하고, Switchover로 Primary를 전환한 뒤, 기존 Primary를 패치하는 방식으로 무중단 패치가 가능해요.

Aurora HA와 구체적으로 무엇이 다른가요?

Aurora의 HA는 스토리지 레이어에서 구현돼요. 데이터를 3개 AZ에 걸쳐 6개 복사본으로 저장하고, 쓰기 시 4개 이상의 복사본에 성공해야 커밋이 완료돼요. 이 방식은 스토리지 레벨의 내구성은 매우 높지만, Failover 시 DNS 전환 방식을 사용하기 때문에 전환 시간이 HeatWave보다 길어요.

항목	MySQL HeatWave	AWS Aurora
SLA	99.995%	99.99%
RPO	0 (동기 복제)	거의 0 (스토리지 레벨 복제)
RTO	수 초	약 30초
Failover 방식	Group Replication 자동 선출	DNS 기반 엔드포인트 전환
Read Replica	최대 18개	최대 15개
크로스 리전	Inbound/Outbound 채널 기반	Global Database (최대 5개 리전)
복제 방식	동기 복제 (Group Replication)	스토리지 레벨 복제 (6개 복사본)
라우팅	MySQL Router (애플리케이션 레벨)	DNS 기반 엔드포인트

SLA 차이가 눈에 띄어요. 99.995%와 99.99%는 숫자로는 작아 보이지만, 연간 허용 다운타임으로 환산하면 99.995%는 약 26분, 99.99%는 약 52분이에요. 두 배 차이예요.

RTO 차이도 실무에서 체감이 달라요. Aurora의 약 30초 Failover는 대부분의 서비스에서 허용 가능한 수준이에요. 하지만 금융 거래나 실시간 결제처럼 초 단위 가용성이 중요한 서비스에서는 HeatWave의 수 초 RTO가 의미 있는 차이를 만들어요.

크로스 리전 복제, 어떻게 다른가요?

재해 복구(DR) 설계에서 크로스 리전 복제는 핵심 요소예요.

Aurora는 Global Database 기능으로 최대 5개 Secondary 리전을 구성할 수 있어요. 스토리지 레벨에서 복제가 이루어지고, 일반적으로 1초 미만의 복제 지연을 보여요.

HeatWave는 Inbound/Outbound 채널 기반의 비동기 복제를 사용해요. Inbound는 외부 MySQL에서 OCI HeatWave로 데이터를 받아오는 방향이고, Outbound는 OCI HeatWave에서 외부로 내보내는 방향이에요. GTID 기반으로 동작하기 때문에 복제 일관성을 보장해요.

크로스 리전 복제를 위한 기본 설정이에요.

-- GTID 기반 복제 설정 확인
SHOW VARIABLES LIKE 'gtid_mode';
SHOW VARIABLES LIKE 'enforce_gtid_consistency';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'log_slave_updates';

운영 환경에서는 gtid_mode=ON, enforce_gtid_consistency=ON, binlog_format=ROW, log_bin=ON, log_slave_updates=ON이 모두 활성화되어 있어야 해요.

Aurora Global Database가 더 간단하게 설정할 수 있는 건 사실이에요. HeatWave의 채널 기반 복제는 설정 항목이 더 많고, 복제 상태를 직접 모니터링해야 해요. 대신 복제 방향과 필터링을 더 세밀하게 제어할 수 있어요.

HA 상태 모니터링 쿼리

HA 구성이 정상적으로 동작하는지 확인하는 SQL 쿼리들이에요. 운영 중에 주기적으로 실행하거나 모니터링 대시보드에 연결해서 사용해요.

멤버 상태 확인

-- Group Replication 멤버 상태 전체 조회
SELECT
  MEMBER_HOST,
  MEMBER_PORT,
  MEMBER_STATE,
  MEMBER_ROLE,
  MEMBER_VERSION
FROM performance_schema.replication_group_members;

MEMBER_STATE가 ONLINE이어야 정상이에요. RECOVERING은 노드가 복구 중인 상태, ERROR는 즉시 확인이 필요한 상태예요. MEMBER_ROLE에서 PRIMARY가 1개, SECONDARY가 2개인지 확인해요.

복제 지연 및 트랜잭션 큐 확인

-- 복제 지연 및 트랜잭션 처리 현황
SELECT
  MEMBER_ID,
  COUNT_TRANSACTIONS_IN_QUEUE,
  COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE,
  COUNT_TRANSACTIONS_CHECKED,
  COUNT_TRANSACTIONS_REMOTE_APPLIED
FROM performance_schema.replication_group_member_stats\G

COUNT_TRANSACTIONS_IN_QUEUE가 지속적으로 증가하면 Secondary 노드가 Primary를 따라가지 못하고 있다는 신호예요. 이 값이 높아지면 Failover 시 데이터 손실 위험이 생길 수 있어요.

복제 연결 상태 확인

-- 복제 채널 연결 상태
SELECT
  CHANNEL_NAME,
  SERVICE_STATE,
  RECEIVED_TRANSACTION_SET,
  LAST_ERROR_MESSAGE
FROM performance_schema.replication_connection_status\G

SERVICE_STATE가 ON이어야 정상이에요. LAST_ERROR_MESSAGE에 내용이 있으면 복제 오류가 발생한 거예요.

복제 적용 상태 확인

-- 복제 Applier 상태
SELECT
  CHANNEL_NAME,
  SERVICE_STATE,
  LAST_ERROR_MESSAGE,
  LAST_APPLIED_TRANSACTION
FROM performance_schema.replication_applier_status\G

이 쿼리들을 OCI Alarm과 연동하면 복제 지연이나 멤버 상태 변화를 자동으로 감지할 수 있어요. 운영하면서 가장 유용했던 알람은 COUNT_TRANSACTIONS_IN_QUEUE가 일정 임계값을 넘을 때 발생하는 알람이었어요.

운영에서 놓치기 쉬운 부분들

HA 아키텍처를 구성했다고 끝이 아니에요. 운영하면서 겪었던 함정들이 있어요.

가장 먼저 확인해야 할 건 Primary Key예요. Group Replication은 모든 테이블에 Primary Key가 있어야 성능이 제대로 나와요. Primary Key가 없는 테이블이 있으면 복제 성능이 급격히 떨어지고, 경우에 따라 복제 오류가 발생해요. 기존 MySQL에서 마이그레이션할 때 이 부분을 놓치는 경우가 많아요.

MySQL Router 배치 위치도 실수하기 쉬운 부분이에요. Router는 애플리케이션과 같은 네트워크 내에 배치해야 해요. Router를 DB 서버와 같은 서브넷에 두면 DB 장애 시 Router도 함께 영향을 받을 수 있어요.

그리고 3개 노드를 배포했더라도 같은 Fault Domain에 2개가 배치되면 HA 효과가 반감돼요. OCI 콘솔에서 각 노드의 Fault Domain을 직접 확인해야 해요. 저희도 초기 구성에서 이걸 놓쳐서 장애 테스트 때 발견했어요.

트레이드오프도 있어요. 동기 복제는 RPO 0을 보장하지만, 네트워크 지연이 높은 환경에서는 쓰기 성능에 영향을 줄 수 있어요. 특히 크로스 AD 구성에서 AD 간 네트워크 지연이 쓰기 레이턴시에 직접 반영돼요. 읽기 성능은 Secondary로 분산되기 때문에 오히려 좋아지지만, 쓰기 집중 워크로드에서는 이 트레이드오프를 고려해야 해요.

어떤 상황에서 HeatWave HA를 선택하나요?

Aurora와 HeatWave HA 중 어느 쪽이 더 낫다고 단정하기는 어려워요. 워크로드와 요구사항에 따라 달라요.

HeatWave HA가 더 적합한 상황이 있어요. RTO를 수 초 이내로 요구하는 서비스, 99.995% SLA가 필요한 서비스, OLAP 워크로드를 함께 처리해야 하는 경우, 이미 OCI 인프라를 사용 중인 경우예요.

Aurora가 더 적합한 상황도 있어요. AWS 생태계에 깊이 통합된 서비스, Aurora Serverless처럼 자동 스케일링이 필요한 경우, Aurora Global Database의 간편한 멀티 리전 설정이 필요한 경우예요.

운영하면서 계속 느낀 건, HA 아키텍처 선택은 기술 스펙보다 운영 팀의 역량과 기존 인프라 환경이 더 큰 변수라는 거예요. 아무리 좋은 HA 구성도 모니터링과 운영 절차가 없으면 장애 시 제대로 동작하지 않아요.

핵심 요약

HeatWave HA는 3-Node InnoDB Cluster(Group Replication) 기반으로, 동기 복제를 통해 RPO 0을 보장해요.
Failover는 수 초 안에 자동으로 완료되며, MySQL Router가 새 Primary로 연결을 자동 전환해요.
Aurora 대비 SLA(99.995% vs 99.99%)와 RTO(수 초 vs 약 30초)에서 차이가 있어요.
Read Replica는 HeatWave가 최대 18개, Aurora가 최대 15개를 지원해요.
MySQL Router SPOF 방지, Primary Key 필수, Fault Domain 분산 배치가 운영 핵심 포인트예요.
동기 복제는 RPO 0을 보장하지만, 쓰기 집중 워크로드에서 레이턴시 트레이드오프가 있어요.

FAQ

Q. HeatWave HA와 Aurora Multi-AZ의 가장 큰 차이는 무엇인가요?

복제 방식과 Failover 메커니즘이 달라요. HeatWave는 Group Replication 기반 동기 복제로 RPO 0을 보장하고, Failover가 수 초 안에 완료돼요. Aurora는 스토리지 레벨 복제(6개 복사본)로 내구성을 확보하고, DNS 기반 엔드포인트 전환으로 Failover가 약 30초 걸려요. SLA도 HeatWave 99.995%, Aurora 99.99%로 차이가 있어요.

Q. MySQL Router가 없으면 HA가 동작하지 않나요?

Router 없이도 Group Replication 자체는 동작해요. 하지만 Failover 시 애플리케이션이 새 Primary 주소를 자동으로 알 수 없어요. Router가 있어야 Failover 후 자동으로 새 Primary로 연결이 전환돼요. Router를 사용하지 않으면 애플리케이션에서 직접 Primary 감지 로직을 구현해야 해요.

Q. 3개 노드 중 2개가 동시에 장애가 나면 어떻게 되나요?

Group Replication은 과반수 합의가 필요해요. 3개 노드 중 2개가 다운되면 남은 1개 노드만으로는 과반수를 충족할 수 없어서 쓰기 작업이 중단돼요. 이 상황을 Split-Brain 방지 메커니즘이라고 해요. 데이터 불일치를 막기 위한 설계예요. 읽기는 가능하지만 쓰기는 불가능한 상태가 돼요.

Q. Switchover와 Failover를 어떻게 구분해서 사용하나요?

Switchover는 계획된 작업 전에 사용해요. 패치 적용, 유지보수, 하드웨어 교체 시 Switchover로 Primary를 전환하면 다운타임 없이 작업할 수 있어요. Failover는 예상치 못한 장애 시 자동으로 발생해요. 운영 절차에서 Switchover를 적극 활용하면 Failover가 발생하는 상황 자체를 줄일 수 있어요.

Q. HeatWave HA에서 크로스 리전 DR을 구성하려면 어떻게 하나요?

Inbound/Outbound 채널 기반 비동기 복제를 사용해요. DR 리전에 별도 HeatWave 인스턴스를 구성하고, Primary 리전에서 Outbound 채널로 복제를 설정해요. GTID 기반으로 동작하기 때문에 복제 일관성을 보장해요. Aurora Global Database보다 설정이 복잡하지만, 복제 방향과 필터링을 더 세밀하게 제어할 수 있어요.

MySQL HeatWave 고가용성 설계, Aurora와 어떻게 다른가요?

MySQL HeatWave 고가용성 설계, Aurora와 어떻게 다른가요?

HeatWave HA의 기반, InnoDB Cluster

Failover가 실제로 어떻게 동작하나요?

Switchover와 Failover의 차이

Aurora HA와 구체적으로 무엇이 다른가요?

크로스 리전 복제, 어떻게 다른가요?

HA 상태 모니터링 쿼리

멤버 상태 확인

복제 지연 및 트랜잭션 큐 확인

복제 연결 상태 확인

복제 적용 상태 확인

운영에서 놓치기 쉬운 부분들

어떤 상황에서 HeatWave HA를 선택하나요?

핵심 요약

FAQ

고가용성 설계, 전문가와 함께 시작하세요.