AWS DOP-C02 시험에서 "고가용성·복원력 설계"와 "확장성 솔루션 구현", "자동 복구·재해 복구" 세 도메인은 전체 문제의 약 35%를 차지합니다. 단순 암기보다는 아키텍처적 판단력을 묻는 문제가 많으므로, 각 서비스의 동작 원리와 적용 시나리오를 정확히 이해해야 합니다.
고가용성(HA) 설계 핵심 패턴
ALB 심층 헬스 체크 — SPOF 자동 격리
ALB의 기본 헬스 체크는 TCP 포트 오픈 여부만 확인합니다. 인스턴스 자체는 살아있어도 그 인스턴스가 의존하는 데이터베이스나 외부 API에 장애가 생기면 ALB는 해당 인스턴스를 정상으로 판단하고 트래픽을 계속 보냅니다. 결과적으로 사용자는 503이나 500 오류를 받습니다.
해결책은 HTTP 헬스 체크 경로를 같은 전용 엔드포인트로 지정하고, 그 엔드포인트 내부에서 DB 연결 및 외부 서비스 상태를 직접 확인하는 것입니다.
ALB가 503을 받으면 해당 인스턴스를 타겟 그룹에서 자동으로 제거합니다. 기존 ALB 인프라 변경 없이 애플리케이션 코드 수정만으로 구현 가능하므로, "기존 인프라 변경 최소화" 조건의 시험 문제에서 정답이 됩니다.
Route 53 Failover는 DNS 수준의 도구로 개별 인스턴스 단위 세밀한 제어가 어렵습니다. CloudWatch Alarm + Auto Scaling은 비정상 인스턴스를 교체하는 방식이라 즉각적인 트래픽 차단보다 시간이 걸립니다.
Aurora Global Database — 글로벌 읽기 + 리전별 데이터 주권
Aurora Global Database는 하나의 기본 리전(읽기-쓰기)과 최대 5개의 보조 리전(읽기 전용)으로 구성됩니다. 전용 복제 인프라를 사용하여 기본 리전에서 보조 리전으로의 복제 지연이 일반적으로 1초 미만입니다.
| 구분 | Aurora Global Database | DynamoDB Global Tables | |------|------------------------|------------------------| | 데이터 모델 | 관계형(MySQL/PostgreSQL) | NoSQL(키-값/문서) | | 쓰기 리전 | 기본 1개 리전만 | 모든 리전에서 쓰기 가능 | | 복제 방식 | 전용 물리 복제 레이어 | DynamoDB Streams 기반 | | 재해 복구 | 보조 리전 승격 1분 이내 | 자동 액티브-액티브 전환 |
Write Forwarding 기능은 보조 리전 인스턴스에 쓰기를 시도하면 자동으로 기본 리전으로 전달하는 기능입니다. 편리해 보이지만 데이터는 실제로 기본 리전에 저장되므로 리전별 데이터 주권 규정이 있는 환경에서는 사용하면 안 됩니다.
DynamoDB Global Tables — 멀티 리전 액티브-액티브
글로벌 서비스에서 모든 리전이 읽기와 쓰기를 동시에 처리해야 한다면 DynamoDB Global Tables를 선택합니다.
핵심 특성: 모든 리전의 복제본에서 읽기와 쓰기 모두 처리 가능 DynamoDB Streams 기반 비동기 복제, 일반적으로 1초 미만 전파 동시 쓰기 충돌은 Last Writer Wins(LWW) 방식으로 자동 해결 커스텀 복제 파이프라인 불필요
Aurora Global Database와의 핵심 차이를 시험에서 자주 묻습니다. "모든 리전에서 쓰기"라는 키워드가 있으면 DynamoDB Global Tables, "관계형 데이터베이스 구조 유지"라는 키워드가 있으면 Aurora Global Database를 선택합니다.
Route 53 Latency 라우팅 + Health Check
지연 시간 최적화와 자동 장애 조치를 동시에 구현하려면 Route 53 Failover 레코드 타입이 아닌 Latency 라우팅 정책에 Health Check를 연결해야 합니다.
Latency 라우팅: 사용자를 응답이 가장 빠른 리전으로 라우팅 Health Check 연결: 헬스 체크 실패 리전은 DNS 응답에서 자동 제외
Failover 레코드 타입은 Primary/Secondary 이진 구조라 정상 운영 시 여러 리전으로 분산이 불가능합니다. Geolocation은 사용자 위치 기반으로 규정 준수나 콘텐츠 현지화 목적에 맞고, 성능 최적화 목적에는 Latency가 적합합니다.
ARC Zonal Shift — AZ 즉각 격리
특정 AZ에서 인프라 장애가 발생했을 때 Auto Scaling이 인스턴스를 교체하는 동안에도 장애 AZ로 트래픽이 계속 들어올 수 있습니다. AWS Application Recovery Controller의 Zonal Shift는 단일 API 호출로 특정 AZ로의 ALB/NLB 트래픽을 즉시 다른 AZ로 이동시킵니다.
DNS TTL 지연 없이 즉각적 트래픽 차단 ALB, NLB와 통합 동작 CloudWatch 경보 기반 자동 트리거 구성 가능 최대 72시간 활성화 가능
Route 53 장애 조치는 DNS TTL 만료를 기다려야 하므로 즉각적인 AZ 격리가 필요한 시나리오에서는 Zonal Shift가 정답입니다.
확장성(Scalability) 솔루션 핵심 패턴
ASG Lifecycle Hook + Warm Pool — 초기화 지연 문제 해결
인스턴스 부팅 후 머신러닝 모델 다운로드, 보안 에이전트 설치, 애플리케이션 초기화 등에 수 분이 소요되는 경우 초기화가 완료되기 전에 로드 밸런서에 등록되면 사용자 요청이 실패합니다.
Lifecycle Hook의 동작 원리:
기본 대기 시간은 1시간이며 최대 48시간까지 연장 가능합니다. 초기화 실패 시 ABANDON 신호를 보내면 인스턴스가 종료됩니다.
Warm Pool은 미리 초기화된 인스턴스를 stopped 또는 running 상태로 풀에 유지합니다. 트래픽 급증 시 cold start 없이 Warm Pool의 인스턴스를 즉시 InService로 전환하여 스케일아웃 지연을 대폭 단축합니다. stopped 상태는 EC2 인스턴스 요금 없이 EBS 비용만 발생하므로 비용 효율적입니다.
Lifecycle Hook과 Warm Pool의 조합: Lifecycle Hook: 초기화 완료 전 로드 밸런서 등록 차단 Warm Pool: 미리 초기화된 인스턴스 준비로 스케일아웃 속도 향상
Auto Scaling 정책 조합 전략
| 정책 | 특성 | 적합한 시나리오 | |------|------|-----------------| | Target Tracking | 메트릭 목표값 유지, AWS 알람 자동 관리 | 일반적인 워크로드 | | Step Scaling | CloudWatch 알람 단계별 즉각 확장 | 예측 불가능한 급증 | | Scheduled Scaling | 특정 시간대 사전 확장 | 패턴이 예측 가능한 트래픽 | | Predictive Scaling | ML 기반, 7~14일 과거 데이터 필요 | 반복적 주기 패턴 |
시험에서 "예측 불가능한 트래픽 급증"과 "야간/주말 비용 절감"을 동시에 요구하는 시나리오에는 Target Tracking + Step Scaling 조합이 정답입니다. Predictive Scaling은 이벤트성 급증에 대응하기 어렵고, Scheduled는 패턴이 고정된 경우에만 효과적입니다.
Kinesis Data Streams + Lambda + DynamoDB 서버리스 파이프라인
수천 개의 IoT 센서나 고빈도 이벤트를 실시간으로 처리하는 완전 서버리스 파이프라인의 표준 설계입니다.
Kinesis Data Streams는 샤드 단위로 처리 용량을 조절합니다. 각 샤드는 초당 1MB 쓰기, 2MB 읽기를 처리합니다. Lambda의 이벤트 소스 매핑이 Kinesis 트리거로 자동 실행되며, 샤드 수에 비례하여 동시 실행됩니다.
Kinesis Data Firehose와의 차이: Kinesis Data Streams: 실시간 처리, 커스텀 소비자 앱 필요, 밀리초 지연 Kinesis Data Firehose: 완전관리형, S3/Redshift/OpenSearch로 자동 전달, 분 단위 지연 가능
키-값 저장소가 필요하고 배송 추적 대시보드처럼 실시간 조회가 필요하면 Kinesis Data Streams + Lambda + DynamoDB 조합입니다. 장기 보관과 배치 분석이 목적이면 Kinesis Data Firehose + S3 조합입니다.
ECS + Fargate — 서버리스 컨테이너
EC2 기반 컨테이너 운영의 OS 패치, 보안 업데이트, 용량 관리 부담을 없애려면 AWS Fargate를 사용합니다.
Fargate: 컨테이너 호스트 자체를 AWS가 완전 관리 ECS + Fargate: 단순한 컨테이너 워크로드, 소규모 팀에 적합 EKS + Fargate: Kubernetes 기능이 필요한 경우
ECS 서비스는 ALB 타겟 그룹과 통합되어 동적 포트 매핑을 지원하므로 ALB를 통한 트래픽 분산이 자연스럽게 구성됩니다.
프라이빗 서브넷에서 ECS Fargate를 운영할 때 ECR 이미지 풀링이 실패하면 VPC 엔드포인트 미구성 문제일 가능성이 높습니다. 필수 엔드포인트:
— ECR API 호출 — Docker 레지스트리 프로토콜 (게이트웨이) — ECR 이미지 레이어는 S3에 저장 — CloudWatch Logs (권장)
IAM 권한이 올바름에도 이미지 풀링 실패 시 VPC 엔드포인트 미구성을 먼저 의심합니다.
재해 복구(DR) 전략 비교
DR 4대 전략 비교표
| 전략 | RTO | RPO | 비용 | 특징 | |------|-----|-----|------|------| | Backup & Restore | 수 시간 | 수 시간 | 최저 | 백업에서 전체 복원 | | Pilot Light | 수십 분~1시간 | 수 분~수 초 | 낮음 | 핵심 서비스만 최소 운영 | | Warm Standby | 수 분~15분 | 수 초~수 분 | 중간 | 축소 규모 스택 상시 운영 | | Multi-Site Active-Active | 수 초 이하 | 거의 0 | 최고 | 모든 리전 동시 운영 |
시험에서 RTO/RPO 숫자를 보고 전략을 선택하는 문제가 자주 출제됩니다.
RTO 15분, RPO 5분: Warm Standby가 최적 (Pilot Light는 스케일업 시간 포함 시 15분 달성 불확실) RPO 1초 미만, RTO 1분 미만: Multi-Site Active-Active 또는 Aurora Global Database 필요 비용을 합리적으로 유지하면서 RTO 수십 분: Warm Standby
!재해 복구 전략 4가지
AWS Elastic Disaster Recovery (AWS DRS)
AWS DRS는 EC2 기반 워크로드의 DR을 위한 전용 서비스입니다. AMI 주기적 복사 방식과 비교하면 근본적으로 다른 접근법을 사용합니다.
동작 원리: 소스 서버에 경량 복제 에이전트 설치 블록 레벨에서 지속적으로 DR 리전의 스테이징 영역으로 복제 스테이징 영역은 저비용 EBS 스토리지 사용 (복제 비용 최소화) 실제 페일오버 시 완전한 EC2 인스턴스 기동
RPO는 수 초 단위로 유지되며 RTO는 수 분 이내입니다. 포인트인타임 복구로 특정 시점 상태로 복구도 가능합니다. 프로덕션에 영향 없이 복구 절차를 검증하는 비파괴 드릴 기능도 지원합니다.
Pilot Light와의 차이: DRS는 RPO 최소화가 목적이고, Pilot Light는 비용 절감이 목적입니다. "수 초 RPO", "지속적 복제", "페일백 지원"이 키워드라면 AWS DRS가 정답입니다.
S3 Cross-Region Replication (CRR) 교차 계정 복제