209. 시스템 신뢰성과 이중화 (Reliability, Resilience, Redundancy)

핵심 인사이트 (3줄 요약)

본질: 신뢰성(Reliability)은 시스템이 기대한 대로 동작하는 능력이고, 복원력(Resilience)은 장애 발생 후 빠르게 회복하는 능력이며, 이중화(Redundancy)는 이 두 가지를 물리적으로 지원하는 중복 구성이다.

가치: RTO(복구 목표 시간)와 RPO(복구 목표 지점)는 조직이 감수할 수 있는 다운타임과 데이터 손실을 정량화하여, 이중화 설계 비용과 리스크 허용 수준의 최적점을 결정하는 기준이다.

판단 포인트: Active-Active가 항상 최선이 아니다. 상태 동기화 복잡성과 비용이 크므로, RTO/RPO 요구사항에 맞춰 Active-Standby나 멀티-리전 Warm Standby가 더 실용적인 선택일 수 있다.

Ⅰ. 개요 및 필요성

현대 디지털 서비스는 단 몇 분의 다운타임도 수억 원의 손실을 만든다. AWS의 2017년 S3 다운타임 4시간은 1.5억 달러 손실을 유발했다. 이런 현실에서 **고가용성(High Availability, HA)**과 **내결함성(Fault Tolerance)**은 선택이 아닌 필수가 됐다.

신뢰성(Reliability)·복원력(Resilience)·이중화(Redundancy)는 서로 다른 차원의 개념이다. 신뢰성은 "정상 상태에서 기대한 대로 동작하는가", 복원력은 "장애 상황에서 얼마나 빨리 회복하는가", 이중화는 "물리적으로 중복 구성이 있는가"를 나타낸다. 세 가지가 함께 충족될 때 견고한(Robust) 시스템이 된다.

비즈니스 관점에서 이중화 설계의 핵심 결정 도구는 RTO(Recovery Time Objective: 복구 목표 시간)와 RPO(Recovery Point Objective: 복구 목표 지점)다. RTO=0(즉시 복구), RPO=0(데이터 손실 없음)을 달성하려면 엄청난 비용이 필요하며, 현실에서는 비즈니스 요구와 비용의 균형점을 찾아야 한다.

📢 섹션 요약 비유: 신뢰성은 자동차가 매번 시동이 걸리는 것, 복원력은 고장 났을 때 빨리 수리되는 것, 이중화는 여분의 자동차(또는 렌터카 예약)를 미리 준비해두는 것이다.

Ⅱ. 아키텍처 및 핵심 원리

RTO vs RPO 개념

  장애 발생
     │
     ▼
  ┌──────────────────────────────────────────────────────┐
  │                     시간 축                           │
  │                                                      │
  │  [최근 백업]──RPO──[장애 발생]──────RTO──[서비스 복구] │
  │                                                      │
  │  RPO: 백업 ~ 장애 사이의 데이터 손실 허용 범위         │
  │  RTO: 장애 ~ 복구까지의 서비스 중단 허용 시간          │
  └──────────────────────────────────────────────────────┘
  
  예: RPO=1시간 → 최대 1시간치 데이터 손실 허용
      RTO=30분  → 최대 30분간 서비스 중단 허용

이중화 전략 비교

전략	구성	RTO	RPO	비용	특징
Active-Active	두 사이트 모두 트래픽 처리	~0초	~0	매우 높음	완전 HA, 데이터 동기화 복잡
Active-Standby	대기 사이트가 준비 상태	수 분	RPO 설정값	높음	전환 시간 필요
Warm Standby	대기 사이트가 소규모로 운영	수 분~10분	최근 백업	중간	빠른 스케일업 가능
Cold Standby	대기 사이트 완전 중단	수 시간	마지막 백업	낮음	복구 느리지만 저비용
Pilot Light	핵심 컴포넌트만 최소 운영	10~30분	설정값	낮음	AWS 권장 중소기업 DR 패턴

Active-Active 아키텍처

  ┌──────────────────────────────────────────────────┐
  │               Global Load Balancer                │
  │            (AWS Route 53 / CloudFront)            │
  └────────────┬──────────────────────┬──────────────┘
               │                      │
     ┌─────────▼──────────┐  ┌────────▼────────────┐
     │   리전 A (서울)     │  │   리전 B (도쿄)      │
     │   [App Cluster]    │  │   [App Cluster]     │
     │   [DB Primary]     │  │   [DB Primary]      │
     └─────────┬──────────┘  └────────┬────────────┘
               │                      │
               └──────────┬───────────┘
                           ▼
                   [양방향 DB 동기화]
                   (DynamoDB Global Tables /
                    Aurora Global Database)

📢 섹션 요약 비유: Active-Active는 두 명의 의사가 동시에 같은 환자 차트를 업데이트하는 것과 같다. 매우 강력하지만, 두 의사의 기록이 충돌하지 않도록 하는 조율이 복잡하다.

Ⅲ. 비교 및 연결

이중화 레이어 구조

레이어	이중화 방법
애플리케이션	멀티 인스턴스, 오토스케일링
로드밸런서	Multi-AZ ALB, 글로벌 라우팅
데이터베이스	Read Replica, Multi-AZ, Aurora Global
스토리지	S3 Cross-Region Replication, EBS Snapshot
네트워크	Multi-AZ 서브넷, VPN 이중화
데이터센터	Multi-AZ (단일 리전), Multi-Region

