🔥 클라우드 인프라에서 HA(High Availability)를 보장하는 진짜 방법

Active-Active, DR, AZ, Docker, 그리고 진짜 고가용성의 본질까지 한방에 정리

📌 목차

Active-Active, DR, AZ, Cloud란?
Standby 전략: Hot / Warm / Cold
애플리케이션 장애에서의 HA 보장 방법
Docker만으로는 HA가 안 되는 이유
왜 인스턴스를 2개 이상 둬야 하는가?
마무리: 진짜 HA 구성은 이렇게 한다

1. ✅ Active-Active, DR, AZ, Cloud의 관계

🔹 Active-Active

두 시스템이 동시에 서비스 처리 (부하 분산 + 장애 허용)
성능과 가용성을 동시에 잡는 구조
단, 데이터 동기화/복잡도 ↑

🔹 DR (Disaster Recovery)

장애 시 백업 시스템으로 서비스 전환
Active-Passive 구조 (Hot/Warm/Cold Standby)
RTO(복구 시간), RPO(데이터 손실 허용 시간)가 핵심 지표

🔹 AZ (Availability Zone)

물리적으로 분리된 데이터센터 그룹 (한 리전에 2~3개 존재)
빠른 네트워크 + 장애 격리 → Active-Active or DR 구성에 유리

🔹 Cloud

위 모든 걸 유연하게 구성할 수 있는 기반 인프라
인프라 자동화, 리전/AZ 분산, 스토리지 복제 등 지원

2. 🔁 DR 전략: Hot / Warm / Cold Standby

항목	Hot	Warm	Cold
가용성	높음	중간	낮음
전환 속도 (RTO)	수초~분	수분	수십분~수시간
데이터 손실 (RPO)	거의 없음	몇 분	수십 분~수시간
비용	💸💸💸	💸💸	💸
운영 방식	항상 실행	일부 실행	꺼져 있음

✅ 진짜 장애 대응은 돈으로 사는 거다.
SLA 빡세면 무조건 Hot, 예산 없으면 Cold.

3. 🚨 애플리케이션 장애 시 HA를 보장하는 방법

컨테이너 수평 확장 (Multi Instance)
로드밸런서 + 헬스체크
컨테이너 상태 모니터링 + 자동 재시작
Kubernetes liveness/readiness probe
서킷 브레이커, Retry, Timeout 설정
로그 수집 + 실시간 알림

죽더라도 유저는 몰라야 한다. 그게 진짜 고가용성이다.

4. 🐳 Docker만으로는 HA가 안 되는 이유

Docker는 컨테이너를 "싸는 도구"일 뿐,
죽었을 때 살아나고, 트래픽을 분산하고, 자동 복구하는 건 Docker 밖에서 해야 한다.

왜?

Docker는 앱이 죽으면 그냥 죽음 (재시작 설정 필요)
하나의 인스턴스에 띄우면 SPOF 발생
트래픽 분산도 없음 (LB 필요)
데이터는 stateless하지 않으면 복구 불가

5. 🤔 인스턴스를 두 개 이상 두는 이유

"AZ에 배포했으니까 괜찮다"는 착각

❌ AZ는 하드웨어 수준의 고가용성
❌ 인스턴스 장애, OS 크래시, 앱 죽음은 AZ가 멀쩡해도 발생

진짜 이유는?

하나 죽으면 나머지로 트래픽 우회
ALB 같은 로드밸런서 구성 필요
클러스터링, 헬스체크, 자동 스케일링 구성 필요

6. 🏗️ 최소 HA 구성도 (AWS 예시)

+----------------------------+
|      AWS ALB              |
|  (Health Check + Routing) |
+----------------------------+
        |           |
        v           v
+----------------+ +----------------+
| EC2 #1 (AZ-A)  | | EC2 #2 (AZ-B)  |
| Docker App     | | Docker App     |
+----------------+ +----------------+
        |           |
       RDS Multi-AZ (DB)
        |
     S3, Redis (External State)