Amazon DOP-C02: 고가용성, 복원력 및 재해 복구 — 학습 가이드

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS DevOps Engineer Professional DOP-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

AWS에서의 고가용성 및 재해 복구는 구성 요소, 가용 영역(AZ) 또는 리전 장애 상황에서 다운타임(RTO)과 데이터 손실(RPO)을 줄이는 데 중점을 둡니다. 다중 AZ 설계는 데이터 손실 없이 최소한의 서비스 영향으로 AZ 장애를 흡수하며, 다중 리전 설계는 리전 중단 및 대규모 이벤트에 대응합니다. active/active, active/passive(웜 스탠바이), 파일럿 라이트 전략 중 선택하는 것은 비즈니스의 RTO/RPO 목표, 일관성 요구 사항 및 비용에 따라 결정됩니다. 이러한 목표를 달성하려면 DNS 라우팅, 컴퓨팅 탄력성, 로드 밸런싱, 데이터베이스 복제/장애 조치, 복제/버전 관리를 통한 내구성 있는 객체 스토리지, 중앙 집중식 백업, 장애 주입을 통한 지속적인 복원력 검증 전반에 걸쳐 일관된 설계가 필요합니다.

RTO/RPO 및 지능형 라우팅을 위한 아키텍처

다중 AZ 및 다중 리전:

• 다중 AZ: 로드 밸런서 뒤 여러 AZ에 있는 최소 두 개 이상의 서브넷에 이중화된 인스턴스를 배치합니다. 동기식 복제를 지원하는 관리형 데이터베이스(RDS Multi-AZ, Aurora Multi-AZ/클러스터)를 사용합니다. 동기식 스토리지의 RPO는 일반적으로 0이며, RTO 목표는 수 분 이내(Aurora)에서 몇 분(RDS 단일 인스턴스 다중 AZ 장애 조치) 사이입니다.
• 다중 리전: 리전 격리 및 짧은 지연 시간으로 가장 낮은 RTO를 원하면 active/active를, 비용 최적화된 DR을 원하면 웜 스탠바이/파일럿 라이트를 선택합니다. 데이터 복제는 RPO를 충족해야 합니다: 비동기식 DB 복제본, Aurora Global Database(일반적으로 RPO < 1초), DynamoDB 전역 테이블(다중 리전, 다중 활성), 그리고 SLA 기반 복제를 위한 선택적 복제 시간 제어(RTC) 기능이 있는 S3 교차 리전 복제(CRR)가 있습니다.

Route 53 라우팅 정책 및 상태 확인:

• 장애 조치 라우팅: 동일한 이름에 대해 Primary와 Secondary 두 개의 레코드를 생성합니다. Primary에 상태 확인을 연결합니다(또는 ALB/NLB 별칭에 대해 “대상 상태 평가” 사용). 장애 발생 시 트래픽이 Secondary로 전환됩니다. DNS 캐시 지연을 줄이기 위해 TTL을 낮게(예: 60초) 유지하고, CloudWatch 경보로 상태 확인 상태를 모니터링합니다.
• 지연 시간 기반 라우팅: 측정된 지연 시간이 가장 낮은 리전으로 사용자를 라우팅합니다. 각 레코드에 상태 확인을 연결하여 정상적인 엔드포인트만 트래픽을 수신하도록 보장합니다. 필요에 따라 최종적/강력한 일관성을 지원하는 다중 리전 스택 및 리전 데이터 스토어와 함께 사용합니다.
• 가중치 기반 라우팅: 카나리 배포, A/B 테스트 또는 “점진적” DR 준비 상태(예: 보조 리전에 지속적으로 1% 트래픽 전송)를 지원하기 위해 트래픽을 백분율로 분할합니다. 상태 확인과 결합하여 비정상 가중치가 제외되도록 합니다. 리전 대피 중에 트래픽을 마이그레이션하기 위해 점진적으로 가중치를 변경하여 사용합니다.
• 상태 확인: HTTP(S)/TCP 엔드포인트 또는 CloudWatch 경보를 프로빙합니다. ALB/NLB 별칭의 경우, “대상 상태 평가”를 활성화하여 대상 그룹의 상태를 상속받습니다. 상태 확인 엔드포인트는 실제 준비 상태(종속성 도달 가능, 마이그레이션 적용 완료 등)를 반영하도록 설계합니다. 상태 저장 앱의 경우, 부분적으로만 정상인 인스턴스로 라우팅되는 것을 방지하기 위해 종속성 확인(데이터베이스, 캐시)을 포함합니다.

