AWS Resilient Architectures 설계 (DR & HA)
이 문서는 SAA-C03 시험의 Domain 2. Design Resilient Architectures 탄력적 아키텍처 설계 과목 관련 핵심 개념과 문제 패턴을 정리합니다.
이 영역은 시험 비중의 26%를 차지하며, 고가용성(HA)과 재해 복구(DR) 전략이 핵심입니다.
핵심 서비스 및 복원력 기능
복원력 있는 아키텍처를 설계하기 위해 실무와 시험에서 자주 언급되는 서비스별 핵심 기능입니다.
고가용성, 재해 복구 유형과 연관된 AWS 기능을 컴퓨팅, 스토리지, DB, 네트워크 4가지로 분류하여 살펴보겠습니다.
| 영역 | 서비스 | 핵심 기능 | 상세 설명 |
|---|---|---|---|
| 컴퓨팅 | ASG | Auto Scaling Group | 부하에 따른 인스턴스 자동 증감, Multi-AZ 배포로 가용성 확보 |
| ELB | Elastic Load Balancing | ALB (L7): HTTP/HTTPS 트래픽 및 상태 확인 기반 비정상 인스턴스 제외 NLB (L4): 고성능/UDP 트래픽/고정 IP 처리 GWLB: 타사 보안 어플라이언스 전용 트래픽 검사 | |
| 스토리지 | S3 | Simple Storage Service | Versioning: 실수 삭제 방지 Replication (CRR/SRR): 리전/AZ 간 자동 복제 Object Lock: WORM 방식의 데이터 불변성 보장 |
| EBS | Elastic Block Store | Snapshots: 리전 간 복제로 DR 준비 Multi-Attach: 동일 AZ 내 여러 인스턴스 동시 연결 | |
| 데이터베이스 | RDS & Aurora | - | Multi-AZ: 대기 인스턴스로 자동 페일오버 (HA) Read Replicas: 읽기 부하 분산 및 리전 복제 (DR) Global Database: 리전 간 매우 낮은 지연 시간의 복제 |
| DynamoDB | Global Tables | 전 세계 리전 자동 복제 및 멀티 마스터 읽기/쓰기 제공 | |
| 네트워크/DR | Route 53 | - | Health Checks: 엔드포인트 감시 Failover Routing: 장애 시 대기 리전으로 트래픽 자동 전환 |
| Global Accelerator | - | 애니캐스트 IP 및 빠른 리전 페일오버, 지연 시간 최적화 | |
| AWS Backup | - | 여러 AWS 서비스의 백업 정책을 중앙에서 관리 및 자동화 |
1. 컴퓨팅 및 오토스케일링
A. Auto Scaling Group - ASG
부하에 따라 EC2 인스턴스를 자동으로 증설/축소. Multi-AZ 배포를 통해 한 AZ 장애 시에도 서비스 유지.
ASG 주요 구성 요소 및 동작 방식
ASG는 단순히 개수를 조절하는 것이 아니라, 인스턴스의 생명주기를 관리하고 고가용성을 유지하는 핵심 서비스입니다.
| 구성 요소 | 설명 |
|---|---|
| Desired Capacity | 그룹 내에 유지하려는 인스턴스의 목표 개수. (기본값: Min) |
| Minimum Capacity | 장애나 스케일 인 상황에서도 유지해야 하는 최소 인스턴스 개수. |
| Maximum Capacity | 트래픽 폭증 시 확장할 수 있는 최대 인스턴스 개수. |
| Launch Template | 구동할 EC2의 AMI, 인스턴스 유형, 키 페어, 보안 그룹 등을 정의한 템플릿. |
| Health Check | EC2 (기본 상태 확인) 또는 ELB (L7 레벨 서비스 가용성) 지표를 사용하여 비정상 인스턴스 교체. |
| Termination Policy | 어느 가용 영역의 인스턴스를 먼저 종료할지 결정. (기본: 균형 유지를 위해 인스턴스가 가장 많은 AZ에서 선택) |
대상 그룹(Target Group) 및 연동
- ASG는 부하 분산을 위해 Target Group에 인스턴스를 자동으로 등록하고 해제합니다.
- ELB가 전달하는 트래픽을 안정적으로 처리할 수 있도록 셋업됩니다.
자동 확장(Auto Scaling) 정책
-
Target Tracking Scaling: 특정 지표(CPU 사용률 등)를 목표 값으로 유지 (가장 권장됨).
-
Step Scaling: 특정 경보 임계값에 도달할 때 단계적으로 인스턴스 증감.
-
Scheduled Scaling: 트래픽이 예측되는 특정 시간(예: 세일 기간)에 맞춰 용량 조절.
-
Predictive Scaling: 과거 트래픽 데이터를 머신러닝으로 분석하여 선제적으로 대응.
-
Elastic Load Balancing - ELB:
- ALB L7: HTTP/HTTPS 트래픽 처리, 상태 확인 기반 비정상 인스턴스 제외.
- NLB L4: 고성능, 고정 IP(Elastic IP) 필요 시, UDP 트래픽 처리.
- GWLB: 타사 보안 어플라이언스 트래픽 검사용.
2. 스토리지 및 데이터베이스
A. 스토리지 (Storage)
| 서비스 | 기능 | 상세 설명 | 복원력 (HA/DR) 관점의 역할 |
|---|---|---|---|
| S3 | Versioning | 객체의 모든 이전 버전을 보관 | 유실/덮어쓰기 등 실수에 의한 데이터 복구 |
| Replication | CRR(리전 간), SRR(리전 내) 자동 복제 | 리전 단위 장애 대비(DR) 및 데이터 공유 | |
| Object Lock | 지정된 기간 동안 데이터 삭제/수정 금지 | 데이터 무결성 보장 및 랜섬웨어 방어 | |
| EBS | Snapshots | 볼륨의 특정 시점 증분 백업 | 데이터 손실 시 복원 및 타 리전으로의 전송(DR) |
| Multi-Attach | 동일 AZ 내 여러 인스턴스에 동시 연결 | 클러스터링 기반 애플리케이션의 가용성 지원 | |
| EFS | Regional | 별도 설정 없이 여러 AZ에 데이터 복제 | 가용 영역(AZ) 장애 시에도 중단 없는 파일 서비스 |
- 특히 S3는 보안, 성능 문제와도 밀접하게 연관이 있어 추후 포스팅으로 내용을 보강하겠습니다.
- 스토리지 서비스 중 적절한 것을 선택해야하는 문제가 많습니다.
B. 데이터베이스 (Database)
| 서비스 | 기능 | 상세 설명 | 복원력 (HA/DR) 관점의 역할 |
|---|---|---|---|
| RDS | Multi-AZ Deployment | 동기식 대기 복제본(Standby) 유지 | AZ 장애 시 엔드포인트 유지하며 자동 페일오버 |
| Read Replica | 비동기식 읽기 전용 복제본 생성 | 읽기 성능 확장 및 다른 리전에 DR 환경 구축 | |
| Aurora | Aurora Global DB | 여러 리전에 걸쳐 데이터 실시간 복제 | 1초 이내 복제 지연, 리전 장애 시 초 단위 복구 |
| DynamoDB | Global Tables | 리전 간 멀티 마스터 복제 제공 | 글로벌 서비스의 저지연 성능 및 리전 가용성 확보 |
RDS vs Aurora vs DynamoDB 중 문제 조건에 따라 적절히 선택해야 하는 문제가 자주 출제됩니다.
3가지 DB 서비스의 차이점을 간략히 정리하면 다음과 같습니다:
| 구분 | RDS | Aurora | DynamoDB |
|---|---|---|---|
| 유형 | 관계형 DB (MySQL, PostgreSQL 등) | 관계형 DB (MySQL, PostgreSQL 호환) | NoSQL (Key-Value, Document) |
| 스케일링 | 수직 확장 (인스턴스 크기 조정) | 수직 + 수평 확장 (Read Replica, Aurora Serverless) | 수평 확장 (자동 파티셔닝) |
| 성능 | 표준 | 표준보다 빠름 (최대 5배) | 매우 빠름 (밀리초 단위) |
| 가용성 | Multi-AZ (자동 페일오버) | Multi-AZ (자동 페일오버) | Multi-Region (Global Tables) |
| 복제 | 비동기 (Read Replica) | 동기 (내부 6개 복제본) | 비동기 (리전 간) |
| 비용 | 저렴 | 중간 | 비쌈 |
| 적합한 워크로드 | 표준 관계형 DB, 기존 애플리케이션 | 고성능 관계형 DB, 마이크로서비스 | 대규모 데이터, 실시간 웹/모바일 앱 |
3. 네트워킹 및 재해 복구(DR)
| 서비스 | 핵심 기능 | 구성 요소 | 주요 유즈 케이스 | 적절한 상황/시험 포인트 |
|---|---|---|---|---|
| Route 53 | Health Checks | 엔드포인트 상태를 주기적으로 감시 (HTTP/HTTPS/TCP 등) | 비정상 엔드포인트 감지 및 자동 트래픽 재라우팅 | 애플리케이션 가용성 모니터링 필요 시 |
| Failover Routing | 주/보조 리소스 지정 및 자동 전환 | 리전 장애 시 대기 리전으로 트래픽 즉시 리디렉션 | 재해 복구(DR) 시나리오, Active-Passive 구성 | |
| Latency-based Routing | 사용자에게 가장 낮은 지연 시간의 엔드포인트 제공 | 글로벌 서비스의 성능 최적화 | 여러 리전에 배포 시 지역별 최적 리전 자동 선택 | |
| Geolocation Routing | 사용자 위치에 따라 특정 리전으로 라우팅 | 법적 규정 준수 또는 지역별 콘텐츠 제공 | GDPR 등 데이터 주권 요구사항 충족 | |
| Global Accelerator | Static Anycast IP | 전 세계에서 동일한 IP 주소 사용 | 고정 IP가 필요하거나 빠른 장애 조치가 필요한 경우 | UDP 애플리케이션(VoIP, 게임), IP 화이트리스트 환경 |
| Health-based Failover | 엔드포인트 상태 기반 자동 페일오버 (30초 이내) | 리전 간 빠른 장애 조치 및 연결 끊김 최소화 | Route 53보다 빠른 페일오버 필요 시 (DNS 캐싱 영향 없음) | |
| Performance Optimization | AWS 백본 네트워크 활용으로 지연 시간 감소 | 글로벌 트래픽의 성능 및 안정성 향상 | 인터넷 경로 불안정 지역의 사용자 대상 서비스 | |
| AWS Backup | Centralized Backup Policy | 여러 AWS 서비스의 백업을 단일 콘솔에서 관리 | EBS, RDS, DynamoDB, EFS 등의 통합 백업/복원 | 운영 오버헤드 최소화하며 규정 준수 달성 |
| Cross-Region Backup | 백업을 다른 리전으로 자동 복제 | 리전 장애 대비 백업 데이터 보호 | 지리적으로 분리된 백업 보관 요구사항(규정 준수) | |
| Lifecycle Management | 오래된 백업을 저렴한 스토리지로 자동 전환 | 비용 절감하며 장기 보관 요구사항 충족 | Backup & Restore DR 전략의 핵심 구성 요소 |
주요 비교 포인트
마찬가지로 Route53, Global Accelerator, AWS Backup 역시 차이점을 인지해야 합니다. 각각의 세부 기능 차이점은 추후 포스팅에서 보강하겠습니다. 아래는 SAA 시험 관점에서 본 주요 비교 포인트입니다.
| 비교 항목 | Route 53 | Global Accelerator | AWS Backup |
|---|---|---|---|
| 주요 목적 | DNS 기반 트래픽 라우팅 | 네트워크 계층 가속 및 고가용성 | 백업 및 복원 관리 |
| 장애 조치 속도 | DNS TTL에 따라 다름 (분 단위 가능) | 30초 이내 (DNS 캐싱 영향 없음) | N/A (백업 복원은 RTO에 따라 다름) |
| 프로토콜 지원 | HTTP/HTTPS (애플리케이션 계층) | TCP/UDP (전송 계층, UDP 핵심) | N/A |
| 고정 IP 제공 | ❌ | ✅ (Anycast IP 2개) | N/A |
| 비용 | 저렴 (쿼리당 과금) | 비쌈 (시간당 + 데이터 전송) | 백업 스토리지 및 복원 요청당 과금 |
| 적합한 DR 전략 | Active-Passive, Multi-Site | Active-Active, Warm Standby | Backup & Restore, Pilot Light |
| 시험 단골 키워드 | "DNS", "도메인", "멀티 리전 HA" | "UDP", "고정 IP", "빠른 페일오버" | "중앙 집중식 백업", "규정 준수" |
DR 전략 패턴 (Disaster Recovery Strategies)
| 전략 | 설명 | 비용 | RTO/RPO |
|---|---|---|---|
| Backup & Restore | 정기적 백업 후 재해 시 인프라 재구축 | 가장 저렴 | 가장 긺 (시간 단위 이상) |
| Pilot Light | 데이터는 실시간 복제, 핵심 인프라(DB 등)만 켜두고 나머지는 정지 상태 | 저렴 | 수십 분 |
| Warm Standby | 최소 규모의 운영 환경을 항상 실행 (Auto Scaling group의 최소 크기 유지) | 중간 | 수 분 |
| Multi-Site (Active-Active) | 두 리전에서 동시에 실시간 서비스 운영 | 가장 비쌈 | 거의 0 (수 초) |
시험에서 "가장 비용 효율적인" 또는 "가장 짧은 RTO/RPO"를 묻는 문제의 단골 주제입니다.
RTO (Recovery Time Objective)
RTO(Recovery Time Objective) 장애 발생 후 서비스가 다시 복구되어야 하는 최대 허용 시간입니다.
- 질문 포인트:
- “얼마나 빨리 복구해야 하나?”
- “다운타임을 얼마나 짧게 허용하나?”
- RTO가 짧을수록 더 비쌈 + 미리 켜둔 리소스 필요
- 주요 문제 유형:
- “몇 분 이내 복구” → Hot / Warm Standby
- “몇 시간 허용” → Backup & Restore
RPO (Recovery Point Objective)
RPO(Recovery Point Objective) 복구 시 허용 가능한 데이터 손실 최대 시간입니다.
- 질문 포인트:
- “얼마나 최근 데이터까지 복구해야 하나?”
- “데이터를 얼마나 잃어도 되나?”
- RPO가 짧을수록 비용 증가로 이어짐
- 실시간/빈번한 복제 필요하기 때문
- 주요 문제 유형:
- “데이터 손실 거의 없음” → Multi-AZ / 동기 복제
- “몇 시간 전 데이터까지 허용” → 스냅샷 / 비동기 복제
RTO/RPO는 문제에서 다음과 같은 문구와 함께 연관됩니다.
- “가장 비용 효율적인”
- 비용 무시
- RTO 길어도 됨
- RPO 어느 정도 허용
- “가장 짧은 RTO/RPO”
- 실시간 복제, 즉시 전환
주어진 문제의 조건에 따라 적절한 컴퓨팅, 스토리지, 네트워크에서 각각의 서비스를 선택하면 됩니다.
주요 문제 출제 패턴
1. 고가용성(HA) vs 장애 조치(Failover)
- 패턴: "단일 AZ의 EC2 인스턴스 하나가 장애가 발생해도 서비스가 유지되어야 함"
- 해석: Multi-AZ 배포와 ELB 사용이 핵심. DB의 경우 RDS Multi-AZ 설정 필요.
2. 읽기 부하 분산 vs 고가용성
- 패턴: "보고서 생성용 쿼리가 많아져 운영 DB 성능이 느려짐"
- 해석: **Read Replica(읽기 전용 복제본)**를 생성하여 쿼리를 분산. (Multi-AZ는 성능 분산 목적이 아님)
3. 결합 해제(Decoupling) 및 비동기 처리
- 패턴: "갑작스러운 트래픽 폭증 시 주문 데이터가 유실되지 않아야 함"
- 해석: **SQS (Simple Queue Service)**를 사용하여 생산자와 소비자를 분리. 주문 유실 방지 및 확장성 확보.
4. 비용 효율적인 데이터 보호
- 패턴: "1개월은 자주 접근하지만 그 이후에는 접근하지 않으며, 무기한 보관해야 함"
- 해석: S3 Lifecycle Policy를 사용하여 S3 Standard -> S3 Glacier Deep Archive로 전환.
Resilient Architectures 관련 문제
Q1: 다중 AZ 간 데이터 일치성 문제 (EBS vs EFS)
회사는 단일 Amazon EC2 인스턴스와 EBS 볼륨을 사용하여 웹 애플리케이션을 호스팅하고 있습니다. 확장성과 가용성을 위해 다른 가용 영역에 두 번째 EC2 인스턴스와 EBS 볼륨을 생성하여 ALB 뒤에 배치했습니다. 하지만 사용자는 새로고침 시마다 일부 문서가 보이지 않는다고 보고합니다. 모든 문서를 동시에 볼 수 있게 하려면?
정답: C
- A. 두 EBS 볼륨에 모든 문서가 포함되도록 데이터를 복사합니다.
- B. 문서가 있는 서버로 사용자를 안내하도록 ALB를 구성합니다.
- C. 두 EBS 볼륨의 데이터를 Amazon EFS 로 복사합니다. 새 문서를 Amazon EFS 에 저장하도록 애플리케이션을 수정합니다.
- D. 두 서버 모두에 요청을 보내도록 ALB 를 구성합니다.
Point: EBS는 특정 AZ에 고정되므로 다른 AZ의 인스턴스가 접근할 수 없습니다. Amazon EFS(공유 스토리지)를 사용하면 Multi-AZ 환경에서 모든 인스턴스가 동일한 파일 시스템에 접근 가능합니다.
Q2: 대규모 트래픽 수집 및 확장성 (SNS + SQS)
들어오는 메시지를 수집하는 애플리케이션이 있고, 수십 개의 소비자 애플리케이션이 이를 소비해야 합니다. 메시지 수는 초당 100,000개로 급증할 수 있습니다. 확장성을 높이고 분리(Decouple)하기 위한 솔루션은?
정답: D
- A. Amazon Kinesis Data Analytics 사용
- B. Auto Scaling 그룹의 CPU 지표 기반 확장
- C. 단일 샤드 Kinesis Data Streams 및 DynamoDB 저장
- D. 여러 Amazon SQS 구독이 있는 Amazon SNS 주제에 메시지를 게시합니다. 대기열의 메시지를 처리하도록 소비자 애플리케이션을 구성합니다.
Point: Fan-out 패턴. SNS가 메시지를 받고 여러 SQS 대기열로 뿌려줌으로써 시스템 간 결합을 해제하고 대규모 확장이 가능합니다.
Q3: 대기열 크기에 따른 자동 확장
분산 애플리케이션을 마이그레이션하며 탄력성과 확장성을 극대화하려고 합니다. 컴퓨팅 노드의 작업 조정을 현대화하기 위한 설계는?
정답: B
- A. SQS 대기열 구성 및 예약된 조정을 사용하도록 EC2 Auto Scaling 구성
- B. 작업의 대상으로 SQS 대기열을 구성합니다. 대기열 크기에 따라 EC2 Auto Scaling을 구성합니다.
- C. AWS CloudTrail 을 작업 대상으로 구성
- D. Amazon EventBridge 를 작업 대상으로 구성
Point: 작업이 쌓이는 정도(대기열 크기)에 따라 워커(EC2)를 늘리거나 줄이는 것이 가장 탄력적인(Resilient) 설계입니다.
Q4: 지연 시간 최소화 및 글로벌 페일오버 (VoIP 서비스)
UDP 연결을 사용하는 VoIP 서비스를 여러 리전에 배포하고 있습니다. 지연 시간이 가장 짧은 리전으로 사용자를 라우팅하고, 리전 간 자동 장애 조치가 필요한 솔루션은?
정답: A
- A. NLB를 배포하고 대상 그룹을 ASG와 연결합니다. 각 리전에서 NLB를 AWS Global Accelerator 엔드포인트로 사용합니다.
- B. ALB를 사용하고 Global Accelerator 연결
- C. Route 53 지연 시간 레코드 및 CloudFront 사용
- D. ALB 및 Route 53 가중치 레코드 사용
Point: UDP 트래픽은 ALB가 아닌 NLB가 처리해야 하며, 글로벌 엔드포인트와 빠른 장애 조치를 위해 Global Accelerator가 적합합니다.
Q5: 안정적인 처리 및 메시지 유실 방지 (SQS)
SNS 주제로 알림을 받고 Lambda로 처리하는 워크플로가 네트워크 문제로 가끔 실패합니다. 수동 재실행 없이 모든 데이터를 수집하려면? (2개 선택)
정답: B, E
- A. 여러 가용 영역에 Lambda 배포
- B. Amazon SQS 대기열을 생성하고 SNS 주제를 구독합니다.
- C. Lambda CPU/Memory 상향
- D. Lambda 프로비저닝된 처리량 상향
- E. Amazon SQS 대기열에서 읽도록 Lambda 함수를 수정합니다.
Point: 일시적인 오류 시 SQS에 메시지가 보관되므로 유실되지 않고 다시 시도할 수 있습니다 (재시도 메커니즘).