이중화·삼중화 완전 가이드 — 99.999% 가용성의 비밀

가용성 = 정상 운영 시간 / 전체 시간 × 100%

정상 상태:
  [Active 서버] ←── 모든 트래픽
  [Standby 서버]    (대기, 동기화만)

장애 발생:
  [Active 서버] ✗   장애 감지!
  [Standby 서버] ←── 트래픽 전환 (Failover)
        ↑
    새 Active로 승격

# Kubernetes에서 Active-Standby: StatefulSet + Leader Election
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-ha
spec:
  replicas: 2 # 1 Active + 1 Standby
  selector:
    matchLabels:
      app: redis
  template:
    spec:
      containers:
        - name: redis
          image: redis:7
          ports:
            - containerPort: 6379
        - name: sentinel # 장애 감지 + 자동 Failover
          image: redis:7
          command: ['redis-sentinel', '/etc/sentinel.conf']

정상 상태:
  [서버 A] ←── 트래픽 50%
  [서버 B] ←── 트래픽 50%
      ↑
  Load Balancer가 분산

장애 발생:
  [서버 A] ✗   장애!
  [서버 B] ←── 트래픽 100% (자동)

# Kubernetes Service = 자동 Active-Active
apiVersion: v1
kind: Service
metadata:
  name: my-api
spec:
  selector:
    app: my-api
  ports:
    - port: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
spec:
  replicas: 2 # 둘 다 Active!
  template:
    spec:
      containers:
        - name: api
          image: my-api:latest
          readinessProbe: # 장애 감지
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 5
            failureThreshold: 3 # 3번 실패 → 트래픽 제외

N+1: N대가 필요한데 1대 더 (최소 여유분)
  [서버1] [서버2] [서버3] [+예비1]
  → 1대 죽어도 OK

N+2: N대가 필요한데 2대 더
  [서버1] [서버2] [서버3] [+예비1] [+예비2]
  → 2대 동시에 죽어도 OK + 1대 점검 가능

2N: 전체를 2배로 (가장 비쌈)
  [서버1] [서버2] [서버3] [서버4] [서버5] [서버6]
  → 반이 죽어도 OK (미션 크리티컬)

이중화에서 네트워크 단절 시:
  [서버 A] ──✗── [서버 B]
  "B가 죽었나? 내가 Active!"  "A가 죽었나? 내가 Active!"
  → 둘 다 Active → 데이터 불일치 → 재앙!

삼중화 (3노드 클러스터):
  [노드 A]──[노드 B]──[노드 C]

네트워크 분할 시:
  [노드 A]    [노드 B]──[노드 C]
  1표 (소수)     2표 (과반수 = 쿼럼!)
  → A는 자진 사퇴
  → B,C가 계속 서비스
  → 스플릿 브레인 방지!

쿼럼 공식: 과반수 = (N/2) + 1
  3노드: 2표 필요 (1노드 장애 허용)
  5노드: 3표 필요 (2노드 장애 허용)
  7노드: 4표 필요 (3노드 장애 허용)

# etcd 3노드 클러스터 (Raft 합의 알고리즘)
# 1노드 죽어도 쿼럼(2/3) 유지 → 서비스 계속
# 2노드 죽으면 쿼럼 상실 → 읽기만 가능

# kubeadm 기본 설정
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
etcd:
  local:
    extraArgs:
      initial-cluster: >-
        etcd-0=https://10.0.0.1:2380,
        etcd-1=https://10.0.0.2:2380,
        etcd-2=https://10.0.0.3:2380

# Raft 합의 알고리즘 (의사코드)
class RaftNode:
    def __init__(self, node_id, peers):
        self.state = "follower"  # follower → candidate → leader
        self.term = 0
        self.voted_for = None
        self.log = []

    def request_vote(self):
        """리더 선출 — 과반수 투표 필요"""
        self.state = "candidate"
        self.term += 1
        votes = 1  # 자기 자신

        for peer in self.peers:
            if peer.grant_vote(self.term, self.log):
                votes += 1

        if votes > len(self.peers) // 2:  # 쿼럼!
            self.state = "leader"
            return True
        return False

    def replicate(self, entry):
        """데이터 복제 — 과반수 확인 후 커밋"""
        self.log.append(entry)
        acks = 1

        for peer in self.peers:
            if peer.append_entry(entry):
                acks += 1

        if acks > len(self.peers) // 2:  # 쿼럼!
            self.commit(entry)  # 과반수 확인 → 안전하게 커밋

[사용자]
   │
   ▼
[DNS] ← Route 53 헬스체크 (다중 리전)
   │
   ▼
[CDN] ← CloudFront (글로벌 엣지)
   │
   ▼
[L4 LB] ← NLB x2 (Active-Active, AZ 분산)
   │
   ▼
[L7 LB] ← ALB x2 (Active-Active)
   │
   ▼
[웹 서버] ← Deployment replicas: 3+ (Active-Active)
   │
   ▼
[앱 서버] ← Deployment replicas: 3+ (Active-Active)
   │
   ├──▶ [DB Primary] ──동기복제──▶ [DB Standby]  (Active-Standby)
   │    └── 비동기복제 ──▶ [DB Read Replica x2]
   │
   ├──▶ [Redis Primary] ── [Redis Replica x2]  (Sentinel)
   │
   └──▶ [MQ] ← RabbitMQ 3노드 (쿼럼 큐)

[동기 복제] (Strong Consistency)
  Primary ──COMMIT──▶ Standby
  "양쪽 다 쓸 때까지 기다림"
  장점: 데이터 손실 0
  단점: 느림 (네트워크 RTT 추가)

[비동기 복제] (Eventual Consistency)
  Primary ──COMMIT──▶ (나중에) Standby
  "일단 Primary에만 쓰고 응답"
  장점: 빠름
  단점: 장애 시 최근 데이터 유실 가능 (RPO > 0)

[반동기 복제] (Semi-Sync)
  Primary ──COMMIT──▶ Standby (1개만 확인)
  MySQL 기본 + 금융권 선호

-- PostgreSQL Streaming Replication 설정
-- Primary (postgresql.conf)
-- wal_level = replica
-- max_wal_senders = 3
-- synchronous_standby_names = 'standby1'

-- Standby 확인
SELECT client_addr, state, sync_state
FROM pg_stat_replication;
-- client_addr | state     | sync_state
-- 10.0.0.2   | streaming | sync
-- 10.0.0.3   | streaming | async

RPO (Recovery Point Objective):
  "얼마나 많은 데이터를 잃어도 되나?"
  동기 복제: RPO = 0 (데이터 무손실)
  비동기 복제: RPO = 수 초~수 분

RTO (Recovery Time Objective):
  "얼마나 빨리 복구해야 하나?"
  Active-Active: RTO ≈ 0
  Active-Standby: RTO = 수 초~수 분
  백업 복원: RTO = 수 시간

MTBF (Mean Time Between Failures):
  장애 간 평균 시간 (길수록 좋음)

MTTR (Mean Time To Repair):
  복구까지 평균 시간 (짧을수록 좋음)

가용성 = MTBF / (MTBF + MTTR)

가용성     │ 구성              │ 상대 비용
───────────┼───────────────────┼──────────
99%        │ 단일 서버         │ 1x
99.9%      │ 이중화 (1 리전)   │ 2~3x
99.99%     │ 삼중화 + 자동복구  │ 5~10x
99.999%    │ 다중 리전 Active   │ 10~50x
99.9999%   │ 다중 리전 + DR    │ 50~100x