클라우드 기반 MSA 아키텍처에 적합한 DR 시나리오 설계

– 수많은 마이크로서비스, 수많은 장애에 대처하는 전략

“모든 시스템은 결국 실패한다.
문제는 **‘얼마나 빨리 복구하느냐’**이다.”
— AWS Well-Architected Framework

📌 1. 왜 MSA에서는 DR 전략이 더 복잡한가?

**마이크로서비스 아키텍처(MSA)**는 다음과 같은 특성을 지닙니다:

특성설명
서비스 분산하나의 시스템이 수십 개 이상의 독립 서비스로 나뉨
DB 분리각 서비스가 자체 데이터 저장소 보유 (Polyglot Persistence)
통신 다양성REST, gRPC, 이벤트 기반 등 다채로운 통신 모델
배포 다양성서비스별 릴리즈 주기와 방법이 다름
상태 관리Stateless or Stateful 서비스 혼재

👉 이러한 특성은 DR 전략 수립 시 고려해야 할 변수의 수가 기하급수적으로 증가한다는 것을 의미합니다.

🧭 2. DR 설계의 4가지 핵심 원칙

항목설명
RTO (Recovery Time Objective)장애 발생 후 정상 상태로 복구되기까지 걸리는 최대 시간
RPO (Recovery Point Objective)장애 발생 시점까지 얼마나 최근의 데이터를 보존할 수 있는가
서비스 단위 복구전체 복구가 아닌 서비스 단위로 복원 가능한 구조 설계
의존성 파악각 서비스의 상호 의존 관계를 명확히 분석하여 복구 순서/전략 수립

🏗️ 3. DR 시나리오 유형별 아키텍처 설계

✅ 시나리오 A: AZ 장애 (Availability Zone Failure)

예: AWS Seoul 리전 내 ap-northeast-2a 장애

  • 아키텍처 대응:
    • Kubernetes 클러스터는 Multi-AZ 노드 구성 (EKS 또는 self-managed)
    • RDS, ElastiCache 등은 Multi-AZ 배포
    • ALB는 가용 영역을 자동 라우팅
  • DR 설계 포인트:
    • Node Affinity/Pod Anti-Affinity 설정
    • Volume은 Multi-AZ 지원 스토리지 사용(EBS → EFS or FSx)

✅ 시나리오 B: 전체 리전 장애 (Region-wide Outage)

예: AWS 서울 리전 전체 불통 시 도쿄 리전으로 전환

  • 아키텍처 대응:
    • 클러스터 전체를 Cross-Region으로 이중화
    • DB는 Read Replica → Promote to Master
    • Route53을 통한 DNS 기반 Failover
  • DR 설계 요소:
    • IaC 기반의 Region 간 클러스터 이식성 확보 (Terraform, Helm Charts)
    • S3, ECR 등의 데이터 → Cross-Region Replication
    • CI/CD: dev-seoul ↔ prod-tokyo 두 환경 동시 운영

✅ 시나리오 C: 서비스 단위 장애 (서비스 A만 죽음)

특정 마이크로서비스 장애 시 전체 시스템 영향 없이 복구

  • 대응 전략:
    • Liveness/Readiness Probe 기반 자동 재시작
    • Circuit Breaker (Resilience4j, Istio), Retry 적용
    • Canary Rollback 또는 이전 버전으로 재배포
  • DR 구성:
    • Helm Release 버전 관리
    • 장애 패턴 자동 감지 + Rollback 트리거 구성

✅ 시나리오 D: DB 유실 or 복원 요구

  • 설계 포인트:
    • Point-in-Time Recovery 지원 DB (RDS, Aurora, etcd)
    • 비정기 백업 + 정기 Snapshot + 데이터 검증
  • DR 전략:
    • DB 백업은 리전 간 복제 (Cross-Region Snapshot)
    • 서비스 간 데이터 동기화 여부 검증(CDC 또는 이벤트 로그 재처리)

🧩 4. 서비스 의존성 기반 DR 매트릭스 예시

서비스DB 유형의존 서비스장애 영향도복구 우선순위
authPostgreSQL없음로그인 차단★★★★☆
orderMySQLauth, product주문 실패★★★★★
paymentRedisorder결제 오류★★★★☆
notifyKafkaorder알림 누락★★☆☆☆

👉 의존도 기반으로 RTO/RPO를 재정의하고 복구 순서를 문서화해야 함

🛠️ 5. 기술 기반 구성 예시 (AWS + EKS 기준)

구성 요소DR 전략
EKS 클러스터Terraform 기반 Region 복제 배포
S3 버킷Cross-Region Replication
RDSMulti-AZ + Cross-Region Read Replica
ECR도쿄 리전으로 컨테이너 이미지 복제
KafkaMSK MirrorMaker 사용
Route53DNS Failover Policy 적용

📑 6. DR 자동화 시 고려사항

  • ✅ Runbook → Script화 → 자동화 (Lambda / SSM / Terraform)
  • ✅ Prometheus Alert → Slack → DR 트리거 연결 가능성 검토
  • ✅ 복구 연습(Chaos Engineering): Gremlin, ChaosMesh, Litmus 사용
  • ✅ 모든 IaC 자산은 GitOps로 관리

🔐 7. 보안과 감사 관점의 DR

항목설계 원칙
IAM 권한최소 권한 + DR 수행자 Role 분리
감사 로그S3 + Athena로 복구 행위 추적
암호화 키KMS 키도 리전 간 복제 및 백업 필요
서비스 토큰실패 시 자동 만료 로직 필요 (e.g., OAuth Refresh 만료 시 재발급 처리)

✅ 8. 마무리 요약

항목전략 요약
장애 범위AZ, 리전, 서비스, DB 단위 등 다층 설계
MSA DR 핵심서비스 독립성 + 상태 격리 + 복구 자동화
기술 구성멀티리전 클러스터, Read Replica, DNS Failover
자동화 수준IaC + GitOps + Chaos 테스트 연동
테스트분기별 시뮬레이션 / 서비스별 재해 리허설 계획 포함