Failback vs. Fail Over

Failback vs. Fail Over

Failover 와 Failback 은 고가용성과 재해 복구 전략에서 중요한 이중 절차이다. 페일오버 (Failover) 는 Active-Passive/Active-Active 구성에서 장애 감지 후 트래픽 전환을 수행하며, AWS ELB, Kubernetes Pod 재배치 등에 적용된다. 페일백 (Failback) 은 데이터 동기화 검증 후 점진적 복구를 수행하며, DB 복제본 재동기화, 클라우드 리전 복구 시나리오에서 활용된다.

설계 방식에 따라 RTO(Recovery Time Objective) 와 RPO(Recovery Point Objective) 에 큰 영향을 미친다.

2025 년 현재 AI 기반 자동 전환 알고리즘과 블록체인 검증 기술이 접목되는 추세이다.

핵심 개념

1. RTO (Recovery Time Objective, 목표 복구 시간)
   서비스 중단 시점부터 복구 완료까지 허용되는 최대 시간을 의미한다. Failover 와 Failback 프로세스 설계 시 가장 중요한 지표 중 하나이다.

2. RPO (Recovery Point Objective, 목표 복구 시점)
   데이터 손실을 허용하는 최대 기간으로, 마지막 백업 시점부터 장애 발생 시점 사이에 손실될 수 있는 데이터의 양을 시간으로 표현한다.

3. 고가용성 (High Availability, HA)
   시스템이나 서비스가 중단 없이 지속적으로 작동할 수 있는 능력을 의미한다. 일반적으로 99.9%(쓰리 나인) 부터 99.999%(파이브 나인) 까지의 가용성을 목표로 한다.

4. 재해 복구 (Disaster Recovery, DR)
   자연재해, 사이버 공격, 장비 고장 등으로 인한 시스템 중단 후 정상 운영 상태로 복구하기 위한 전략과 프로세스를 말한다.

5. 상태 확인 (Health Check)
   시스템의 현재 상태를 모니터링하여 장애를 감지하고 Failover 를 트리거하는 메커니즘이다.

6. 스플릿 브레인 (Split Brain)
   두 시스템이 모두 자신을 주 시스템으로 인식하는 상황으로, 데이터 불일치와 시스템 충돌을 초래할 수 있는 심각한 문제이다.

Failover(장애 극복)

Failover 는 주 시스템 (Primary System) 에 장애가 발생했을 때 미리 준비된 대기 시스템 (Secondary System) 이 그 역할을 이어받아 서비스를 계속 제공하는 메커니즘이다. 이는 고가용성 (High Availability) 시스템의 핵심 구성 요소로, 시스템 장애가 발생해도 서비스가 중단되지 않도록 한다.

graph LR
A[주 시스템 장애] --> B[장애 감지]
B --> C{자동 전환 가능?}
C -->|Yes| D[예비 시스템 활성화]
C -->|No| E[수동 조치]
D --> F[서비스 재개]
E --> F

Failover 작동 원리

1. 상태 모니터링: 헬스 체크를 통해 주 시스템의 상태를 지속적으로 모니터링합니다.
2. 장애 감지: 주 시스템에서 장애가 감지되면 Failover 메커니즘이 활성화됩니다.
3. 전환 프로세스 시작: 대기 시스템으로 서비스를 전환하는 프로세스가 시작됩니다.
4. 리소스 활성화: 대기 시스템에서 필요한 모든 서비스와 리소스를 활성화합니다.
5. 네트워크 라우팅 변경: VIP(Virtual IP) 주소 이전이나 DNS 레코드 업데이트를 통해 트래픽을 대기 시스템으로 리디렉션합니다.
6. 데이터 검증: 대기 시스템의 데이터 상태를 검증하고 필요 시 최종 동기화를 수행합니다.
7. 서비스 검증: 대기 시스템에서 모든 서비스가 정상적으로 작동하는지 확인합니다.
8. 알림: 관리자에게 Failover 완료 및 현재 시스템 상태를 알립니다.

Failover 상세 프로세스

1
2
3
4
5
6
7
8
9

