Cloud 인프라 설계 및 가용성 아키텍처 학습은 단순히 서비스 배포가 아닌 **"신뢰성 있는 클라우드 기반 시스템 구축"**을 목표로 해야 하며, 아래와 같이 체계적으로 진행하는 것이 좋습니다.
✅ 1단계: 기본 개념 정리
☁️ 클라우드 인프라 기초
- IaaS / PaaS / SaaS 구분
- Public / Private / Hybrid / Multi-Cloud 개념
- 대표 서비스: AWS / Azure / GCP 구성요소 (EC2, VPC, S3 등)
📌 추천 학습 포인트
- Cloud VM, Storage, Load Balancer, NAT, DNS, VPC 등 개념과 역할
- 클라우드의 리소스 구성 단위 (Region, Zone, Resource Group) 이해
✅ 2단계: 아키텍처 설계 원칙 학습
🏗️ 클라우드 인프라 설계 5대 원칙 (예: AWS Well-Architected Framework)
- 가용성 (Availability) – 다중 AZ 구성, ELB, Auto Scaling
- 신뢰성 (Reliability) – 실패 복구, 백업, 장애 격리
- 보안성 (Security) – IAM, 보안그룹, 네트워크 ACL
- 비용 최적화 (Cost Optimization) – 리소스 효율, 예약 인스턴스
- 운영 효율성 (Operational Excellence) – 모니터링, 자동화, IaC
📌 학습 방향
- 클라우드 전용 아키텍처 설계 패턴
- 모놀리식 → 마이크로서비스 구조로 전환 시 고려사항
✅ 3단계: 사용자 요구 기반 가용성 설계
🧩 핵심 키워드
- SLA / SLO / SLI
- RTO / RPO 기반 이중화 구조
- Single Point of Failure 제거
- Failover, Load Balancing, DR 설계
예시 시나리오
- 사용자 요구: "99.99% 가용성, 장애시 5분 내 복구, 1시간 이내 데이터 복구"
- → 설계 대응:
- Multi-AZ 배포
- RDS 복제 및 백업 설정
- Auto Healing + ELB + ASG
✅ 4단계: 실무 설계 사례 학습
- Azure 기반 설계 시 Resource Group, Availability Zone, Recovery Vault 설계
- AWS 기반 설계 시 VPC subnet 구성, Multi-AZ, Route53 설정
- WAS + DB 이중화 구성 (e.g., Web → App → DB 구조, DR 포함)
- 장애 복구 시나리오: DB Failover, Web 서비스 롤백, 스토리지 장애 대응
✅ 5단계: 실전 문제 풀이 및 시나리오
- 장애 대응 기반 문제집 (가용성, 이중화, DR 시나리오 중심)
- 실무 기반 설계 문서 분석 및 설계도 도식화 훈련
- 가용성 보장을 위한 테스트 계획 수립 (Chaos Engineering 포함)
📚 참고자료
- AWS Well-Architected Framework / Azure Architecture Center
- [KT, LGU+, SKT 사례 기반 클라우드 구축 사례 분석]
- Kubernetes 기반 HA 구성 사례
- Terraform / ARM Template 기반 인프라 코드 실습
필요 시 다음 요청 예시
- “클라우드 가용성 설계 문제집 만들어줘”
- “RTO/RPO 기반 DR 구성 시나리오 문제 10개”
- “Azure 기반 다중존 설계 사례 요약해줘”
- “오픈북용 인프라 키워드 인덱스 정리해줘”
☁️ 클라우드 인프라 구성요소 + 가용성 아키텍처 개요
✅ 1. 클라우드 인프라 구성요소
🏢 1.1 리전(Region) / 가용 영역(Availability Zone, AZ)
| Region | 전 세계 물리적 데이터센터 집합 (예: korea-central) |
| Availability Zone (AZ) | 리전 내 독립된 전력/네트워크를 가진 데이터센터 (장애 격리 단위) |
| Multi-AZ | 여러 AZ에 자원을 배포하여 장애 발생 시 서비스 지속성 확보 |
📌 TA 관점: 고가용성 설계를 위해 리전 내 최소 2개 이상의 AZ를 사용해야 함
🌐 1.2 네트워크 구성 요소
| VPC (Virtual Private Cloud) | 사용자 전용 네트워크, 서브넷으로 분리 |
| Subnet (Public/Private) | 서비스 목적에 따른 분리: Public은 LB, Private은 DB |
| NAT Gateway | Private Subnet → 외부 인터넷 통신 가능 |
| Internet Gateway (IGW) | Public Subnet 인터넷 연결을 위해 사용 |
| Route Table | 패킷 전달 경로 정의 |
| Security Group / NSG | 인바운드/아웃바운드 트래픽 필터링 |
| Load Balancer (LB) | 트래픽 분산, 장애 시 자동 분산 지원 (ALB, NLB 등) |
💻 1.3 컴퓨팅/스토리지/데이터베이스
| VM / Instance | EC2, Azure VM 등 가상서버 |
| Auto Scaling Group (ASG) | 트래픽 증가 시 자동 확장, 실패 시 자동 복구 |
| Object Storage (Blob/S3) | 비정형 데이터 저장, 무제한 확장 가능 |
| Block Storage (EBS/Disk) | VM에 연결되는 디스크 스토리지 |
| DBaaS (RDS/Azure SQL) | 관리형 DB, 자동 백업/이중화 지원 |
| Backup/Recovery Vault | 정책 기반 백업 스케줄링 및 복구 기능 |
🛠 1.4 기타 핵심 인프라 요소
| IAM | 사용자별 권한 제어 (RBAC/ABAC) |
| Monitoring | CloudWatch, Azure Monitor |
| Bastion Host / Jump Box | 보안용 접근 통제 VM |
| Infrastructure as Code | Terraform, ARM Template, Bicep |
✅ 2. 가용성(Availability) 아키텍처 개요
📌 2.1 고가용성(HA) 정의
시스템 또는 서비스가 지속적으로 사용 가능하도록 설계하는 것
- SLA (Service Level Agreement): 제공자 ↔ 사용자 간 보장되는 가용성 수치 (예: 99.9%)
- SLO / SLI: 내부 운영 기준
🧩 2.2 핵심 설계 요소
| 이중화(Redundancy) | 컴퓨팅, DB, 네트워크 구성요소에 대한 이중 구성 |
| Failover 구성 | Active-Passive, Active-Active 구성 |
| Auto Healing | 장애 발생 시 자동 복구 메커니즘 |
| DR(재해복구) | Region/AZ 전체 장애에 대비한 복구 계획 수립 |
| RTO/RPO 설계 | 복구시간 목표 / 복구시점 목표에 따른 백업정책 |
🔁 2.3 아키텍처 예시
✅ 웹서비스 고가용성 설계 예
장애 시 동작:
- App 서버 인스턴스 장애: Auto Healing 재생성
- AZ 장애: LB가 다른 AZ로 트래픽 분산
- DB 장애: RDS Failover to Standby
✅ 3. 사용자 요구 기반 설계 대응 예시
| 99.99% 가용성 보장 | Multi-AZ + LB + Auto Scaling + DB 이중화 |
| 장애 발생 시 10분 내 복구 | Auto Healing + Health Probe + 빠른 RTO |
| 1시간 이내 데이터 복구 | 정기 Snapshot, 백업 정책(RPO ≤ 1hr) |
| 보안 요구 강화 | Private Subnet, Bastion, SG/NSG 강화, IAM Least Privilege |
| 비용 고려 | Spot Instance, Reserved Instance, 규모에 맞는 ASG 정책 |
✅ 4. TA 관점 실전 팁
| SPoF 제거 | 단일 장애점 분석 및 제거 |
| 계층별 이중화 | LB/App/DB/Storage/Network 전 계층 고려 |
| Multi-AZ/Multi-Region | 재해복구 및 SLA 대응 |
| IaC 도입 | 아키텍처 재현성 확보 |
| 모니터링 + 자동화 | 장애 예측 및 대응 효율성 |
필요하시면 다음 자료도 이어서 제공할 수 있습니다:
- 문제집: 실무 시나리오 기반 고가용성 설계 문제 20~30제
- 암기카드: 인프라 요소별 키워드 요약
- 블로그용 키워드 인덱스 요약본
- Azure 기반 가용성 설계 시나리오
- RTO/RPO 기반 백업 설계 문제집
📘 실무 시나리오 기반 고가용성 설계 문제집 (30문항)
✅ NO.01
[난이도: 하]
한 웹서비스가 단일 AZ에만 모든 자원을 배치한 경우, 장애 발생 시 가장 취약한 부분은?
A. 네트워크 대역폭
B. Auto Scaling 정책
C. AZ 자체 장애
D. DNS TTL 설정
정답: C
해설: 단일 AZ 구성은 Availability Zone 전체 장애에 매우 취약함.
✅ NO.02
[난이도: 중]
서비스 중인 DB 인스턴스에 대해 RTO 5분, RPO 1시간 요구사항이 주어졌다. 적절한 구성은?
A. DB Snapshot 하루 1회
B. Multi-AZ 구성 + 자동 백업
C. DB Read Replica
D. Single AZ 구성 + RAID
정답: B
해설: Multi-AZ 구성은 장애 시 자동 Failover, 백업은 RPO 보장 목적.
✅ NO.03
[난이도: 중]
고객사 요구로 99.95% SLA를 충족해야 한다. 가장 적절한 구성은?
A. 단일 리전에 2개 인스턴스 구성
B. 서로 다른 AZ에 인스턴스를 분산
C. 단일 VM 고사양 구성
D. CDN 구성
정답: B
해설: SLA 99.95%를 만족하려면 AZ 분산이 필수.
✅ NO.04
[난이도: 상]
다음 중 Auto Scaling Group 설정 오류로 인해 가용성이 낮아질 수 있는 경우는?
A. Health Check Type을 ELB가 아닌 EC2로 설정
B. Launch Template에서 인스턴스 유형 지정
C. Desired Count보다 Min Count가 낮음
D. CloudWatch Metric 설정
정답: A
해설: Health check가 EC2이면 애플리케이션 장애를 감지하지 못함.
✅ NO.05
[난이도: 중]
DB 복구시간 목표(RTO)를 3분으로 설정했을 때 적절한 전략은?
A. 스냅샷 기반 수동 복구
B. 스토리지 계층의 복제
C. Multi-AZ DB 구성
D. DB Dump 수동 적용
정답: C
해설: Multi-AZ는 장애 발생 시 수분 내 자동 Failover가 가능.
✅ NO.06
[난이도: 하]
다중 지역(Multi-Region) 구성을 채택하는 주된 이유는?
A. 비용 절감
B. 장애 시 재해복구
C. 네트워크 성능 향상
D. 데이터 암호화
정답: B
해설: Multi-Region은 대규모 재해 상황 대비용.
✅ NO.07
[난이도: 중]
Azure에서 App Service의 고가용성을 위한 기본 구성 요소는?
A. 수동 백업
B. Traffic Manager와 다중 지역 배포
C. Azure Key Vault
D. Single Region 구성
정답: B
해설: Azure Traffic Manager를 통해 다중 지역 배포로 가용성 확보.
✅ NO.08
[난이도: 상]
웹서버가 5초 이내 응답하지 않으면 LB가 요청을 다른 인스턴스로 분산해야 한다. 설정해야 할 항목은?
A. Sticky Session
B. Listener Timeout
C. Health Check Timeout
D. HTTP Redirect
정답: C
해설: Health Check 응답이 없는 경우 Failover 대상에서 제외됨.
✅ NO.09
[난이도: 중]
RPO를 0분으로 설정하려는 서비스의 적절한 아키텍처는?
A. 정기적 백업 스케줄링
B. 동기식 복제 기반 이중화
C. 비동기식 복제
D. 백업 → S3 업로드
정답: B
해설: RPO = 0은 실시간 동기 복제를 의미함.
✅ NO.10
[난이도: 상]
이중화된 DB 환경에서 비동기식 복제를 사용할 경우 주의해야 할 점은?
A. 쓰기 지연
B. 데이터 손실 가능성
C. 비용 증가
D. 백업 불가
정답: B
해설: 비동기 복제는 장애 발생 시 마지막 복제본과 차이로 인한 데이터 손실 가능성 존재.
✅ NO.11
[난이도: 중]
Auto Scaling이 작동하지 않는 원인이 Health Check 미설정으로 추정된다. 우선 확인해야 할 것은?
A. CPU 사용률
B. LB와 연결 여부
C. Security Group 포트
D. 리전 상태
정답: B
해설: LB 연동 없이 ASG는 인스턴스 상태를 파악할 수 없음.
✅ NO.12
[난이도: 중]
서비스 운영 중 일부 사용자 요청이 지연되고 있다. AZ 단위 장애는 아니며, 한 인스턴스에만 영향이 있다면 적절한 조치는?
A. 전체 서비스 재시작
B. 해당 인스턴스를 Auto Healing으로 교체
C. 리전 재배포
D. DB Failover 수행
정답: B
해설: Auto Healing이 인스턴스 단위 장애에 대응 가능.
✅ NO.13
[난이도: 중]
아래 중 SPoF(Single Point of Failure)를 야기할 수 있는 구성은?
A. 이중화 LB 구성
B. DB Master-Slave 복제
C. 단일 Bastion Host
D. DNS 이중화
정답: C
해설: Bastion Host가 단일일 경우 해당 장비 장애 시 전체 접속 차단됨.
✅ NO.14
[난이도: 하]
가용성(Availability)을 높이기 위한 가장 기본적인 접근은?
A. VM 스펙 업그레이드
B. 멀티 리전 구성
C. 이중화 구성
D. 암호화 정책 강화
정답: C
해설: 이중화는 가용성 확보의 핵심 기법.
✅ NO.15
[난이도: 상]
로드밸런서 구성 시 사용자가 항상 같은 인스턴스에 연결되도록 설정하려면?
A. Health Check
B. Connection Draining
C. Sticky Session
D. SSL Offloading
정답: C
해설: Sticky Session은 사용자 요청을 동일 인스턴스로 라우팅함.
✅ NO.16
[난이도: 중]
DNS 구성 시 트래픽 장애를 최소화하고 빠른 전환을 유도하기 위한 설정은?
A. TTL 값을 높게 설정
B. DNS 레코드를 CNAME으로 구성
C. TTL 값을 짧게 설정
D. DNSSEC 활성화
정답: C
해설: TTL(Time to Live)이 짧아야 장애 시 빠른 IP 갱신 및 전환이 가능.
✅ NO.17
[난이도: 상]
Web + App + DB 3계층 구조에서 App 서버를 무중단으로 교체하려면?
A. 서버를 순차적으로 전원 끄고 교체
B. LB에서 해당 인스턴스를 일시 제외하고 교체
C. DB를 먼저 정지하고 교체
D. App 서버에 SSH 연결하여 직접 교체
정답: B
해설: LB에서 트래픽 분리를 먼저 수행한 뒤 교체해야 무중단 유지 가능.
✅ NO.18
[난이도: 중]
Azure에서 가용성을 위한 배포 전략으로 옳은 것은?
A. Availability Set은 리전 간 배포를 지원한다.
B. Availability Zone은 물리적 장애에 강하다.
C. Resource Group 단위로 고가용성 설정한다.
D. Bastion Host를 각 VM에 설치한다.
정답: B
해설: AZ는 각기 다른 전력, 네트워크를 가진 장애격리 영역이다.
✅ NO.19
[난이도: 중]
다음 중 가용성 높은 아키텍처 설계의 기준 요소가 아닌 것은?
A. 최소 컴퓨팅 자원
B. 단일 장애점 제거
C. RTO/RPO 설정
D. 수평 확장 지원
정답: A
해설: 자원 최소화는 비용 최적화 관점이지 고가용성과 직접 연관은 없다.
✅ NO.20
[난이도: 하]
클라우드 LB에서 기본적으로 수행하는 동작은?
A. 저장소 압축
B. 패킷 캡처
C. 트래픽 분산
D. 사용자 인증
정답: C
해설: LB의 핵심 기능은 트래픽 부하 분산.
✅ NO.21
[난이도: 상]
Auto Scaling 시 VM의 기동 시간이 5분 이상 소요된다. 갑작스런 트래픽 급증 시 대응 방안으로 적절한 것은?
A. On-demand VM 예약
B. Warm Pool 설정
C. Spot Instance 대체
D. VM 스펙 축소
정답: B
해설: Warm Pool은 미리 기동된 인스턴스를 대기 상태로 두어 빠른 확장을 지원함.
✅ NO.22
[난이도: 중]
DB 이중화 구성 시 Failover 후 클라이언트 연결이 안 되는 경우, 가장 먼저 확인할 것은?
A. DB Index
B. 보안 그룹
C. Endpoint 라우팅
D. VM 로그
정답: C
해설: Failover 후 새로운 Primary로의 라우팅이 정상적으로 설정되었는지 확인 필요.
✅ NO.23
[난이도: 중]
웹서비스의 로그 수집이 실패했는데, 로그 수집 에이전트가 단일 서버에만 존재할 경우 가장 큰 문제점은?
A. 로그 형식 불일치
B. 암호화 설정 누락
C. 단일 장애점(SPoF)
D. 로그 레벨 오류
정답: C
해설: 로그 수집 서버의 이중화가 없으면 장애 발생 시 전체 로그 수집 실패.
✅ NO.24
[난이도: 하]
가용성을 높이기 위한 서브넷 구성 전략으로 적절한 것은?
A. 모든 자원을 Public Subnet에 배치
B. 모든 AZ에 동일한 서브넷 구성
C. DB는 Public Subnet에 배치
D. 모든 트래픽을 하나의 NAT Gateway로 전환
정답: B
해설: AZ마다 동일한 구성의 Subnet을 구성하여 장애 발생 시 빠른 전환이 가능.
✅ NO.25
[난이도: 중]
고가용성을 위해 동일 리전 내 서로 다른 AZ에 DB를 배포할 경우 중요한 조건은?
A. 서브넷 IP가 동일해야 함
B. DB 동기화 방식 결정
C. LB가 필요 없음
D. 암호화 설정은 무조건 필요 없음
정답: B
해설: 동기 vs 비동기 복제 여부는 데이터 손실 가능성과 가용성에 영향을 줌.
✅ NO.26
[난이도: 상]
다음 중 고가용성과 재해복구(HA/DR) 모두를 고려한 아키텍처 요소로 옳은 것은?
A. Auto Scaling Group만 구성
B. Multi-AZ 구성
C. Multi-Region + Global DNS 구성
D. 백업을 Local에만 저장
정답: C
해설: DR을 고려하려면 Region 자체 이중화 + DNS 기반 라우팅이 필요함.
✅ NO.27
[난이도: 중]
서비스 구성도에 LB → App → DB 구조에서 LB와 App 사이의 고가용성을 고려할 때 확인할 사항은?
A. DB 스키마
B. TLS 버전
C. Health Check 설정
D. DNS TTL
정답: C
해설: LB가 App 상태를 체크하여 비정상 인스턴스를 자동 제외해야 함.
✅ NO.28
[난이도: 상]
Azure에서 Availability Set과 Availability Zone의 차이는?
A. 둘 다 리전 간 구성
B. 둘 다 동일 장애 도메인
C. Availability Zone은 데이터센터 간 이격
D. Availability Set은 비용이 높음
정답: C
해설: AZ는 물리적으로 다른 전력/네트워크 구조의 DC에 위치함.
✅ NO.29
[난이도: 하]
고가용성 확보를 위한 기본 원칙으로 적절한 것은?
A. 모든 자원은 최소화
B. 암호화를 최대화
C. 수평적 확장성 고려
D. DB 단일 구성
정답: C
해설: 수평적 확장은 서비스 중단 없이 확장이 가능함.
✅ NO.30
[난이도: 중]
가용성을 위한 인프라 설계 시, 정기점검 중에도 서비스가 중단되지 않도록 구성하는 전략은?
A. 점검 시 전체 리소스 종료
B. Blue-Green Deployment
C. Sticky Session 제거
D. DB 단일화
정답: B
해설: Blue-Green 방식은 운영 중인 시스템과 별도로 새 환경을 구성하여 무중단 배포 지원.
📒 고가용성 설계 암기카드 요약 (Flashcards)
☁️ 클라우드 인프라 & 가용성 구성 요소
- Availability Zone (AZ) – 리전 내 독립된 장애격리 단위
- Multi-AZ 구성 – 가용성 확보 위한 기본 설계 (AZ 간 분산)
- Multi-Region 구성 – 재해복구 목적의 지역 이중화
- SPoF (Single Point of Failure) – 단일 장애 지점, 반드시 제거 대상
- RTO (복구 시간 목표) – 장애 발생 후 복구까지 소요 허용 시간
- RPO (복구 시점 목표) – 장애 발생 시 복구 가능한 데이터 시점 기준
🛠 고가용성 설계 핵심 기법
- 이중화 구성 – LB, VM, DB, NAT 등 모든 계층에 이중화 적용
- Auto Scaling – 수요에 따라 인스턴스 자동 확장/복구
- Health Check – 비정상 인스턴스 제거를 위한 상태 점검
- Sticky Session – 사용자를 동일 인스턴스로 지속 연결
- Blue-Green Deployment – 무중단 배포를 위한 이중 환경 구성
- Warm Pool – 미리 기동된 인스턴스를 통해 빠른 확장 대응
🔐 네트워크/보안 및 DNS
- TTL 설정 – DNS 전환 속도에 직접 영향 (짧게 설정 시 빠른 전환 가능)
- Security Group(NSG) – 네트워크 접근 제어, LB/VM 계층마다 적용
- Bastion Host 이중화 – 원격 접속 지점의 단일 장애 제거
💽 DB 및 스토리지
- Multi-AZ DB (동기식 복제) – 장애 시 자동 Failover, RPO ≒ 0
- Read Replica (비동기식) – 읽기 부하 분산, 일부 데이터 유실 가능
- Endpoint 기반 Failover – DB 전환 시 클라이언트 라우팅 필수
- Log Collector 이중화 – 운영/보안 로그 수집 장애 예방
📊 실전 설계 고려 요소
- 수평 확장성 (Scalability) – 서비스 중단 없이 확장 가능
- 정기 점검 시 무중단 전략 – Blue-Green 또는 Rolling 배포 방식
- Health Check → Auto Healing → Replace – 단일 VM 장애 대응 흐름
- Global DNS + Multi-Region – 지역 장애 시에도 글로벌 트래픽 유지
- Failover 시 장애 인지 – Health Check or Monitor 기반 알림/대응
🧠 상황별 판단 기준 요약
| RPO = 0 요구 | 동기식 복제 필수 |
| 빠른 복구 (RTO ≤ 5분) | Auto Healing + Multi-AZ + Warm Pool |
| 인스턴스 응답 없음 | Health Check 미반응 → 제거 → 대체 |
| 클라이언트 연결 불가 | Failover 후 Endpoint 라우팅 확인 필요 |
| 점검 중 무중단 필요 | Blue-Green Deployment 구성 |
[ 사용자 ]
│
┌──────────────┐
│ Azure Front Door│
└────┬──────┬──┘
↓ ↓
┌────────────┐ ┌────────────┐
│ Region1 │ │ Region2 │ ← DR 구성
└────┬──┬────┘ └────┬──┬────┘
↓ ↓ ↓ ↓
[Zone1][Zone2] [Zone1][Zone2]
↓ ↓ ↓ ↓
[App1][App2] [App3][App4]
↓ ↓ ↓ ↓
[DB P][DB S] [DB P][DB S]
좋습니다! 아래는 Azure 기반 다중존(Availability Zone, AZ) 설계 사례 요약입니다.
TA(Technical Architect) 관점에서 실무 적용 가능한 구조를 구성도 + 설계 포인트 + 주요 서비스로 정리했으며, 오픈북/블로그용 요약으로도 활용할 수 있게 구성했습니다.
☁️ Azure 기반 다중존 설계 사례 요약
✅ 1. 설계 목적
"AZ 단위 장애에도 중단 없이 서비스를 제공하는 고가용성 인프라 구성"
- SLA 보장 (예: 99.99%)
- 자동 복구, 자동 확장, 트래픽 분산
- RTO/RPO 요건 충족
✅ 2. Azure 다중존 기본 구성도
✅ 3. 설계 주요 포인트
🏗️ 1) 네트워크 계층
| Azure Front Door | 글로벌 로드 밸런싱 + HTTPS 오프로드 + Health Probe |
| Azure Load Balancer (Zonal) | 각 AZ 내 VM 간 로드 밸런싱 |
| VNet/Subnet 구성 | 각 AZ마다 분리된 서브넷 구성 (Zone-aware) |
| Private Link 사용 권장 | 내부 서비스 접근용, 보안 강화 |
💻 2) 컴퓨팅 계층
| VMSS (Virtual Machine Scale Set) | 다중 AZ 배포 + 자동 확장 가능 |
| Azure App Service (Zone-redundant 지원) | P3 이상 SKU에서 AZ 배포 가능 |
| Availability Zone-aware 배포 | VM 또는 App을 명시적으로 Zone에 배포 |
📌 권장 구성: 동일 Region 내 Zone1/2/3에 App 배치, Scale Set으로 관리
💾 3) 데이터 계층
| Azure SQL Database (Zone-redundant) | Premium/Business-critical Tier에서 ZRS 제공 |
| Azure Database for PostgreSQL / MySQL (Flexible Server) | HA 설정 시 Zone 이중화 구성 가능 |
| Azure Cosmos DB | 멀티-AZ, 멀티-Region 활성화 가능 |
| Azure Storage ZRS (Zone Redundant Storage) | 블롭, 파일 등 객체 데이터의 자동 3AZ 복제 |
🔁 4) 복구 및 가용성
| Azure Site Recovery | Region 간 DR 구성용, VM/DB 복제 가능 |
| Azure Backup | VM, SQL, Files 등 백업 정책 관리 |
| RTO/RPO 기반 구성 | RTO 짧을수록 ZRS + 자동 Failover 필수 |
| Zone-aware Routing | 트래픽이 정상 Zone으로 유도되도록 설정 필요 |
✅ 4. 실제 적용 시나리오
☑️ 시나리오 1: 웹 포탈 서비스 고가용성 구성
- Front Door → VMSS + LB (Zone 1/2/3) → Azure SQL Zone-redundant
- 이점: 웹 트래픽을 전 세계에서 수신 가능, AZ 장애 시에도 무중단 서비스 가능
☑️ 시나리오 2: 금융 API 시스템
- App Service Premium (Zone Enabled)
- Flexible Server DB (HA on + Zone Redundant)
- Storage: ZRS + Geo-backup
결과: 금융거래 API의 중단 없이 고가용성 및 데이터 일관성 유지
✅ 5. 고가용성 구성 시 유의사항
| 비용 증가 | AZ간 트래픽 비용 및 복제 비용 발생 |
| 리전마다 AZ 개수 상이 | 일부 리전은 3개 AZ 미만일 수 있음 |
| Zone-aware 서비스만 사용 | 일부 구형 서비스는 AZ 미지원 |
| 성능 분산 고려 | DB Write Master는 단일 Zone일 수 있음 (지연 발생 가능) |
✅ 6. 키워드 요약 (Ctrl+F 검색용)
- Azure Front Door, Zone Redundant, VMSS, ZRS, Flexible Server,
Site Recovery, Zone-aware, App Service Premium, Global Load Balancing
✅ 7. 요약 정리 (시험/블로그용)
| 네트워크 계층 | Azure Front Door + LB (Zonal) |
| 컴퓨팅 계층 | VMSS (Zone-aware), App Service Premium |
| DB 계층 | SQL DB ZRS, Flexible Server HA, CosmosDB |
| 스토리지 계층 | Azure Storage ZRS |
| 백업/DR | Azure Backup + Site Recovery |
| 실전 적용 | 웹서비스, 금융API, 내부 포털, 운영툴 등 |
📘 Azure 고가용성(HA) 사례 기반 문제집 (총 20문항)
✅ NO.01
[객관식 / 난이도: 하]
Azure Availability Zone의 주된 목적은?
A. 리전 간 데이터 전송
B. 전력/네트워크 분리된 장애 격리
C. 동일 서브넷 내 IP 분산
D. 비용 절감을 위한 자원 축소
정답: B
해설: Availability Zone은 물리적 격리를 통해 고가용성을 보장한다.
✅ NO.02
[단답형 / 난이도: 중]
Azure에서 App Service를 고가용성으로 배포하고자 한다. 어떤 App Service 요금제를 선택해야 하는가?
정답: Premium P1 이상
해설: App Service는 Premium 요금제부터 Zone Redundant 구성을 지원함.
✅ NO.03
[객관식 / 난이도: 중]
Azure에서 다중존 구성을 위해 명시적으로 Zone을 지정하여 배포할 수 있는 리소스는?
A. Azure SQL Database
B. App Service Standard
C. Virtual Machine
D. Storage Account
정답: C
해설: VM은 Zone-aware 리소스로 명시적 Zone 지정 가능함.
✅ NO.04
[시나리오형 / 난이도: 상]
한 금융 서비스가 Azure Region 내 Zone 1에만 App과 DB를 구성하였다. Zone 1에 정전이 발생했다.
이 서비스의 가용성 문제를 해결하기 위한 근본적 조치는?
정답: App과 DB를 다중 Zone에 분산 구성
해설: 단일 Zone 구성은 AZ 장애 시 전체 서비스 중단 유발 → 다중 Zone 분산 필요.
✅ NO.05
[객관식 / 난이도: 중]
Azure SQL Database에서 Zone Redundant 구성을 위해 선택해야 하는 가격 티어는?
A. Basic
B. Standard
C. Premium or Business-critical
D. Free
정답: C
해설: Premium 및 Business-critical 티어에서 ZRS 옵션 제공됨.
✅ NO.06
[객관식 / 난이도: 중]
Azure Storage 계층 중 AZ 장애 시에도 데이터 유실 없이 제공 가능한 계층은?
A. LRS
B. GRS
C. ZRS
D. RA-GRS
정답: C
해설: ZRS는 Zone 간 3중 복제 지원 → AZ 장애에도 데이터 보존 가능.
✅ NO.07
[단답형 / 난이도: 하]
Azure에서 VMSS를 사용하여 고가용성을 구성할 경우, 가용성 설정 옵션 이름은?
정답: Zone Balancing / Zonal Distribution
해설: VMSS는 Zone 간 균등 분산을 통해 고가용성 확보 가능.
✅ NO.08
[객관식 / 난이도: 상]
Azure Front Door의 역할로 올바른 것은?
A. 내부 DB 암호화
B. VM 모니터링
C. 글로벌 트래픽 분산 및 Health Probe
D. 로컬 DNS 구성
정답: C
해설: Azure Front Door는 글로벌 LB + 헬스체크 기능 포함.
✅ NO.09
[시나리오형 / 난이도: 상]
Azure에서 Web App을 Zone 1/2/3에 배포했지만, 특정 Zone의 App이 느려 사용자 응답 시간이 지연되고 있다.
Azure Front Door를 사용하는 경우, 이 문제를 완화할 수 있는 기술은?
정답: Health Probe 기반 트래픽 라우팅
해설: AFD는 Zone 별 상태를 감지하고 비정상 Zone으로의 라우팅을 차단함.
✅ NO.10
[객관식 / 난이도: 중]
Azure VM에 대해 Azure Site Recovery를 구성하면 얻을 수 있는 이점은?
A. 동기식 복제로 실시간 RPO 보장
B. 리전 간 자동 DR 구성
C. 부하 분산 기능
D. 암호화 복제본 생성
정답: B
해설: Site Recovery는 리전 간 재해복구 구성을 자동화함.
✅ NO.11
[객관식 / 난이도: 중]
Azure Flexible Server (PostgreSQL/MySQL)에서 고가용성 구성을 위해 필수 설정은?
A. VNet Integration
B. HA 활성화 + Zone 지정
C. 자동 백업
D. Geo-replication
정답: B
해설: Flexible Server는 Zone 내 이중화 구성을 HA 설정으로 지원함.
✅ NO.12
[단답형 / 난이도: 중]
Azure App Gateway에 연결된 백엔드 VM 중 하나가 비정상일 경우, 사용자를 다른 VM으로 연결하기 위한 설정은?
정답: Health Probe
해설: 백엔드 상태 감지를 위한 헬스 프로브 설정이 필수임.
✅ NO.13
[객관식 / 난이도: 상]
Azure 고가용성 설계 시 고려 대상이 아닌 것은?
A. Zone Redundant Storage
B. Sticky Session
C. Availability Set
D. DNS TTL
정답: B
해설: Sticky Session은 로드 밸런싱 균형을 깨뜨릴 수 있어 HA 설계에서는 비권장.
✅ NO.14
[시나리오형 / 난이도: 상]
App 서비스가 특정 리전에서만 배포되어 있고, 해당 리전 전체 장애 발생 시 백업 리전으로 트래픽을 자동 전환하고 싶다.
적절한 구성은?
정답: Azure Front Door + 다중 리전 App 배포
해설: AFD는 리전 상태에 따라 백업 리전으로 라우팅 가능.
✅ NO.15
[객관식 / 난이도: 중]
Azure Load Balancer는 내부와 외부 모두 가능하다. 내부 LB를 활용하는 대표적 시나리오는?
A. WebApp → DB 연결
B. 사용자 → WebApp 접근
C. Azure Files 백업
D. Blob Storage 마이그레이션
정답: A
해설: 내부 LB는 내부 트래픽 분산용으로 사용됨 (예: App → DB).
✅ NO.16
[단답형 / 난이도: 하]
Azure에서 백업 정책을 통합 관리할 수 있는 리소스 이름은?
정답: Recovery Services Vault
해설: Backup/Restore 정책은 Vault에서 통합 관리됨.
✅ NO.17
[객관식 / 난이도: 중]
Availability Set은 어떤 목적에 가장 적합한가?
A. Region 이중화
B. DR 구성
C. AZ 간 복제
D. VM 간 장애 격리
정답: D
해설: Availability Set은 VM 간 장애 도메인/업데이트 도메인을 분리하여 격리함.
✅ NO.18
[시나리오형 / 난이도: 상]
VMSS로 구성된 App 서버가 트래픽 증가로 인해 확장 중인데, 신규 인스턴스 기동 시간이 3분 이상 걸린다.
이로 인한 응답 지연을 줄이기 위한 Azure 기능은?
정답: Warm Pool
해설: 미리 기동된 인스턴스를 대기시켜 확장 시간 단축 가능.
✅ NO.19
[객관식 / 난이도: 중]
Azure SQL DB 장애 발생 시 자동으로 Standby로 전환되는 기능은?
A. Failover Group
B. Geo-Replication
C. Read Replica
D. Manual Snapshot
정답: A
해설: Failover Group은 자동 장애 전환을 지원함.
✅ NO.20
[단답형 / 난이도: 중]
Azure에서 Zone 장애 발생 시 동일 Region 내 정상 Zone으로 트래픽을 분산하는 구성 요소는?
정답: Azure Load Balancer (Zonal) or App Gateway
해설: LB나 App Gateway는 AZ별 라우팅을 지원하며 헬스 체크 기반 분산 가능.
📊 Azure 고가용성 설계 문제 – 3단 구성표 (문제 | 정답 | 해설)
| 01 | Azure Availability Zone의 주된 목적은? | B | 전력/네트워크가 분리된 장애 격리 단위로 고가용성 보장 |
| 02 | App Service를 고가용성으로 배포하려면 필요한 요금제는? | Premium P1 이상 | Premium 요금제부터 Zone Redundant 지원 |
| 03 | Zone 지정 배포 가능한 리소스는? | C | VM은 명시적 Zone 지정이 가능함 |
| 04 | Zone 1에만 App과 DB 구성 → 정전 발생. 해결방안은? | 다중 Zone 분산 구성 | 단일 AZ 구성은 치명적 → AZ 분산 필수 |
| 05 | Azure SQL ZRS 구성을 위해 선택할 티어는? | C | Premium, Business-critical에서 ZRS 지원 |
| 06 | AZ 장애에도 데이터 유실 없는 Storage는? | C | ZRS는 3개 AZ에 동시 복제 |
| 07 | VMSS 고가용성 구성 시 사용하는 설정은? | Zone Balancing | Zone 간 균형 분산 배포 설정 필요 |
| 08 | Azure Front Door의 기능은? | C | 글로벌 트래픽 분산 + 헬스체크 기능 |
| 09 | 특정 Zone 지연 발생 시 Front Door의 해결 방법은? | Health Probe 기반 트래픽 라우팅 | 상태 기반으로 비정상 Zone 회피 |
| 10 | Site Recovery 구성 시 효과는? | B | 리전 간 자동 복제 및 장애 전환 구성 가능 |
| 11 | Flexible Server HA 구성 방법은? | B | HA 설정 + Zone 지정으로 이중화 구성 |
| 12 | App Gateway 백엔드 VM 감지 설정은? | Health Probe | 상태 점검 통해 장애 인스턴스 제외 |
| 13 | HA 설계에서 고려 대상이 아닌 것은? | B | Sticky Session은 장애 시 분산 불가 위험 |
| 14 | 리전 장애 시 백업 리전 자동 전환을 위한 구성은? | AFD + 다중 리전 배포 | Front Door로 상태 기반 리전 전환 가능 |
| 15 | 내부 LB 대표 시나리오는? | A | 내부 트래픽 분산: WebApp → DB |
| 16 | Azure 백업 정책 통합 관리 리소스는? | Recovery Services Vault | 백업 스케줄 및 보존 정책 관리 |
| 17 | Availability Set 주요 목적은? | D | 장애/업데이트 도메인 분리로 고가용성 보장 |
| 18 | VMSS 확장 지연 최소화 위한 기능은? | Warm Pool | 사전 기동 인스턴스 대기상태 유지 |
| 19 | SQL DB 자동 장애 전환 기능은? | Failover Group | 자동 장애 인지 및 전환 지원 |
| 20 | Zone 장애 발생 시 트래픽 분산 구성 요소는? | Azure LB or App Gateway | Zone별 라우팅 지원 + 헬스 체크 기반 분산 |
🧠 Azure 고가용성 설계 암기카드 요약 (20개)
- Availability Zone (AZ) – 장애 격리된 데이터센터, 전력·네트워크 독립
- App Service HA 요금제 – Premium P1 이상부터 Zone Redundant 지원
- Zone 지정 배포 리소스 – VM은 Zonal 배포 가능 (Zone-aware)
- AZ 단일 구성의 문제 – AZ 장애 시 전체 서비스 중단 → AZ 분산 필요
- SQL ZRS 구성 요금제 – Premium, Business-critical만 Zone Redundant 가능
- ZRS (Zone-Redundant Storage) – 3개의 AZ에 실시간 동기 복제
- VMSS HA 구성 옵션 – Zone Balancing 설정으로 Zone 간 균등 배치
- Azure Front Door (AFD) – 글로벌 트래픽 분산 + 헬스체크 + HTTPS 오프로드
- AFD 트래픽 회피 기능 – Health Probe 기반으로 비정상 Zone 차단
- Site Recovery 목적 – 리전 간 DR(재해복구) 자동 구성
- Flexible Server HA 구성 – HA 활성화 + Zone 지정으로 자동 Failover
- App Gateway 장애 감지 – Health Probe로 백엔드 VM 상태 확인
- Sticky Session 주의 – HA 구조에선 로드밸런싱 효율을 저해할 수 있음
- 리전 장애 대비 구성 – Azure Front Door + 다중 리전 배포 조합 필요
- 내부 Load Balancer 활용 – App → DB 연결 등 내부 트래픽 분산
- Backup 통합 관리 리소스 – Recovery Services Vault 사용
- Availability Set 목적 – 장애 도메인/업데이트 도메인 분리
- VMSS 확장속도 개선 – Warm Pool로 사전 기동된 인스턴스 유지
- SQL DB 자동 Failover – Failover Group으로 장애 시 자동 전환
- Zone 장애 시 분산 구성 요소 – Azure Load Balancer 또는 App Gateway