고가용성 시스템 설계: 페일오버와 로드 밸런싱, 클러스터 운영

가용성은 장애 시간과 복구 시간의 관계로 결정된다

고가용성(High Availability, HA)은 하드웨어 장애, 소프트웨어 오류, 네트워크 단절이 발생해도 서비스가 계속 동작하도록 설계하는 접근이다. 핵심은 장애 자체를 없애는 데 있지 않다. 장애가 생겼을 때 영향 범위를 제한하고, 감지와 전환, 복구를 가능한 짧게 만드는 데 있다.

가용성 비율은 다음과 같이 계산한다.

가용성(%) = (전체 시간 - 다운타임) / 전체 시간 × 100
99.9%(Three Nines): 연간 약 8.76시간 다운타임 허용
99.99%(Four Nines): 연간 약 52.56분 다운타임 허용
99.999%(Five Nines): 연간 약 5.26분 다운타임 허용

복구 관점에서는 MTBF(Mean Time Between Failures)와 MTTR(Mean Time To Repair)을 함께 본다. MTBF는 평균 고장 간격이고, MTTR은 평균 복구 시간이다. 둘의 관계는 아래 식으로 표현할 수 있다.

가용성 = MTBF / (MTBF + MTTR)

단일 장애 지점(SPOF)을 없애려면 각 컴포넌트의 이중화, Active-Active 또는 Active-Standby 구성, 지리적 분산을 통한 재해 대비가 필요하다.

⤢✕

장애를 감지한 뒤 전환하는 페일오버

자동 페일오버는 Health Check로 장애를 감지하고, 미리 정의한 정책에 따라 대상 서버나 경로를 전환한다. DNS 기반 전환, IP Takeover, 가상 IP 이동이 여기에 해당한다.

반대로 수동 페일오버는 관리자가 전환 여부를 판단한다. 계획된 유지보수에 활용할 수 있고, Split-Brain 위험을 줄이는 데도 유리하다.

대기 환경은 준비 수준에 따라 Hot Standby, Warm Standby, Cold Standby로 나뉜다.

Hot Standby는 대기 서버를 항상 준비 상태로 두고 실시간 데이터 동기화(Synchronous Replication)를 사용한다. 전환 시간은 수 초 이내로 최소화할 수 있지만 리소스 비용이 높다.
Warm Standby는 대기 서버를 부분 가동하고 비동기 복제(Asynchronous Replication)를 사용한다. 전환 시간은 수십 초~수 분이며 비용 대비 효율적이다.
Cold Standby는 대기 서버를 가동하지 않고 백업 데이터에서 복구한다. 전환 시간은 수 시간이고 비용은 최소화된다.

데이터베이스의 Primary-Replica 구조에서는 쓰기 작업을 Primary에서만 수행한다. Replica는 읽기 부하 분산과 백업을 맡으며, 장애가 발생하면 Replica Promotion으로 Replica를 새 Primary로 승격한다.

장애 감지에는 Heartbeat 패킷 모니터링, 쿼럼(Quorum) 기반 합의, 타임아웃 임계값 설정이 쓰인다. 타임아웃은 보통 3-10초로 설정한다.

⤢✕

트래픽 분산과 세션 처리의 선택

로드 밸런싱은 성능뿐 아니라 특정 서버 장애 시 서비스가 한 노드에 묶이지 않도록 하는 장치다.

L4 로드 밸런싱은 IP 주소와 포트 번호를 기준으로 TCP/UDP 트래픽을 분산한다. 처리 속도가 빠르고 오버헤드가 낮으며, HAProxy와 F5 BIG-IP 등이 여기에 해당한다.

L7 로드 밸런싱은 HTTP 헤더, URL, 쿠키를 기준으로 요청을 분산한다. 콘텐츠 기반 라우팅과 SSL/TLS 종료(Termination)를 지원하며, Nginx, AWS ALB, Envoy 등을 사용할 수 있다.

분산 알고리즘도 워크로드 특성에 맞아야 한다.

Round Robin은 요청을 순서대로 배분한다. 서버 성능이 같을 때 적합하며, Weighted Round Robin으로 성능 차이를 반영할 수 있다.
Least Connections는 현재 연결 수가 가장 적은 서버를 선택한다. 세션 지속 시간이 고르지 않을 때 유리하지만 상태를 유지해야 한다.
IP Hash는 클라이언트 IP를 해싱해 서버를 정한다. 같은 클라이언트가 같은 서버에 접속하도록 해 세션 유지(Session Affinity)를 보장한다.
Least Response Time은 응답 시간이 가장 짧은 서버를 우선 선택한다. 실시간 성능을 반영하지만 Health Check 오버헤드가 있다.

