☁️ 영역 2 - 확장 가능하고 느슨하게 결합된 아키텍처 설계
🎯 목표
- 복원력(Resilience) 있는 시스템 설계
- 확장성(Scalability) 확보
- 느슨한 결합(Loose Coupling) 구조 유지
- 장애 발생 시에도 서비스 지속 가능
🔧 1️⃣ 크기 조정(Scaling)의 개념
| 유형 |
설명 |
예시 |
| 수직적 확장 (Vertical Scaling) |
서버의 성능을 향상 (CPU, RAM 업그레이드) |
EC2 인스턴스 타입을 t3.micro → t3.large 로 변경 |
| 수평적 확장 (Horizontal Scaling) |
서버 개수를 늘리거나 줄임 |
Auto Scaling Group에서 인스턴스 수 조절 |
💡 탄력성(Elasticity)
→ 수요 변화에 따라 자동으로 리소스를 확장/축소하는 능력
→ AWS Auto Scaling, EC2 Auto Scaling 활용
⚙️ 2️⃣ 컴퓨팅 옵션 비교
| 유형 |
설명 |
특징 |
| 🧩 EC2 |
가상 인스턴스 |
자유도 높지만 관리 필요 |
| 🐳 컨테이너(ECS / EKS) |
애플리케이션을 컨테이너로 패키징 |
관리형 클러스터, 이식성 우수 |
| ⚡ 서버리스(Lambda) |
서버 관리 불필요 |
짧은 실행, 이벤트 기반 |
💬 상황에 따라 선택:
- 고정된 트래픽 → EC2 + Auto Scaling
- 이벤트 중심, 비정기적 트래픽 → Lambda
- 마이크로서비스 구조 → ECS / EKS
🧠 3️⃣ 데이터베이스 설계
| 서비스 |
유형 |
특징 |
| 💾 Amazon RDS |
관계형 DB |
Multi-AZ로 고가용성 |
| ⚡ Amazon Aurora |
클라우드 네이티브 RDB |
고성능, 자동 복제 |
| 🌐 Amazon DynamoDB |
NoSQL |
짧은 지연 시간, 자동 확장 |
| 🧮 Amazon Redshift |
데이터 웨어하우스 |
대규모 분석용 |
✅ 성능 및 복원력 향상
- 읽기 전용 복제본 (Read Replica) : 읽기 트래픽 분산
- Multi-AZ : 고가용성 (Standby 복제)
- RDS Proxy : 연결 풀링, 복원력 향상
🚀 4️⃣ 캐싱(Cache) 전략
| 서비스 |
역할 |
특징 |
| 🌍 Amazon CloudFront |
글로벌 캐시 CDN |
정적 콘텐츠 전송 |
| 💾 Amazon ElastiCache |
인메모리 캐시 |
Redis / Memcached 지원 |
| ⚙️ DAX (DynamoDB Accelerator) |
DynamoDB 캐시 |
밀리초 응답 시간 |
💡 캐싱은 DB 읽기 부하를 줄이고 응답속도 향상에 핵심 역할
🔒 5️⃣ 엣지 및 전송 서비스
| 서비스 |
기능 |
사용 목적 |
| 🌎 Amazon Route 53 |
DNS 라우팅 |
가용성 및 트래픽 제어 |
| ⚡ AWS Global Accelerator |
TCP/UDP 전송 가속 |
글로벌 성능 최적화 |
| 📦 AWS Transfer Family |
파일 전송 자동화 |
SFTP/FTPS 지원, 서버 관리 불필요 |
🧩 6️⃣ 마이크로서비스 및 분산 시스템 설계
🧱 서비스 지향 아키텍처 (SOA)
- 구성 요소 간 재사용 가능한 서비스 인터페이스 제공
💬 마이크로서비스 아키텍처
- 더 작고 독립적인 서비스 단위
- API 기반 통신 (REST / GraphQL / gRPC)
💬 이점
- 독립적 배포 및 확장 가능
- 장애 격리성 향상
- 빠른 개발 주기
🔄 7️⃣ 동기 vs 비동기 통합
| 유형 |
설명 |
예시 |
| 동기식(Synchronous) |
요청-응답 구조로 실시간 상호작용 필요 |
ALB → EC2, API Gateway → Lambda |
| 비동기식(Asynchronous) |
메시지 큐로 구성요소 간 분리 |
SQS, SNS, EventBridge |
💡 비동기 분리는 장애 시에도 시스템의 나머지 부분이 정상 동작 가능
🧩 8️⃣ 느슨한 결합(Loose Coupling) 구현 서비스
| 서비스 |
역할 |
설명 |
| 📬 Amazon SQS |
메시지 큐 |
컴포넌트 간 비동기 통신 |
| 🔔 Amazon SNS |
알림/이벤트 브로커 |
Fan-out 구조 가능 |
| 🧩 Amazon EventBridge |
이벤트 버스 |
서비스 간 이벤트 기반 통합 |
| 🌀 API Gateway |
마이크로서비스 API 통신 허브 |
Lambda, Fargate 등과 연결 |
🏗️ 9️⃣ 대표 아키텍처 예시 (Mermaid 다이어그램)
🧭1️⃣0️⃣ 설계 시 고려할 주요 서비스
- 🏗 Application Load Balancer (ALB) – 트래픽 분산
- 🐳 AWS Fargate – 서버리스 컨테이너 실행
- ⚙️ Amazon ECS / EKS – 컨테이너 오케스트레이션
- 🔐 AWS Secrets Manager – 자격 증명 및 암호 관리
- 🔄 AWS Lambda – 이벤트 기반 서버리스 컴퓨팅
- 📡 Amazon API Gateway – API 엔드포인트 관리
✅ 핵심 요약
| 핵심 요소 |
주요 포인트 |
| 확장성 (Scalability) |
Auto Scaling, SQS, Lambda 동시성 |
| 느슨한 결합 (Loose Coupling) |
SQS, SNS, EventBridge, ALB |
| 복원력 (Resilience) |
Multi-AZ, Read Replica, 캐시, 장애 격리 |
| 비용 최적화 |
Auto Scaling, 서버리스, S3 Intelligent-Tiering |
🧩 참고 AWS 서비스 맵
- 컴퓨팅: EC2, Lambda, Fargate
- 데이터베이스: RDS, DynamoDB, Aurora
- 스토리지: S3, EFS, FSx
- 네트워킹: ALB, Route 53, Global Accelerator
- 통합/메시징: SQS, SNS, EventBridge
- 보안/관리: Secrets Manager, CloudWatch, CloudTrail
☁️ 영역 2 - 고가용성(HA) 및 내결함성(FT) 아키텍처 설계
🎯 학습 목표
- 고가용성(High Availability), 내결함성(Fault Tolerance), **재해 복구(Disaster Recovery)**의 차이 이해
- AWS 서비스 기반 고가용성 구성 방법 습득
- RTO/RPO 및 DR 전략(Active-Passive / Active-Active) 설계
- 단일 장애 지점(Single Point of Failure, SPOF) 제거
🧱 1️⃣ 고가용성(High Availability, HA)
시스템이 가능한 한 자주 서비스를 **“제공할 수 있는 상태”**를 유지하도록 설계하는 것
🔍 특징
- 장애 발생 시 자동 복구 또는 빠른 교체
- 짧은 가동 중단 시간 허용 가능
- 완전 무중단은 아니지만, 서비스 지속성에 초점
💡 예시
- EC2 인스턴스를 1대만 운영 → 장애 시 서비스 중단
- Auto Scaling + Multi-AZ 배포 구성
→ 한 인스턴스가 중단되면 다른 AZ의 인스턴스로 장애 조치(Failover)
⚙️ 2️⃣ 내결함성(Fault Tolerance, FT)
장애 발생 시에도 서비스가 중단되지 않고 계속 작동하는 설계
🔍 특징
- 장애 발생 시에도 서비스 무중단 유지
- 실시간 장애 감지 및 자동 대체
- 비용은 높지만 가장 높은 복원력(Resilience) 보장
💡 예시
- 두 서버를 모두 활성(Active-Active) 상태로 운영
- 한 서버 장애 시 자동 트래픽 전환
- 사용자는 중단 없이 서비스 이용 가능
🔁 3️⃣ 재해 복구(Disaster Recovery, DR)
예기치 않은 재해(화재, 지진, 시스템 장애) 발생 시 시스템 복원 절차를 설계하는 것
🔍 핵심 요소
| 항목 |
설명 |
| 🕒 RTO (Recovery Time Objective) |
서비스 중단 후 복원까지 허용되는 최대 시간 |
| 📅 RPO (Recovery Point Objective) |
데이터 손실 허용 가능한 최대 시간 (백업 주기 결정) |
💡 DR 전략 유형
| 전략 |
설명 |
비용 |
복구 속도 |
| 🧊 백업 & 복원 (Backup & Restore) |
S3/Glacier에 백업, 필요 시 복원 |
💲 낮음 |
🕒 느림 |
| 🔥 파일럿 라이트 (Pilot Light) |
최소 구성만 유지, 필요 시 전체 확장 |
💲 중간 |
⚡ 보통 |
| 🌡️ 웜 스탠바이 (Warm Standby) |
축소된 형태의 운영 환경 유지 |
💲 중상 |
⚡ 빠름 |
| 💡 액티브-액티브 (Active-Active) |
모든 리전에서 동시에 운영 |
💲 높음 |
⚡⚡ 매우 빠름 |
🌍 4️⃣ AWS 글로벌 인프라와 고가용성 설계
📦 AWS 구성 요소 계층
| 계층 |
설명 |
| 🌐 Region (리전) |
지리적으로 독립된 AWS 인프라 단위 |
| 🧭 Availability Zone (AZ) |
리전 내 독립 전력/네트워크를 가진 데이터센터 |
| 🧱 Edge Location |
CloudFront, Route 53 캐시를 위한 전 세계 엣지 노드 |
💡 Multi-AZ 배포는 AZ 장애 시 자동으로 다른 AZ로 장애 조치
💡 Multi-Region 배포는 리전 전체 장애 시 복구 가능 (Active-Passive / Active-Active)
🔒 5️⃣ 데이터베이스의 HA & DR
| 서비스 |
기능 |
특징 |
| 💾 Amazon RDS (Multi-AZ) |
자동 장애 조치 |
가용성 중심 |
| ⚡ Aurora Global Database |
교차 리전 복제 |
빠른 복구 (1분 미만) |
| 🌐 DynamoDB Global Tables |
리전 간 실시간 동기화 |
내결함성 보장 |
| 🧩 RDS Proxy |
DB 연결 풀링 및 Failover 단축 |
장애 조치 시간 66% 단축 |
🗂️ 6️⃣ 스토리지 및 백업 복원
| 서비스 |
역할 |
특징 |
| 🧱 Amazon S3 |
백업 및 아카이브 |
11 9s(99.999999999%) 내구성 |
| 💾 Amazon EFS / FSx |
파일 스토리지 |
AZ 간 중복 저장 |
| 🧊 S3 Glacier |
장기 보관 |
저비용 백업 |
| 🧩 AWS Elastic Disaster Recovery (DRS) |
온프레미스 ↔ 클라우드 복구 자동화 |
레거시 지원 |
⚙️ 7️⃣ AWS 네트워킹 구성과 복원력
| 서비스 |
역할 |
설명 |
| 🛰️ Route 53 |
DNS 기반 장애 조치 라우팅 |
지연 시간 / 장애 조치 / 가중치 라우팅 지원 |
| ⚡ Global Accelerator |
TCP/UDP 네트워크 성능 가속 |
글로벌 사용자 연결 최적화 |
| 🔀 Transit Gateway |
여러 VPC 간 중앙 라우팅 허브 |
단일 장애 지점 제거 |
| 🔗 Direct Connect / VPN |
온프레미스 연결 |
고속, 안정적 네트워크 통신 |
🧩 8️⃣ 배포 및 복구 자동화 서비스
| 서비스 |
기능 |
| 🌱 AWS CloudFormation |
인프라 자동 복구 및 프로비저닝 |
| ☁️ Elastic Beanstalk |
애플리케이션 자동 배포 및 확장 |
| 🐳 ECS / EKS (컨테이너) |
고가용성 컨테이너 오케스트레이션 |
| 🔄 OpsWorks / CodeDeploy |
구성 관리 및 자동 롤백 |
🧠 9️⃣ 모니터링 & 지속 개선
| 서비스 |
역할 |
| 👁️ Amazon CloudWatch |
지표 수집, 알람, 자동화 트리거 |
| 🔍 AWS X-Ray |
애플리케이션 요청 추적 (분산 추적) |
| 🧠 Amazon Inspector |
취약점 스캔 및 보안 진단 |
| 🤖 Amazon CodeGuru |
코드 품질 분석 및 성능 개선 |
| 🧩 Amazon EventBridge |
실시간 이벤트 기반 자동 대응 |
🗣️ 1️⃣0️⃣ AI 기반 고가용성 활용 예시
| 서비스 |
역할 |
사용 예시 |
| 🗣️ Amazon Polly |
텍스트 → 음성 변환 |
고객센터, 셀프 서비스 음성 안내 |
| 🧠 Amazon Comprehend |
자연어 분석 |
IT 서비스 요청 자동 분류 |
💡 예시: Comprehend로 요청 카테고리 자동 분류 → Polly가 음성으로 안내 → Connect가 셀프 서비스 제공
🧩1️⃣1️⃣고가용성 아키텍처 예시 (Mermaid)
🧾 1️⃣2️⃣ 핵심 요약
| 항목 |
설명 |
| 고가용성(HA) |
장애 발생 시 빠르게 복구하는 시스템 |
| 내결함성(FT) |
장애 발생 중에도 중단 없이 작동 |
| 재해 복구(DR) |
대규모 장애 후 신속한 복원 전략 |
| RTO/RPO |
복구 목표 시간 및 데이터 손실 허용치 |
| 대표 서비스 |
RDS Multi-AZ, Aurora Global DB, Route 53, Global Accelerator, DRS, CloudFormation |
🧭 마무리
고가용성과 내결함성은 AWS Well-Architected Framework의 “신뢰성(Reliability)” 핵심 원칙입니다.
아키텍처 설계 시 다음 3가지를 항상 체크하세요.
1️⃣ 단일 장애 지점 제거 (SPOF)
2️⃣ Multi-AZ / Multi-Region 설계
3️⃣ 자동화된 복구 프로세스 구성
☁️ 영역 2 복습 - 확장 가능하고 복원력 있는 아키텍처 설계
🎯 핵심 목표
- 확장성(Scalability) 과 탄력성(Elasticity) 이해
- 고가용성(High Availability) 과 내결함성(Fault Tolerance) 차이 구분
- AWS 글로벌 인프라 기반 복원력 설계
- 재해 복구(Disaster Recovery, DR) 전략 이해
- 워크로드 모니터링 & 자가 복구 환경 구축
🚀 1️⃣ AWS 클라우드의 핵심 이점
| 항목 |
설명 |
| 🧠 용량 추측 불필요 |
필요한 만큼 자동 확장 / 축소 |
| 💰 비용 효율성 |
사용한 만큼만 지불 (Pay-as-you-go) |
| ⚙️ 자동화된 확장성 |
Auto Scaling / Elastic Load Balancing |
| 🌎 글로벌 인프라 |
다중 AZ & 다중 리전 기반 복원력 |
🧩 2️⃣ 고가용성(HA) vs 내결함성(FT)
| 구분 |
고가용성 (High Availability) |
내결함성 (Fault Tolerance) |
| 🧱 정의 |
장애 발생 시 빠르게 복구하여 서비스 지속 |
장애 발생 중에도 시스템이 중단 없이 동작 |
| ⏱ 중단 시간 |
약간의 중단 허용 |
무중단 (Zero downtime) |
| 💰 비용 |
중간 |
높음 |
| ⚙️ 예시 |
Multi-AZ RDS, Auto Scaling, ALB |
Active-Active Aurora Global DB |
🧭 3️⃣ AWS 글로벌 인프라 활용
| 계층 |
설명 |
| 🌐 Region |
지리적으로 분리된 AWS 데이터센터 그룹 |
| 🏢 Availability Zone (AZ) |
독립된 전원·네트워크를 가진 가용 단위 |
| 📍 Edge Location |
CloudFront, Route 53 등 엣지 네트워크 |
💡 Multi-AZ + Multi-Region 설계는
서버, 스토리지, DB 장애에도 중단 없는 서비스를 제공하도록 돕습니다.
⚙️ 4️⃣ 자가 복구(Self-Healing) 환경을 위한 핵심 서비스
| 서비스 |
역할 |
| ⚖️ Elastic Load Balancing (ELB) |
여러 인스턴스 간 트래픽 분산 및 장애 감지 |
| 📈 Amazon EC2 Auto Scaling |
인스턴스 자동 추가/제거, 비정상 인스턴스 교체 |
| 🛰️ Route 53 (Failover Routing) |
리전 단위 장애 발생 시 다른 리전으로 트래픽 전환 |
| 🌍 AWS Global Accelerator |
TCP/UDP 트래픽 지연 최소화 및 글로벌 복원력 향상 |
🔁 5️⃣ 재해 복구(Disaster Recovery) 전략 비교
| 전략 |
설명 |
비용 💰 |
복구 속도 ⚡ |
| 🧊 백업 & 복원 |
S3, Glacier에 백업 후 필요 시 복원 |
낮음 |
느림 |
| 🔥 파일럿 라이트 |
핵심 구성만 유지 후 필요 시 확장 |
중간 |
보통 |
| 🌡️ 웜 스탠바이 |
축소된 프로덕션 환경 유지 |
중상 |
빠름 |
| 💡 액티브-액티브 |
모든 리전 동시 운영 |
높음 |
매우 빠름 |
💡 RTO(복구시간목표) & RPO(복구시점목표)를 기준으로 선택해야 함.
🧠 6️⃣ AWS 서비스별 복원력 내장 기능
| 서비스 |
내장 복원력 기능 |
사용 예시 |
| 💻 EC2 Auto Scaling |
인스턴스 자동 교체 / 증감 |
트래픽 급증 시 수평 확장 |
| ⚖️ Elastic Load Balancer |
트래픽 자동 분산 |
웹 서버 장애 시 자동 우회 |
| 🧾 RDS Multi-AZ |
자동 장애 조치(Failover) |
DB 가용성 확보 |
| ⚡ Aurora Global DB |
교차 리전 복제 |
리전 장애 대비 |
| 📬 SQS / SNS / EventBridge |
비동기 메시징 |
서비스 간 결합도 최소화 |
| 🐳 ECS / Fargate |
자동 리스타트, 헬스체크 |
컨테이너 복원력 |
| 🧠 Lambda |
서버리스 확장성 |
짧은 처리 이벤트 기반 애플리케이션 |
🧱 7️⃣ 상태(State) 관리 전략
| 유형 |
설명 |
예시 |
| ⚙️ Stateless (비상태) |
인스턴스 교체 시 데이터 의존 없음 |
웹 서버, Lambda 함수 |
| 💾 Stateful (상태 유지) |
인스턴스에 데이터 저장 |
RDS, EFS, 세션 유지 |
💡 Stateless 아키텍처는 확장성과 복원력 측면에서 유리
💡 Stateful 컨테이너는 EFS, FSx 등 외부 스토리지 연결로 해결 가능
🧰 8️⃣ 세션 관리와 로드 밸런싱
- Application Load Balancer (ALB) 기본 라우팅 → 요청을 무작위로 배분
- 스티키 세션(Sticky Session) → 사용자를 특정 인스턴스에 고정
- 세션 유지가 필요한 로그인 기반 애플리케이션에 유용
- 단, 인스턴스 장애 시 세션 손실 위험 있음
⚡ 9️⃣ 캐싱 & 읽기 부하 분산 전략
| 서비스 |
역할 |
특징 |
| 🧠 Amazon ElastiCache (Redis/Memcached) |
데이터 캐싱 |
DB 쿼리 부하 감소 |
| ⚡ DynamoDB Accelerator (DAX) |
NoSQL 캐시 |
밀리초 응답 시간 |
| 🧩 RDS Read Replica |
읽기 부하 분산 |
읽기 성능 향상 (복제 기반) |
💡 캐싱은 지연 시간 단축 + 비용 절감 + DB 부하 감소의 핵심 전략
🔍1️⃣0️⃣ 모니터링 & 가시성 확보
| 서비스 |
기능 |
설명 |
| 👁️ Amazon CloudWatch |
지표 수집 & 알람 |
인스턴스/서비스 상태 모니터링 |
| 🕵️ AWS X-Ray |
분산 추적 |
요청 흐름 분석 및 병목 탐지 |
💡 CloudWatch 알람 + Auto Scaling 정책 = 자가 복구(Self-healing) 시스템 구축
🧩 1️⃣1️⃣ 복원력 있는 아키텍처 예시
✅ 1️⃣2️⃣ 핵심 정리 요약
| 핵심 주제 |
주요 포인트 |
| 확장성 (Scalability) |
Auto Scaling, Load Balancing |
| 복원력 (Resilience) |
Multi-AZ, Multi-Region, Self-Healing |
| 고가용성 (HA) |
장애 발생 시 빠른 복구 |
| 내결함성 (FT) |
장애 중에도 서비스 지속 |
| 재해 복구 (DR) |
Backup & Restore, Pilot Light, Warm Standby |
| 모니터링 |
CloudWatch, X-Ray |
| 비동기 분리 |
SQS, SNS, EventBridge |
| 상태 관리 |
Stateless 아키텍처 + EFS 통합 |
| 캐시 활용 |
ElastiCache, DAX, Read Replica |
🧭 마무리
- AWS 클라우드의 자동 확장 + 복원력 + 관리형 서비스 조합은
기존 인프라 대비 가용성과 효율성을 극대화합니다.
- 시험에서는 다음과 같은 포인트를 명확히 구분해야 합니다.
1️⃣ Auto Scaling vs Elastic Load Balancing
2️⃣ Stateless vs Stateful
3️⃣ RDS Multi-AZ vs Read Replica
4️⃣ Route 53 Failover vs Global Accelerator