목표별 복원력 패턴:

• 낮은 RPO, 전 세계적으로 수 분 이내의 RTO: Route 53 지연 시간 기반 라우팅 및 상태 확인을 사용하는 active/active, 리전-로컬 상태 비저장 컴퓨팅, DynamoDB 전역 테이블 또는 Aurora Global Database, 중요한 객체를 위한 RTC가 포함된 S3 CRR.
• 중간 수준의 RPO(≤15분), RTO ≤4시간: 축소된 보조 리전을 사용하는 웜 스탠바이, 비동기식 DB 복제본(RDS 교차 리전 읽기 전용 복제본 또는 Aurora Global), Route 53 장애 조치 라우팅, 장애 조치 시 스케일업 및 승격을 위한 런북 또는 자동화.
• 비용 최적화된 DR: 핵심 데이터 서비스에만 파일럿 라이트 사용, 호출 시 앱 티어를 스케일 아웃하기 위한 코드형 인프라(IaC), RPO는 복제 빈도에 따라 결정, RTO는 프로비저닝 시간 및 데이터 동기화 시간에 따라 결정.

Elastic Load Balancing과 Auto Scaling

Elastic Load Balancing:

• Application Load Balancer (ALB): 계층 7(Layer 7), 호스트/경로 기반 라우팅, WebSocket/HTTP/2, 통합 WAF, 대상 그룹 쿠키를 통한 고정 세션(stickiness), 요청 기반 상태 확인. 교차 영역 로드 밸런싱과 등록 취소 지연(연결 드레이닝)을 사용하여 스케일 인 또는 배포 중에 대상을 정상적으로 드레이닝합니다. 불균일한 백엔드 준비(warm-up)에 대비하여 느린 시작(slow start) 및 이상 탐지(outlier detection)를 구성합니다.
• Network Load Balancer (NLB): 계층 4(Layer 4), 초저지연, 고정 IP/탄력적 IP, TLS 통과(pass-through)/종료(termination), 소스 IP 보존, 오래 지속되는 연결 지원. TCP/UDP 프로토콜, 높은 처리량의 워크로드 또는 클라이언트 IP 가시성이 필수적인 경우에 사용합니다. 상태 확인은 구성에 따라 계층 4/7에서 TCP/HTTP/HTTPS로 수행됩니다.
• 연결 드레이닝(등록 취소 지연): 처리 중인 요청이 완료될 수 있도록 적절한 지연 시간(예: 60–300초)을 설정합니다. 배포 및 Auto Scaling 종료 이벤트가 이 지연 시간을 준수하도록 하여 사용자 중단을 방지합니다.

Auto Scaling 그룹:

• 조정 정책:
  • 대상 추적 조정: 지표(CPUUtilization, ALB RequestCountPerTarget)를 목표 값으로 유지합니다. 웹/API 플릿에 가장 간단하고 적응성이 뛰어난 정책입니다.
  • 단계 조정: 지표가 임계값을 넘을 때 정의된 단계별로 조정합니다. 예측 가능한 패턴의 폭증하는 트래픽에 유용합니다.
  • 예약된 조정: 알려진 이벤트(세일, 출시 등)에 대비해 사전 확장하여 콜드 커패시티(cold capacity)를 방지합니다.
  • 예측 조정: 선택적으로 ML을 사용하여 일간/주간 패턴의 수요를 예측합니다.
• 수명 주기 후크: Launching:Wait 및 Terminating:Wait를 사용하면 인스턴스 준비 및 해체 과정을 제어할 수 있습니다. 후크를 사용하여 다음을 수행합니다.
  • 인스턴스가 서비스에 투입되기 전에 부트스트랩(SSM Automation, 사용자 데이터 완료, AMI 하이드레이션)합니다.
  • 근본 원인 분석을 위해 종료 전에 로그 및 아티팩트를 수집합니다.
  • 준비 신호(예: cfn-signal)를 확인해야 하는 블루/그린 또는 인플레이스(in-place) 배포를 조정합니다.
