단일 AZ 설계가 장애로 전면 중단됐다

상황

사내 예약 서비스가 다음과 같이 구성되어 있습니다.

• Application Load Balancer 하나. 등록된 서브넷은 가용 영역 하나뿐입니다.
• 애플리케이션 인스턴스 4대. Auto Scaling 그룹에 들어 있지만 VPCZoneIdentifier에 서브넷이 하나만 지정되어 있습니다.
• Amazon RDS 단일 인스턴스. Multi-AZ가 꺼져 있습니다.
• NAT 게이트웨이 하나. 프라이빗 라우팅 테이블 전부가 이 하나를 가리킵니다.
• 세션 정보는 각 인스턴스의 로컬 디스크에 저장됩니다.
• 업로드된 첨부 파일도 인스턴스의 EBS 볼륨에 저장됩니다.

해당 가용 영역에 문제가 생기자 다음 순서로 장애가 확산됐습니다.

1. 인스턴스 4대가 동시에 응답하지 않게 되고, 로드 밸런서의 상태 확인이 전부 실패했습니다.
2. Auto Scaling 그룹이 교체 인스턴스를 시작하려 했지만, 지정된 서브넷이 그 가용 영역에만 있어 시작이 실패했습니다.
3. 로드 밸런서 자체도 그 가용 영역에만 등록되어 있어 요청을 받을 곳이 없었습니다.
4. 데이터베이스도 같은 가용 영역이라 접속이 끊겼습니다.
5. NAT 게이트웨이가 그 가용 영역에 있어, 다른 가용 영역에 무언가 띄웠더라도 외부 호출이 불가능했습니다.
6. 복구 후에도 로컬 디스크에 있던 세션과 첨부 파일을 되살리지 못했습니다.

요구사항과 제약

배경 개념은 7장 로드 밸런싱과 오토스케일링과 10장 RDS와 관계형 데이터베이스에 있습니다.

후보 설계안 비교

"가용성을 높이자"는 합의는 쉽지만, 무엇을 얼마나 바꿀지에서 갈립니다. 네 가지 수준의 안을 놓고 비교합니다.

선택과 근거

D안을 고릅니다. C안까지만 하면 요구 1·2는 만족하지만 요구 3·4가 남습니다. 그리고 요구 3·4를 해결하지 않으면 자동 교체가 사용자에게 장애로 보입니다. 인스턴스가 바뀔 때마다 로그인이 풀리고 첨부 파일이 사라지면, 가용성을 높인 대가로 신뢰를 잃습니다.

계층별 처방

Auto Scaling 그룹을 여러 가용 영역으로

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name booking-app \
  --vpc-zone-identifier "subnet-0aaa000000000000a,subnet-0bbb000000000000b" \
  --min-size 4 \
  --max-size 12 \
  --health-check-type ELB \
  --health-check-grace-period 300

# 실제로 여러 가용 영역에 퍼졌는지 확인합니다.
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names booking-app \
  --query 'AutoScalingGroups[0].Instances[].[InstanceId,AvailabilityZone,LifecycleState,HealthStatus]' \
  --output table

최소 용량을 어떻게 잡는가

가용 영역 두 곳에 인스턴스를 나누기만 하면 되는 것이 아닙니다. 한 가용 영역이 사라졌을 때 남은 쪽이 전체 부하를 감당할 수 있어야 합니다.

• 필요 용량이 4대이고 가용 영역이 2개라면, 각 가용 영역에 4대씩 총 8대를 두는 것이 가장 안전합니다(N+N).
• 가용 영역을 3개로 늘리면 필요 용량의 절반만 여유로 두어도 됩니다(N+1 성격). 가용 영역 수를 늘릴수록 필요한 여유 비율이 줄어듭니다.
• Auto Scaling이 남은 가용 영역에서 즉시 인스턴스를 시작하더라도 기동 시간 동안은 용량이 부족합니다. 이 지연을 감수할 수 있는지가 여유 용량을 정하는 기준입니다.

교차 영역 로드 밸런싱 기본값 차이

가용 영역마다 대상 수가 다를 때 트래픽 분포가 균등하지 않은 현상은 교차 영역 로드 밸런싱 설정에서 나옵니다.

시험 관점에서 중요한 것은 "ALB는 기본이 켜짐"보다 "ALB는 끌 수 없다"는 사실입니다. Network Load Balancer를 다중 가용 영역에 두고 가용 영역마다 대상 수가 다르면 기본 설정에서는 트래픽이 고르게 분배되지 않습니다.

