DAY3 - 모니터링 및 스케일링

발행: 1일 전 (2026년 1월 31일 오전 09:20 GMT+9)

4 min read

Source: Dev.to

개요

오늘의 실습에서는 Application Load Balancer (ALB), Auto Scaling Group (ASG), 그리고 CloudWatch를 사용해 EC2 인스턴스를 모니터링하고 스케일링하는 방법을 다룹니다.

네트워크 설정

서브넷: Day 1 실습에서 만든 퍼블릭 서브넷을 사용합니다.
라우트: 프라이빗 서브넷에 연결된 프라이빗 라우트 테이블에 기본 라우트를 추가하여 해당 서브넷의 인스턴스가 인터넷에 접근할 수 있도록 합니다.

보안 그룹

ALB 보안 그룹

인바운드: 0.0.0.0/0 에서 HTTP 80
아웃바운드: 모든 트래픽 (기본)

EC2 보안 그룹

인바운드: 위에서 만든 ALB 보안 그룹에서 HTTP 80
아웃바운드: 모든 트래픽 (기본)

대상 그룹

대상 유형: 인스턴스

런치 템플릿

다음 설정으로 ASG용 런치 템플릿을 생성합니다:

AMI: Amazon Linux 2023
User data:

#!/bin/bash
set -e

dnf -y update
dnf -y install nginx
systemctl enable --now nginx

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id)

cat > /usr/share/nginx/html/index.html <<EOF

## Day3: ALB + ASG (Private EC2)

InstanceId: ${INSTANCE_ID}

EOF

Auto Scaling Group (ASG)

런치 템플릿: 위에서 만든 템플릿 사용
스키마: 인터넷‑페이싱

ASG를 생성한 뒤, ALB의 DNS 이름에 접속해 인스턴스 ID가 표시된 페이지가 로드되는지 확인합니다. 대상 그룹 상태가 healthy인지 확인하세요.

스케일링 정책

ASG 콘솔에서 Automatic scaling → Create dynamic scaling policy 로 이동합니다.
Day 2와 같이 SSM을 통해 EC2 인스턴스에 접속하고, 다음 명령을 실행해 10분 동안 CPU 부하를 발생시킵니다:

sudo dnf -y install stress-ng
cd /tmp
stress-ng --cpu 2 --timeout 10m

몇 분 기다린 뒤 ASG 대시보드에서 스케일링 활동을 관찰합니다.

정리 순서

의존성 오류를 방지하려면 다음 순서대로 리소스를 삭제합니다:

Auto Scaling Group
런치 템플릿
ALB와 대상 그룹
서브넷, 라우트 테이블, NAT 리소스
보안 그룹

핵심 시험 포인트

NAT Gateway: 관리형 서비스; Elastic IP (EIP)와 자동으로 연결됩니다.
NAT Instance: EIP 또는 퍼블릭 IP를 가진 EC2 인스턴스; 장애 조치와 로드 밸런싱을 직접 관리해야 합니다.

ALB vs. NLB

기능	ALB	NLB
프로토콜	HTTP/HTTPS (layer 7)	TCP, TLS, UDP (layer 4)
라우팅	URL‑기반, 호스트‑기반, 경로‑기반; Lambda 함수도 대상 가능; ACM과 연동해 인증서 관리	고처리량, 고정 IP (EIP); 지연시간에 민감한 워크로드에 적합 (예: 금융 시스템)
사용 사례	URL 라우팅이나 SSL 종료가 필요한 웹 애플리케이션	고속, 저지연 트래픽 또는 고정 IP가 필요한 서비스

리소스 스케일링

EC2: ASG + ALB/NLB + 스케일링 메트릭(CPU, 요청 수 등)
Lambda: 동시성 제한, 이벤트 소스(SQS, Kinesis 등) 기반 자동 확장
ECS/EKS: 서비스 Auto Scaling

Day 4 실습에서 곧 뵙겠습니다!