[Daily morning study] 멀티 리전 아키텍처 설계
#daily morning study
멀티 리전이 필요한 이유
단일 리전 아키텍처는 해당 리전에 장애가 발생하면 서비스 전체가 다운된다. 멀티 리전은 이 문제를 해결하기 위해 애플리케이션과 데이터를 지리적으로 분산된 여러 리전에 배치하는 설계 방식이다.
주요 도입 이유:
- 고가용성: 리전 장애 시 다른 리전으로 트래픽 전환
- 낮은 레이턴시: 사용자와 가까운 리전에서 응답
- 데이터 레지던시: GDPR, PIPL 등 법적 요건 충족
- 재해 복구(DR): RPO/RTO 목표 달성
핵심 패턴
Active-Passive (Warm Standby)
하나의 리전이 모든 트래픽을 처리하고, 나머지 리전은 최소 인프라만 유지하다가 장애 시 Failover한다.
[Region A - Active] [Region B - Passive]
├── 모든 트래픽 처리 ├── 최소 인프라 대기
└── DB Primary └── DB Replica (읽기 전용)
↑ 단방향 복제
- RTO: 수 분 ~ 수십 분
- 비용 부담 낮음 (Standby 리전 인프라가 최소화)
Active-Active
모든 리전이 동시에 트래픽을 처리한다. DNS 기반 로드 밸런싱으로 사용자를 가까운 리전으로 라우팅한다.
[Region A] [Region B]
├── 트래픽 처리 ├── 트래픽 처리
└── DB Master └── DB Master
↕ 양방향 복제
- RTO: 초 단위
- 데이터 충돌(Conflict) 해결 로직이 필요
- 비용 높음
Read Replica 분산
Write는 단일 Primary 리전, Read는 여러 리전의 Replica에서 처리한다. 읽기 비중이 높은 서비스에 적합하며 Eventual Consistency를 허용해야 한다.
RPO와 RTO
- RPO (Recovery Point Objective): 장애 발생 시 허용 가능한 최대 데이터 손실 시점. “마지막으로 복구 가능한 데이터가 얼마나 오래됐는가”
- RTO (Recovery Time Objective): 서비스가 정상화되기까지 허용 가능한 최대 시간
| 패턴 | RPO | RTO | 상대적 비용 |
|---|---|---|---|
| Backup & Restore | 수 시간 | 수 시간 | 낮음 |
| Pilot Light | 수십 분 | 수십 분 | 중간 |
| Warm Standby | 수 분 | 수 분 | 높음 |
| Active-Active | 거의 0 | 초 단위 | 매우 높음 |
데이터 복제 전략
동기 복제
Write 요청이 모든 리전에 저장 확인된 뒤 응답을 반환한다. Strong Consistency를 보장하지만 리전 간 네트워크 레이턴시만큼 응답이 느려진다.
대표 서비스: Cloud Spanner, RDS Multi-AZ
비동기 복제
Primary에 먼저 저장하고 이후 Replica로 전파한다. Replication Lag이 발생할 수 있어 Eventual Consistency를 전제로 한다. 레이턴시에 유리하다.
대표 서비스: RDS Read Replica, DynamoDB Global Tables
AWS 멀티 리전 핵심 서비스
| 서비스 | 역할 |
|---|---|
| Route 53 | DNS 기반 글로벌 라우팅 (레이턴시, 장애 조치, 지역 기반 정책) |
| CloudFront | CDN, 엣지 로케이션에서 정적 콘텐츠 캐싱 및 가속 |
| DynamoDB Global Tables | 완전 관리형 멀티 마스터 다중 리전 복제 |
| Aurora Global Database | 리전 간 RPO < 1초, 빠른 Failover |
| S3 Cross-Region Replication | S3 버킷 객체 자동 리전 간 복제 |
| Global Accelerator | AWS 백본을 통한 트래픽 경로 최적화 및 Failover |
Route 53 Failover 설정 예시
# Terraform으로 Active-Passive Failover 레코드 구성
resource "aws_route53_health_check" "primary" {
fqdn = "api-us.example.com"
port = 443
type = "HTTPS"
failure_threshold = 3
request_interval = 30
}
resource "aws_route53_record" "primary" {
zone_id = var.hosted_zone_id
name = "api.example.com"
type = "A"
failover_routing_policy {
type = "PRIMARY"
}
alias {
name = aws_lb.us_east.dns_name
zone_id = aws_lb.us_east.zone_id
evaluate_target_health = true
}
health_check_id = aws_route53_health_check.primary.id
set_identifier = "primary"
}
resource "aws_route53_record" "secondary" {
zone_id = var.hosted_zone_id
name = "api.example.com"
type = "A"
failover_routing_policy {
type = "SECONDARY"
}
alias {
name = aws_lb.ap_northeast.dns_name
zone_id = aws_lb.ap_northeast.zone_id
evaluate_target_health = true
}
set_identifier = "secondary"
}
Primary 헬스 체크가 3회 연속 실패하면 Route 53이 자동으로 Secondary로 트래픽을 전환한다.
설계 시 고려사항
데이터 일관성 vs 가용성
CAP 정리에 따라 네트워크 파티션 상황에서 일관성(Consistency)과 가용성(Availability) 중 하나를 선택해야 한다.
- 금융 결제: Strong Consistency 필수 → 레이턴시 증가 감수
- SNS 좋아요, 조회수: Eventual Consistency 허용 → 높은 가용성 확보
비용
멀티 리전은 인프라 비용이 최소 2배 이상 증가한다. 서비스 SLA 요건(가용성 목표)과 비용의 균형을 사전에 정의해야 한다.
운영 복잡성
- 배포: 여러 리전에 동시 배포하는 파이프라인 필요
- 모니터링: 리전별 메트릭을 통합 관제하는 대시보드
- DR 훈련: Game Day를 주기적으로 실행해 Failover 절차 검증
데이터 레지던시
GDPR(EU), LGPD(브라질), PIPL(중국) 등의 규정으로 특정 사용자 데이터는 특정 국가 내에서만 저장·처리해야 한다. 리전 선택 시 이 규정을 반드시 확인해야 한다.
