Amazon SOA-C02: 고가용성, 내결함성 및 재해 복구 — 학습 가이드

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

이 도메인은 구성 요소, 서비스 또는 전체 리전이 실패했을 때 가용성과 복구 가능성을 유지하는 시스템 설계를 다룹니다. 백업 및 스냅샷 전략, 복제 및 장애 조치(failover) 패턴, 그리고 비즈니스의 RTO(복구 목표 시간) 및 RPO(복구 목표 시점) 목표를 충족하는 데 필요한 운영 테스트를 포괄합니다. 운영상의 중요성은 매우 높습니다. 중단 및 데이터 손실은 SLA, 수익, 규정 준수에 직접적인 영향을 미칩니다. 효과적인 설계는 비용, 복잡성, 그리고 허용 가능한 데이터 손실 및 다운타임 위험 사이의 균형을 맞춥니다.

백업 전략, 스냅샷, 보존

백업은 자동화되어야 하고, 애플리케이션 상태와 일관성을 유지해야 하며, 정책에 따라 보존되어야 합니다. AWS Backup을 사용하여 계획, 보존 및 수명 주기 규칙을 중앙에서 관리합니다(볼트(vault)로 백업 계획 생성, 리소스 ID ARN 또는 태그 할당). EBS 볼륨의 경우 Data Lifecycle Manager(DLM)를 사용하여 스냅샷을 예약합니다(콘솔 또는 aws dlm create-lifecycle-policy). CLI 스냅샷 생성 예시: aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 --description "pre-upgrade". RDS의 경우 자동 스냅샷 또는 수동 DB 스냅샷을 사용합니다(aws rds create-db-snapshot --db-instance-identifier mydb --db-snapshot-identifier mydb-snap-YYYYMMDD). 특정 시점 복구(point-in-time recovery)를 위해 RDS 자동 백업을 활성화하고, 보존 SLA를 충족하기 위해 향상된 모니터링 및 스냅샷 보존을 활성화합니다.

보존, 불변성, 리전 간 복사는 중요한 결정 사항입니다:

짧은 RPO/RTO는 빈번한 스냅샷과 짧은 보존 삭제 기간을 필요로 하며, 이는 비용을 증가시킵니다.
규제 준수를 위한 불변성이 필요할 경우, 법적 보존(legal hold)을 위해 AWS Backup Vault Lock 또는 S3 Object Lock을 사용합니다.
리전 간 내구성을 위해 스냅샷을 복사하고(aws ec2 copy-snapshot --source-region us-east-1 --source-snapshot-id snap-abc --destination-region us-west-2), 리전 간 복제 전에 S3 버전 관리를 활성화합니다.

항상 애플리케이션과 일관된 상태를 캡처해야 합니다. EC2의 경우, 스냅샷을 생성하기 전에 AWS Systems Manager Run Command나 스크립트를 사용하여 파일 시스템을 플러시/잠금 처리합니다. 데이터베이스의 경우, 특정 시점 검증을 위해 엔진 네이티브 스냅샷(RDS/Aurora)이나 논리적 백업(mysqldump, pg_dump)을 선호합니다.

리전 간 복제 및 재해 복구 패턴

