Failover & Failback

🖥️ Failover & Failback 정리

1. Failover (장애 조치)

✅ 정의

• 서비스 운영 중 장애가 발생했을 때, 대기 중이던 서버나 시스템으로 업무를 자동 전환하는 과정.
• 목표: 서비스 중단 최소화 (고가용성, HA)

✅ 동작 방식

1. 감지 (Detection)
   모니터링 시스템(Heartbeat, Health check 등)이 Primary 서버의 장애를 감지
2. 전환 (Switching)
   Standby 서버(Secondary)가 Primary 역할을 이어받음
3. 서비스 유지 (Continuity)
   클라이언트 입장에서는 큰 중단 없이 서비스가 유지됨

✅ 종류

• Cold Standby: Standby 서버는 꺼져 있다가 장애 시 부팅 → 전환 속도 느림
• Warm Standby: Standby 서버는 켜져 있지만 동기화 주기는 느림 → 데이터 손실 가능성 있음
• Hot Standby: Primary와 거의 실시간 동기화 → 전환 속도 빠름, 고비용

✅ 예시

• DB 이중화 (Oracle RAC, PostgreSQL Replication, MySQL Replication)
  Master 장애 → Slave가 Master로 승격
• 웹 서버 로드밸런싱 (NGINX, AWS ALB, GCP LB)
  특정 서버 장애 시 트래픽을 다른 서버로 자동 분산

2. Failback (복구 후 원복)

✅ 정의

• 장애로 Failover 되었던 시스템이 정상 복구된 후, 다시 원래 Primary 서버로 역할을 돌려주는 과정.

✅ 동작 방식

1. 장애 서버 복구 및 동기화
2. 서비스 안정성 확인
3. 운영 정책에 따라 자동/수동으로 원래 Primary로 역할 반환

✅ 자동 vs 수동

• 자동 Failback: 복구된 Primary로 서비스가 자동 이동 → 편리하지만 서비스 흔들림 가능
• 수동 Failback: 관리자가 안정성을 확인 후 직접 원복 → 서비스 안정성↑, 운영 개입 필요

✅ 예시

• DB Master가 장애로 Slave로 넘어갔다가, Master 복구 후 다시 Master로 역할 복귀
• 방화벽 이중화(Active-Standby)에서 Primary 장비 복구 후 다시 트래픽을 Primary로 돌림

3. Failover / Failback 비교표

구분	Failover(장애조치)	Failback(복구 후 원복)
목적	서비스 연속성 유지	운영 환경 원상 복구
발생 시점	Primary 장애 발생	Primary 복구 후
동작 방식	Secondary가 역할 승계	Primary로 역할 복귀
자동화 여부	대부분 자동화	자동/수동 모두 가능

 

실제 활용 사례

• 금융 시스템: 은행 전산망은 이중화 + 실시간 Hot Standby 필수
• 클라우드 서비스: AWS RDS Multi-AZ, GCP Cloud SQL High Availability
• 네트워크 장비: Cisco ASA, Palo Alto 방화벽 이중화 (Active-Standby)