• 웜 풀: ASG에 연결된 인스턴스를 중지(Stopped) 또는 실행 중(Running) 상태로 사전 초기화하여 스케일 아웃 지연 시간을 대폭 단축합니다. 웜 풀은 긴 부트스트랩 단계(대규모 패키지 설치, 모델 다운로드)와 잘 맞습니다. 최소 웜 커패시티와 재사용 정책을 구성합니다. 수명 주기 후크 Launching:Wait와 결합하여 앱 준비 상태 확인이 통과될 때만 후크를 완료함으로써 일관된 전환 시간을 보장합니다.
• 복원력 설정: 스팟 인스턴스를 위한 용량 재조정(Capacity Rebalance), 여러 인스턴스 유형/할당 전략, 대상 그룹 상태와 연계된 상태 확인, 상태 가드레일이 포함된 안전한 롤링 업데이트를 위한 인스턴스 새로 고침을 활성화합니다.

데이터 계층 복원력, 복제 및 백업

관계형 데이터베이스:

• RDS 다중 AZ(Multi-AZ): 다른 AZ의 대기 인스턴스로 동기식 복제. 자동 장애 조치가 DNS 엔드포인트를 대기 인스턴스로 업데이트합니다. 이는 다중 AZ 대기 기능이 있는 단일 AZ DB 인스턴스의 경우 RPO ≈ 0, RTO는 일반적으로 몇 분으로 AZ 및 인스턴스 장애로부터 보호합니다. 최신 MySQL/PostgreSQL용 다중 AZ DB 클러스터는 여러 읽기 가능한 대기 인스턴스를 통해 더 빠른 장애 조치를 제공합니다.
• 읽기 전용 복제본: 읽기 확장 및 DR을 위한 비동기식 복제. DR을 위해 리전 간 읽기 전용 복제본을 사용합니다. 승격은 수동(또는 런북/서버리스 함수로 자동화)이며 RPO > 0이 발생합니다. binlog 또는 논리적 복제가 올바르게 구성되었는지, 복제 지연이 모니터링되는지 확인합니다.
• Aurora: Aurora 다중 AZ(클러스터)는 여러 AZ에 복제본이 있는 공유 스토리지를 사용하며, 장애 조치는 일반적으로 1분 미만입니다. Aurora Global Database는 일반적으로 RPO < 1초, RTO < 1분의 성능으로 보조 리전에 스토리지 기반 물리적 복제를 제공합니다. 데이터 손실 없는 마이그레이션을 위해 관리형 계획된 장애 조치를 사용하거나, 재해 발생 시 계획되지 않은 장애 조치를 사용합니다. 라이터/리더 엔드포인트가 토폴로지를 추상화하므로 애플리케이션은 백오프를 사용한 재시도를 구현해야 합니다.

객체 스토리지 및 DR:

• S3 버전 관리: 덮어쓰기/삭제로부터 보호하고 CRR을 지원하기 위해 버전 관리를 활성화합니다. 이전 버전을 더 저렴한 스토리지로 전환하고 적절한 보존 기간을 설정하도록 수명 주기 정책을 구성합니다.
• S3 리전 간 복제(CRR): 소스 및 대상 버킷에 버전 관리가 필요합니다. 복제 IAM 역할을 사용합니다. 교차 계정인 경우, 소스 역할에 s3:ObjectOwnerOverrideToBucketOwner 및 put 권한을 허용하는 대상 버킷 정책을 추가합니다. KMS로 암호화된 객체의 경우, 역할에 소스 키에 대한 kms:Decrypt 권한과 대상 키에 대한 kms:Encrypt 권한을 부여합니다. 다음을 고려하십시오.
  • 복제 시간 제어(RTC): 99.9%의 객체를 15분 이내에 복제하며 지표/경보를 제공합니다.
  • 필요에 따라 삭제 마커 및 소유권 제어 복제.
  • 기존 객체를 위한 S3 배치 복제.
  • SLA를 위한 복제 지표 및 알림.
• DynamoDB: 다중 리전/다중 라이터 환경의 저지연 및 고가용성을 위해 글로벌 테이블을 사용합니다. 또는 PITR(지정 시간 복구) 및 온디맨드 백업을 활성화하여 복구합니다.

AWS Backup을 사용한 중앙 집중식 백업:

• 백업 계획: 스케줄(CRON), 백업 기간, 수명 주기(콜드 스토리지로 전환, 보존), 다른 리전/계정으로 복사 작업을 정의합니다. 정책 기반 적용 범위를 위해 태그 또는 ARN으로 리소스를 할당합니다.
• 백업 볼트: 독립적인 KMS 암호화 키와 액세스 정책을 가진 논리적 컨테이너입니다. WORM 불변성 및 랜섬웨어 방지 태세를 위해 AWS Backup Vault Lock을 활성화합니다. 영향 반경 축소를 위해 교차 계정 볼트 복사를 사용합니다.
• 교차 계정 백업: Organizations에서 멤버 계정에 백업 정책을 적용하여 일관된 거버넌스를 유지합니다. 중앙 백업 계정에서 복사/복원을 허용하도록 볼트 액세스 정책을 구성합니다. 자동화된 복원 훈련을 정기적으로 수행하여 RTO를 측정하고 런북을 검증합니다.
• 통합: EBS, EC2, RDS/Aurora, DynamoDB, EFS, FSx 등을 보호합니다. 규제 RPO/RTO에 맞춰 스케줄 및 보존 기간을 조정하고, 필요한 경우 애플리케이션 일관성 있는 정지(quiescing)와 조율합니다(SSM 사전/사후 스크립트).

카오스 엔지니어링과 AWS Fault Injection Simulator (FIS)

카오스 실험은 고가용성(HA) 및 재해 복구(DR) 메커니즘이 설계된 대로 동작하는지 검증합니다. AWS FIS는 가드레일을 사용하여 제어된 장애를 오케스트레이션합니다:

• 실험 템플릿은 작업(예: ASG에 있는 EC2 인스턴스의 일정 비율을 중지 또는 재부팅, SSM을 통해 CPU 또는 메모리 스트레스 주입, 인스턴스에 네트워크 지연/패킷 손실 추가, EKS 파드(pod) 종료, ECS 태스크 중지, RDS/Aurora 장애 조치 트리거)과 대상(리소스 태그, ARN)을 정의합니다.
• 안전 제어: CloudWatch 경보 중지 조건, 시간 제한, 태그/필터를 통한 장애 영향 반경(blast radius) 제약 조건, 사전 확인 등을 지정합니다. 먼저 비프로덕션 환경에서 실행한 다음, 엄격한 가드레일과 비즈니스 승인을 받아 프로덕션 환경에서 실행합니다.
• 관찰 가능성: KPI(오류율, 테일 지연 시간, 대기열 기간, 복제 지연)를 측정하고, Auto Scaling 반응, 로드 밸런서 상태 수렴, Route 53 장애 조치, 데이터베이스 승격, 서킷 브레이커 동작을 포함한 자동화된 응답을 확인합니다.
• 지속적인 복원력: 실험을 파이프라인/게임데이에 통합하여 구성 드리프트(configuration drift)로 인해 복원력이 저하되는 것을 방지합니다. Parameter Store 또는 AppConfig를 사용하여 토글(toggle)을 관리하고 안전한 롤아웃을 조정합니다.

실제 문제 시나리오

Expedia Group은 글로벌 여행 검색 API를 운영합니다. 이 API는 북미 및 유럽 사용자의 낮은 지연 시간을 유지하면서, 중요한 예약 데이터에 대해 60초 미만의 RTO와 거의 0에 가까운 RPO를 제공해야 합니다. 팀은 간헐적인 리전(Region) 단위 성능 저하(brownout)와 배포로 인한 불안정성을 경험하고 있으며, 감사팀은 교차 계정 불변 백업과 문서화된 DR 훈련을 요구합니다.

단계별 접근 방식:

1. 다중 리전, 활성/활성(active/active) 스택 구축

• us-east-1 및 eu-west-1 리전에 ALB 뒤 여러 AZ에 걸쳐 무상태(stateless) API 스택을 배포합니다. 상태 확인 기능이 있는 Route 53 지연 시간 기반 라우팅과 별칭 레코드의 ‘대상 상태 평가(Evaluate Target Health)‘를 사용합니다. 이를 통해 낮은 지연 시간의 라우팅과 엔드포인트가 비정상일 경우 자동 리전 회피가 가능합니다.

2. 글로벌, 낮은 RPO의 데이터스토어

• 예약 및 세션 데이터를 Amazon Aurora Global Database(MySQL 호환)로 마이그레이션하고, us-east-1을 프라이머리(primary)로, eu-west-1을 세컨더리(secondary)로 구성합니다. 일반적인 RPO <1초 및 RTO <1분은 장애 목표를 충족합니다. 애플리케이션 구성에서 클러스터 및 리더 엔드포인트를 재시도/백오프(retry/backoff)와 함께 사용하여 장애 조치를 허용합니다.

3. 탄력적인 확장 및 정상적인 전환