리전 간 전략은 리전 장애로 인한 영향 반경(blast radius)을 줄여줍니다. S3 리전 간 복제(CRR)는 버전 관리, IAM 복제 역할, 복제 구성이 필요합니다(콘솔 또는 aws s3api put-bucket-replication --bucket src --replication-configuration file://replication.json). RDS는 리전 간 읽기 전용 복제본(aws rds create-db-instance-read-replica)을 지원하며, Aurora Global Database는 제어된 장애 조치를 통해 지연 시간이 짧은 리전 간 읽기/쓰기 아키텍처를 지원합니다. DynamoDB Global Tables는 여러 리전에 걸쳐 데이터를 비동기적으로 복제하며, 최종적 일관성(eventual consistency)을 고려해야 하는 다중 리전 읽기 작업에 적합합니다.

RTO/RPO 및 비용에 따라 DR 패턴을 선택합니다:

파일럿 라이트(Pilot Light): 중요한 데이터를 보조 리전으로 복제(S3, 스냅샷, DB 복제본)하되, 실행 중인 인프라는 최소화합니다. IaC 템플릿을 통해 신속하게 확장(scale-up)합니다.
웜 스탠바이(Warm Standby): 보조 리전에 더 작은 규모의 활성 풋프린트를 유지하며, 데이터를 지속적으로 복제하고 축소된(scaled-down) 서비스를 자동으로 확장할 수 있도록 구성합니다.
다중 리전 액티브-액티브(Multi-Region Active-Active): 여러 리전에서 전체 스택을 실행하며 트래픽 라우팅 및 충돌 해결을 관리합니다. 전역 복제(DynamoDB Global Tables, Aurora Global DB, 애플리케이션 수준 충돌 처리)가 필요합니다.

복제 일관성을 고려해야 합니다. 동기식 복제는 RPO를 최소화하지만 지연 시간을 증가시키며 리전 간에는 지원되지 않을 수 있습니다. 대부분의 리전 간 옵션은 비동기식이며, 현실적인 RPO를 결정하는 복제 지연(replication lag)이 발생합니다.

다중 AZ 및 다중 리전 아키텍처 선택

다중 AZ는 리전 내 고가용성을 위한 기본 옵션이며, 많은 관리형 서비스에 대해 최소한의 RTO로 자동 장애 조치를 제공합니다. RDS 다중 AZ와 Aurora는 여러 AZ에 걸쳐 스토리지를 복제하며, 장애 조치는 일반적으로 자동이며 DNS 전환(switch-over)을 사용합니다. EC2의 경우, 인스턴스를 여러 AZ에 배치하고 Application Load Balancer 및 Auto Scaling 그룹 뒤에 둡니다. AZ 간 상태 확인(health check)을 사용하여 비정상 대상을 탐지하고 교체합니다.

다중 리전은 리전 전체의 장애에 대한 복원력을 추가하지만 복잡성(데이터 복제, 글로벌 라우팅, 규정 준수)을 증가시킵니다. 결정 기준:

리전 내에서 낮은 지연 시간의 고가용성이 필요하고, 더 낮은 비용으로 관리형 자동 장애 조치를 원할 때 다중 AZ를 사용합니다.
리전 손실에 대비한 재해 복구나 글로벌 액티브-액티브 구성으로 지연 시간을 줄여야 할 때 다중 리전을 사용합니다.

설계 시 고려 사항:

DNS TTL: 빠른 DNS 기반 장애 조치를 위해서는 낮은 TTL(예: 60초)이 필요하지만, 이는 DNS 쿼리 부하를 증가시킵니다.
데이터 상주 위치 및 규정 준수: 일부 데이터는 특정 리전에 남아 있어야 하므로, 이에 맞춰 복제 및 암호화를 설계해야 합니다.
비용 대 RTO/RPO: 다중 리전 액티브-액티브는 비용을 증가시키지만 RTO를 최소화합니다.

장애 조치(Failover) 메커니즘 (Route53 상태 확인, 자동화)

자동화된 장애 조치는 상태 확인, 라우팅 정책, 오케스트레이션을 사용합니다. Route53은 상태 확인과 장애 조치/가중치/지연 시간 기반 라우팅을 지원합니다. Route53 상태 확인을 구성하여 엔드포인트(HTTP, TCP 또는 CloudWatch 경보)를 프로빙하고, 기본 리소스에 장애가 발생했을 때 보조 리소스로 전환하는 장애 조치 레코드 세트를 설정합니다. CLI 업데이트 예시:

undefined

. DNS 작업이 아닌 장애 조치를 오케스트레이션하려면 CloudWatch 경보(경보 작업이 AWS Lambda를 트리거)를 사용합니다.

로드 밸런서와 Auto Scaling 통합: ALB/NLB 대상 그룹 상태 확인은 비정상 인스턴스를 제거하고, Auto Scaling은 이를 자동으로 교체합니다. 데이터베이스 장애 조치의 경우, 서비스 수준 메커니즘에 의존합니다: RDS 다중 AZ(Multi-AZ) 또는 Aurora 자동 장애 조치, 그리고 리전 간 승격에는 읽기 전용 복제본(read replicas) 또는 Aurora Global DB 제어 승격을 사용합니다.

두 가지 운영 패턴:

DNS 장애 조치 (Route53): 구현이 빠르지만 DNS TTL 및 클라이언트 캐싱에 의존적입니다.
컨트롤 플레인 장애 조치 (Lambda/Step Functions + API 호출): 복잡한 애플리케이션을 위해 승격, IP/EIP 재할당, Route53 업데이트를 예측 가능한 순서로 오케스트레이션합니다.

RTO/RPO 계획, 테스트 및 검증

RTO는 최대 허용 가능 다운타임이며, RPO는 최대 허용 가능 데이터 손실입니다. 각 워크로드에 대해 측정 가능한 목표를 정의하고 아키텍처 선택을 이에 맞춥니다. 동기식 복제는 RPO를 줄이지만 지연 시간이 증가할 수 있으며, 비동기식 복제는 비용을 낮추지만 잠재적인 데이터 손실 기간을 늘립니다. 비즈니스 SLA를 보존 및 복제 주기로 변환합니다: RPO = 복제 지연(replication lag) + 백업 간격, RTO = 감지 시간 + 장애 조치 오케스트레이션 시간 + 복구 검증 시간.

테스트는 필수적입니다. 복원 절차, DNS 장애 조치, 애플리케이션 무결성을 검증하는 정기적인 DR 훈련을 실행하세요. 격리된 계정이나 VPC로 복원하여 백업을 검증합니다(재구축 자동화를 위해 CloudFormation/CloudFormation StackSets 또는 Terraform 사용). 테스트 중 지표(DNS 전파 시간, 복구 시점, 애플리케이션 수준 확인)를 수집하고 자동화를 반복하여 RTO를 줄입니다.

일반적인 함정과 의사 결정 기준

스냅샷이 곧 복구 가능성을 의미한다고 가정하는 것: 항상 별도의 환경으로 복원을 수행하고 애플리케이션 일관성을 검증해야 합니다. 엔진 네이티브 스냅샷을 사용하거나 스냅샷 생성 전에 애플리케이션을 정지(quiesce)시키세요.
글로벌 중요 워크로드를 위해 단일 리전 시스템을 설계하는 것: 리전 장애가 고객에게 영향을 미칠 때 다중 리전(Multi-Region) 패턴이나 웜 스탠바이(warm standby)를 선택하세요. 데이터 주권(data sovereignty)을 고려해야 합니다.
설계 시 RTO/RPO를 무시하는 것: 워크로드별로 RTO/RPO를 파악하고 그에 따라 복제/백업을 선택하세요. RPO를 복제 주기에, RTO를 오케스트레이션 자동화에 매핑하세요.
빠른 장애 조치를 방해하는 긴 DNS TTL: 중요한 장애 조치 레코드에는 낮은 TTL을 설정하고, 안정적인 라우팅이 필요할 때만 글로벌 가속(global acceleration)을 사용하세요.
리전 간 복제를 위한 IAM/권한을 소홀히 하는 것: CRR, 스냅샷 복사, 백업 볼트(backup vault) 접근에는 올바른 역할과 리소스 정책이 필요합니다. 복제 IAM 경로를 테스트하세요.
복제 지연 및 상태를 모니터링하지 않는 것: CloudWatch 지표(ReplicaLag, CPU, 네트워크)를 측정하고 임계값이 RPO 한계에 가까워지면 경보를 설정하세요.

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

AcmePayments는 us-east-1에서 PCI 범위의 트랜잭션 API를 운영하며, 리전 장애 발생 시 핵심 트랜잭션 데이터에 대해 5분 미만의 RTO와 거의 0에 가까운 RPO가 필요합니다.

빠른 리전 간 복제를 위해 us-east-1에 쓰기 가능한 기본 데이터베이스를, eu-west-1에 보조 데이터베이스를 두는 Aurora Global Database를 선택하여 RTO=5분, RPO≈0으로 정의합니다.
리전 내 HA를 위해 동기식/리전별 다중 AZ(Aurora 복제본 + Multi-AZ)를 활성화하고, 장애 조치 라우팅을 위해 상태 확인 및 낮은 TTL(60초)을 설정한 Route53을 통해 DNS를 게시합니다.
보존 및 볼트 잠금(vault lock) 기능이 있는 추가적인 불변 복사본으로 리전 간 자동 스냅샷과 AWS Backup 볼트 복사본을 사용합니다.
Step Functions와 Lambda로 장애 조치 플레이북을 자동화하여 복제본 승격을 검증하고, Route53 레코드를 업데이트하며(aws route53 change-resource-record-sets), 스모크 테스트를 실행하고, 장애 감지 시 롤백합니다.
분기별 DR 훈련을 계획하여 격리된 VPC로 백업을 복원하고 실제 RTO 및 RPO를 측정하여 자동화 및 스케일링 정책을 개선합니다.

근거: 지연 시간이 낮은 글로벌 DB 제품(Aurora Global)과 DNS 기반 라우팅 및 자동화된 오케스트레이션을 결합하면 엄격한 RTO/RPO를 충족하면서 운영 단계를 반복 가능하고 테스트 가능하게 유지할 수 있습니다. 정기적인 검증을 통해 백업과 복제본이 실제로 복구 가능한지 확인할 수 있습니다.

← 모니터링 · 모든 도메인 · 배포 →

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