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

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

RTO 및 RPO 계획: 허용 오차 정량화 및 아키텍처 매핑

RTO(복구 시간 목표)와 RPO(복구 시점 목표)는 컴퓨팅 사이징부터 복제 토폴로지에 이르기까지 모든 복원력 관련 결정을 좌우합니다. 먼저 비즈니스 영향과 다운타임 비용에 따라 워크로드를 분류한 다음, 이러한 우선순위를 측정 가능한 목표로 변환합니다. 밀리초 단위의 RPO는 동기식 복제나 특수 목적의 글로벌 데이터베이스를 필요로 하는 반면, 분에서 시간 단위의 RPO는 비동기식 복제, 스냅샷 스케줄, 또는 배치 방식의 로그 전달을 허용합니다. 목표에 부합하는 AWS 서비스를 사용하십시오. 대규모 환경에서 낮은 RTO/RPO를 위한 Amazon Aurora Multi‑AZ 및 Aurora Global Database, 단일 리전 내 동기식 고가용성을 위한 RDS Multi‑AZ, 복구 및 리포팅을 위한 교차 리전 읽기 전용 복제본, 그리고 최소한의 애플리케이션 변경으로 온프레미스 서버를 거의 실시간으로 복제하는 AWS Elastic Disaster Recovery(DRS) 등이 있습니다. 흔한 함정 중 하나는 최악의 복구 상황이 아닌 평균 부하에 맞춰서만 설계하는 것입니다. 또 다른 함정은 스냅샷만으로 트랜잭션 시스템의 RPO를 충족할 수 있다고 가정하는 것입니다. 스냅샷은 몇 분 간격으로 생성될 수 있으며 애플리케이션 일관성이 부족할 수 있습니다. 결정에 따르는 트레이드오프는 명확합니다. 동기식 복제는 비용과 쓰기 지연 시간을 증가시키지만 RPO를 낮춥니다. 비동기식 복제는 지연 시간과 비용을 줄이지만 잠재적인 데이터 손실을 증가시킵니다. 카오스 테스트, 예약된 장애 조치, 복원 훈련을 통해 계획을 테스트하여 실제 RTO/RPO를 검증하고 외부 인증, DNS 또는 IP 화이트리스트와 같은 숨겨진 종속성을 식별하십시오.

Multi‑AZ 및 Multi‑Region 아키텍처와 장애 조치 전략

Multi‑AZ 아키텍처는 여러 가용 영역(Availability Zone)에 걸쳐 중복된 컴퓨팅, 네트워킹, 스토리지를 배치하여 AZ 장애로부터 보호합니다. Multi‑Region은 리전 수준의 장애, 자연재해 또는 대규모 네트워크 단절에 대한 내결함성을 확장합니다. 비용 및 복구 요구 사항에 따라 파일럿 라이트(pilot light), 웜 스탠바이(warm standby), 액티브-패시브(active-passive), 또는 액티브-액티브(active-active)와 같은 아키텍처 패턴을 선택하십시오. 파일럿 라이트는 보조 리전에 최소한의 리소스를 사용하여 비용을 최소화하고 장애 조치 중에 스케일업합니다. 웜 스탠바이는 더 빠른 복구를 위해 축소된 규모의 서비스를 계속 실행합니다. 액티브-액티브는 여러 리전에서 트래픽을 처리하여 가장 낮은 RTO를 달성하지만, 강력한 데이터 복제 및 충돌 해결 메커니즘이 필요합니다. 상태 확인 및 장애 조치 라우팅 기능이 있는 Route 53, 글로벌 트래픽 관리를 위한 Amazon CloudFront 또는 Global Accelerator, 교차 리전 복제를 위한 DynamoDB Global Tables 또는 Aurora Global Database와 같은 데이터 서비스를 사용하십시오. 일반적인 함정으로는 너무 긴 DNS TTL에 의존하는 것, 상태 저장 서비스(세션 스토어, 캐시)의 장애 조치를 검증하지 않는 것, 교차 리전 데이터 전송 비용 및 규정 준수 제약 조건을 간과하는 것 등이 있습니다. 다중 리전 배포의 복잡성 및 비용과 허용 가능한 다운타임 및 데이터 손실 사이의 트레이드오프를 고려하십시오. 확실하지 않은 경우, 장애 조치 시간을 측정하고 모델링하여 비즈니스 사례에 대한 정보를 제공하십시오.

애플리케이션 복원력 패턴: 무상태성, 디커플링, 상태 관리

개별 컴퓨팅 노드에 고정된 상태를 최소화하고 구성 요소를 디커플링하여 부분적인 장애가 연쇄적으로 퍼지지 않도록 장애를 염두에 두고 설계하십시오. Application Load Balancer 또는 Network Load Balancer 뒤에 있는 무상태(stateless) 애플리케이션 노드는 수평적 확장과 신속한 교체를 가능하게 합니다. 세션 상태의 경우 스티키 세션(sticky sessions) 대신 Amazon DynamoDB 또는 Amazon ElastiCache와 같은 외부 저장소를 사용하는 것이 좋습니다. 파일 공유의 경우 프로토콜 및 성능 요구 사항에 따라 Amazon S3, Amazon EFS 또는 FSx를 사용하십시오. Amazon SQS, SNS 또는 Kinesis를 사용하는 비동기 패턴은 트래픽 급증을 버퍼링하고, 재시도를 활성화하며, 역압력(backpressure)을 완화하고, 장애 조치 중 동기식 종속성을 줄여줍니다. 장애가 발생한 하위 시스템을 격리하기 위해 클라이언트에 서킷 브레이커(circuit breakers), 벌크헤드(bulkheads), 지수 백오프(exponential backoff)를 구현하십시오. 아키텍트가 자주 빠지는 함정은 콜드 스타트(cold-start) 또는 스케일업 시간을 과소평가하는 것입니다. Lambda 동시성 제한, Auto Scaling 쿨다운, 워밍업 전략은 RTO에 영향을 미칩니다. 또 다른 함정은 캐싱을 내구성으로 취급하는 것입니다. 캐시는 재구축이 가능해야 합니다. 비용 대 복원력 선택은 버퍼 크기 조정 및 복제에서 나타납니다. 더 높은 복원력은 종종 더 많은 예약 용량이나 교차 리전 복제를 필요로 하여 비용을 증가시킵니다. 장애를 감지하고 해결하기 위한 관찰성(observability)과 자동화를 보장하면서 RTO/RPO를 만족하는 최소한의 실행 가능한 이중화를 선택하십시오.

백업, 복제, 거버넌스 및 운영 준비성

백업은 보험과 같습니다. 중요한 요소는 일관성, 보안, 보존 및 복구 가능성입니다. EBS, RDS, DynamoDB, EFS, FSx 전반에 걸쳐 중앙 집중식 백업 정책을 적용하려면 AWS Backup을 사용하고, 지리적 복원력을 위해 교차 계정, 교차 리전 백업 사본 생성을 강제하세요. 객체 데이터의 경우, 교차 리전 내구성을 위해 S3 버전 관리와 수명 주기 규칙(Lifecycle rules) 및 S3 Replication(CRR)을 활성화하세요. 데이터베이스 네이티브 백업, RDS 자동 스냅샷 또는 VSS를 지원하는 AWS DRS를 활용하여 데이터베이스 및 Windows 파일 시스템에 대한 애플리케이션 일관성 있는 스냅샷을 보장하세요. 교차 계정 복제와 IAM 최소 권한 원칙은 실수로 인한 삭제를 방지하는 데 필수적입니다. 정기적인 복원 훈련을 통해 누락된 IAM 역할, 네트워킹(VPC CIDR 겹침), 또는 외부 통합과 관련된 문제를 발견할 수 있습니다. Systems Manager Automation으로 런북을 자동화하고, CloudFormation이나 Terraform으로 장애 조치 절차를 코드화하여 수동 오류를 줄이세요. 흔히 저지르는 실수로는 내보내기 기능이 없는 특정 시점 스냅샷에만 의존하거나, 고객 관리형 키로 백업을 암호화하지 않거나, 백업 작업 성공 여부를 모니터링하지 않는 것 등이 있습니다. 규제 요구 사항에 맞춰 보존 기간과 스토리지 비용의 균형을 맞추세요. 오래된 백업은 S3 Glacier로 계층화하여 비용을 관리하고, 최신 백업은 빠른 복원을 위해 신속하게 액세스할 수 있도록 유지하세요.

실용적인 문제: 사용 사례 시나리오

시나리오: 글로벌 라이브 이벤트 기업인 Meridian Events Inc.는 단일 AWS 리전에서 ALB 뒤에 EC2 Auto Scaling 그룹을 사용하여 티켓팅 애플리케이션을 운영하고 있습니다. 데이터베이스는 단일 AZ 내 EC2에 3개 노드로 구성된 PostgreSQL 클러스터를 사용하며, 매일 밤 EBS 스냅샷을 생성합니다. 이 조직은 운영 오버헤드와 비용을 최소화하면서 RTO를 10분 미만, RPO를 5분 미만으로 줄여야 합니다.

과제: 예측 가능한 장애 조치와 최소한의 애플리케이션 변경으로 여러 AZ/리전에 걸쳐 데이터베이스의 거의 지속적인 가용성과 낮은 데이터 손실을 달성해야 합니다.

권장 접근 방식:

Amazon RDS for PostgreSQL을 다중 AZ(Multi‑AZ) 배포로 구성하거나, Amazon Aurora PostgreSQL(Multi‑AZ)로 마이그레이션하고 자동화된 연속 백업 및 빠른 스냅샷 내보내기를 활성화합니다. 적절한 보존 기간을 설정하여 자동 백업을 활성화합니다.
지리적 RPO 목표를 충족하기 위해 Aurora Global Database(또는 보조 리전의 읽기 전용 복제본으로 RDS 논리적/물리적 복제)를 사용하여 교차 리전 복제를 추가하고, 제어된 리전 장애 조치가 가능하도록 Route 53 지연 시간 기반 라우팅과 상태 확인을 구성합니다.
단일 AZ의 EC2 PostgreSQL을 관리형 서비스로 교체하여 호스트 유지 관리를 없애고, 애플리케이션 연결 로직을 리팩터링하여 클러스터 엔드포인트나 RDS Proxy를 사용함으로써 커넥션 풀링 및 더 빠른 장애 조치 처리를 구현합니다.
지속적인 복제 검증 및 런북 자동화를 구현합니다. 즉, Systems Manager Automation과 CloudFormation 템플릿을 사용하여 정기적인 장애 조치 훈련을 수행하여 리소스를 신속하게 재생성하고, CloudWatch와 SNS를 통해 지표를 측정하고 경보를 실행합니다.

근거: 관리형 다중 AZ 데이터베이스 서비스와 교차 리전 복제를 사용하면 운영 복잡성을 줄이고 까다로운 RTO/RPO 목표를 충족할 수 있습니다. 자동화와 정기적인 훈련을 통해 계획이 실제로 작동하는지 확인할 수 있으며, RDS/Aurora는 수동 장애 조치 단계와 장애 조치 시간을 최소화합니다.

← 마이그레이션 및 현대화 · 모든 도메인 · 비용 최적화 및 거버넌스 →

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