상태 비저장으로 만들기

제약 1(코드 변경 최소) 때문에 이 케이스에서는 업로드 파일을 Amazon EFS로 옮깁니다. 기존 코드가 파일 경로로 읽고 쓰는 구조라면 마운트 지점만 바꾸면 되기 때문입니다. 새로 설계한다면 S3가 더 나은 기본값입니다.

비용과 운영에 미치는 영향

설계 체크리스트

다중 가용 영역 배치

• 로드 밸런서가 둘 이상의 가용 영역 서브넷에 등록되어 있다
• Auto Scaling 그룹의 서브넷이 둘 이상의 가용 영역에 걸쳐 있다
• 한 가용 영역이 빠져도 남은 용량이 전체 부하를 감당한다
• 데이터베이스에 Multi-AZ가 켜져 있다
• NAT 게이트웨이가 가용 영역마다 있고 라우팅이 가용 영역별로 분리되어 있다
• 단일 지점으로 남은 구성 요소가 없는지 계층별로 확인했다

상태 비저장

• 세션이 인스턴스 밖에 저장된다
• 업로드 파일이 인스턴스 로컬 디스크에 있지 않다
• 로그가 인스턴스 밖으로 전송된다
• 인스턴스를 임의로 종료해도 사용자 경험이 유지되는지 실제로 시험해 봤다
• 배포와 스케일 인이 세션을 끊지 않는다

자동 복구

• Auto Scaling 상태 확인에 ELB가 포함되어 있다
• 유예 기간이 실제 기동 시간보다 넉넉하다
• 대상 그룹의 상태 확인 경로가 의존 관계까지 확인하는지 정했다
• 데이터베이스 장애 조치를 실제로 일으켜 애플리케이션 재연결을 확인했다
• 가용 영역 하나를 의도적으로 격리하는 훈련을 계획했다

관련 시험 포인트

이어서 볼 곳

• 7장 · 로드 밸런싱과 오토스케일링 ALB·NLB·GWLB 선택 기준, 대상 그룹과 상태 확인, 스케일링 정책과 수명주기 훅을 다룹니다. 기본개념 · 도메인 2
• 9장 · 파일 스토리지와 데이터 전송 EFS와 FSx의 성격, 여러 인스턴스가 공유하는 스토리지의 선택 기준입니다. 기본개념 · 도메인 3
• 실습 2 · ALB + ASG 웹 티어 다중 가용 영역 웹 티어를 CLI로 만들고 상태 확인 실패를 관찰합니다. 실습 예제
• 케이스 7 · 트래픽 급증에 스케일아웃이 못 따라갔다 같은 Auto Scaling 구성이 부하 급증에서는 다른 방식으로 실패합니다. 아키텍처 케이스
• 케이스 8 · 리전 장애에 대비한 DR을 설계하라 가용 영역이 아니라 리전 단위 장애로 범위를 넓혔을 때의 판단입니다. 아키텍처 케이스
• 복원력 있는 아키텍처 설계 (26%) 과제 진술 2개와 출제 포인트, 자주 나오는 함정을 정리했습니다. 시험 대비

공식 문서 출처

• Amazon EC2 Auto Scaling API 레퍼런스 — UpdateAutoScalingGroup — 상태 확인 유형(EC2 · EBS · ELB · VPC_LATTICE)과 EC2가 기본이며 끌 수 없다는 서술, VPCZoneIdentifier와 가용 영역의 관계
• Elastic Load Balancing API 레퍼런스 — ModifyLoadBalancerAttributes — load_balancing.cross_zone.enabled의 기본값이 로드 밸런서 유형마다 다르고 Application Load Balancer에서는 변경할 수 없다는 서술
• Amazon RDS 사용 설명서 — 단일 대기 인스턴스를 사용하는 Multi-AZ 배포 — 동기식 복제와 자동 장애 조치의 동작
• Amazon VPC 사용 설명서 — NAT 게이트웨이 — NAT 게이트웨이가 지정한 서브넷에 만들어진다는 점(따라서 가용 영역에 묶인다)
• Amazon EC2 사용 설명서 — 리전과 가용 영역 — 가용 영역이 독립된 장애 격리 단위라는 정의
• Amazon EC2 API 레퍼런스 — CreateVolume — EBS 볼륨이 특정 가용 영역에 생성된다는 제약