단일 장애점(SPOF, Single Point of Failure)은 엔터프라이즈 시스템에서 허용되지 않는 리스크입니다. 99.999%의 가용성(SLA)을 달성하기 위해서는 연간 다운타임을 5분 15초 이내로 유지해야 하며, 이를 위해 데이터베이스 클러스터링은 선택이 아닌 필수적인 아키텍처 패턴입니다. 단순히 DB 서버를 늘리는 것이 아니라, 비즈니스 요구사항(RTO, RPO)과 인프라 비용, 데이터 정합성 간의 트레이드오프를 고려하여 Active-Active와 Active-Standby 전략 중 하나를 선택해야 합니다.
1. Active-Standby 아키텍처의 메커니즘
Active-Standby(또는 Active-Passive) 패턴은 가장 널리 사용되는 고가용성 전략입니다. 평시에는 Active 노드가 모든 읽기/쓰기 트래픽을 처리하며, Standby 노드는 Active 노드의 변경 사항을 복제(Replication)받으며 대기 상태를 유지합니다. 장애 발생 시, Failover 프로세스를 통해 Standby가 새로운 Active로 승격됩니다.
클러스터 내 노드들은 서로의 상태를 확인하기 위해 주기적으로 Heartbeat 패킷을 교환합니다. 네트워크 단절로 인해 서로가 죽었다고 판단하여 양쪽이 모두 Active로 승격되는 'Split-brain' 현상을 방지하기 위해 Quorum 메커니즘이나 Fencing Device(STONITH)가 필수적으로 구현되어야 합니다.
VIP(Virtual IP) 기반의 Failover
애플리케이션은 물리적 IP가 아닌 VIP를 바라보게 설정하며, Keepalived와 같은 데몬이 VIP의 소유권을 관리합니다. Active 노드 장애 시 VIP는 즉시 Standby 노드로 플로팅(Floating)됩니다.
# /etc/keepalived/keepalived.conf 예시
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass SecretPassword
}
virtual_ipaddress {
192.168.1.100 # 애플리케이션이 접속하는 VIP
}
track_script {
check_mysql_health
}
}
이 구성의 핵심은 복제 방식입니다. 동기식(Synchronous) 복제는 데이터 정합성을 보장하지만 쓰기 성능(Latency)에 페널티를 주며, 비동기식(Asynchronous) 복제는 성능은 우수하나 Failover 시 데이터 유실 가능성(RPO > 0)이 존재합니다.
2. Active-Active 아키텍처와 분산의 복잡성
Active-Active 구성은 두 개 이상의 노드가 동시에 읽기/쓰기 트래픽을 처리하는 구조입니다. 이는 이론적으로 리소스 활용률을 극대화하고 쓰기 분산을 가능하게 하지만, 실제 구현 난이도는 기하급수적으로 상승합니다.
노드를 2배로 늘린다고 해서 쓰기 성능이 2배가 되지 않습니다. Active-Active 환경에서는 모든 변경 사항이 양방향으로 동기화되어야 하므로, 네트워크 오버헤드와 잠금(Locking) 경합으로 인해 오히려 단일 노드보다 쓰기 성능이 떨어질 수 있습니다.
데이터 충돌(Conflict) 해결 전략
서로 다른 노드에서 동일한 Primary Key에 대한 업데이트가 동시에 발생할 경우 충돌이 일어납니다. 이를 해결하기 위해 다음과 같은 전략이 사용됩니다.
- Last Write Wins (LWW): 타임스탬프가 가장 최신인 데이터를 채택합니다. 시계 동기화(NTP) 이슈에 취약합니다.
- Conflict-free Replicated Data Types (CRDTs): 데이터 구조 자체를 병합 가능하게 설계합니다.
- 애플리케이션 샤딩: 특정 사용자 ID 대역은 특정 노드에만 쓰도록 강제하여 충돌을 원천 차단합니다.
-- Active-Active 환경에서의 Auto Increment 충돌 방지 설정 (MySQL 예시)
-- Node A 설정
SET GLOBAL auto_increment_increment = 2;
SET GLOBAL auto_increment_offset = 1; -- 1, 3, 5, 7... 생성
-- Node B 설정
SET GLOBAL auto_increment_increment = 2;
SET GLOBAL auto_increment_offset = 2; -- 2, 4, 6, 8... 생성
3. 전략 비교 및 의사결정 매트릭스
두 아키텍처의 선택은 기술적 우위가 아닌 비즈니스 요구사항에 따라 결정되어야 합니다. 아래 표는 주요 지표에 따른 비교 분석입니다.
| 비교 항목 | Active-Standby | Active-Active |
|---|---|---|
| 구축 난이도 | 낮음 (표준화된 패턴) | 매우 높음 (충돌 처리 필요) |
| 데이터 정합성 | 강한 정합성 (Strong Consistency) 용이 | 최종 일관성 (Eventual Consistency) |
| 자원 효율성 | 낮음 (Standby 자원 유휴 상태) | 높음 (모든 자원 활용) |
| 쓰기 확장성 | 단일 노드 한계 (수직 확장 필요) | 제한적 확장 (동기화 비용 발생) |
| 장애 복구 시간 (RTO) | 수 초 ~ 수 분 (승격 시간 필요) | 즉시 (거의 0에 수렴) |
아키텍처 선정 기준 가이드
Active-Standby를 선택해야 하는 경우:
- 엄격한 데이터 정합성이 요구되는 금융 트랜잭션 시스템.
- 운영 복잡도를 낮추고 유지보수 비용을 최소화해야 하는 경우.
- 읽기 트래픽이 많고 쓰기 트래픽은 단일 노드로 감당 가능한 경우 (Read Replica 활용).
Active-Active를 선택해야 하는 경우:
- 지리적으로 분산된 사용자가 있어 각 리전(Region)에서의 낮은 지연 시간이 필수적인 경우.
- 다운타임 허용치가 0에 가까워, 노드 장애 시에도 즉각적인 서비스 지속이 필요한 경우.
- 애플리케이션 레벨에서 데이터 충돌을 처리할 수 있는 설계가 되어 있는 경우.
결론
데이터베이스 고가용성 전략에서 "만병통치약"은 없습니다. Active-Active 구성은 높은 가용성을 제공하지만, 데이터 충돌 해결과 복잡한 동기화 이슈라는 엔지니어링 비용을 청구합니다. 반면 Active-Standby는 리소스 낭비가 있어 보일 수 있지만, 운영의 안정성과 데이터 무결성을 보장하는 가장 현실적인 대안입니다. 현재 시스템의 병목 구간이 읽기 성능인지, 쓰기 성능인지, 혹은 지리적 지연 시간인지 정확히 프로파일링한 후 아키텍처를 결정하십시오.
Post a Comment