고가용성 및/또는 내결함성 아키텍처 설계
발행: (2026년 2월 5일 오후 05:04 GMT+9)
12 min read
원문: Dev.to
Source: Dev.to
위에 제공된 Source 링크만으로는 번역할 실제 본문 내용이 포함되어 있지 않습니다. 번역이 필요한 텍스트(본문, 코드 블록 제외)를 제공해 주시면, 요청하신 대로 마크다운 형식과 기술 용어를 유지하면서 한국어로 번역해 드리겠습니다.
Exam Guide – Solutions Architect – Associate
Domain 2: Design Secure Architectures
Task Statement 2.2 – Designing Highly Available and Fault‑Tolerant Architectures
High Availability (HA) – 시스템이 구성 요소 장애가 발생해도 계속 가동됩니다.
Fault Tolerance (FT) – 시스템이 중단 없이 계속 운영됩니다.
Typical HA pattern – Multi‑AZ + 로드 밸런싱 + 관리형 서비스 + 단일 장애 지점 없음.
1️⃣ AWS Global Infrastructure
| Component | Description |
|---|---|
| Availability Zones (AZs) | 리전 내에 격리된 장애 도메인. |
| Regions | 별도의 지리적 영역 – 재해 복구(DR)에 사용. |
| Amazon Route 53 | DNS 기반 라우팅 및 상태 검사; 지역 장애 조치에 일반적으로 사용. |
- “AZ 장애를 견딜 수 있어야 함” → Multi‑AZ 설계.
- “지역 전체 장애를 견딜 수 있어야 함” → Multi‑Region DR + Route 53 장애 조치.
2️⃣ AWS Managed Services – Appropriate Use Cases
- 관리형 서비스는 내장된 HA, 자동 스케일링, 운영 위험 감소를 제공하는 경우가 많습니다.
- 서비스 자체가 HA 주제가 아니더라도(예: Comprehend, Polly) 시험에서는 신뢰성을 높이고 커스텀 작업을 줄이기 위해 관리형 서비스를 선호하도록 요구합니다.
3️⃣ Basic Networking Concepts
| Element | HA/FT Considerations |
|---|---|
| Route Tables | 올바른 라우팅이 필수입니다. |
| Public Subnets | 인터넷 게이트웨이(IGW)로 라우팅됩니다. |
| Private Subnets | NAT Gateway를 통한 아웃바운드 트래픽. |
| Multi‑AZ Designs | 각 AZ마다 자체 서브넷 및 라우팅이 필요합니다. |
4️⃣ Disaster‑Recovery (DR) Strategies
| DR Strategy | What It Is | Typical RTO / RPO | Cost |
|---|---|---|---|
| Backup & Restore | 백업에서 새로운 환경으로 복원 | 느린 RTO, 높은 RPO | 가장 낮음 |
| Pilot Light | 핵심 서비스만 최소 수준으로 실행(예: DB + 최소 인프라) | 중간 RTO, 중간 RPO | 낮음‑중간 |
| Warm Standby | 축소된 규모이지만 완전하게 동작하는 스택을 항상 실행 | 빠른 RTO, 낮은 RPO | 중간‑높음 |
| Active‑Active | 두 리전이 동시에 트래픽을 서비스 | 가장 낮은 RTO/RPO | 가장 높음 |
Tip: RTO/RPO가 엄격할 경우 Warm Standby 또는 Active‑Active를 선호하세요.
5️⃣ Distributed Design Patterns
- Retry with back‑off – 폭주를 방지합니다.
- Timeouts – 자원 고갈을 방지합니다.
- Circuit breaker / Bulkhead – 연쇄 장애를 제한합니다.
- Queue‑based load leveling – 예: Amazon SQS.
- Idempotency – 안전한 재시도를 보장합니다.
- Multi‑AZ deployment – 모든 핵심 계층에 적용합니다.
6️⃣ Failover Strategies
- Load‑balancer failover – 리전 내 여러 AZ에 있는 대상들 간 전환.
- Database failover – 예: RDS Multi‑AZ.
- DNS failover – Route 53 상태 검사를 이용한 리전 간 전환.
- Client‑side failover – 애플리케이션이 보조 엔드포인트를 시도.
“리전 간 장애 조치” → Route 53 장애 조치 라우팅(또는 지연 기반 + 상태 검사) 사용.
Immutable Deployments
- 새 AMI / 컨테이너 이미지를 빌드합니다.
- 새 인스턴스 / 작업을 배포합니다.
- 기존 인스턴스를 종료합니다.
Benefits
- 일관성.
- 빠른 복구.
- 구성 드리프트 감소.
Best practice: IaC(CloudFormation, CDK, Terraform)와 immutable 배포를 결합해 “인프라 무결성과 재현성을 보장”합니다.
8️⃣ Load‑Balancing Concepts – Application Load Balancer (ALB)
- 여러 AZ에 있는 대상에 트래픽을 분산합니다.
- 단일 인스턴스 SPOF를 제거합니다.
9️⃣ Proxy Concepts – Amazon RDS Proxy
스파이크가 있거나 서버리스 워크로드의 신뢰성을 높이기 위해 다음을 수행합니다.
- DB 연결을 풀링하고 재사용합니다.
- 연결 폭주로 인한 DB 과부하를 감소시킵니다.
- 지원되는 패턴에 대해 장애 조치 동작을 개선합니다.
Use case: Lambda 함수가 과도한 DB 연결을 생성 → RDS Proxy 활용.
🔟 Service Quotas & Throttling – Standby Environments
- DR 시나리오에서 스탠바이 환경은 서비스 한도와 스로틀링을 고려해 설계해야 합니다.
- 필요 시 한도 증액 요청을 미리 진행하고, 자동 스케일링 정책을 활용해 급증에 대비합니다.
Source: …
1️⃣1️⃣ 스토리지 옵션 및 특성 – 내구성 & 복제
| Service | 내구성 / 복제 |
|---|---|
| Amazon S3 | 매우 높은 내구성을 갖춘 지역 기반 스토리지; 버전 관리 및 복제를 지원합니다. |
| Amazon EBS | AZ 내에서 복제되며, 스냅샷을 S3에 저장해 내구성을 확보할 수 있습니다. |
| Amazon EFS | 리전 내에서 다중 AZ에 걸쳐 지역 기반으로 제공됩니다. |
1️⃣2️⃣ 워크로드 가시성 – AWS X‑Ray
- CloudWatch – 상태 및 스케일링을 위한 메트릭 및 알람.
- AWS X‑Ray – 분산 요청을 추적하고 병목 현상을 정확히 파악합니다.
가시성은 HA에 필수적입니다: 감지하고 진단함으로써 장애를 신속히 파악할 수 있습니다.
A️⃣ 인프라 무결성을 보장하기 위한 자동화 전략 결정
찾아볼 항목:
- Infrastructure as Code – CloudFormation, CDK, Terraform.
- Automated deployments – blue/green, rolling.
- Auto Scaling + health checks.
- Automated recovery actions – replace unhealthy instances/tasks.
공통 아키텍처 선택
- Multi‑AZ: ALB + Auto Scaling + Multi‑AZ 데이터베이스 (RDS Multi‑AZ).
- Multi‑Region: Route 53 + 복제된 데이터 + 대기/활성 환경.
“AZ 장애가 다운타임을 초래해서는 안 된다” → Multi‑AZ everything.
주요 운영 지표
- 가용성 / 오류율 (5xx).
- 지연 시간 p95 / p99.
- 큐 깊이 / 연령 (SQS).
- CPU / 메모리 / 연결 수 (컴퓨트 및 DB).
- RPO / RTO 준수 신호 (백업 성공, 복제 지연).
D️⃣ 단일 장애 지점을 완화하기 위한 설계 구현
- Multi‑AZ 배포.
- Redundant NAT Gateways – AZ당 하나 (모범 사례).
- Multi‑AZ 데이터베이스.
- 단일 인스턴스 “펫” 서버 회피.
E️⃣ 데이터 내구성 및 가용성 보장 – 백업
- 자동 백업 (RDS).
- 스냅샷 (EBS, RDS).
- 필요에 따라 S3 버전 관리 + 복제.
- 중앙 집중식 백업을 위한 AWS Backup 정책.
RTO/RPO에 따라 백업 전략 선택:
| 전략 | 비용 | RTO / RPO |
|---|---|---|
| 백업/복구 | 낮음 | 느림 / 높음 |
| 파일럿 라이트 | 낮음‑중간 | 중간 |
| 워밍 스탠바이 | 중간‑높음 | 빠름 / 낮음 |
| 액티브‑액티브 | 가장 높음 | 가장 빠름 / 가장 낮음 |
G️⃣ 레거시 애플리케이션 신뢰성 향상
애플리케이션 코드를 변경할 수 없을 때는 인프라 패턴을 사용하세요:
- 앱을 ALB 뒤에 배치합니다.
- Auto Scaling groups을 사용해 실패한 인스턴스를 자동으로 교체합니다.
- RDS Proxy를 배포해 DB 연결을 안정화합니다.
- caching(예: ElastiCache)을 추가해 백엔드 부하를 줄입니다.
- DNS failover(Route 53)를 구성해 지역별 복원력을 확보합니다.
재해 복구 (DR) – 장애 유형을 줄이는 관리형 서비스
- Application Layer: ALB, Auto Scaling, Route 53
- Data Layer: RDS Multi‑AZ, DynamoDB (관리형 HA)
- Messaging: SQS / SNS를 사용해 스파이크와 장애를 디커플링
- Edge: CloudFront를 통해 엣지 캐싱 및 오리진 보호
요구 사항 및 지침
| 시나리오 | 권장 AWS 서비스 |
|---|---|
| 인스턴스 장애 복구 | Auto Scaling + health checks + ALB |
| 가용 영역(AZ) 장애 복구 | Multi‑AZ for each tier (ALB targets across AZs, Multi‑AZ DB) |
| 리전 장애 복구 | DR strategy + Route 53 failover + replicated data |
| 엄격한 RTO / RPO | Warm standby or active‑active |
| Lambda가 RDS 연결을 과부하 | RDS Proxy |
| 마이크로서비스 전반의 병목 현상 파악 필요 | X‑Ray (plus CloudWatch) |
| 대기 상태가 장애 시 확장 필요 | Plan Service Quotas + scaling policies |
체크리스트
- 모든 핵심 계층이 여러 AZ에 배포됨
- 트래픽이 ALB/NLB를 통해 분산되고 비정상 대상은 자동으로 교체됨
- 데이터베이스가 HA 기능을 사용 (예: RDS Multi‑AZ 또는 관리형 HA 서비스)
- DR 전략이 비즈니스 RTO/RPO와 일치 (백업/복구 vs 파일럿‑라이트 vs 웜 스탠바이 vs 액티브‑액티브)
- 지역 장애 조치는 필요 시 Route 53 상태 검사/라우팅 사용
- 데이터 내구성이 보장됨 (백업, 스냅샷, 복제)
- 장애 조치/스탠바이 확장을 위해 할당량 및 제한을 고려
- 모니터링 및 추적이 존재 (CloudWatch + X‑Ray)
기본 AWS 문서 (참고용)
- Route 53 – DNS 라우팅 및 상태 검사
- Disaster Recovery on AWS – 설계 패턴 및 모범 사례
- VPC Route Tables – 네트워크 트래픽 흐름
- Application Load Balancer – 레이어‑7 로드 밸런싱
- Auto Scaling (EC2) – 동적 인스턴스 스케일링
- RDS Multi‑AZ – 고가용성 데이터베이스 배포
- RDS Proxy – 서버리스 워크로드를 위한 연결 풀링
- Service Quotas – 제한 및 스케일링 고려 사항
- S3 Replication – 크로스‑리전 객체 내구성
- EBS Snapshots – 시점 복구 볼륨 백업
- EFS Overview – AZ 간 공유 파일 스토리지
- AWS X‑Ray – 분산 추적
- CloudWatch – 메트릭, 로그, 알람
- Amazon Comprehend – 자연어 처리 (선택 사항)
- Amazon Polly – 텍스트‑음성 변환 (선택 사항)