• 두 리전 모두에서 최소 용량을 설정하고 ALB RequestCountPerTarget에 대한 Auto Scaling 대상 추적을 구성합니다. 주요 이벤트 중 10배의 트래픽 급증을 흡수할 수 있는 크기의 웜 풀(warm pool)과, 앱 준비 상태 확인이 통과될 때까지 등록을 지연시키는 수명 주기 후크(lifecycle hook) Launching:Wait을 추가합니다. 스케일 인 및 배포 중에 처리 중인 요청(in-flight request)을 보존하기 위해 ALB 등록 취소 지연을 120초로 활성화합니다.

4. 내구성 있는 객체 DR

• us-east-1에서 eu-west-1로의 여정 문서를 위해 S3 버전 관리(Versioning)와 RTC를 사용한 CRR(교차 리전 복제)을 활성화합니다. 소스에서는 kms:Decrypt, 대상에서는 kms:Encrypt 권한을 부여하여 두 리전 모두에서 전용 복제 IAM 역할과 KMS 키를 사용합니다. RTC 지표 및 경보를 통해 복제 SLA에 대한 신뢰도를 확보합니다.

5. 카나리 및 장애 조치를 위한 DNS 제어

• 가중치 기반 Route 53 레코드(eu-west-1로 1%의 지속적인 트래픽 흐름)를 추가하여 세컨더리 경로를 지속적으로 테스트합니다. 이를 상태 확인과 결합하면 대기(standby) 환경이 프로덕션 준비 상태임을 보장하고 위기 상황 전에 드리프트를 포착할 수 있습니다.

6. 중앙 집중식 불변 백업

• 보안팀 소유의 백업 계정에 Vault Lock 및 KMS CMK를 사용하여 AWS Backup 볼트를 생성합니다. 조직 수준 백업 정책을 정의하여 일일 백업 및 RDS, DynamoDB, EFS, EBS에 대한 교차 계정 복사를 예약합니다. Backup_Frequency 태그로 리소스를 할당합니다. 이를 통해 랜섬웨어 저항성과 직무 분리를 달성합니다.

7. 자동화된 장애 조치 오케스트레이션

• Aurora 프라이머리 장애 신호를 감지하고, 세컨더리 리전을 승격시키며 Parameter Store에 저장된 애플리케이션 엔드포인트를 업데이트하는 Lambda 함수를 호출하는 EventBridge 규칙을 구현합니다. 애플리케이션은 시작 시 엔드포인트를 로드하고 연결 오류 시 새로 고쳐 수동 단계를 최소화합니다.

8. AWS FIS를 사용한 카오스 검증

• 다음과 같은 FIS 실험 템플릿을 생성합니다: ASG 인스턴스의 10% 종료, SSM을 통해 EC2에 150ms 지연 시간 및 1% 패킷 손실 주입, Aurora 장애 조치 트리거. p95 지연 시간 및 오류율에 대한 CloudWatch 경보 중지 조건으로 가드레일을 설정합니다. 월간 게임데이를 실행하여 Route 53 장애 조치 속도, ASG 복구, ALB 상태 수렴, Aurora 승격 RTO를 검증합니다.

이러한 서비스를 사용하는 이유:

• Route 53의 지연 시간 기반 및 가중치 기반 라우팅은 최적의 사용자 지연 시간과 DR 준비를 위한 제어된 트래픽 셰이핑(traffic shaping)을 모두 제공합니다.
• 웜 풀 및 수명 주기 후크가 있는 ALB와 ASG는 콜드 스타트 패널티나 사용자 중단 없이 빠르고 정상적인(graceful) 확장을 보장합니다.
• Aurora Global Database는 최소한의 앱 변경으로 리전 간에 거의 0에 가까운 RPO와 1분 미만의 RTO를 유일하게 충족합니다.
• S3 버전 관리 및 RTC를 사용한 CRR은 중요한 아티팩트에 대해 감사 가능하고 SLA가 보장되는 복제를 제공합니다.
• 교차 계정 볼트 및 Vault Lock이 있는 AWS Backup은 규정 준수 요구 사항에 맞춰 중앙에서 관리되는 불변 백업을 생성합니다.
• AWS FIS는 안전하고 자동화된 장애 주입을 제공하여 복원력 상태를 지속적으로 증명하고 구성 드리프트가 DR 계획을 약화시키는 것을 방지합니다.

← 컨테이너 및 서버리스 운영 · 모든 도메인 · 이벤트 기반 아키텍처 및 자동화 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →