Infra/High Availability

RDBMS에서 일반적인 HA 패턴

peanutwalnut 2025. 1. 21. 15:16

전통적인 RDBMS(예: MySQL, PostgreSQL, Oracle, SQL Server 등)에서도 **HA(High Availability)**를 위해 다양한 기술과 아키텍처가 있습니다. 일반적으로는 아래와 같은 패턴이 널리 쓰입니다.

1. 단일 리전 내 HA

1) Shared Disk Clustering (예: Oracle RAC)

  • 여러 DB 인스턴스가 동시에 하나의 스토리지(공유 디스크)를 사용.
  • 노드 중 하나가 죽어도 다른 노드들이 계속 같은 물리 디스크/스토리지를 바라보며 DB 서비스를 이어감.
  • 대표적으로 Oracle RAC(Real Application Clusters), MSSQL Server FCI(Failover Cluster Instance) 등이 있음.
  • 스토리지가 단일 지점(Single Point)이 되므로, 스토리지 레벨에서 이중화 또는 SAN(Storage Area Network) 구성 등을 고려해야 함.
  • 주로 한 데이터센터(리전) 내에서 저지연 네트워크로 구성.

2) Replication 기반 Active/Passive (예: MySQL Master-Slave, PostgreSQL Streaming Replication)

  • 하나의 마스터(Primary) DB가 쓰기(Write) 연산을 처리하고, 다른 노드(Standby)들은 그 변경 사항을 로그(또는 WAL, binlog) 형태로 복제받아 동기화.
  • 장애 발생 시 수동 혹은 자동으로 Failover(Standby를 Master로 승격).
  • MySQL의 고전적 Master-Slave 구조, PostgreSQL의 Streaming Replication + Patroni/pgpool-II를 통한 오토-페일오버 등이 대표적.
  • 동기(Synchronous) vs 비동기(Asynchronous) 모드:
    • 동기 복제: 장애 시 데이터 유실이 없지만, 지연(latency)이 커질 수 있음.
    • 비동기 복제: 지연은 작지만, 장애 시 마지막 일부 트랜잭션 손실 가능성 존재.

3) 무공유(Shared-Nothing) 동기 멀티마스터 클러스터 (예: Galera Cluster, Percona XtraDB Cluster)

  • MySQL 계열에서 Galera 라이브러리를 이용해 모든 노드가 동시에 쓰기/읽기 처리 가능(멀티마스터)하게 구성.
  • 트랜잭션마다 합의(Consensus) 과정을 통해 동기화.
  • 노드 하나 장애 시에도 다른 노드에서 계속 동작.
  • 보통 단일 리전 내에 3대 이상의 노드를 두어 쿼럼(quorum)을 맞추는 식으로 사용.

2. 멀티 리전(멀리 떨어진 데이터센터) 간 HA

1) 기본 복제(Replication) 확장

  • 위에서 언급한 Master-Slave(혹은 Primary-Standby) 구조를, 물리적으로 다른 리전에 있는 Standby 노드까지 확장.
  • 동기 복제로 원거리 리전에 데이터를 쓰려면 네트워크 지연이 커져 성능이 크게 저하될 수 있음.
  • 그래서 주로 비동기(Asynchronous) 복제를 쓰고, 재해(DC 단위 장애) 발생 시 RPO(Recovery Point Objective)를 일부 감수하고 Failover를 진행.

2) 로그-시나리오별 전문 솔루션 (예: Oracle Data Guard, Microsoft SQL Server Always On AG)

  • Oracle Data Guard: Primary-Standby 구조에서 여러 모드(Maximum Performance, Maximum Availability 등)를 선택하여 동기/비동기, 세미싱크 등을 결정.
  • MSSQL Server Always On Availability Groups: 멀리 떨어진 리전에 복제본(Secondary)을 두고, 장애 시 자동으로 Failover. 동기/비동기 가능.
  • PostgreSQL BDR(Bi-Directional Replication): 다중 활성(Active) 노드 간 양방향 복제. 다만 지연, 충돌 처리 등 복잡도가 있음.

3) 클라우드 매니지드 DB의 “멀티 리전” 기능

  • AWS RDS / Aurora:
    • Multi-AZ 배포(동일 리전 내 AZ 2~3개)를 통한 자동 Failover,
    • Cross-Region Read Replica를 이용한 재해 복구,
    • Aurora Global Database(멀티 리전 동기화)로 전 지구적으로 단일 DB Cluster처럼 운영 가능(단, 내부적으로는 지연이 있을 수 있음).
  • Azure SQL Database / Google Cloud SQL도 비슷한 “Geo-Replication”을 지원.

4) 액티브-액티브(Active-Active) 다중 리전

  • 쓰기 노드를 여러 리전에 두고, 트랜잭션 단위로 2PC(2 Phase Commit) 또는 **합의(Consensus)**를 거쳐 동시 일관성을 지키려 하면 **레이트리시(지연)**가 매우 커짐.
  • 그래서 글로벌 스케일 서비스는 다중 리전을 “지역성 트래픽” 기준으로 나눠서, 주로 읽기/쓰기 분산을 한다음, 뒤에서 비동기 복제를 통해 eventually consistent 를 보장하는 식으로 운영.
  • 예: Google Spanner 같은 “글로벌 분산 DB”는 하드웨어 클록(PTP, GPS) 동기화 기반으로 이 문제를 해결하지만, 일반 RDBMS에는 적용하기가 쉽지 않음.

3. 정리

  • RDBMS에서의 HA는 보통 한 리전(데이터센터) 안에서 동기화를 통해 즉시 장애조치가 가능한 구조(Shared Disk Clustering, Streaming Replication 등)를 먼저 구성.
  • 멀티 리전 간에는 비동기 복제나 세미싱크를 사용하는 것이 일반적. 완전 동기화로 실시간 글로벌 트랜잭션 일관성을 보장하려면 지연이 매우 커지고 운영 난이도가 올라가기 때문.
  • Oracle Data Guard, SQL Server Always On AG, MySQL Replication, PostgreSQL Streaming Replication 등 DB별로 고가용성을 위한 모듈/솔루션이 있으며, 클라우드 환경에선 RDS, Aurora, Azure SQL, Cloud SQL 등이 이를 매니지드 형태로 제공.
  • 완전 글로벌 액티브-액티브(동시 쓰기) 구조가 필요하다면, 구글 Spanner, CockroachDB 같은 NewSQL / Geo-Distributed DB 솔루션을 검토하기도 함.
    (다만 전통 RDBMS와는 아키텍처 및 비용 구조가 다름)

결국, 전통 RDBMS HA는

  1. 단일 리전 내에서는 동기 / Shared Disk / 클러스터 구성이 일반적이고,
  2. 멀리 떨어진 리전 간에는 비동기 복제(DR용)나 클라우드 매니지드 DB의 글로벌 기능을 활용하여 “재해 복구” 수준의 HA를 구축하는 경우가 많습니다.