🏰 멀티 리전 재해 복구

왜 멀티 리전 재해 복구가 필요할까?

2019년 8월, AWS 서울 리전에서 대규모 장애가 발생했습니다. 쿠팡, 배달의민족, 업비트 등 서울 리전에만 인프라를 구축했던 서비스들이 수 시간 동안 접속 불가 상태가 되었습니다.

이 사건 이후 많은 기업들이 멀티 리전 아키텍처를 도입하기 시작했습니다. 단일 리전에 모든 것을 배치하면, 그 리전에 장애가 발생했을 때 서비스 전체가 중단됩니다.

재해 복구(Disaster Recovery, DR)란:

• 장애가 발생해도 서비스를 계속 운영할 수 있는 전략과 인프라
• 핵심 질문: "서울 리전이 통째로 다운되면 우리 서비스는 어떻게 되나?"

DR 전략에는 4가지 수준이 있습니다 (비용 순):

1. Backup & Restore — 백업에서 복원 (가장 저렴, 복구 수 시간)
2. Pilot Light — 핵심 DB만 복제 (장애 시 컴퓨팅 구축, 복구 수십 분)
3. Warm Standby — 축소 환경 상시 가동 (장애 시 스케일 업, 복구 수 분)
4. Active-Active — 양쪽 리전 동시 운영 (즉시 전환, 가장 비쌈)

이 실습에서는 가장 실용적인 Warm Standby 전략을 구현합니다. 서울 리전(Primary)에서 장애 발생 시, 도쿄 리전(Secondary)으로 자동 전환되는 아키텍처를 직접 구축하고 테스트합니다.

이 실습을 마치면 여러분은:

• DR 전략의 4가지 유형과 RPO/RTO 개념을 이해합니다
• Route 53 Failover 라우팅으로 자동 전환을 구현할 수 있습니다
• RDS 크로스 리전 Read Replica를 설정할 수 있습니다
• 실제 장애 시뮬레이션으로 Failover를 테스트할 수 있습니다

아키텍처 개요

페일오버 흐름

비용 예측

Step 1: DR 전략 이해

본격적인 구축 전에, 4가지 DR 전략의 차이를 명확히 이해합시다. RPO와 RTO라는 두 가지 핵심 지표가 있습니다:

• RPO (Recovery Point Objective): 장애 발생 시 허용 가능한 데이터 손실량
  • RPO가 1시간이면: 최대 1시간치 데이터를 잃을 수 있음
• RTO (Recovery Time Objective): 장애 발생부터 서비스 복구까지 허용 가능한 시간
  • RTO가 30분이면: 30분 안에 서비스가 다시 정상이어야 함

Step 2: Secondary 리전 인프라 준비 (도쿄)

Warm Standby를 위해 도쿄 리전에도 VPC, 서브넷, ALB, ASG를 구축합니다. 서울 리전과 동일한 구조를 만들되, 축소된 규모로 구성합니다.

Step 3: Route 53 헬스 체크 및 페일오버 설정

Route 53의 Failover 라우팅 정책은 DR의 핵심입니다. 헬스 체크가 Primary를 모니터링하다가, 장애를 감지하면 자동으로 Secondary로 전환합니다.

동작 방식:

1. 헬스 체크가 30초마다 Primary ALB에 HTTP 요청을 보냄
2. 3회 연속 실패하면 Unhealthy 판정 (약 90초)
3. Route 53이 DNS를 Secondary ALB로 전환
4. 사용자들이 동일한 도메인으로 접속하면 도쿄로 라우팅됨

# 헬스 체크 생성
aws route53 create-health-check --caller-reference $(date +%s) \
  --health-check-config '{
    "FullyQualifiedDomainName":"primary-alb.elb.amazonaws.com",
    "Port":80,"Type":"HTTP","ResourcePath":"/health",
    "FailureThreshold":3,"RequestInterval":30
  }'

resource "aws_route53_health_check" "primary" {
  fqdn              = aws_lb.primary.dns_name
  port              = 80
  type              = "HTTP"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}
 