고가용성 설계 원칙

원칙	설명
SPOF 제거	Single Point of Failure(단일 장애 지점) 없애기
무상태(Stateless) 설계	세션을 외부 저장소(Redis)에 보관하여 인스턴스 교체 용이
헬스체크 + 자동 복구	장애 인스턴스 자동 감지·교체
서킷 브레이커	종속 서비스 장애 격리, 연쇄 실패 방지
그레이스풀 디그레이데이션	일부 기능 비활성화로 핵심 기능 유지

📢 섹션 요약 비유: SPOF는 건물의 유일한 출입구와 같다. 그 문 하나가 막히면 전체가 마비된다. 여러 출구를 만들어 두어야(이중화) 하나가 막혀도 나머지로 계속 이동할 수 있다.

Ⅳ. 실무 적용 및 기술사 판단

RTO/RPO 목표와 이중화 전략 매핑:

비즈니스 요구:      권장 전략:
─────────────────────────────────────────
RTO < 1분          Active-Active
RPO = 0

RTO < 30분         Active-Active (단일 리전 Multi-AZ)
RPO < 5분          또는 Aurora Multi-AZ

RTO < 4시간        Warm Standby 또는 Pilot Light
RPO < 1시간        다른 리전에 DR 환경 유지

RTO < 24시간       Cold Standby
RPO < 24시간       백업 + 복구 프로세스

AWS 재해복구 4가지 패턴 (비용 순):

1. Backup & Restore    - 비용 최저, RTO 최장
2. Pilot Light         - 핵심 서비스만 최소 운영
3. Warm Standby        - 소규모로 운영 중인 DR 환경
4. Active-Active       - 비용 최고, RTO 최저

기술사 판단 포인트:

RTO와 RPO는 기술이 결정하는 것이 아니라 비즈니스가 결정하는 값이다. 비용을 무한정 투자할 수 없으므로 "이 서비스가 1시간 다운되면 손실이 얼마인가?"를 먼저 계산해야 한다.
Active-Active의 핵심 과제는 **데이터 충돌(Conflict Resolution)**이다. 양쪽에서 같은 데이터를 동시에 수정하면 무엇이 최종값인지 결정하는 로직이 필요하다.
이중화는 구축만으로 끝나지 않는다. 정기적인 Failover 훈련(DR Drill)을 통해 실제로 작동하는지 검증해야 한다.

📢 섹션 요약 비유: DR 훈련 없는 이중화는 소화기만 있고 사용법 훈련이 없는 것과 같다. 진짜 화재가 났을 때 패닉 상태에서 올바르게 사용하기 어렵다. 정기적인 실전 훈련이 이중화의 완성이다.

Ⅴ. 기대효과 및 결론

기대효과	설명
서비스 연속성	단일 인프라 장애에 의한 서비스 중단 방지
데이터 보호	RPO 달성으로 비즈니스 크리티컬 데이터 보호
고객 신뢰	SLA 준수로 고객 신뢰 유지
규제 준수	금융·의료 등 고가용성 규정 충족

이중화와 신뢰성 설계는 "장애가 발생하지 않도록 하는 것"이 목표가 아니다. 장애는 반드시 발생한다(Failure is inevitable). 목표는 "장애가 발생했을 때 비즈니스가 허용하는 시간과 데이터 손실 범위 내에서 복구되는 것"이다.

📢 섹션 요약 비유: 신뢰성 설계의 목표는 영원히 고장 나지 않는 자동차를 만드는 것이 아니다. 고장 났을 때 갓길에 안전하게 세우고(그레이스풀 디그레이데이션), 30분 내에 구조대가 와서(RTO), 트렁크 짐은 손상되지 않도록(RPO) 하는 것이다.

📌 관련 개념 맵

개념	연결 포인트
RTO / RPO	이중화 전략 선택의 핵심 비즈니스 기준값
Active-Active	최고 가용성, 양방향 데이터 동기화 필요
Aurora Global Database	Active-Active 멀티리전 DB의 AWS 관리형 솔루션
서킷 브레이커	연쇄 장애(Cascade Failure) 방지를 위한 복원력 패턴
Chaos Engineering	실제 Failover가 작동하는지 검증하는 도구
Error Budget (SRE)	허용 다운타임을 RTO/RPO로 연결하는 SRE 개념

👶 어린이를 위한 3줄 비유 설명

RPO는 게임에서 마지막으로 저장한 포인트와 현재의 차이야. 저장 안 하고 너무 오래 하다가 꺼지면 그 시간 동안 한 것이 날아가.

📈 관련 키워드 및 발전 흐름도

RPO (Recovery Point Objective): 허용 데이터 손실량
RTO (Recovery Time Objective): 복구 소요 시간 목표
    │
    ▼
DR 전략: Backup & Restore → Pilot Light → Warm Standby → Active-Active
    │
    ▼
Multi-Region · Multi-AZ 이중화 + Chaos Engineering 검증

RTO는 게임이 꺼진 후 다시 켜서 이어서 할 수 있게 되는 시간이야. 빠를수록 좋지.
Active-Active는 게임을 두 대 콘솔에서 동시에 하는 것처럼, 하나가 꺼져도 다른 하나로 즉시 계속할 수 있어.