AWS Certified CloudOps Engineer - Associate (SOA-C03) #4 Domain 1-3 모니터링: 자동 복구와 성능 최적화
#2의 지표와 #3의 로그로 감지를 정리했습니다. 운영의 다음 단계는 감지한 뒤 사람 손 없이 자동으로 조치하는 것입니다. SOA-C03에서 “수동 개입 없이(without manual intervention)“라는 조건을 자주 거는 이유가 여기 있습니다. 이 글은 자동 복구의 구성 요소와, 모니터링 도메인의 마지막 축인 성능 최적화를 정리하겠습니다.
EventBridge: 이벤트에 반응하는 중심 #
EventBridge는 AWS에서 일어나는 이벤트를 규칙으로 받아 대상으로 보내는 라우터입니다. 자동 복구의 출발점입니다.
| 구성 | 설명 |
|---|---|
| Event source | 이벤트를 내는 곳. AWS 서비스, 사용자 정의, SaaS 파트너 |
| Rule | 이벤트 패턴으로 거르거나, 일정(cron)으로 트리거 |
| Target | 보낼 대상. Lambda, SSM Automation, SNS, Step Functions 등 |
두 가지 트리거 방식이 핵심입니다.
- 이벤트 패턴: “EC2 인스턴스가
stopped상태로 바뀌면”, “Health 이벤트가 발생하면” 같이 상태 변화에 반응 - 일정(Scheduled): cron,rate 식으로 주기 실행. 예전 CloudWatch Events의 역할을 그대로 이어받음
“인스턴스가 특정 상태가 되면 자동으로 무언가 하라"는 시나리오의 출발이 EventBridge 규칙입니다.
Systems Manager Automation: 복구 런북 #
감지(EventBridge) 다음의 실제 조치를 담당하는 것이 Systems Manager Automation입니다. 런북(Runbook, Automation document)이라는 단계별 절차를 정의해 두고 실행합니다.
- AWS 제공 런북:
AWS-RestartEC2Instance,AWS-StopEC2Instance등 즉시 사용 가능 - 사용자 정의 런북: 여러 단계(스냅샷 → 복구 → 검증)를 묶어 정의
- 권한: 런북이 사용할 IAM Role로 동작
대표 자동 복구 흐름은 다음과 같습니다.
CloudWatch Alarm (또는 EventBridge 규칙)
→ SSM Automation 런북 실행
→ 인스턴스 재시작,교체,태깅 등 조치
→ SNS로 결과 통지“디스크가 가득 차면 자동으로 정리 스크립트를 돌려라” 같은 요구는 EventBridge/알람 → SSM Automation 런북으로 구현합니다.
EC2 자동 복구와 Auto Scaling 자가 치유 #
자동 복구에는 더 간단한 내장 장치도 있습니다.
| 장치 | 동작 | 언제 |
|---|---|---|
| EC2 자동 복구(recover) | 같은 인스턴스를 새 하드웨어에서 복구. ID,IP 유지 | 시스템 상태 점검(하드웨어) 실패 |
| Auto Scaling 헬스체크 | 비정상 인스턴스를 종료하고 새 인스턴스로 교체 | EC2 또는 ELB 헬스체크 실패 |
둘의 차이가 시험 포인트입니다.
- 자동 복구는 같은 인스턴스를 살리는 것입니다. 단일 인스턴스의 하드웨어 장애에 씁니다.
- Auto Scaling은 비정상 인스턴스를 버리고 새것으로 교체합니다. 무상태(stateless) 워크로드의 자가 치유에 씁니다.
상태(state)를 인스턴스에 들고 있어 교체가 곤란하면 자동 복구, 상태가 없어 언제든 교체 가능하면 Auto Scaling이 답입니다. Auto Scaling 헬스체크를 ELB 헬스체크로 설정해야 애플리케이션 레벨 장애까지 잡는다는 점도 단골입니다.
성능 최적화: 진단의 순서 #
SOA-C03에서 성능은 별도 도메인이 아니라 모니터링 도메인 안에 들어왔습니다. 핵심은 지표로 병목을 특정한 뒤 맞는 조치를 고르는 흐름입니다.
| 자원 | 병목 신호(지표) | 대표 조치 |
|---|---|---|
| 컴퓨팅 | CPUUtilization 지속 高 | 인스턴스 타입 상향, ASG 확장, 더 큰 패밀리 |
| 메모리 | (Agent) 메모리 사용률 高 | 메모리 최적화 패밀리(R 계열) |
| EBS | VolumeQueueLength 高, IOPS 한계 | gp3 IOPS 상향, io2 전환 |
| RDS | ReadIOPS 高, FreeableMemory 低 | Read Replica, 인스턴스 상향, 캐싱 |
| 네트워크 | 대역폭 한계 | 향상된 네트워킹, 더 큰 인스턴스 |
EBS 성능 포인트 #
EBS는 시험 단골입니다. gp3는 용량과 무관하게 IOPS,처리량을 따로 올릴 수 있어, gp2에서 성능이 부족할 때 1차 답입니다. 매우 높은 일관된 IOPS가 필요하면 io2/io2 Block Express입니다. “디스크가 느린데 용량은 충분하다"는 답은 보통 gp3로 전환해 IOPS를 올리는 것입니다.
Compute Optimizer와 비용,성능의 균형 #
Compute Optimizer는 과거 지표를 분석해 인스턴스가 과대,과소 프로비저닝되었는지 권고합니다. EC2,ASG,EBS,Lambda를 대상으로 합니다.
- 과대 프로비저닝: 사용률이 낮은 인스턴스를 더 작은 타입으로 → 비용 절감
- 과소 프로비저닝: 사용률이 한계인 인스턴스를 더 큰 타입으로 → 성능 개선
성능과 비용은 같은 진단의 양면입니다. “비용은 줄이되 성능은 유지하라"는 요구의 답으로 Compute Optimizer 권고에 따른 라이트사이징(rightsizing)이 자주 나옵니다. 메모리 권고를 받으려면 CloudWatch Agent의 메모리 지표가 있어야 한다는 점도 함께 기억해 둘 만합니다.
시험 출제 패턴 #
- 상태 변화에 자동 반응 → EventBridge 규칙
- 감지 후 여러 단계 복구 자동화 → SSM Automation 런북
- 단일 인스턴스 하드웨어 장애 자동 복구 → EC2 자동 복구(같은 인스턴스)
- 무상태 워크로드 자가 치유 → Auto Scaling + ELB 헬스체크(교체)
- 디스크가 느린데 용량은 충분 → gp3로 전환해 IOPS 상향
- 비용은 줄이되 성능 유지 → Compute Optimizer 라이트사이징
자주 만나는 함정 #
1) 자동 복구와 Auto Scaling을 같다고 봄 #
자동 복구는 같은 인스턴스를 살리고, Auto Scaling은 버리고 교체합니다. 상태 보유 여부로 갈립니다.
2) Auto Scaling 헬스체크를 EC2로만 둠 #
기본 EC2 헬스체크는 인스턴스가 살아 있는지만 봅니다. 애플리케이션 장애를 잡으려면 ELB 헬스체크를 켜야 합니다.
3) 성능 문제에 무조건 인스턴스를 키움 #
병목이 EBS IOPS인데 인스턴스 타입을 키우는 답은 빗나갑니다. 지표로 병목 자원을 먼저 특정해야 합니다.
4) Lambda를 EventBridge 없이 주기 실행하려 함 #
Lambda 자체에는 스케줄러가 없습니다. 주기 실행은 EventBridge 일정 규칙으로 트리거합니다.
정리 #
이번 글에서 잡은 것:
- EventBridge가 자동 복구의 출발. 이벤트 패턴(상태 변화)과 일정(cron) 두 트리거
- SSM Automation 런북으로 감지 후 다단계 조치 자동화. 알람,EventBridge가 트리거
- EC2 자동 복구는 같은 인스턴스 살리기(하드웨어 장애), Auto Scaling은 버리고 교체(무상태)
- Auto Scaling 헬스체크를 ELB 기준으로 둬야 애플리케이션 장애까지 자가 치유
- 성능은 지표로 병목 자원 특정 후 조치. EBS는 gp3 IOPS 상향이 단골
- Compute Optimizer로 과대,과소 프로비저닝 진단. 비용과 성능을 함께 라이트사이징
다음: Domain 2-1 Multi-AZ와 Auto Scaling #
모니터링 도메인을 마쳤습니다. 다음은 두 번째 도메인인 신뢰성과 비즈니스 연속성입니다.
#5 Domain 2-1 신뢰성: Multi-AZ,Auto Scaling,ELB 헬스체크에서는 가용 영역을 가로지르는 다중화 구성, Auto Scaling 그룹의 용량,정책,수명 주기, ELB의 종류별 헬스체크와 연결 드레이닝, 그리고 Route 53 페일오버까지 묶어 가용성 설계를 운영 관점에서 정리하겠습니다.