Failover (장애 조치)
1. 개요
Failover(장애 조치)란 시스템의 일부 구성 요소에 장애가 발생했을 때, 예비 시스템(Backup System)이 자동으로 그 기능을 이어받아 서비스 중단을 최소화하는 고가용성(High Availability, HA) 메커니즘을 의미한다.
Failover의 주된 목적은 단일 장애점(SPOF, Single Point of Failure)을 제거하는 것이다. SPOF란 시스템 내에서 특정 지점이 고장 났을 때 전체 시스템이 중단되는 취약 지점을 말하며, Failover는 이러한 지점에 중복성(Redundancy)을 부여함으로써 서비스 연속성을 보장하고 시스템의 신뢰성을 높인다.
2. 작동 원리 및 메커니즘
Failover는 기본적으로 '감시 → 판단 → 전환'의 프로세스로 작동한다.
- 장애 감지 (Detection): 주 시스템(Primary)과 보조 시스템(Secondary)은 하트비트(Heartbeat) 신호를 주고받는다. 하트비트는 시스템이 살아있음을 알리는 주기적인 작은 패킷이며, 특정 시간 동안 이 신호가 수신되지 않거나 헬스 체크(Health Check) 결과가 실패로 판명되면 장애로 간주한다.
- 장애 판단 (Decision): 감지된 장애가 일시적인 네트워크 지연인지, 실제 시스템 다운인지 판단한다.
- 전환 (Failover): 트래픽의 경로를 보조 시스템으로 변경하고, 보조 시스템이 주 시스템의 역할(IP 점유, 데이터 처리 등)을 수행하도록 활성화한다.
[표 1] 정상 상태 vs 장애 발생 시 트래픽 흐름 비교
| 구분 |
정상 상태 (Normal) |
장애 발생 시 (Failover) |
| 트래픽 경로 |
클라이언트 → 주 시스템 (Active) |
클라이언트 → 보조 시스템 (Standby) |
| 보조 시스템 상태 |
대기 또는 보조 처리 (Passive/Active) |
주 시스템 역할 승계 (Promoted to Active) |
| 데이터 흐름 |
주 시스템에서 처리 및 저장 |
보조 시스템에서 처리 및 저장 |
| 사용자 체감 |
정상 서비스 이용 |
일시적 지연 후 서비스 유지 |
3. Failover 구성 방식
시스템 운영 방식에 따라 크게 두 가지 모델로 나뉜다.
하나의 시스템이 모든 요청을 처리하고, 다른 하나는 대기 상태로 유지되는 방식이다.
- 특징: 보조 시스템은 평소에 유휴 상태이며, 주 시스템 장애 시에만 활성화된다.
- 장점: 구성이 단순하며, 데이터 일관성 유지가 상대적으로 쉽다.
- 단점: 보조 시스템의 자원이 낭비되며, 전환 시 약간의 시간이 소요된다.
두 대 이상의 시스템이 동시에 요청을 처리하며 부하를 분산하는 방식이다.
- 특징: 모든 시스템이 활성 상태이며, 로드 밸런서를 통해 트래픽이 분산된다.
- 장점: 자원 활용도가 높고 전체 처리 성능(Throughput)이 향상된다.
- 단점: 구성이 복잡하며, 시스템 간 데이터 동기화(Synchronization) 오버헤드가 발생한다.
[표 2] 구성 방식별 비교 요약
| 비교 항목 |
Active-Passive |
Active-Active |
| 자원 효율성 |
낮음 (대기 자원 발생) |
높음 (모든 자원 활용) |
| 전환 속도 |
상대적으로 느림 (기동 시간 필요) |
매우 빠름 (이미 구동 중) |
| 구현 난이도 |
낮음 |
높음 |
| 데이터 일관성 |
유지 용이 |
복잡한 동기화 메커니즘 필요 |
| 확장성 |
수직 확장 위주 |
수평 확장(Scale-out) 용이 |
4. 주요 구현 기술 및 도구
Failover를 실제로 구현하기 위해 다음과 같은 네트워크 및 소프트웨어 기술이 사용된다.
- 가상 IP (VIP, Virtual IP): 물리적 서버의 실제 IP와 별개로 서비스용 가상 IP를 설정하는 기술이다. 장애 발생 시 VIP를 보조 서버로 빠르게 이전(Migration)시켜 사용자가 동일한 주소로 접속하게 한다.
- 로드 밸런서 (L4/L7 Switch): 트래픽을 여러 서버로 분산하는 장치이다. 서버의 상태를 지속적으로 체크하여 장애가 발생한 서버를 제외하고 정상 서버로만 트래픽을 전달한다.
- 데이터 복제 (Replication): 상태 저장(Stateful) 시스템에서 데이터 연속성을 보장하기 위한 필수 기술이다.
- 동기 복제 (Synchronous): 주 시스템과 보조 시스템 모두에 데이터가 기록되어야 완료된다. 데이터 유실이 없으나(RPO=0), 쓰기 성능이 저하된다.
- 비동기 복제 (Asynchronous): 주 시스템에 먼저 기록 후 보조 시스템으로 전달한다. 성능은 좋으나 장애 시 일부 데이터 유실 가능성이 있다.
- 클러스터링 소프트웨어:
- Keepalived: VRRP(Virtual Router Redundancy Protocol)를 기반으로 VIP 관리 및 헬스 체크를 수행한다.
- Pacemaker: 리소스 관리자로, 서비스의 상태를 감시하고 장애 시 다른 노드로 서비스를 이동시키는 오케스트레이션 역할을 한다.
5. Failback (복구 전환)
Failback은 장애가 발생했던 주 시스템이 복구된 후, 서비스를 다시 원래의 주 시스템으로 되돌리는 과정이다.
5.1 복구 프로세스 및 주의사항
- 데이터 동기화: 장애 기간 동안 보조 시스템에서 처리된 데이터가 주 시스템에 반영되어야 한다. 동기화 없이 전환할 경우 데이터 유실(Data Loss)이 발생한다.
- 순단 현상 (Blip): VIP를 다시 이전하거나 세션을 전환하는 과정에서 아주 짧은 시간 동안 네트워크 연결이 끊기는 순단 현상이 발생할 수 있다.
- 안정성 검증: 복구된 시스템이 즉시 전체 부하를 견딜 수 있는지 확인한 후 단계적으로 트래픽을 전환해야 한다.
6. 설계 시 고려사항 및 한계
6.1 스플릿 브레인 (Split-brain) 현상
네트워크 단절로 인해 두 시스템이 서로 상대방이 죽었다고 판단하여, 둘 다 주 시스템(Active)으로 동작하려는 현상이다. 이 경우 데이터 쓰기 충돌이 발생하여 데이터베이스가 오염될 위험이 매우 크다.
[해결 방안]
- 쿼럼(Quorum) 구성: 과반수 이상의 노드가 동의해야 Active 권한을 갖도록 설정한다.
- STONITH (Shoot The Other Node In The Head): 장애가 의심되는 노드의 전원을 강제로 차단하여 확실하게 비활성화하는 하드웨어적 제어 방식을 사용한다.
- 분리된 네트워크(Heartbeat Network) 구축: 서비스망 외에 별도의 전용 하트비트 망을 구성하여 네트워크 단절 가능성을 최소화한다.
6.2 쿼럼 (Quorum) 메커니즘
스플릿 브레인을 방지하기 위해 도입된 의사결정 정족수(Quorum) 개념이다. 클러스터 내의 과반수 이상의 노드가 동의해야만 특정 노드를 Active로 승격시키는 방식으로, 홀수 개의 노드로 구성하는 것이 일반적이다.
6.3 헬스 체크 주기 설정 기준
헬스 체크 주기는 '감지 속도'와 '시스템 부하/안정성' 사이의 트레이드오프를 고려하여 설정한다.
- 짧은 주기 (예: 1초 미만): 장애 감지가 매우 빠르나, 네트워크 오버헤드가 증가하고 일시적인 지연(Jitter)에도 Failover가 발생하는 '플래핑(Flapping)' 현상이 생길 수 있다.
- 긴 주기 (예: 10초 이상): 시스템 부하는 적으나, 장애 발생 시 서비스 중단 시간이 길어져 RTO가 증가한다.
- 권장 설정: 체크 주기(Interval) × 실패 임계치(Threshold)를 통해 결정한다. (예: 2초 간격으로 체크하되, 3회 연속 실패 시에만 장애로 판단하여 오탐지 방지)
7. 가용성 측정 지표: RTO와 RPO
Failover 설계 시 목표로 하는 복구 수준을 정의하기 위해 다음 두 지표를 사용한다.
- RTO (Recovery Time Objective, 복구 목표 시간): 장애 발생 시점부터 서비스가 다시 정상화될 때까지 걸리는 최대 허용 시간이다. (예: "장애 발생 후 30초 이내에 Failover 완료")
- RPO (Recovery Point Objective, 복구 목표 시점): 장애 발생 시 어느 시점의 데이터까지 복구할 것인가에 대한 기준이다. 즉, 허용 가능한 최대 데이터 손실량이다. (예: "최대 5분 전 데이터까지 복구")
8. 실제 적용 사례 (Case Study)
사례 1: 데이터베이스 고가용성 구성 (MySQL MHA)
- 구성: Master $\rightarrow$ Slave 구조
- 프로세스: Manager 노드가 Master 장애 감지 $\rightarrow$ 가장 최신 데이터를 가진 Slave 선정 $\rightarrow$ VIP를 해당 Slave로 이전 $\rightarrow$ 서비스 재개
사례 2: 클라우드 기반 웹 서비스 (AWS ELB + Auto Scaling)
- 구성: Load Balancer $\rightarrow$ Auto Scaling Group (EC2 Instances)
- 프로세스: 특정 인스턴스 헬스 체크 실패 $\rightarrow$ ELB가 해당 인스턴스로의 트래픽 차단 $\rightarrow$ Auto Scaling이 자동으로 새 인스턴스 생성 및 교체 $\rightarrow$ 서비스 가용성 유지
사례 3: 엔터프라이즈 스토리지 (SAN/NAS Dual Controller)
- 구성: Dual Active Controller (Active-Active)
- 프로세스: 컨트롤러 A 하드웨어 장애 $\rightarrow$ 컨트롤러 B가 즉시 모든 I/O 경로 점유 $\rightarrow$ 호스트 측 멀티패싱(Multipathing) 소프트웨어가 경로 자동 전환 $\rightarrow$ 무중단 데이터 액세스 유지
# Failover (장애 조치)
## 1. 개요
**Failover(장애 조치)**란 시스템의 일부 구성 요소에 장애가 발생했을 때, 예비 시스템(Backup System)이 자동으로 그 기능을 이어받아 서비스 중단을 최소화하는 고가용성(High Availability, HA) 메커니즘을 의미한다.
Failover의 주된 목적은 **단일 장애점(SPOF, Single Point of Failure)**을 제거하는 것이다. SPOF란 시스템 내에서 특정 지점이 고장 났을 때 전체 시스템이 중단되는 취약 지점을 말하며, Failover는 이러한 지점에 중복성(Redundancy)을 부여함으로써 서비스 연속성을 보장하고 시스템의 신뢰성을 높인다.
## 2. 작동 원리 및 메커니즘
Failover는 기본적으로 '감시 → 판단 → 전환'의 프로세스로 작동한다.
1. **장애 감지 (Detection):** 주 시스템(Primary)과 보조 시스템(Secondary)은 **하트비트(Heartbeat)** 신호를 주고받는다. 하트비트는 시스템이 살아있음을 알리는 주기적인 작은 패킷이며, 특정 시간 동안 이 신호가 수신되지 않거나 **헬스 체크(Health Check)** 결과가 실패로 판명되면 장애로 간주한다.
2. **장애 판단 (Decision):** 감지된 장애가 일시적인 네트워크 지연인지, 실제 시스템 다운인지 판단한다.
3. **전환 (Failover):** 트래픽의 경로를 보조 시스템으로 변경하고, 보조 시스템이 주 시스템의 역할(IP 점유, 데이터 처리 등)을 수행하도록 활성화한다.
### [표 1] 정상 상태 vs 장애 발생 시 트래픽 흐름 비교
| 구분 | 정상 상태 (Normal) | 장애 발생 시 (Failover) |
| :--- | :--- | :--- |
| **트래픽 경로** | 클라이언트 → 주 시스템 (Active) | 클라이언트 → 보조 시스템 (Standby) |
| **보조 시스템 상태** | 대기 또는 보조 처리 (Passive/Active) | 주 시스템 역할 승계 (Promoted to Active) |
| **데이터 흐름** | 주 시스템에서 처리 및 저장 | 보조 시스템에서 처리 및 저장 |
| **사용자 체감** | 정상 서비스 이용 | 일시적 지연 후 서비스 유지 |
## 3. Failover 구성 방식
시스템 운영 방식에 따라 크게 두 가지 모델로 나뉜다.
### 3.1 Active-Passive (대기 방식)
하나의 시스템이 모든 요청을 처리하고, 다른 하나는 대기 상태로 유지되는 방식이다.
- **특징:** 보조 시스템은 평소에 유휴 상태이며, 주 시스템 장애 시에만 활성화된다.
- **장점:** 구성이 단순하며, 데이터 일관성 유지가 상대적으로 쉽다.
- **단점:** 보조 시스템의 자원이 낭비되며, 전환 시 약간의 시간이 소요된다.
### 3.2 Active-Active (분산 방식)
두 대 이상의 시스템이 동시에 요청을 처리하며 부하를 분산하는 방식이다.
- **특징:** 모든 시스템이 활성 상태이며, 로드 밸런서를 통해 트래픽이 분산된다.
- **장점:** 자원 활용도가 높고 전체 처리 성능(Throughput)이 향상된다.
- **단점:** 구성이 복잡하며, 시스템 간 데이터 동기화(Synchronization) 오버헤드가 발생한다.
### [표 2] 구성 방식별 비교 요약
| 비교 항목 | Active-Passive | Active-Active |
| :--- | :--- | :--- |
| **자원 효율성** | 낮음 (대기 자원 발생) | 높음 (모든 자원 활용) |
| **전환 속도** | 상대적으로 느림 (기동 시간 필요) | 매우 빠름 (이미 구동 중) |
| **구현 난이도** | 낮음 | 높음 |
| **데이터 일관성** | 유지 용이 | 복잡한 동기화 메커니즘 필요 |
| **확장성** | 수직 확장 위주 | 수평 확장(Scale-out) 용이 |
## 4. 주요 구현 기술 및 도구
Failover를 실제로 구현하기 위해 다음과 같은 네트워크 및 소프트웨어 기술이 사용된다.
- **가상 IP (VIP, Virtual IP):** 물리적 서버의 실제 IP와 별개로 서비스용 가상 IP를 설정하는 기술이다. 장애 발생 시 VIP를 보조 서버로 빠르게 이전(Migration)시켜 사용자가 동일한 주소로 접속하게 한다.
- **로드 밸런서 (L4/L7 Switch):** 트래픽을 여러 서버로 분산하는 장치이다. 서버의 상태를 지속적으로 체크하여 장애가 발생한 서버를 제외하고 정상 서버로만 트래픽을 전달한다.
- **데이터 복제 (Replication):** 상태 저장(Stateful) 시스템에서 데이터 연속성을 보장하기 위한 필수 기술이다.
- **동기 복제 (Synchronous):** 주 시스템과 보조 시스템 모두에 데이터가 기록되어야 완료된다. 데이터 유실이 없으나(RPO=0), 쓰기 성능이 저하된다.
- **비동기 복제 (Asynchronous):** 주 시스템에 먼저 기록 후 보조 시스템으로 전달한다. 성능은 좋으나 장애 시 일부 데이터 유실 가능성이 있다.
- **클러스터링 소프트웨어:**
- **Keepalived:** VRRP(Virtual Router Redundancy Protocol)를 기반으로 VIP 관리 및 헬스 체크를 수행한다.
- **Pacemaker:** 리소스 관리자로, 서비스의 상태를 감시하고 장애 시 다른 노드로 서비스를 이동시키는 오케스트레이션 역할을 한다.
## 5. Failback (복구 전환)
**Failback**은 장애가 발생했던 주 시스템이 복구된 후, 서비스를 다시 원래의 주 시스템으로 되돌리는 과정이다.
### 5.1 복구 프로세스 및 주의사항
1. **데이터 동기화:** 장애 기간 동안 보조 시스템에서 처리된 데이터가 주 시스템에 반영되어야 한다. 동기화 없이 전환할 경우 데이터 유실(Data Loss)이 발생한다.
2. **순단 현상 (Blip):** VIP를 다시 이전하거나 세션을 전환하는 과정에서 아주 짧은 시간 동안 네트워크 연결이 끊기는 순단 현상이 발생할 수 있다.
3. **안정성 검증:** 복구된 시스템이 즉시 전체 부하를 견딜 수 있는지 확인한 후 단계적으로 트래픽을 전환해야 한다.
## 6. 설계 시 고려사항 및 한계
### 6.1 스플릿 브레인 (Split-brain) 현상
네트워크 단절로 인해 두 시스템이 서로 상대방이 죽었다고 판단하여, **둘 다 주 시스템(Active)으로 동작**하려는 현상이다. 이 경우 데이터 쓰기 충돌이 발생하여 데이터베이스가 오염될 위험이 매우 크다.
**[해결 방안]**
- **쿼럼(Quorum) 구성:** 과반수 이상의 노드가 동의해야 Active 권한을 갖도록 설정한다.
- **STONITH (Shoot The Other Node In The Head):** 장애가 의심되는 노드의 전원을 강제로 차단하여 확실하게 비활성화하는 하드웨어적 제어 방식을 사용한다.
- **분리된 네트워크(Heartbeat Network) 구축:** 서비스망 외에 별도의 전용 하트비트 망을 구성하여 네트워크 단절 가능성을 최소화한다.
### 6.2 쿼럼 (Quorum) 메커니즘
스플릿 브레인을 방지하기 위해 도입된 **의사결정 정족수(Quorum)** 개념이다. 클러스터 내의 과반수 이상의 노드가 동의해야만 특정 노드를 Active로 승격시키는 방식으로, 홀수 개의 노드로 구성하는 것이 일반적이다.
### 6.3 헬스 체크 주기 설정 기준
헬스 체크 주기는 **'감지 속도'**와 **'시스템 부하/안정성'** 사이의 트레이드오프를 고려하여 설정한다.
- **짧은 주기 (예: 1초 미만):** 장애 감지가 매우 빠르나, 네트워크 오버헤드가 증가하고 일시적인 지연(Jitter)에도 Failover가 발생하는 '플래핑(Flapping)' 현상이 생길 수 있다.
- **긴 주기 (예: 10초 이상):** 시스템 부하는 적으나, 장애 발생 시 서비스 중단 시간이 길어져 RTO가 증가한다.
- **권장 설정:** `체크 주기(Interval) × 실패 임계치(Threshold)`를 통해 결정한다. (예: 2초 간격으로 체크하되, 3회 연속 실패 시에만 장애로 판단하여 오탐지 방지)
## 7. 가용성 측정 지표: RTO와 RPO
Failover 설계 시 목표로 하는 복구 수준을 정의하기 위해 다음 두 지표를 사용한다.
- **RTO (Recovery Time Objective, 복구 목표 시간):** 장애 발생 시점부터 서비스가 다시 정상화될 때까지 걸리는 최대 허용 시간이다. (예: "장애 발생 후 30초 이내에 Failover 완료")
- **RPO (Recovery Point Objective, 복구 목표 시점):** 장애 발생 시 어느 시점의 데이터까지 복구할 것인가에 대한 기준이다. 즉, 허용 가능한 최대 데이터 손실량이다. (예: "최대 5분 전 데이터까지 복구")
## 8. 실제 적용 사례 (Case Study)
### 사례 1: 데이터베이스 고가용성 구성 (MySQL MHA)
- **구성:** Master $\rightarrow$ Slave 구조
- **프로세스:** Manager 노드가 Master 장애 감지 $\rightarrow$ 가장 최신 데이터를 가진 Slave 선정 $\rightarrow$ VIP를 해당 Slave로 이전 $\rightarrow$ 서비스 재개
### 사례 2: 클라우드 기반 웹 서비스 (AWS ELB + Auto Scaling)
- **구성:** Load Balancer $\rightarrow$ Auto Scaling Group (EC2 Instances)
- **프로세스:** 특정 인스턴스 헬스 체크 실패 $\rightarrow$ ELB가 해당 인스턴스로의 트래픽 차단 $\rightarrow$ Auto Scaling이 자동으로 새 인스턴스 생성 및 교체 $\rightarrow$ 서비스 가용성 유지
### 사례 3: 엔터프라이즈 스토리지 (SAN/NAS Dual Controller)
- **구성:** Dual Active Controller (Active-Active)
- **프로세스:** 컨트롤러 A 하드웨어 장애 $\rightarrow$ 컨트롤러 B가 즉시 모든 I/O 경로 점유 $\rightarrow$ 호스트 측 멀티패싱(Multipathing) 소프트웨어가 경로 자동 전환 $\rightarrow$ 무중단 데이터 액세스 유지