resource "aws_route53_record" "primary" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "app.example.com"
  type    = "A"
  set_identifier  = "primary"
  health_check_id = aws_route53_health_check.primary.id
  failover_routing_policy { type = "PRIMARY" }
  alias {
    name    = aws_lb.primary.dns_name
    zone_id = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}
 
resource "aws_route53_record" "secondary" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "app.example.com"
  type    = "A"
  set_identifier  = "secondary"
  failover_routing_policy { type = "SECONDARY" }
  alias {
    name    = aws_lb.secondary.dns_name
    zone_id = aws_lb.secondary.zone_id
    evaluate_target_health = true
  }
}

Step 4: RDS 크로스 리전 Read Replica 생성

데이터베이스는 DR에서 가장 중요한 부분입니다. 서버(EC2)는 언제든 새로 만들 수 있지만, 데이터는 한번 잃으면 복구가 불가능합니다.

크로스 리전 Read Replica는 서울의 RDS 데이터를 도쿄로 실시간 복제합니다. 복제는 비동기(Async)로 이루어지며, 보통 수 초 이내의 지연(Replication Lag)이 있습니다.

장애 발생 시 도쿄의 Replica를 독립 인스턴스로 승격(Promote)하면, 읽기/쓰기 모두 가능한 새로운 Primary가 됩니다.

aws rds create-db-instance-read-replica \
  --db-instance-identifier lab-db-replica-tokyo \
  --source-db-instance-identifier arn:aws:rds:ap-northeast-2:ACCOUNT:db:lab-db-primary \
  --db-instance-class db.t3.micro --region ap-northeast-1

resource "aws_db_instance" "replica" {
  provider            = aws.tokyo
  identifier          = "lab-db-replica-tokyo"
  replicate_source_db = aws_db_instance.primary.arn
  instance_class      = "db.t3.micro"
  skip_final_snapshot = true
}

Step 5: S3 크로스 리전 복제(CRR)

정적 파일이나 사용자 업로드 파일이 S3에 저장되어 있다면, 이것도 도쿄 리전으로 복제해야 합니다.

S3 크로스 리전 복제(CRR)는 소스 버킷에 새 객체가 업로드되면 자동으로 대상 버킷에 복제하는 기능입니다.

Step 6: 페일오버 테스트

이제 가장 핵심적인 단계 — 실제 장애를 시뮬레이션하고 Failover를 확인합니다. 이 테스트를 통해 DR 아키텍처가 실제로 동작하는지 검증합니다.

장애를 시뮬레이션하는 가장 안전한 방법은 보안 그룹에서 HTTP 트래픽을 차단하는 것입니다. 서울 ALB의 보안 그룹에서 HTTP(80) 규칙을 삭제하면, 헬스 체크가 실패하면서 Failover가 트리거됩니다.

핵심 개념 확인

직접 설명해 보기

완성 후 테스트 가이드

전체 DR 아키텍처가 구축되었다면, 다음 체크리스트로 검증하세요.

트러블슈팅

확장 아이디어

1. Active-Active 구성: 양쪽 리전에 동일 규모 인프라를 배치하고, Route 53 지연 시간 기반 라우팅으로 가까운 리전에서 서비스하기.
2. Aurora Global Database: RDS 대신 Aurora를 사용하면 크로스 리전 복제가 더 빠르고 안정적입니다. 1초 미만의 RPO를 달성할 수 있습니다.
3. 자동화된 Failover Runbook: AWS Systems Manager Automation으로 Failover 절차(RDS 승격, ASG 스케일 업 등)를 자동화해 보세요.
4. DR 모니터링 대시보드: CloudWatch Dashboard에 양쪽 리전의 상태, 복제 지연, 비용 등을 한눈에 볼 수 있는 대시보드를 만들어 보세요.
5. Chaos Engineering: AWS Fault Injection Simulator로 더 정교한 장애 시뮬레이션(AZ 장애, 네트워크 지연 등)을 해 보세요.

학습 정리

리소스 정리