Sticky Session은 쿠키나 IP로 서버를 고정하는 방식이다. 로드 밸런서 부하가 늘고 서버 장애 시 세션이 유실될 수 있다. 서버 간에 세션을 복제하는 Session Clustering은 메모리 사용량과 네트워크 트래픽을 늘린다. Redis, Memcached 같은 External Session Store를 사용하면 서버를 무상태(Stateless)로 유지할 수 있지만, 세션 스토어 자체의 SPOF를 주의해야 한다.

클러스터는 쿼럼으로 분할 상태를 통제한다

Active-Active Cluster에서는 모든 노드가 동시에 서비스를 제공한다. 로드 분산과 고가용성을 함께 얻고 리소스 활용률도 높지만, 데이터 일관성 관리는 복잡해진다.

Active-Passive Cluster는 Active 노드만 서비스를 제공하고 Passive 노드는 대기한다. 데이터 일관성을 보장하기 쉽지만 리소스 활용률이 낮고 전환 시간이 존재한다.

쿼럼은 클러스터가 정상 동작하기 위해 필요한 최소 노드 수다. 보통 (전체 노드 수 / 2) + 1로 계산하며, 네트워크가 분할됐을 때는 다수 파티션만 서비스를 계속 제공한다.

Split-Brain은 네트워크 단절로 클러스터가 여러 파티션으로 나뉜 뒤, 각 파티션이 Primary 역할을 시도하는 상황이다. 데이터 불일치가 발생할 수 있다. 이를 막기 위해 소수 파티션 노드를 강제로 종료하는 Fencing, STONITH(Shoot The Other Node In The Head), Witness/Tiebreaker 노드를 사용한다.

⤢✕

Linux HA 스택에서는 Pacemaker와 Corosync를 결합할 수 있다. Pacemaker는 리소스 관리와 Failover를 담당하고, Corosync는 클러스터 통신과 멤버십 관리를 맡는다. DRBD로 블록 레벨 복제를 결합할 수도 있다.

Keepalived는 VRRP(Virtual Router Redundancy Protocol)를 구현해 가상 IP Failover를 제공한다. 설정이 간편한 경량 솔루션이다. Consul은 서비스 디스커버리와 Health Check, 분산 키-값 저장소를 제공하며 다중 데이터센터를 지원한다.

네트워크 경로와 배치 영역까지 분산한다

DNS 기반 Failover는 Health Check 실패 시 DNS 레코드를 자동으로 변경한다. TTL(Time To Live) 설정으로 전환 시간을 제어하며 Route53, Cloudflare 등이 지원한다.

Anycast는 같은 IP 주소를 여러 위치에서 광고하는 방식이다. 네트워크 레벨 로드 밸런싱에 쓰이며 DDoS 방어와 레이턴시 최적화에 활용된다.

Multi-AZ(Availability Zone)는 같은 리전 안에서 물리적으로 분리된 데이터센터에 배치하는 방식이다. 저지연 동기 복제가 가능하지만 단일 리전 재해에는 취약하다. Multi-Region은 지리적으로 떨어진 리전을 사용해 재해 복구와 글로벌 서비스를 지원하지만, 비동기 복제와 지연 시간이 따른다.

감지·복구·기능 저하를 운영 설계에 포함한다

Passive Health Check는 실제 트래픽의 응답을 관찰해 장애를 감지한다. 장애가 발생한 뒤 반응하는 방식이며 오버헤드가 낮다. Active Health Check는 주기적으로 프로브를 전송해 조기에 장애를 감지하지만 네트워크 트래픽이 증가한다.

Auto-Healing은 장애 서버를 자동으로 재시작하는 방식이다. Kubernetes Liveness Probe와 AWS Auto Scaling Health Check가 활용될 수 있다.

모든 기능을 같은 수준으로 복구할 수 없을 때는 Graceful Degradation이 필요하다. 부분 장애 상황에서도 핵심 기능을 유지하고, 비필수 기능을 비활성화해 사용자 경험에 미치는 영향을 최소화한다. 장애 시나리오 테스트는 이 감지·전환·복구 경로가 실제로 동작하는지 확인하는 과정이다.