AWS Certified CloudOps Engineer - Associate (SOA-C03) #5 Domain 2-1 신뢰성: Multi-AZ,Auto Scaling,ELB 헬스체크
#4까지 모니터링 도메인을 마쳤습니다. 이번 글부터는 두 번째 도메인인 신뢰성과 비즈니스 연속성(22%)입니다. 신뢰성의 첫 축은 “장애가 나도 서비스가 계속되게” 하는 가용성 운영입니다. SAA에서 설계로 배운 Multi-AZ,Auto Scaling,ELB를, 여기서는 운영 중에 어떻게 동작하고 무엇이 어긋날 때 무엇을 고치는가의 관점으로 다시 봅니다.
가용성의 기본: 가용 영역 다중화 #
리전(Region)은 물리적으로 분리된 여러 가용 영역(AZ)으로 구성됩니다. 한 AZ가 통째로 실패해도 서비스가 살아 있으려면, 자원을 여러 AZ에 걸쳐 두어야 합니다.
| 구성 | Single-AZ | Multi-AZ |
|---|---|---|
| AZ 장애 영향 | 서비스 중단 | 다른 AZ로 계속 |
| 대표 적용 | 개발,임시 | 운영 워크로드 |
핵심은 다중화는 거의 항상 AZ 수준에서 시작한다는 점입니다. 리전 전체 장애에 대비하는 멀티리전은 비용이 크고, 어소시에이트 시험의 기본 답은 대체로 Multi-AZ입니다.
Auto Scaling 그룹(ASG) 운영 #
ASG는 정해진 용량을 유지하고, 부하에 따라 인스턴스 수를 조절하는 장치입니다. 세 용량 값이 운영의 핵심입니다.
| 값 | 의미 |
|---|---|
| Minimum | 항상 유지하는 최소 인스턴스 수 |
| Desired | 현재 목표 수. 정책이 이 값을 조절 |
| Maximum | 늘릴 수 있는 상한 |
스케일링 정책 #
| 정책 | 동작 | 언제 |
|---|---|---|
| Target Tracking | 목표 지표값(예: CPU 50%)을 유지하도록 자동 조절 | 가장 권장. 단순,안정 |
| Step Scaling | 임계값 구간별로 정해진 양만큼 조절 | 세밀한 제어 필요 시 |
| Scheduled | 정해진 시각에 용량 변경 | 트래픽 패턴이 예측되는 경우 |
“트래픽이 매일 오전에 몰린다"처럼 예측 가능한 패턴은 Scheduled Scaling, “부하에 따라 알아서"는 Target Tracking이 답입니다.
수명 주기 훅(Lifecycle Hook) #
인스턴스가 ASG에 들어오거나 나갈 때 특정 작업을 끼워 넣는 장치입니다.
- 시작 훅: 인스턴스가 서비스에 들어가기 전 설정,등록 완료를 보장
- 종료 훅: 인스턴스가 종료되기 전 로그 수집,연결 정리 같은 마무리
“종료되는 인스턴스의 로그를 잃지 않게 하라"는 요구의 답이 종료 수명 주기 훅입니다. 인스턴스를 일시 대기 상태로 잡아 두고 마무리 작업을 끝낸 뒤 보냅니다.
ELB: 종류와 헬스체크 #
ELB는 트래픽을 건강한 대상으로만 분배합니다. 종류 구분이 시험 포인트입니다.
| 종류 | 계층 | 대표 용도 |
|---|---|---|
| ALB | L7(HTTP/HTTPS) | 경로,호스트 기반 라우팅, 웹 애플리케이션 |
| NLB | L4(TCP/UDP) | 초고성능,고정 IP,낮은 지연 |
| GWLB | L3 | 방화벽 등 인라인 보안 어플라이언스 |
헬스체크 #
ELB는 대상 그룹의 인스턴스에 주기적으로 헬스체크 요청을 보내 건강 여부를 판단합니다.
- 정상 임계값,비정상 임계값,간격,타임아웃,경로를 설정
- 비정상으로 판정된 대상에는 트래픽을 보내지 않음
- ALB는 HTTP 경로(예:
/health)와 상태 코드로, NLB는 TCP 연결로 판단
“일부 인스턴스가 응답하지 않는데 ELB가 계속 트래픽을 보낸다"는 시나리오는 보통 헬스체크 경로,임계값 설정 문제입니다.
연결 드레이닝(Deregistration Delay) #
인스턴스를 대상 그룹에서 빼거나 종료할 때, 진행 중인 요청을 끝까지 처리하도록 기다리는 시간입니다. 이 값이 0이면 배포,축소 중에 사용자 요청이 끊깁니다. “배포할 때마다 일부 요청이 실패한다"는 답이 연결 드레이닝(등록 해제 지연) 설정입니다.
Route 53 페일오버 #
AZ를 넘어 엔드포인트 수준의 가용성은 Route 53로 구성합니다.
| 라우팅 정책 | 동작 |
|---|---|
| Failover | 주(primary)가 비정상이면 보조(secondary)로 전환 |
| Weighted | 가중치 비율로 분산(점진 배포,A/B) |
| Latency | 가장 지연이 낮은 리전으로 |
| Multivalue | 여러 정상 엔드포인트를 반환(간단한 분산) |
페일오버의 전제는 Route 53 헬스체크입니다. 엔드포인트를 주기적으로 점검해 비정상이면 DNS 응답에서 빼고 보조로 넘깁니다. “리전 장애 시 다른 리전으로 자동 전환"의 답이 Route 53 Failover 라우팅 + 헬스체크입니다. DNS 캐시(TTL) 때문에 전환이 즉시는 아니라는 점도 함께 기억해 둘 만합니다.
시험 출제 패턴 #
- AZ 장애에도 계속 → 자원을 여러 AZ에 다중화
- 예측 가능한 트래픽 급증 → Scheduled Scaling
- 부하에 따라 자동 조절 → Target Tracking
- 종료 인스턴스의 로그 보존 → 종료 수명 주기 훅
- 비정상 인스턴스에 트래픽이 계속 감 → 헬스체크 설정 점검
- 배포 중 요청 실패 → 연결 드레이닝(등록 해제 지연)
- 리전 장애 시 자동 전환 → Route 53 Failover + 헬스체크
자주 만나는 함정 #
1) Desired만 바꾸면 영구적이라고 생각 #
스케일링 정책이 Desired를 다시 조절합니다. 고정하려면 Min,Max를 같은 값으로 두거나 정책을 손봐야 합니다.
2) ASG 헬스체크를 EC2로만 둠 #
#4에서 본 함정의 반복입니다. 애플리케이션 장애까지 잡으려면 ELB 헬스체크를 켜야 합니다.
3) NLB에 HTTP 경로 헬스체크를 기대 #
NLB는 L4입니다. 애플리케이션 응답 코드로 거르려면 ALB가 맞습니다.
4) Route 53 페일오버가 즉시라고 가정 #
DNS TTL과 헬스체크 간격 때문에 전환에 시간이 걸립니다. TTL을 낮춰 전환을 빠르게 합니다.
정리 #
이번 글에서 잡은 것:
- 다중화는 AZ 수준에서 시작. 어소시에이트의 기본 가용성 답은 Multi-AZ
- ASG는 Min,Desired,Max로 용량을 유지,조절. 정책은 Target Tracking(권장),Step,Scheduled
- 수명 주기 훅으로 시작,종료 시 작업 삽입. 종료 훅으로 로그 보존
- ELB는 ALB(L7),NLB(L4),GWLB. 헬스체크로 건강한 대상만 분배
- 연결 드레이닝으로 배포,축소 중 진행 요청 보호
- Route 53 Failover + 헬스체크로 엔드포인트,리전 수준 전환. DNS TTL로 전환 속도 조절
다음: Domain 2-2 백업,복원과 재해 복구 #
가용성으로 “계속 도는 것"을 잡았으니, 다음은 “데이터를 잃지 않고 복구하는 것"입니다.
#6 Domain 2-2 신뢰성: 백업,복원과 재해 복구(DR)에서는 EBS 스냅샷과 AMI, RDS 백업과 스냅샷, AWS Backup으로 백업을 중앙 관리하는 법, RPO와 RTO의 의미, 그리고 백업,파일럿 라이트,웜 스탠바이,멀티사이트로 이어지는 DR 전략까지 정리하겠습니다.