주 시스템 (Active) ── 장애 발생 ──┐
                                 ↓
상태 모니터링 ─── 장애 감지 ─── Failover 트리거
                                 ↓
네트워크 라우팅 변경 ←── 리소스 활성화 ←── 대기 시스템 (Standby)
                  ↓
            서비스 검증
                  ↓
            알림 및 로깅

Failover 아키텍처 유형

Failover 주요 구성 요소

Failover 구현 기법

Failover 유형

페일오버 구현 (Kubernetes 예시)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

apiVersion: v1
kind: Pod
metadata:
  name: app-primary
  labels:
    app: high-availability
spec:
  containers:
  - name: app
    image: my-app:v1
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

장단점

Failback(장애 복구)

Failback 은 장애 발생 후 Failover 에 의해 대기 시스템으로 전환된 서비스를 원래의 주 시스템으로 되돌리는 과정이다. 주 시스템이 복구되면 서비스를 다시 주 시스템으로 전환하여 원래의 아키텍처 구성으로 복원한다.

graph LR
A[주 시스템 복구] --> B[데이터 동기화]
B --> C[무결성 검증]
C --> D{검증 통과?}
D -->|Yes| E[트래픽 점진적 전환]
D -->|No| F[재동기화 실행]
E --> G[모니터링 강화]
F --> B

Failback 작동 원리

1. 복구 확인: 주 시스템이 완전히 복구되었는지 확인합니다.
2. 데이터 동기화: Failover 기간 동안 대기 시스템에서 변경된 데이터를 주 시스템으로 동기화합니다.
3. 테스트 및 검증: 주 시스템의 완전한 기능을 테스트하고 검증합니다.
4. 전환 계획 수립: 최소한의 서비스 중단으로 전환하기 위한 시간과 절차를 계획합니다.
5. 사전 알림: 필요한 경우 사용자와 이해관계자에게 예정된 전환에 대해 알립니다.
6. 서비스 전환: 계획된 시점에 서비스를 주 시스템으로 다시 전환합니다.
7. 네트워크 라우팅 복원: 네트워크 트래픽을 주 시스템으로 다시 라우팅합니다.
8. 대기 시스템 재설정: 대기 시스템을 원래 상태로 재설정하고 다음 Failover 를 위해 준비합니다.
9. 모니터링: 전환 후 주 시스템의 성능과 안정성을 모니터링합니다.

Failback 상세 프로세스

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

주 시스템 (복구됨) ──── 복구 확인 ────┐
                                     ↓
데이터 동기화 ──── 테스트 및 검증 ──── Failback 계획 수립
        ↓
    전환 실행
        ↓
네트워크 라우팅 복원
        ↓
대기 시스템 재설정
        ↓
주 시스템 모니터링 및 확인

Failback 아키텍처 고려사항

Failback 주요 구성 요소

Failback 구현 기법

Failback 유형

페일백 구현 (PostgreSQL 예시)

1
2
3
4
5
6
7
8

-- 스탠바이 서버 승격
SELECT pg_promote(true);

-- 데이터 재동기화
SELECT pg_rewind(
    target_pgdata => '/var/lib/postgresql/12/main',
    source_conninfo => 'host=primary.example.com'
);

장단점

카테고리별 비교 분석

Failover 및 Failback 프로세스 흐름도

1
2
3

[주 시스템 (정상 작동)] → 모니터링 → [장애 감지] → Failover 트리거 → [대기 시스템으로 전환]
                                                                      ↓
[주 시스템 (복구됨)] ← Failback 프로세스 ← [복구 확인] ← [대기 시스템 운영 중]

목적 및 필요성

Failover 와 Failback 메커니즘의 주요 목적은 시스템 장애 상황에서도 비즈니스 연속성을 보장하고 사용자에게 끊김 없는 서비스를 제공하는 것이다.

주요 기능 및 역할

Failover 와 Failback 은 각각 장애 발생 시와 복구 후의 시스템 전환을 담당하며, 여러 핵심 기능을 수행한다.

특징

Failover 와 Failback 은 구현 방식과 특성에 있어 몇 가지 중요한 차이점이 있다.

