AWS High Availability & Scalability 정리
AWSELBALBNLBAuto ScalingDVA-C02
작성자 : 오예환 | 작성일 : 2026-01-05 | 수정일 : 2026-01-05
1. 확장성과 고가용성 개념
🤔 확장성(Scalability)이 뭔가요?
비유로 이해하기: 콜센터를 상상해보세요.
- 전화가 많이 오면 어떻게 해야 할까요?
- 방법 1: 더 빠르고 능력 있는 상담원 고용 (수직 확장)
- 방법 2: 상담원을 더 많이 고용 (수평 확장)
수직 확장 (Vertical Scaling)
┌─────────────────────────────────────────────────────────────────┐
│ 수직 확장 (Scale Up) │
│ │
│ [t2.micro] ───업그레이드───→ [t2.large] ───→ [m5.xlarge] │
│ (1 vCPU) (2 vCPU) (4 vCPU) │
│ (1GB RAM) (8GB RAM) (16GB RAM) │
│ │
│ 비유: 신입 상담원 → 경력 상담원 → 슈퍼 상담원 │
│ │
│ ⚠️ 한계: 하드웨어 최대치가 있음 (u-12tb1.metal: 12.3TB RAM) │
│ │
└─────────────────────────────────────────────────────────────────┘초보자 설명:
- 인스턴스 크기를 키우는 것
- 더 좋은 CPU, 더 많은 RAM으로 업그레이드
- 비분산 시스템에 적합 (예: 데이터베이스)
- RDS, ElastiCache가 수직 확장 사용
한계:
- 아무리 좋은 컴퓨터도 한계가 있음 (최대 448 vCPU, 12.3TB RAM)
수평 확장 (Horizontal Scaling = Elasticity)
┌─────────────────────────────────────────────────────────────────┐
│ 수평 확장 (Scale Out) │
│ │
│ [EC2] [EC2] [EC2] [EC2] │
│ │ │ │ │ │
│ │ ──추가───→ │ │ │ │
│ │ │ │ │ │
│ │
│ 비유: 상담원 1명 → 상담원 3명 → 상담원 6명 │
│ │
│ ✅ 장점: 이론상 무한 확장 가능! │
│ │
└─────────────────────────────────────────────────────────────────┘초보자 설명:
- 인스턴스 개수를 늘리는 것
- 분산 시스템에 적합 (예: 웹 애플리케이션)
- 클라우드의 장점! (EC2 쉽게 추가/제거)
- Auto Scaling Group + Load Balancer 사용
고가용성 (High Availability)
┌─────────────────────────────────────────────────────────────────┐
│ 고가용성 (HA) │
│ │
│ ┌─ us-east-1a ─┐ ┌─ us-east-1b ─┐ │
│ │ │ │ │ │
│ │ [EC2] [EC2] │ │ [EC2] [EC2] │ │
│ │ │ │ │ │
│ │ 뉴욕 빌딩 │ │ 샌프란 빌딩 │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ⚠️ 뉴욕 빌딩 화재 발생! → 샌프란 빌딩이 트래픽 처리! │
│ │
│ 목표: 데이터센터 장애에도 서비스 지속! │
│ │
└─────────────────────────────────────────────────────────────────┘초보자 설명:
- **최소 2개 이상의 AZ(가용영역)**에서 실행
- 하나가 죽어도 다른 하나가 서비스 유지
- Passive HA: RDS Multi-AZ (대기 상태)
- Active HA: 여러 EC2가 동시에 트래픽 처리
EC2에서의 적용
| 전략 | 방법 | AWS 서비스 |
|---|---|---|
| 수직 확장 | 인스턴스 크기 변경 | 인스턴스 타입 변경 |
| 수평 확장 | 인스턴스 수 변경 | Auto Scaling Group |
| 고가용성 | Multi-AZ 배포 | ASG + Load Balancer |
2. Load Balancer 개요
🤔 Load Balancer가 뭔가요?
비유로 이해하기: 교통 경찰과 같습니다.
- 차(요청)가 많이 오면 여러 도로(서버)로 분산
- 막힌 도로(장애 서버)는 피해서 안내
- 모든 차가 한 도로로 몰리지 않게 조절
┌─────────────────────────────────────────────────────────────────┐
│ Load Balancer │
│ │
│ ┌──────────────┐ │
│ 사용자1 ─┐ │ │ ┌─→ [EC2 #1] │
│ 사용자2 ─┼────────→│ ELB │─────────┼─→ [EC2 #2] │
│ 사용자3 ─┘ │ (교통 경찰) │ └─→ [EC2 #3] │
│ └──────────────┘ │
│ │
│ ✅ 트래픽을 여러 서버에 분산! │
│ │
└─────────────────────────────────────────────────────────────────┘Load Balancer를 쓰는 이유
| 이유 | 설명 | 초보자 설명 |
|---|---|---|
| 부하 분산 | 여러 서버에 트래픽 분배 | 한 서버만 힘들지 않게 |
| 단일 진입점 | 하나의 DNS만 노출 | 사용자는 서버 개수 몰라도 됨 |
| 장애 대응 | 죽은 서버로 안 보냄 | 자동으로 건강한 서버로 |
| Health Check | 서버 상태 확인 | 아픈 서버 자동 감지 |
| SSL 종료 | HTTPS 처리 | 서버 부담 감소 |
| Stickiness | 같은 사용자 → 같은 서버 | 세션 유지 |
| 고가용성 | Multi-AZ | 장애에도 서비스 지속 |
Elastic Load Balancer (ELB)
왜 AWS ELB를 쓰나요?
직접 구축 vs AWS ELB
직접 구축:
❌ 서버 설치/관리 필요
❌ 업그레이드 직접 해야 함
❌ 고가용성 직접 구현
❌ 보안 패치 책임
💰 저렴하지만 시간/노력 많이 필요
AWS ELB:
✅ 완전 관리형 (AWS가 알아서)
✅ 자동 업그레이드/유지보수
✅ 고가용성 내장
✅ 다른 AWS 서비스와 통합
💰 약간 비싸지만 편리함!통합되는 AWS 서비스:
- EC2, Auto Scaling Groups, ECS
- ACM (인증서), CloudWatch
- Route 53, WAF, Global Accelerator
3. Health Check
🤔 Health Check가 뭔가요?
비유로 이해하기: 의사의 건강 검진과 같습니다.
- 주기적으로 서버에 "너 살아있어?" 물어봄
- 대답이 없거나 이상하면 → "이 서버 아프네, 트래픽 안 보낼게"
┌─────────────────────────────────────────────────────────────────┐
│ Health Check │
│ │
│ ELB ──────→ GET /health ──────→ EC2 │
│ │ │ │
│ │ ← 200 OK ←──────────┤ → 건강함! ✅ 트래픽 전송 │
│ │ │ │
│ │ ← 500 Error ←───────┤ → 아픔! ❌ 트래픽 중단 │
│ │ │ │
│ │ ← 타임아웃 ←────────┤ → 죽음! ❌ 트래픽 중단 │
│ │
└─────────────────────────────────────────────────────────────────┘Health Check 설정
| 설정 | 예시 | 설명 |
|---|---|---|
| Protocol | HTTP | 어떤 프로토콜로 확인 |
| Port | 4567 | 어떤 포트로 확인 |
| Endpoint | /health | 어떤 경로로 확인 |
| 성공 조건 | 200 OK | 이 응답이면 건강 |
초보자 팁: 애플리케이션에 /health 엔드포인트를 만들어두세요!
// Express.js 예시
app.get("/health", (req, res) => {
// DB 연결 등 확인 후
res.status(200).send("OK");
});4. Load Balancer 종류
4가지 ELB 비교
| 종류 | 출시 | Layer | 프로토콜 | 주요 용도 |
|---|---|---|---|---|
| CLB (Classic) | 2009 | 4, 7 | HTTP, HTTPS, TCP | 레거시 (사용 비권장) |
| ALB (Application) | 2016 | 7 | HTTP, HTTPS, WebSocket | 웹 애플리케이션 |
| NLB (Network) | 2017 | 4 | TCP, UDP, TLS | 초고성능, 게임 |
| GWLB (Gateway) | 2020 | 3 | IP | 보안 장비 연동 |
🤔 Layer가 뭔가요?
OSI 7계층 모델:
Layer 7 (Application): HTTP, HTTPS ← ALB가 여기서 동작
Layer 6 (Presentation)
Layer 5 (Session)
Layer 4 (Transport): TCP, UDP ← NLB가 여기서 동작
Layer 3 (Network): IP ← GWLB가 여기서 동작
Layer 2 (Data Link)
Layer 1 (Physical)초보자 설명:
- Layer 7 (ALB): URL 경로, 헤더 등 "내용"을 보고 판단
- Layer 4 (NLB): IP, 포트만 보고 빠르게 전달
- Layer 3 (GWLB): IP 패킷 수준에서 처리
5. Application Load Balancer (ALB)
🤔 ALB가 왜 가장 많이 쓰이나요?
비유로 이해하기: 똑똑한 안내 데스크와 같습니다.
- "민원실 어디예요?" → 민원실로 안내
- "세금 납부하러 왔어요" → 세금 창구로 안내
- URL, 헤더 등을 보고 어디로 보낼지 판단
ALB 특징
| 특징 | 설명 |
|---|---|
| Layer 7 | HTTP 레벨에서 동작 |
| 다중 Target Group | 여러 그룹으로 라우팅 |
| HTTP/2 | 최신 프로토콜 지원 |
| WebSocket | 실시간 통신 지원 |
| 리다이렉트 | HTTP → HTTPS |
라우팅 규칙
┌─────────────────────────────────────────────────────────────────┐
│ ALB 라우팅 규칙 │
│ │
│ example.com/users ──→ Target Group 1 (User 서비스) │
│ example.com/products ──→ Target Group 2 (Product 서비스) │
│ │
│ api.example.com ──→ Target Group 3 (API 서버) │
│ web.example.com ──→ Target Group 4 (웹 서버) │
│ │
│ ?platform=mobile ──→ Target Group 5 (모바일 최적화) │
│ ?platform=desktop ──→ Target Group 6 (데스크톱 버전) │
│ │
└─────────────────────────────────────────────────────────────────┘라우팅 기준
| 기준 | 예시 | 설명 |
|---|---|---|
| Path | /users, /posts | URL 경로 |
| Host | api.example.com | 도메인 |
| Query String | ?id=123 | 쿼리 파라미터 |
| Headers | X-Custom-Header | HTTP 헤더 |
Target Group 종류
┌─────────────────────────────────────────────────────────────────┐
│ ALB Target Groups │
│ │
│ 1. EC2 Instances (Auto Scaling Group) │
│ └─ 가장 일반적인 형태 │
│ │
│ 2. ECS Tasks │
│ └─ 컨테이너 환경 │
│ │
│ 3. Lambda Functions │
│ └─ 서버리스! HTTP → JSON 변환 │
│ │
│ 4. IP Addresses (Private IP만) │
│ └─ 온프레미스 서버 연동 │
│ │
└─────────────────────────────────────────────────────────────────┘ALB 알아야 할 것들
고정 호스트명
my-alb-1234567890.ap-northeast-2.elb.amazonaws.com
↑
리전별 고유한 DNS 이름클라이언트 IP 확인 (중요!)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Client ──────→ ALB ──────→ EC2 │
│ (12.34.56.78) │ │ │
│ │ │ │
│ Connection Termination │
│ │ │ │
│ └──Private IP로 연결──→ │
│ │
│ ⚠️ EC2는 Client IP를 직접 볼 수 없음! │
│ │
│ 해결: HTTP 헤더에서 확인 │
│ - X-Forwarded-For: 12.34.56.78 (Client IP) │
│ - X-Forwarded-Port: 443 (Client Port) │
│ - X-Forwarded-Proto: https (Protocol) │
│ │
└─────────────────────────────────────────────────────────────────┘코드 예시 (Express.js):
app.get("/api", (req, res) => {
// 잘못된 방법 (ALB의 IP가 나옴)
console.log(req.ip);
// 올바른 방법 (실제 클라이언트 IP)
const clientIp = req.headers["x-forwarded-for"];
console.log(clientIp); // 12.34.56.78
});6. Network Load Balancer (NLB)
🤔 NLB는 언제 쓰나요?
비유로 이해하기: 초고속 터널과 같습니다.
- ALB처럼 내용을 확인하지 않음
- 그냥 빠르게 통과시킴
- 초당 수백만 요청 처리 가능
NLB 특징
| 특징 | 설명 |
|---|---|
| Layer 4 | TCP/UDP 레벨 |
| 초저지연 | Ultra-low latency |
| 고성능 | 초당 수백만 요청 |
| 고정 IP | AZ당 1개 Static IP |
| Elastic IP | 특정 IP 지정 가능 |
ALB vs NLB 비교
| 항목 | ALB | NLB |
|---|---|---|
| Layer | 7 (HTTP) | 4 (TCP/UDP) |
| 지연시간 | 보통 | 극히 낮음 |
| 처리량 | 높음 | 매우 높음 |
| IP | 변동 | 고정 |
| 라우팅 | URL, 헤더 등 | 포트만 |
| 용도 | 웹 앱 | 게임, IoT, 금융 |
NLB Target Groups
┌─────────────────────────────────────────────────────────────────┐
│ NLB Target Groups │
│ │
│ 1. EC2 Instances │
│ │
│ 2. IP Addresses (Private IP) │
│ │
│ 3. ALB (!) │
│ └─ NLB 앞에 ALB를 둬서 고정 IP + HTTP 라우팅 동시에! │
│ │
└─────────────────────────────────────────────────────────────────┘NLB + ALB 조합:
Client ──→ NLB (고정 IP) ──→ ALB (HTTP 라우팅) ──→ Target Groups
↑ ↑
IP 화이트리스트 URL 기반 라우팅언제 NLB를 쓸까?
| 상황 | 추천 |
|---|---|
| 일반 웹 애플리케이션 | ALB |
| 고정 IP 필요 (화이트리스트) | NLB |
| 초저지연 필요 (게임, 금융) | NLB |
| TCP/UDP 프로토콜 | NLB |
| 초당 수백만 요청 | NLB |
7. Gateway Load Balancer (GWLB)
🤔 GWLB는 뭔가요?
비유로 이해하기: 공항 보안 검색대와 같습니다.
- 모든 승객(트래픽)이 보안 검색대(보안 장비)를 거쳐야 함
- 검사 후 통과하면 탑승구(목적지)로 이동
┌─────────────────────────────────────────────────────────────────┐
│ GWLB 동작 방식 │
│ │
│ Users │
│ │ │
│ ▼ │
│ Route Table │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ GWLB │ │
│ │ (트래픽 분산) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────┐ │
│ │ 3rd Party 보안 장비들 │ │
│ │ [Firewall] [IDS] [DPI] │ │
│ └─────────────────────────────┘ │
│ │ │
│ ▼ │
│ Application │
│ │
└─────────────────────────────────────────────────────────────────┘GWLB 특징
| 특징 | 설명 |
|---|---|
| Layer 3 | IP 패킷 레벨 |
| 용도 | 보안 어플라이언스 연동 |
| 프로토콜 | GENEVE (포트 6081) |
| Target | EC2, IP |
사용 사례
| 사례 | 설명 |
|---|---|
| Firewall | 방화벽 통과 |
| IDS/IPS | 침입 탐지/방지 |
| Deep Packet Inspection | 패킷 내용 검사 |
초보자 팁: 일반적인 웹 개발에서는 거의 사용 안 함. 네트워크 보안 담당자가 주로 사용.
8. Sticky Sessions (Session Affinity)
🤔 Sticky Session이 뭔가요?
비유로 이해하기: 단골 식당에서 항상 같은 웨이터가 서빙하는 것과 같습니다.
- 첫 방문 시 웨이터 A가 담당 → 다음 방문도 웨이터 A가 담당
- 이전 주문 기록(세션)을 웨이터가 알고 있음
┌─────────────────────────────────────────────────────────────────┐
│ Sticky Session 동작 │
│ │
│ Client1 ────────────────────────────→ EC2 #1 │
│ (쿠키: server=ec2-1) (항상 같은 서버!) │
│ │
│ Client2 ────────────────────────────→ EC2 #2 │
│ (쿠키: server=ec2-2) (항상 같은 서버!) │
│ │
│ ⚠️ 주의: 트래픽 불균형 발생 가능! │
│ │
└─────────────────────────────────────────────────────────────────┘쿠키 종류
| 종류 | 생성 주체 | 쿠키 이름 |
|---|---|---|
| Application-based (Custom) | Target (앱) | 자유 (예약어 제외) |
| Application-based (LB) | Load Balancer | AWSALBAPP |
| Duration-based | Load Balancer | AWSALB (ALB), AWSELB (CLB) |
예약어 (사용 금지): AWSALB, AWSALBAPP, AWSALBTG
언제 쓰나요?
| 상황 | Sticky 필요? |
|---|---|
| 로그인 세션이 서버 메모리에 저장됨 | ✅ 필요 |
| Redis/DB에 세션 저장 (Stateless) | ❌ 불필요 |
| 쇼핑 카트가 서버에 저장됨 | ✅ 필요 |
초보자 팁: 가능하면 Stateless 아키텍처를 추천! (Redis, DynamoDB에 세션 저장) → Sticky Session 없이도 어떤 서버든 처리 가능
9. Cross-Zone Load Balancing
🤔 이게 뭔가요?
비유로 이해하기:
- 없을 때: 각 지점이 자기 지역 손님만 받음
- 있을 때: 모든 지점이 전체 손님을 균등하게 나눠 받음
비교 그림
┌─────────────────────────────────────────────────────────────────┐
│ Cross-Zone Load Balancing 없음 │
│ │
│ AZ-1 (2개 EC2) AZ-2 (8개 EC2) │
│ ┌────────────┐ ┌────────────────────────────┐ │
│ │ ELB Node │ │ ELB Node │ │
│ │ 50% │ │ 50% │ │
│ └─────┬──────┘ └─────────────┬──────────────┘ │
│ ┌───┴───┐ ┌───────┴───────┐ │
│ ↓ ↓ ↓ ↓ ↓ ↓ ↓ │
│ [EC2] [EC2] [EC2][EC2][EC2][EC2]... │
│ 25% 25% 6.25% 6.25% ... │
│ │
│ ⚠️ AZ-1의 EC2는 과부하, AZ-2의 EC2는 놀고 있음! │
│ │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ Cross-Zone Load Balancing 있음 │
│ │
│ AZ-1 (2개 EC2) AZ-2 (8개 EC2) │
│ ┌────────────┐ ┌────────────────────────────┐ │
│ │ ELB Node │ │ ELB Node │ │
│ └─────┬──────┘ └─────────────┬──────────────┘ │
│ └──────────────┬────────────────┘ │
│ ↓ │
│ 전체 10개 EC2에 균등 분배 (각 10%) │
│ │
│ [EC2] [EC2] [EC2][EC2][EC2][EC2][EC2][EC2][EC2][EC2] │
│ 10% 10% 10% 10% 10% 10% 10% 10% 10% 10% │
│ │
│ ✅ 모든 EC2가 균등하게 트래픽 받음! │
│ │
└─────────────────────────────────────────────────────────────────┘ELB별 기본 설정
| ELB 종류 | 기본값 | AZ 간 데이터 비용 |
|---|---|---|
| ALB | ✅ 활성화 | 무료 |
| NLB | ❌ 비활성화 | 유료 |
| GWLB | ❌ 비활성화 | 유료 |
| CLB | ❌ 비활성화 | 무료 |
10. SSL/TLS 인증서
🤔 SSL/TLS가 뭔가요?
비유로 이해하기: 신분증 + 암호화된 대화와 같습니다.
- SSL 인증서 = "나는 진짜 이 웹사이트야" 라는 신분증
- TLS 암호화 = 도청 못하게 암호로 대화
SSL/TLS 기본 개념
┌─────────────────────────────────────────────────────────────────┐
│ SSL/TLS 동작 │
│ │
│ Client ←───HTTPS (암호화)───→ ELB ←───HTTP───→ EC2 │
│ (인터넷, 암호화 필수) (VPC 내부, 선택) │
│ │
│ 1. Client가 ELB에 접속 │
│ 2. ELB가 인증서 제시 ("나는 example.com이야") │
│ 3. Client가 인증서 확인 (CA가 발급한 거 맞네!) │
│ 4. 암호화된 통신 시작 │
│ │
└─────────────────────────────────────────────────────────────────┘인증서 관리
| 방법 | 설명 |
|---|---|
| ACM (AWS Certificate Manager) | AWS에서 무료 인증서 발급/관리 |
| 직접 업로드 | 외부에서 구매한 인증서 사용 |
SNI (Server Name Indication)
문제: 하나의 서버에 여러 도메인 → 어떤 인증서를 보여줄까? 해결: 클라이언트가 "나 example.com 접속할 거야" 라고 미리 알려줌
┌─────────────────────────────────────────────────────────────────┐
│ SNI 동작 │
│ │
│ Client: "www.mycorp.com 접속할게요" │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ ALB │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ 인증서 1: www.mycorp.com │ ← 이거 사용! │
│ │ │ 인증서 2: api.example.com │ │
│ │ │ 인증서 3: shop.mysite.com │ │
│ │ └─────────────────────────────┘ │ │
│ └─────────────────────────────────────┘ │
│ │
│ ⚠️ SNI는 ALB, NLB, CloudFront만 지원 (CLB는 미지원!) │
│ │
└─────────────────────────────────────────────────────────────────┘ELB별 SSL 인증서 지원
| ELB | 다중 인증서 | SNI |
|---|---|---|
| CLB | ❌ (1개만) | ❌ |
| ALB | ✅ | ✅ |
| NLB | ✅ | ✅ |
11. Connection Draining / Deregistration Delay
🤔 이게 뭔가요?
비유로 이해하기: 퇴근 시간에 마지막 손님 응대 완료하는 것과 같습니다.
- "이제 퇴근이라 새 손님 안 받아요" (새 요청 차단)
- "하지만 지금 응대 중인 손님은 끝까지 도와드릴게요" (기존 요청 완료)
┌─────────────────────────────────────────────────────────────────┐
│ Connection Draining │
│ │
│ EC2 #1 [DRAINING] │
│ │ │
│ ├─ 기존 연결: 응답 완료까지 대기 ⏳ │
│ │ │
│ └─ 새 연결: ❌ 차단 (다른 EC2로 전달) │
│ │
│ EC2 #2 [정상] │
│ │ │
│ └─ 새 연결: ✅ 모두 여기로! │
│ │
└─────────────────────────────────────────────────────────────────┘설정
| 항목 | 값 |
|---|---|
| 기본값 | 300초 (5분) |
| 범위 | 1 ~ 3600초 |
| 비활성화 | 0으로 설정 |
설정 가이드:
- 짧은 요청 (API) → 낮은 값 (30초)
- 긴 요청 (파일 업로드) → 높은 값 (300초)
12. Auto Scaling Group (ASG)
🤔 Auto Scaling이 뭔가요?
비유로 이해하기: 자동 직원 채용/해고 시스템과 같습니다.
- 손님 많아짐 → 직원 더 채용 (Scale Out)
- 손님 줄어듦 → 직원 줄임 (Scale In)
- 최소 2명, 최대 10명 유지
┌─────────────────────────────────────────────────────────────────┐
│ Auto Scaling Group │
│ │
│ Minimum: 2 Desired: 4 Maximum: 10 │
│ (최소) (희망) (최대) │
│ │
│ [EC2][EC2] [EC2][EC2][EC2][EC2] 최대 10개 │
│ ↑ ↑ ↑ │
│ │ │ │ │
│ "절대 이 이하로 "평소엔 이 정도로" "아무리 바빠도 │
│ 줄이지 마!" 이 이상은 안 돼" │
│ │
└─────────────────────────────────────────────────────────────────┘ASG 기능
| 기능 | 설명 |
|---|---|
| Scale Out | 인스턴스 추가 (부하 증가 시) |
| Scale In | 인스턴스 제거 (부하 감소 시) |
| 최소/최대 유지 | 항상 범위 내 개수 유지 |
| 자동 등록 | 새 인스턴스 자동으로 ELB에 등록 |
| 자동 복구 | Unhealthy 인스턴스 교체 |
💰 비용: ASG 자체는 무료! (EC2 인스턴스 비용만 발생)
Launch Template
ASG가 EC2를 만들 때 사용하는 "설계도"
┌─────────────────────────────────────────────────────────────────┐
│ Launch Template │
│ │
│ ├─ AMI: ami-12345 (Amazon Linux 2) │
│ ├─ Instance Type: t3.medium │
│ ├─ Security Group: sg-web │
│ ├─ SSH Key: my-key │
│ ├─ IAM Role: EC2-S3-Access │
│ ├─ User Data: #!/bin/bash ... │
│ ├─ EBS: 20GB gp3 │
│ └─ Network: VPC, Subnet 정보 │
│ │
│ → ASG는 이 설계도대로 똑같은 EC2를 찍어냄! │
│ │
└─────────────────────────────────────────────────────────────────┘13. Scaling Policies (스케일링 정책)
🤔 언제 스케일링 할까요?
1️⃣ Target Tracking Scaling (가장 쉬움!)
"평균 CPU 사용률을 40%로 유지해줘"
CPU 50% → Scale Out (인스턴스 추가)
CPU 30% → Scale In (인스턴스 제거)
마치 에어컨 온도 설정처럼 자동 조절!장점: 설정 간단, AWS가 알아서 조절
2️⃣ Simple / Step Scaling
CloudWatch Alarm 기반:
CPU > 70% 알람 발생 → 인스턴스 2개 추가
CPU < 30% 알람 발생 → 인스턴스 1개 제거
Step (단계별):
CPU 70~80% → 1개 추가
CPU 80~90% → 2개 추가
CPU > 90% → 4개 추가장점: 세밀한 제어 가능
3️⃣ Scheduled Scaling (예약 스케일링)
"매주 금요일 5pm에 최소 인스턴스를 10개로 늘려줘"
사용 사례:
- 주말 트래픽 증가 예상
- 세일 이벤트 예정
- 정기 배치 작업장점: 예측 가능한 트래픽 대응
4️⃣ Predictive Scaling (예측 스케일링)
┌─────────────────────────────────────────────────────────────────┐
│ Predictive Scaling │
│ │
│ 과거 데이터 분석 → ML로 예측 → 미리 스케일링! │
│ │
│ 트래픽 │
│ ↑ ┌───실제 트래픽 │
│ │ ╱ ╲ │
│ │ ╱ ╲ ┌───예측 │
│ │ ╱ ╲ ╱ │
│ │──╱───────╲──╱────── │
│ │ 시간→ │
│ │
│ 장점: 스케일링이 트래픽보다 먼저 일어남! │
│ │
└─────────────────────────────────────────────────────────────────┘좋은 스케일링 지표
| 지표 | 설명 | 사용 사례 |
|---|---|---|
| CPUUtilization | CPU 사용률 | 일반적 |
| RequestCountPerTarget | EC2당 요청 수 | 웹 서버 |
| NetworkIn/Out | 네트워크 트래픽 | 데이터 처리 |
| Custom Metric | 직접 정의 | 특수 상황 |
14. Scaling Cooldown
🤔 Cooldown이 뭔가요?
비유로 이해하기: 스케일링 후 쉬는 시간입니다.
- 방금 인스턴스 추가했는데 또 추가하면?
- 새 인스턴스가 아직 준비도 안 됐는데!
- → 잠깐 기다리고 상황 보자 (Cooldown)
┌─────────────────────────────────────────────────────────────────┐
│ Scaling Cooldown │
│ │
│ Scale Out 발생 → Cooldown 시작 (기본 300초) │
│ │ │ │
│ │ 이 동안 추가 스케일링 안 함 │
│ │ │ │
│ ▼ ▼ │
│ [EC2 추가됨] [지표 안정화 대기] │
│ │ │
│ ▼ │
│ Cooldown 끝 → 다시 스케일링 가능 │
│ │
└─────────────────────────────────────────────────────────────────┘팁: Ready-to-use AMI 사용하면 설정 시간 줄어서 Cooldown 단축 가능!
15. Instance Refresh
🤔 이게 뭔가요?
비유로 이해하기: 직원 전체 교육과 같습니다.
- 새 매뉴얼(Launch Template) 나왔다!
- 기존 직원들도 새 매뉴얼대로 바꿔야 함
- 한 번에 다 바꾸면 업무 마비!
- → 한 명씩 순차적으로 교체
┌─────────────────────────────────────────────────────────────────┐
│ Instance Refresh │
│ │
│ 기존: Old Template으로 만든 EC2들 │
│ [EC2-old] [EC2-old] [EC2-old] [EC2-old] [EC2-old] │
│ │
│ Instance Refresh 시작 (Min Healthy: 60%) │
│ │
│ Step 1: [EC2-old] [EC2-old] [EC2-old] [EC2-new] [종료 중] │
│ Step 2: [EC2-old] [EC2-old] [EC2-new] [EC2-new] [종료 중] │
│ Step 3: [EC2-old] [EC2-new] [EC2-new] [EC2-new] [종료 중] │
│ ... │
│ 완료: [EC2-new] [EC2-new] [EC2-new] [EC2-new] [EC2-new] │
│ │
│ ✅ 서비스 중단 없이 전체 교체 완료! │
│ │
└─────────────────────────────────────────────────────────────────┘설정
| 설정 | 설명 |
|---|---|
| Min Healthy Percentage | 최소 유지 비율 (예: 60%) |
| Warm-up Time | 새 인스턴스 준비 시간 |
핵심 요약
ELB 선택 가이드
| 상황 | 추천 |
|---|---|
| 일반 웹 애플리케이션 | ALB |
| 초고성능, 게임, 금융 | NLB |
| 고정 IP 필요 | NLB |
| 보안 어플라이언스 | GWLB |
| 레거시 | CLB (비권장) |
스케일링 정책 선택
| 상황 | 추천 |
|---|---|
| 간단하게 | Target Tracking |
| 세밀하게 | Simple/Step |
| 예측 가능 | Scheduled |
| ML 기반 | Predictive |