[AWS 네트워크 계층으로 읽기 #4] Auto Scaling Group + Launch Template — 자동 증감의 본체

AWS 네트워크 계층으로 읽기

시리즈 소개
AWS EC2 Auto Scaling 실습 하나를 OSI 7계층 / TCP/IP 4계층 관점으로 한 챕터씩 뜯어보는 5부작입니다.

#1 VPC·서브넷·라우팅 — L3 토대

#2 보안 그룹 vs NACL — L4 방화벽

#3 ALB 완전 분석 — L7 로드밸런서 (vs NLB)

#4 (이번 편) Auto Scaling Group + Launch Template ← 현재 위치

#5 CloudWatch 동적 스케일링 + 부하 테스트로 증명하기

실습 환경: 서울 리전(ap-northeast-2) · CloudFormation(ASG_LAB.yaml) + 콘솔

0. 공통 지도 — OSI 7계층 / TCP/IP 4계층 (매 편 반복)

OSI 7계층	TCP/IP 4계층	이 시리즈에서
7. 응용	4. 응용	ALB(3편), UserData가 만드는 웹 콘텐츠
4. 전송	3. 전송	보안 그룹·포트(2편)
3. 네트워크	2. 인터넷	VPC·서브넷(1편)
1~2	1. 네트워크 접근	ENI, 데이터센터

이번 편의 자리: ASG와 Launch Template은 특정 네트워크 계층이 아니라 그 위에서 인프라를 자동 운영하는 "제어 평면(control plane)" 입니다. 단, 이들이 다루는 EC2와 그 위의 웹 콘텐츠는 L7과 맞닿아 있습니다.

1. Launch Template — "서버 붕어빵 틀" 만들기

Launch Template — 동일 EC2를 찍어내는 붕어빵 틀

오토 스케일링이 서버를 자동으로 찍어내려면, "어떤 서버를 찍을지"에 대한 설계도가 필요합니다. 그게 Launch Template(시작 템플릿) 입니다. 붕어빵 틀 하나를 만들어두면 똑같은 붕어빵을 무한정 찍어낼 수 있죠.

실습에서 만든 EC2Template의 핵심 설정:

AMI: Amazon Linux (OS 이미지)
인스턴스 유형: t2.micro (1 vCPU, 1GiB — 프리티어)
키 페어: koo (SSH 접속용)
보안 그룹: ASG-VPC1SG-* (2편에서 본 L4 방화벽)
상세 CloudWatch 모니터링: 활성화 ← 중요. 기본 5분이 아니라 1분 간격 지표를 받아야 5편의 스케일링이 빠르게 반응합니다.
UserData(부팅 스크립트): 아래가 핵심

#!/bin/bash
echo "sudo su -" >> /home/ec2-user/.bashrc
# 인스턴스 메타데이터 서비스(IMDS, 169.254.169.254)에서 자기 정보 읽기
RZAZ=$(curl http://169.254.169.254/latest/meta-data/placement/availability-zone-id)
IID=$(curl 169.254.169.254/latest/meta-data/instance-id)
LIP=$(curl 169.254.169.254/latest/meta-data/local-ipv4)
dnf install -y php8.1.x86_64
yum install httpd htop tmux -y
systemctl start httpd && systemctl enable httpd
# 자기 AZ·인스턴스ID·사설IP를 박은 웹페이지 생성
echo "<h1>RegionAz($RZAZ) : Instance ID($IID) : Private IP($LIP) : Web Server</h1>" > /var/www/html/index.html
echo "1" > /var/www/html/HealthCheck.txt          # 3편 ALB 헬스체크용
curl -o /var/www/html/load.php https://.../load.php --silent   # 5편 CPU 부하용

이 스크립트의 영리한 점: 각 서버가 부팅하며 자기 AZ·인스턴스ID·사설IP를 페이지에 박아둡니다. 그래서 5편에서 ALB로 접속하면 매번 다른 서버가 응답하는 게 눈에 보입니다(로드밸런싱 증명). 169.254.169.254는 인스턴스 메타데이터 서비스(IMDS) 주소로 외워두면 두고두고 쓰입니다.

📷 이미지 삽입 위치 — 시작 템플릿 UserData
EC2 콘솔 > 시작 템플릿 생성 > 고급 세부 정보 > 사용자 데이터 입력 화면. (실습 PDF 9페이지에 캡처 있음)

대안 — Launch Template vs Launch Configuration

예전엔 Launch Configuration을 썼지만 지금은 지원 종료(deprecated) 입니다. Launch Template은 버전 관리(v1, v2…)가 되고 최신 기능(혼합 인스턴스, 스팟 비율 등)을 지원합니다. 실습 안내에도 *"2023년 5월 31일 이후 생성된 계정은 시작 템플릿으로만 ASG 생성 가능"이라 나옵니다. *신규 프로젝트는 무조건 Launch Template**입니다.

2. Auto Scaling Group — 자동 증감의 본체

Auto Scaling Group 구조 — 2 AZ·용량·ALB 연결

FirstEC2ASG를 만들며 핵심 숫자 세 개를 정합니다.

원하는 용량(Desired) = 2: 평상시 항상 유지할 서버 수
최소(Min) = 1: 아무리 한가해도 이 밑으로 안 줄임
최대(Max) = 5: 아무리 바빠도 이 위로 안 늘림(과금 안전벨트)

그리고:

2개 AZ 서브넷(SN1·SN2)에 걸쳐 배치 → 인스턴스를 여러 AZ에 균등 분산(고가용성)
3편의 ALB Target Group(ALB-TG)에 자동 연결 → 새로 뜬 서버가 자동으로 로드밸런서 뒤에 등록됨
헬스체크 유형을 ELB로 켬

📷 이미지 삽입 위치 — ASG 생성 완료 + 인스턴스
EC2 콘솔 > Auto Scaling 그룹 FirstEC2ASG(원하는 용량 2, 1~5) 및 인스턴스 목록에 WebServer 2대가 서로 다른 AZ에 뜬 화면. (실습 PDF 14·15페이지에 캡처 있음)

3. ELB 헬스체크를 켜는 이유 (이 편의 핵심)

EC2 헬스체크 vs ELB 헬스체크

ASG의 헬스체크에는 두 종류가 있습니다.

헬스체크	무엇을 보나	한계/장점
EC2 헬스체크(기본)	인스턴스가 "켜져 있나"(시스템 상태)	httpd가 죽어도 서버는 살아있으니 "정상" 판정 → 장애 못 잡음
ELB 헬스체크(추가)	ALB가 `/HealthCheck.txt`를 실제 HTTP 요청해 200이 오나	웹 프로세스가 죽으면 즉시 "비정상" → ASG가 그 인스턴스를 교체

즉 L7 헬스체크(ELB)를 켜야 "진짜 서비스가 살아있는지"를 검사할 수 있습니다. 3편에서 ALB가 URL 경로로 건강검진을 한다고 했죠? ASG는 그 결과를 받아 비정상 인스턴스를 자동으로 갈아끼웁니다. 3편(ALB)과 4편(ASG)이 헬스체크로 손을 잡는 지점입니다.

상태 확인 유예 기간(grace period) 60초는 "부팅 직후엔 아직 httpd가 안 떴을 수 있으니 60초는 봐준다"는 의미입니다.

4. 인스턴스 종료 정책 — 줄일 때 누구부터 끄나

Scale In(축소) 시 어느 인스턴스를 먼저 종료할지의 규칙입니다. 실습은 "최신 인스턴스(Newest Instance)"를 1순위로, 기본 휴지 기간을 180초로 둡니다.

최신 인스턴스 우선: 방금 늘린 서버부터 끔 → 부하 스파이크가 지나가면 새로 띄운 것부터 정리. 직관적.
대안: OldestInstance(인스턴스 갱신용), OldestLaunchTemplate(롤링 업데이트), ClosestToNextInstanceHour(과금 경계 최적화), Default(AZ 균형).
Cooldown 180초: 한 번 조정 후 180초간 추가 조정을 멈춰 "방금 늘렸는데 또 늘리는" 출렁임(thrashing)을 방지.

5. ASG, 안 쓰면 안 되나 — 대안과 사용 이유

방법	설명	한계
고정 대수 EC2 N대	늘 같은 수를 켜둠	한가할 땐 돈 낭비, 몰릴 땐 터짐
수동 스케일링	사람이 보고 늘림	새벽 폭주 대응 불가
ASG(이 실습)	지표 기반 자동 증감	학습 곡선(한 번 짜두면 끝)
컨테이너/서버리스	ECS Fargate, Lambda	워크로드가 컨테이너/이벤트형일 때 적합

그럼에도 ASG를 쓰는 이유: (1) 비용 효율(필요한 만큼만 켜서 idle 비용 절감), (2) 고가용성(죽으면 자동 교체·여러 AZ 분산), (3) 탄력성(트래픽 자동 대응)을 한 번의 설정으로 얻습니다. EC2 기반 웹 서비스의 사실상 표준입니다. 단, 순수 이벤트형(이미지 업로드 시 썸네일 생성)이면 Lambda, 컨테이너 마이크로서비스면 ECS/EKS가 더 맞습니다. "상시 떠 있는 웹 서버 군집"엔 ASG입니다.

6. 이번 편 계층 종합표

구성요소	동작 계층	근거	한 줄 역할
Launch Template	(제어 평면)	인스턴스 생성 설계도	서버 붕어빵 틀
Auto Scaling Group	(제어 평면)	대수 관리 로직	자동 증감 관리자
ELB 헬스체크	L7	`/HealthCheck.txt` HTTP 검사	진짜 서비스 생존 확인
EC2 헬스체크	(호스트)	시스템 상태	인스턴스 전원 확인
UserData 웹 콘텐츠	L7	index.html/HealthCheck.txt/load.php	응답 콘텐츠
종료 정책·Cooldown	(제어 평면)	운영 로직	축소 우선순위·출렁임 방지

한 문장 요약: ASG와 Launch Template은 네트워크 계층이 아니라 그 위에서 인프라를 자동 운영하는 제어 평면입니다. 다만 ELB 헬스체크(L7)로 3편의 ALB와, 보안 그룹(L4)으로 2편과, 서브넷(L3)으로 1편과 모두 연결됩니다.

7. 실습 핵심 수치 (이번 편)

Launch Template: EC2Template, t2.micro, 키 koo, 상세 모니터링(1분), UserData로 httpd·HealthCheck.txt·load.php 설치
ASG: FirstEC2ASG, desired 2 / min 1 / max 5, 2개 AZ 서브넷, ALB-TG 연결
헬스체크: ELB(L7), 유예 60초
종료 정책: 최신 인스턴스, cooldown 180초

다음 편 예고

#5(최종편)에서는 이 ASG가 실제로 자동으로 늘었다 줄어드는지를 증명합니다. CloudWatch 경보로 CPU를 감시해 CPU>80이면 +1(Scale Out), CPU<10이면 -1(Scale In)하는 정책을 만들고, ApacheBench로 부하를 걸어 2대 → 5대로 늘어나는 장면을 직접 확인합니다. 마지막으로 비용을 위한 리소스 삭제까지 다루며 시리즈를 마무리합니다.

이번 편 한 줄 복습: Launch Template은 서버를 찍는 틀, ASG는 그 틀로 대수를 자동 조절하는 관리자다. ELB(L7) 헬스체크를 켜야 진짜 서비스 생존을 검사할 수 있다.

시리즈 #4 끝 · 다음 편: CloudWatch 동적 스케일링 + 부하 테스트로 증명하기

저작자표시 (새창열림)

'클라우드 컴퓨팅 > AWS' 카테고리의 다른 글

[AWS 네트워크 계층으로 읽기 #3] ALB 완전 분석 — L7 로드밸런서는 왜 URL을 읽는가 (0)	2026.06.15
[AWS 네트워크 계층으로 읽기 #2] 보안 그룹 vs NACL — L4 방화벽의 원리 (0)	2026.06.15
[AWS 네트워크 계층으로 읽기 #1] VPC·서브넷·라우팅 — 클라우드의 L3 토대 짓기 (0)	2026.06.15
실습 2-4 _ ELB 실습 ④편 — 출발지 IP 보존 (1)	2026.06.09
실습 2-2 _ ELB 실습 ②편 — ALB (0)	2026.06.08

0. 공통 지도 — OSI 7계층 / TCP/IP 4계층 (매 편 반복)

1. Launch Template — "서버 붕어빵 틀" 만들기

대안 — Launch Template vs Launch Configuration

2. Auto Scaling Group — 자동 증감의 본체

3. ELB 헬스체크를 켜는 이유 (이 편의 핵심)

4. 인스턴스 종료 정책 — 줄일 때 누구부터 끄나

5. ASG, 안 쓰면 안 되나 — 대안과 사용 이유

6. 이번 편 계층 종합표

7. 실습 핵심 수치 (이번 편)

다음 편 예고

'클라우드 컴퓨팅 > AWS' 카테고리의 다른 글

티스토리툴바