핵심 원칙

효과적인 Failover 와 Failback 메커니즘 설계를 위한 핵심 원칙들이다.

구조 및 아키텍처

액티브 - 패시브 Failover/Failback 아키텍처:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

[사용자] → [로드 밸런서] → [주 시스템(Active)] → [데이터베이스]
                   ↓            ↑               ↑
                   ↓            |               |
                   ↓            |           [데이터 복제]
                   ↓            |               |
                   └─→ [대기 시스템(Passive)] ──┘
                       
                       [모니터링 시스템]
                          ↑       ↑
                          |       |
                          |       |
                       [주 시스템] [대기 시스템]

액티브 - 액티브 Failover/Failback 아키텍처:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

                [사용자]
                   ↓
              [로드 밸런서]
               ↙        ↘
    [시스템 A(Active)] ⟷ [시스템 B(Active)]
              ↓        ↓
     [데이터베이스 A] ⟷ [데이터베이스 B]
              ↑        ↑
              └────────┘
               데이터 복제

실무 적용 예시

활용 사례

데이터베이스 고가용성 시나리오

시나리오 설명: 금융 서비스 회사는 고객 거래 데이터를 처리하는 핵심 데이터베이스 시스템을 운영하고 있다. 이 시스템은 99.999%(5 나인) 가용성을 요구하며, 장애 발생 시 최대 허용 가능한 다운타임은 연간 5.26 분에 불과하다.

Failover 구현: 이 회사는 Oracle Data Guard 를 사용하여 주 데이터베이스 (Primary) 와 대기 데이터베이스 (Standby) 를 구성했다. 두 데이터베이스는 서로 다른 데이터 센터에 위치하여 물리적 재해에도 대응할 수 있다. 동기식 복제를 통해 RPO(Recovery Point Objective) 를 0 에 가깝게 유지하고, Fast-Start Failover 기능을 활성화하여 자동 장애 감지 및 전환을 구현했다.

Failback 프로세스: 주 데이터베이스가 복구된 후, 다음과 같은 Failback 프로세스를 수행한다:

1. 대기 데이터베이스 (현재 활성) 의 변경 사항을 복구된 주 데이터베이스에 동기화
2. 동기화 완료 후 데이터 일관성 검증
3. 낮은 트래픽 시간대 (새벽 2 시) 에 전환 윈도우 설정
4. 새로운 트랜잭션을 일시적으로 중지 (약 30 초)
5. 주 데이터베이스로 역할 전환
6. 애플리케이션 연결 재설정
7. 모니터링 강화 및 성능 검증

다이어그램:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

[클라이언트 애플리케이션] → [데이터베이스 리스너]
               ↓
           [로드 밸런서]
           ↙         ↘
[주 DB(Primary)] ⟷ [대기 DB(Standby)]
       ↑                ↓
       |                |
       |    [Observer]  |
       |        ↓       |
       |  [장애 감지]    |
       |        ↓       |
       |  [자동 Failover]|
       |        ↓       |
       |  [Failback 과정]|
       └────────←───────┘

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항 및 주의할 점

주제와 관련하여 추가로 학습해야 할 내용

용어 정리

참고 및 출처

• AWS Fault Injection Service
• Kubernetes Self-Healing Docs
• PostgreSQL HA 공식 문서
• AWS DR FAQ
• Azure Site Recovery 개요
• Google Cloud - Failover & Failback 개념
• Netflix Tech Blog – Chaos Engineering
• Terraform Infrastructure as Code
• AWS 고가용성 패턴
• Microsoft Azure 재해 복구 솔루션
• Oracle Data Guard 개념 및 관리
• VMware 고가용성 솔루션
• Redhat 클러스터링 및 고가용성 가이드
• HAProxy 문서
• PostgreSQL 고가용성 및 부하 분산
• Kubernetes 고가용성 구성
• Netflix 장애 내성 아키텍처 블로그
• Gartner IT 용어사전 - 장애 복구
• IBM 시스템 가용성 개념
• Cloudflare 장애 감지 및 대응 시스템