고가용성과 재해 복구
들어가며
시스템이 1분만 다운되어도 수십만 원의 손실이 발생할 수 있습니다. 고가용성(High Availability)은 하드웨어 장애, 소프트웨어 버그, 네트워크 문제 등의 이상 상황에서도 시스템이 지속적으로 서비스를 제공할 수 있는 능력을 말합니다. 재해 복구(Disaster Recovery)는 더 큰 규모의 재난이 발생했을 때 시스템이 서비스를 복구할 수 있는 능력을 의미합니다.
이 글에서 무엇을 배우게 되나요?
이 장을 마치면 다음을 얻게 됩니다:
- 가용성 측정: '9의 개수'의 의미와 그에 해당하는 다운타임 이해
- 장애 조치: 액티브-스탠바이, 액티브-액티브, 멀티 활성 등 고가용성 아키텍처 파악
- 재해 복구 전략: RPO와 RTO의 개념 및 설계 방법 이해
- 장애 감지: 하트비트, 프로브, 서킷 브레이커 등 장애 발견 메커니즘 이해
- 카오스 엔지니어링: 능동적으로 장애를 주입하여 시스템 복원력을 검증하는 방법 이해
| 장 | 내용 | 핵심 개념 |
|---|---|---|
| 1장 | 가용성 측정 | SLA, 9의 개수, 다운타임 |
| 2장 | 장애 조치 아키텍처 | 액티브-스탠바이, 액티브-액티브, 다중 가용 영역, 다중 지역 활성 |
| 3장 | 재해 복구 설계 | RPO, RTO, 백업 전략 |
| 4장 | 장애 감지와 복구 | 하트비트, 서킷 브레이커, 자동 스케일링 |
| 5장 | 카오스 엔지니어링 | 장애 주입, 복원력 검증 |
1. 가용성 측정: 9의 개수가 의미하는 것
가용성은 보통 '9의 개수'로 측정하며, 계산 공식은 다음과 같습니다:
가용성 = 정상 가동 시간 / 전체 시간 x 100%
예를 들어 한 달(30일 = 43,200분) 동안 43분이 다운되었다면, 가용성은 (43200 - 43) / 43200 = 약 99.9%입니다. 9가 하나 늘어날 때마다 허용 다운타임이 한 자리 수 줄어들며, 구현 난이도와 비용도 기하급수적으로 증가합니다.
| 가용성 등급 | 백분율 | 월간 허용 다운타임 | 연간 허용 다운타임 | 일반적 요구 사항 |
|---|---|---|---|---|
| 2개의 9 | 99% | 7.3시간 | 3.65일 | 내부 도구 |
| 3개의 9 | 99.9% | 43분 | 8.76시간 | 일반 비즈니스 시스템 |
| 4개의 9 | 99.99% | 4.3분 | 52.6분 | 전자상거래, SaaS |
| 5개의 9 | 99.999% | 26초 | 5.26분 | 금융, 결제 |
SLA란 무엇인가요?
SLA(Service Level Agreement, 서비스 수준 협약)는 서비스 제공자와 고객 간의 공식적인 약속입니다. 예를 들어 AWS S3는 99.99%의 가용성을 보장하며, 달성하지 못하면 비율에 따라 환불합니다. SLA는 단순한 기술 지표가 아니라 상업 계약입니다. SLA 위반은 곧 금전적 손실을 의미합니다.
3개의 9에서 4개의 9로의 간극
3개의 9(99.9%)는 월 43분의 다운타임을 허용합니다. 한 번의 배포 문제로 롤백하는 데 그 시간을 다 쓸 수 있습니다. 4개의 9(99.99%)는 월 4분의 다운타임만 허용합니다. 이를 위해서는 자동 장애 조치, 롤링 배포, 헬스 체크 등 완전한 고가용성 체계가 필요합니다.
2. 장애 조치 아키텍처
장애 조치(Failover)는 고가용성의 핵심 메커니즘입니다: 주 노드에 장애가 발생하면 자동으로 대기 노드로 전환하여 서비스를 계속 제공합니다.
액티브-스탠바이 모드
가장 일반적인 고가용성 아키텍처입니다. 주 노드가 모든 요청을 처리하고, 대기 노드는 실시간으로 데이터를 동기화하지만 요청을 처리하지 않습니다. 주 노드에 장애가 발생하면 대기 노드가 자동으로 인계받습니다.
정상 상태:
클라이언트 → 주 노드(요청 처리)
대기 노드(데이터 동기화, 대기)
장애 조치:
클라이언트 → 대기 노드(새로운 주 노드로 인계)
원래 주 노드(장애, 복구 대기)핵심 문제는 스플릿 브레인(Split Brain)입니다: 네트워크 파티션 발생 시, 주 노드와 대기 노드가 모두 상대방이 죽었다고 판단하여 동시에 서비스를 제공하면 데이터 불일치가 발생합니다. 해결책은 쿼럼(Quorum) 노드를 도입하는 것입니다. 최소 3개의 노드가 투표하여 주 노드를 결정합니다.
다중 가용 영역(Multi-AZ)
같은 리전의 여러 데이터센터(가용 영역)에 서비스를 배포합니다. 단일 데이터센터의 정전, 네트워크 단절이 전체 서비스에 영향을 주지 않습니다. 클라우드 제공자의 가용 영역 간에는 일반적으로 저지연 전용선 연결(< 2ms)이 있습니다.
다중 지역 액티브-액티브(Multi-Region Active-Active)
다른 도시, 심지어 다른 국가에 완전한 서비스 복제본을 배포하며, 각 사이트가 독립적으로 요청을 처리할 수 있습니다. 이것은 최고 수준의 고가용성 아키텍처이지만, 가장 복잡하기도 합니다. 핵심 과제는 지역 간 데이터 동기화의 지연 시간과 일관성 문제입니다.
| 아키텍처 | 가용성 수준 | 비용 | 복잡도 | 적용 시나리오 |
|---|---|---|---|---|
| 단일 서버 | 99%~99.9% | 낮음 | 낮음 | 개발/테스트, 내부 도구 |
| 액티브-스탠바이 | 99.9%~99.99% | 중간 | 중간 | 중소 규모 비즈니스 시스템 |
| 다중 가용 영역 | 99.99% | 높음 | 높음 | 전자상거래, SaaS 플랫폼 |
| 다중 지역 액티브-액티브 | 99.999% | 매우 높음 | 매우 높음 | 금융, 대형 인터넷 서비스 |
3. 재해 복구 설계: RPO와 RTO
재해 복구 설계는 두 가지 핵심 지표를 중심으로 전개됩니다:
| 지표 | 전체 명칭 | 의미 | 예시 |
|---|---|---|---|
| RPO | Recovery Point Objective | 얼마나 많은 데이터 손실을 감당할 수 있는가 | RPO=0은 어떤 데이터도 잃을 수 없음을 의미 |
| RTO | Recovery Time Objective | 얼마나 오래 다운타임을 감당할 수 있는가 | RTO=5분은 5분 이내에 복구해야 함을 의미 |
백업 전략과 RPO의 관계
| 백업 방식 | RPO | 비용 | 설명 |
|---|---|---|---|
| 일일 전체 백업 | 24시간 | 낮음 | 최대 하루치 데이터 손실 가능 |
| 실시간 증분 백업 | 분 단위 | 중간 | binlog/WAL 지속 동기화 |
| 동기 복제 | 0 | 높음 | 기록 시 반드시 복제본 확인 대기 |
모든 데이터에 RPO=0이 필요한 것은 아닙니다
사용자 프로필 사진이丢失되면 다시 업로드하면 됩니다(RPO=24시간이면 충분). 하지만 결제 기록은 단 한 건도 잃을 수 없습니다(RPO=0). 데이터의 비즈니스 가치에 따라 백업 전략을 결정해야 하며, 일괄 적용은 피해야 합니다.
4. 장애 감지와 복구
4.1 장애 감지 메커니즘
| 메커니즘 | 원리 | 감지 속도 | 적용 시나리오 |
|---|---|---|---|
| 하트비트 감지 | 정기적으로 하트비트 패킷을 보내고, 타임아웃 시 장애로 판정 | 초 단위 | 노드 생존 감지 |
| 헬스 체크 | HTTP/TCP 프로브로 서비스 상태 확인 | 초 단위 | 로드 밸런서 백엔드 감지 |
| 비즈니스 프로브 | 실제 요청을 시뮬레이션하여 비즈니스 로직 확인 | 초~분 단위 | 엔드투엔드 가용성 모니터링 |
하트비트 감지의 작동 원리: 노드 A는 일정한 간격(예: 5초)마다 모니터링 대상에게 "나 아직 살아 있어"라는 신호를 보냅니다. 연속으로 N번(예: 3번) 하트비트를 받지 못하면 노드 A에 장애가 발생한 것으로 판정합니다. 핵심 파라미터는 하트비트 간격과 타임아웃 임계값입니다. 간격이 너무 짧으면 네트워크 오버헤드가 증가하고, 너무 길면 장애 발견이 지연됩니다.
헬스 체크의 세 가지 수준:
- 활성 프로브(Liveness): 프로세스가 아직 실행 중인가? 아니면 재시작
- 준비 프로브(Readiness): 서비스가 요청을 받을 수 있는가? 아니면 로드 밸런서에서 제외
- 시작 프로브(Startup): 서비스 시작이 완료되었는가? 미완료 시 대기, 장애로 오인하지 않음
4.2 자동 복구 메커니즘
| 메커니즘 | 설명 | 대표적 도구 |
|---|---|---|
| 자동 재시작 | 프로세스 충돌 후 자동으로 다시 시작 | systemd, PM2, K8s |
| 자동 스케일링 | 부하 증가 시 자동으로 인스턴스 추가 | K8s HPA, 클라우드 Auto Scaling |
| 서킷 브레이커/저하 | 다운스트림 장애 시 빠른 실패로 연쇄 장애 방지 | Hystrix, Sentinel, Resilience4j |
| 속도 제한 | 수용 능력을 초과하는 요청은 즉시 거부 | Nginx limit_req, 게이트웨이 속도 제한 |
서킷 브레이커 패턴(Circuit Breaker) 상세:
서킷 브레이커의 영감은 전기 회로의 퓨즈에서 왔습니다. 과전류가 흐르면 자동으로 차단되어 전체 회로가 타버리는 것을 방지합니다. 마이크로서비스에서 다운스트림 서비스에 장애가 발생하면 서킷 브레이커가 '차단'되어, 요청이 타임아웃될 때까지 기다리지 않고 빠르게 실패합니다.
서킷 브레이커의 세 가지 상태:
닫힘(정상) ──→ 실패율이 임계값 초과 ──→ 열림(차단)
↑ │
│ 쿨다운 시간 대기
│ ↓
└── 탐지 요청 성공 ←── 반열림(탐지)- 닫힘 상태: 정상적으로 요청을 전달하면서 실패율을 통계냄
- 열림 상태: 모든 요청이 즉시 오류를 반환(빠른 실패), 다운스트림 호출 중단
- 반열림 상태: 쿨다운 시간이 끝나면 소수의 탐지 요청을 통과시킴. 성공하면 닫힘으로 복구, 실패하면 열림 상태 유지
저하(Fallback)는 서킷 브레이커와 함께 사용하는 전략입니다: 서킷 브레이커가 작동한 후 단순히 오류를 반환하는 것이 아니라, '대체' 결과를 반환합니다. 예를 들어 추천 서비스가 다운되면 인기 상품 목록을 반환하고, 사용자 프로필 사진 로딩에 실패하면 기본 이미지를 표시합니다.
5. 카오스 엔지니어링: 능동적으로 문제 찾기
카오스 엔지니어링의 핵심 철학은: 장애가 발생하기를 기다리는 것보다, 능동적으로 장애를 만들어내어 통제 가능한 환경에서 시스템의 복원력을 검증하는 것입니다.
| 도구 | 제안자 | 핵심 기능 |
|---|---|---|
| Chaos Monkey | Netflix | 프로덕션 환경의 인스턴스를 무작위로 종료 |
| Chaos Mesh | PingCAP | K8s 환경에서의 장애 주입 |
| Litmus | CNCF | 클라우드 네이티브 카오스 엔지니어링 프레임워크 |
| ChaosBlade | 알리바바 | 다중 시나리오 장애 주입 도구 |
카오스 엔지니어링의 실행 단계
- 안정 상태 정의: 시스템이 정상적으로 실행되는 지표를 명확히 함(예: P99 지연 < 200ms)
- 가설 수립: 특정 노드가 다운되면 시스템이 30초 이내에 자동 복구되어야 함
- 장애 주입: 통제 가능한 범위 내에서 장애를 발생시킴(먼저 테스트 환경에서, 그 다음 프로덕션에서)
- 결과 관찰: 시스템이 예상대로 복구되었는가? 연쇄 장애가 발생했는가?
- 약점 수정: 발견된 문제를 바탕으로 아키텍처와 프로세스를 개선
요약
고가용성은 하나의 기능이 아니라 아키텍처 역량입니다. 설계, 개발, 배포, 운영의 모든 단계에서 보장되어야 합니다.
이 장의 핵심 요점을 되돌아보겠습니다:
- 9의 개수: 9가 하나 늘어날 때마다 다운타임이 한 자리 수 줄어들고, 비용과 복잡도는 기하급수적으로 증가합니다
- 장애 조치: 액티브-스탠바이부터 다중 지역 액티브-액티브까지, 비즈니스 요구에 맞는 아키텍처를 선택하세요
- RPO와 RTO: 데이터의 가치와 비즈니스 허용도에 따라 백업 및 복구 전략을 설계하세요
- 자동화: 장애 감지, 자동 재시작, 서킷 브레이커/저하는 고가용성의 기반 인프라입니다
- 카오스 엔지니어링: 능동적으로 장애를 주입하여 통제 가능한 환경에서 시스템 복원력을 검증하세요
더 읽어보기
- Site Reliability Engineering - Google SRE 고전
- Chaos Monkey - Netflix 카오스 엔지니어링 도구
- Release It! - 프로덕션 환경 설계 패턴
- Chaos Mesh - K8s 카오스 엔지니어링 플랫폼