개념 01
왜 로드밸런서가 필요한가
서버 한 대만 운영하면 그 서버가 장애를 일으키는 순간 서비스 전체가 중단될 수 있습니다. 또 트래픽이 증가해도 한 대가 모든 요청을 감당해야 합니다.
Elastic Load Balancing(ELB)은 여러 대상에 요청을 분산하고, 헬스 체크에 실패한 대상에는 새 요청을 보내지 않습니다. 여기에 EC2 Auto Scaling을 연결하면 필요한 인스턴스 수까지 자동으로 조절할 수 있습니다.
사용자
→
ALB
→
EC2 #1
EC2 #2
ASG가 증감
고가용성은 “큰 서버 1대”가 아니라 “여러 장애 단위에 분산”하는 설계입니다.
일반적인 웹 서비스는 서로 다른 AZ의 여러 대상에 트래픽을 분산해 한 AZ나 한 인스턴스의 장애 영향을 줄입니다.
일반적인 웹 서비스는 서로 다른 AZ의 여러 대상에 트래픽을 분산해 한 AZ나 한 인스턴스의 장애 영향을 줄입니다.
개념 02
ALB vs NLB — 언제 무엇을 쓰나
| 구분 | ALB | NLB |
|---|---|---|
| 주요 계층 | L7 — HTTP/HTTPS | L4 — TCP/UDP/TLS |
| 라우팅 | 호스트, 경로, 헤더, 쿼리 등 애플리케이션 조건 | IP와 포트 중심의 네트워크 연결 |
| 대상 유형 | 인스턴스, IP, Lambda 등 | 인스턴스, IP, ALB 등 지원 유형 |
| 고정 IP 요구 | DNS 이름 사용이 기본 | AZ별 고정 IP 특성을 활용 가능, 인터넷용은 EIP 지정 가능 |
| 대표 용도 | 웹, REST API, 마이크로서비스 | 고성능 TCP/UDP, 고정 IP가 필요한 연결 |
일반 웹·API라면 ALB부터 생각하면 됩니다.
예를 들어
예를 들어
api.example.com은 API 대상 그룹으로, /admin/*은 관리자 대상 그룹으로 보내는 식의 L7 라우팅이 가능합니다.로드밸런서는 과금 리소스입니다.
시간과 처리 용량 단위에 따라 비용이 발생하며 정확한 금액은 리전과 현재 AWS 가격표에 따라 달라집니다. 실습용 로드밸런서는 끝나면 삭제합니다.
시간과 처리 용량 단위에 따라 비용이 발생하며 정확한 금액은 리전과 현재 AWS 가격표에 따라 달라집니다. 실습용 로드밸런서는 끝나면 삭제합니다.
개념 03
ALB 구성 요소
| 구성 요소 | 역할 | 예시 |
|---|---|---|
| 리스너 | 어떤 프로토콜·포트로 연결을 받을지 정의 | HTTP 80, HTTPS 443 |
| 리스너 규칙 | 조건에 따라 전달·리다이렉트·고정 응답 수행 | /api/* → API 대상 그룹 |
| 대상 그룹 | 실제 요청을 처리할 대상의 논리적 묶음 | EC2 2대, 컨테이너 IP |
| 헬스 체크 | 대상이 요청을 받을 수 있는 상태인지 주기적으로 검사 | /health 200 응답 |
요청이 흘러가는 순서
DNS로 ALB 도착
→
리스너 수신
→
규칙 평가
→
Healthy 대상 전달
개념 04
헬스 체크 — 살아있는 서버만 트래픽 받게 하기
대상 그룹은 각 대상의 상태를 확인합니다. 일정 횟수 이상 실패하면 unhealthy로 판단해 로드밸런서의 정상 트래픽 대상에서 제외하고, 다시 성공 기준을 만족하면 복귀시킵니다.
좋은 헬스 체크
애플리케이션이 실제 요청을 처리할 준비가 되었는지 빠르게 확인하고, 외부 시스템 장애에 지나치게 의존하지 않는 경량 엔드포인트를 사용합니다.
애플리케이션이 실제 요청을 처리할 준비가 되었는지 빠르게 확인하고, 외부 시스템 장애에 지나치게 의존하지 않는 경량 엔드포인트를 사용합니다.
주의할 헬스 체크
DB·외부 API를 모두 호출하는 무거운 검사 하나에 의존하면 일시적인 외부 장애가 전체 서버를 unhealthy로 만들 수 있습니다.
DB·외부 API를 모두 호출하는 무거운 검사 하나에 의존하면 일시적인 외부 장애가 전체 서버를 unhealthy로 만들 수 있습니다.
unhealthy일 때 확인 순서
| 순서 | 확인 | 대표 원인 |
|---|---|---|
| 1 | 앱 프로세스 | 애플리케이션 미기동 또는 재시작 반복 |
| 2 | 헬스 체크 경로·응답코드 | 경로 오타, 301/401/500 등 예상 외 응답 |
| 3 | 포트 | 대상 그룹 포트와 앱 리스닝 포트 불일치 |
| 4 | 보안 그룹 | EC2가 ALB 보안 그룹의 트래픽을 허용하지 않음 |
| 5 | 네트워크 경로 | NACL, 라우팅, 잘못된 대상 등록 |
실습 01
ALB + HTTPS 구성 흐름
HTTPS 웹 서비스를 구성할 때는 인증서, 리스너, 대상 그룹, 보안 그룹, DNS를 하나의 흐름으로 이해하면 쉽습니다.
ACM 인증서
→
대상 그룹
→
ALB 생성
→
HTTPS 443
→
DNS 연결
| 단계 | 핵심 작업 |
|---|---|
| 1. 인증서 | ACM에서 서비스 도메인 인증서를 발급하고 DNS 등으로 도메인 소유권 검증 |
| 2. 대상 그룹 | 애플리케이션 포트와 헬스 체크 경로를 지정하고 대상 등록 |
| 3. ALB | 인터넷 공개용이면 internet-facing으로 생성하고 서로 다른 AZ의 서브넷을 활성화 |
| 4. 리스너 | HTTPS 443에 ACM 인증서를 연결하고 대상 그룹으로 전달. 필요하면 HTTP 80을 HTTPS로 리다이렉트 |
| 5. 보안 그룹 | ALB는 필요한 외부 포트만, EC2 앱 포트는 소스를 ALB 보안 그룹으로 제한 |
| 6. DNS | Route 53 등 DNS에서 서비스 도메인을 ALB DNS 이름으로 연결 |
외부 사용자가 EC2 앱 포트로 직접 들어오게 만들지 마세요.
예를 들어 애플리케이션이 8080을 사용한다면 EC2 보안 그룹의 8080 소스를 ALB 보안 그룹으로 제한하는 패턴이 일반적입니다.
예를 들어 애플리케이션이 8080을 사용한다면 EC2 보안 그룹의 8080 소스를 ALB 보안 그룹으로 제한하는 패턴이 일반적입니다.
개념 05
Auto Scaling Group — 인스턴스 수를 자동으로 유지
Auto Scaling Group(ASG)은 지정한 최소·최대·희망 용량 범위 안에서 EC2 인스턴스 수를 유지합니다. 인스턴스가 비정상이면 교체하고, 스케일링 정책에 따라 수를 늘리거나 줄일 수 있습니다.
| 구성 요소 | 역할 |
|---|---|
| 시작 템플릿 | AMI, 인스턴스 유형, 보안 그룹, IAM 역할, 유저 데이터 등 새 EC2의 생성 설정 |
| 최소 용량 | ASG가 유지할 최소 인스턴스 수 |
| 희망 용량 | 현재 유지하려는 목표 인스턴스 수 |
| 최대 용량 | 자동 확장할 수 있는 상한 |
| 대상 그룹 연결 | ASG가 만든 인스턴스를 로드밸런서 대상 그룹에 자동 등록 |
ASG가 있다고 자동으로 “CPU 70%면 1대 추가”되는 것은 아닙니다.
최소·희망·최대 용량은 인스턴스 수의 경계이고, 실제 증감 조건은 별도의 스케일링 정책에서 정합니다.
최소·희망·최대 용량은 인스턴스 수의 경계이고, 실제 증감 조건은 별도의 스케일링 정책에서 정합니다.
개념 06
스케일링 정책과 워밍업
| 정책 | 작동 방식 | 적합한 상황 |
|---|---|---|
| Target Tracking | 평균 CPU나 ALB 요청량 같은 지표를 목표값 근처로 유지하도록 자동 조정 | 대부분의 일반 서비스 |
| Step Scaling | 알람의 초과 정도에 따라 서로 다른 증감 폭 적용 | 임계값별 세밀한 제어 |
| Scheduled Scaling | 정해진 시간에 미리 용량 변경 | 출근 시간·이벤트 등 예측 가능한 패턴 |
| Predictive Scaling | 과거 패턴을 바탕으로 필요한 용량을 예측해 준비 | 반복성이 있는 대규모 트래픽 패턴 |
인스턴스 워밍업이 필요한 이유
새 EC2는 생성 직후 바로 정상 부하를 처리하지 못할 수 있습니다. OS 부팅, 애플리케이션 시작, JVM 워밍업, 캐시 준비 시간이 필요하기 때문입니다. 인스턴스 워밍업을 고려하지 않으면 새 서버가 준비되기도 전에 지표가 다시 악화되어 불필요한 추가 확장이 반복될 수 있습니다.
Scale Out
사용량 증가 → 새 인스턴스 생성 → 헬스 체크 통과 → 대상 그룹에서 트래픽 수신.
사용량 증가 → 새 인스턴스 생성 → 헬스 체크 통과 → 대상 그룹에서 트래픽 수신.
Scale In
부하 감소 → 필요 없는 인스턴스 축소. 너무 공격적인 축소는 재확장을 반복하는 진동을 만들 수 있으므로 정책을 안정적으로 잡습니다.
부하 감소 → 필요 없는 인스턴스 축소. 너무 공격적인 축소는 재확장을 반복하는 진동을 만들 수 있으므로 정책을 안정적으로 잡습니다.
개념 07
실무 설계 — ALB + ASG + Multi-AZ
인터넷
→
ALB · 2+ AZ
→
ASG · AZ-a
ASG · AZ-b
| 설계 포인트 | 이유 |
|---|---|
| 서로 다른 AZ 사용 | 하나의 AZ 장애가 전체 서비스 장애로 이어지는 위험을 줄임 |
| 앱 서버는 직접 인터넷 노출 최소화 | 외부 진입점을 ALB로 집중해 보안 정책 단순화 |
| 세션을 서버 로컬에만 저장하지 않기 | 어느 인스턴스로 요청이 가도 동일한 사용자 상태를 처리하도록 설계 |
| 시작 템플릿 자동화 | 새 인스턴스가 사람 손 없이 동일한 상태로 시작되어야 Auto Scaling이 의미 있음 |
| CloudWatch 지표 관찰 | CPU만이 아니라 요청 수, 응답 시간, 오류율 등 실제 병목과 맞는 지표 선택 |
핵심 정리
CH04 핵심 개념 요약
📌 ELB · Auto Scaling 한눈에 보기
ALBL7 HTTP/HTTPS 로드밸런서. 애플리케이션 조건 기반 라우팅에 적합.
NLBL4 TCP/UDP/TLS 중심. 고성능 네트워크 연결이나 고정 IP 요구에 활용.
리스너수신 프로토콜·포트와 전달 규칙의 시작점.
대상 그룹실제 요청을 처리할 대상 묶음. 헬스 체크 상태와 연결.
헬스 체크비정상 대상을 트래픽에서 제외하고 회복 시 다시 포함.
ASG최소·희망·최대 범위에서 인스턴스 수를 유지하고 비정상 인스턴스를 교체.
Scaling PolicyTarget Tracking, Step, Scheduled, Predictive 방식으로 용량 증감을 결정.
Warmup새 인스턴스가 실제 부하를 받을 준비가 될 때까지의 시간을 정책에 반영.