[AWS] ELB와 ASG

Nov 16, 2025

Contents

확장성(Scalability)ELB (Elastic Load Balancer)ELB 타입 비교 Cross-Zone Load Balancing Auto Scaling Group (ASG)확장 쿨다운(Scaling Cooldown)실전 아키텍처 패턴 연결 드레이닝(Connection Draining)모니터링 및 알림 비용 최적화 전략 트러블슈팅

프로덕션 환경에서는 단일 서버로는 안정적인 서비스를 제공하기 어렵기 때문에 트래픽 분산과 자동 확장을 구현한다.

확장성(Scalability)

수직 확장(Vertical Scaling)

인스턴스의 크기를 늘림

t3.micro → t3.large → m5.xlarge

장점:

구현이 간단

애플리케이션 수정 불필요

단점:

확장 한계 존재

다운타임 발생

단일 장애점

Before: [t3.micro - 1GB RAM]
After:  [m5.xlarge - 16GB RAM]

수평 확장(Horizontal Scaling)

인스턴스의 개수를 늘림

1대 → 3대 → 10대

장점:

무제한 확장 가능

고가용성 확보

장애 격리

단점:

복잡한 설계 필요

로드 밸런서 필요

상태 관리 고려

Before: [EC2] 
After:  [EC2] [EC2] [EC2] [EC2] [EC2]

ELB (Elastic Load Balancer)

AWS 관리형 로드 밸런서

트래픽을 여러 대상으로 분산

자동 확장 및 고가용성 제공

ELB의 주요 기능

1. 헬스 체크

Load Balancer
    ↓ /health 요청
┌─────────┬─────────┬─────────┐
│ EC2 ✅  │ EC2 ✅  │ EC2 ❌  │
│ 200 OK  │ 200 OK  │ 500 Error│
└─────────┴─────────┴─────────┘
         ↑         ↑
트래픽 전송        트래픽 차단

2. SSL/TLS 종료

HTTPS 복호화를 로드 밸런서에서 처리

EC2 인스턴스의 부담 감소

중앙화된 인증서 관리

3. 고정 세션(Sticky Session)

동일 사용자의 요청을 같은 인스턴스로 전송

쿠키 기반 구현

상태 유지가 필요한 애플리케이션에 유용

4. 다중 AZ 배포

Internet
    ↓
[Load Balancer]
    ↓
┌────────────┬────────────┐
│   AZ-A     │   AZ-C     │
│   [EC2]    │   [EC2]    │
└────────────┴────────────┘

ELB 타입 비교

1. Application Load Balancer (ALB) - Layer 7

특징:

HTTP/HTTPS 트래픽 전용

URL 경로 기반 라우팅

호스트 기반 라우팅

웹소켓, HTTP/2 지원

라우팅 규칙 예시:

example.com/api/*    → API 서버 그룹
example.com/images/* → 이미지 서버 그룹
example.com/admin/*  → 관리자 서버 그룹

api.example.com      → API 서버 그룹
web.example.com      → 웹 서버 그룹

대상 그룹(Target Group):

EC2 인스턴스

ECS 작업

Lambda 함수

IP 주소

사용 사례:

마이크로서비스 아키텍처

컨테이너 기반 애플리케이션

서버리스 애플리케이션


# ALB 생성
aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-12345678 subnet-87654321 \
  --security-groups sg-12345678

# 대상 그룹 생성
aws elbv2 create-target-group \
  --name my-targets \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-12345678 \
  --health-check-path /health

# 리스너 생성
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:... \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:...

2. Network Load Balancer (NLB) - Layer 4

특징:

TCP/UDP 트래픽 처리

초당 수백만 건의 요청 처리

매우 낮은 지연시간 (밀리초 미만)

고정 IP 지원 (Elastic IP 할당 가능)

성능:

ALB: ~50,000 요청/초

NLB: ~수백만 연결/초

사용 사례:

게임 서버

IoT 애플리케이션

금융 거래 시스템

레거시 애플리케이션 (비HTTP)


# NLB 생성
aws elbv2 create-load-balancer \
  --name my-nlb \
  --type network \
  --subnets subnet-12345678 subnet-87654321

3. Gateway Load Balancer (GWLB)

특징:

Layer 3 (IP 패킷) 수준 작동

보안 어플라이언스 배포 및 확장

사용 사례:

방화벽

침입 탐지/방지 시스템

네트워크 모니터링

4. Classic Load Balancer (CLB) - 레거시

2009년 출시된 구세대 로드 밸런서

신규 사용 권장하지 않음

ALB 또는 NLB로 마이그레이션 권장

Cross-Zone Load Balancing

비활성화 시

AZ-A: [ELB] → [EC2-1] [EC2-2]
              ↓
          트래픽 50%

AZ-B: [ELB] → [EC2-3]
              ↓
          트래픽 50%

결과: EC2-3에 과부하

활성화 시

[ELB] → 모든 AZ의 모든 인스턴스로 균등 분산
    ↓
EC2-1: 33.3%
EC2-2: 33.3%
EC2-3: 33.3%

기본 설정:

ALB: 기본 활성화 (비용 무료)

NLB: 기본 비활성화 (AZ 간 데이터 전송 비용 발생)

CLB: 기본 비활성화

Auto Scaling Group (ASG)

EC2 인스턴스를 자동으로 확장/축소

목표: 최소/최대 인스턴스 수 유지

비용 최적화 + 가용성 보장

ASG 주요 구성 요소

1. Launch Template (시작 템플릿)

yaml

Launch Template:
  - AMI ID
  - Instance Type
  - Key Pair
  - Security Groups
  - User Data
  - IAM Role
  - EBS Volumes

2. 크기 설정

Minimum Capacity: 2  (최소 인스턴스)
Desired Capacity: 4  (원하는 인스턴스)
Maximum Capacity: 10 (최대 인스턴스)

3. 헬스 체크

EC2 상태 체크 (기본)

ELB 상태 체크 (권장)

Unhealthy 인스턴스 자동 교체

ASG 생성


# 시작 템플릿 생성
aws ec2 create-launch-template \
  --launch-template-name my-template \
  --version-description "Version 1" \
  --launch-template-data file://template.json

# ASG 생성
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --launch-template LaunchTemplateName=my-template \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 4 \
  --vpc-zone-identifier "subnet-12345678,subnet-87654321" \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --target-group-arns arn:aws:elasticloadbalancing:...

확장 정책(Scaling Policies)

1. 대상 추적 확장(Target Tracking)

가장 간단하고 권장되는 방식

목표: 평균 CPU 사용률 50% 유지

CPU < 50% → 인스턴스 제거
CPU > 50% → 인스턴스 추가


# 대상 추적 정책 생성
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name target-tracking-cpu \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 50.0
  }'

추적 가능한 지표:

CPU 사용률

네트워크 입출력

ALB 요청 수

사용자 정의 CloudWatch 지표

2. 단계 확장(Step Scaling)

세밀한 제어가 필요할 때 사용

CPU 사용률 기준:
30-50%: 변화 없음
50-70%: +1 인스턴스
70-90%: +2 인스턴스
90%+:   +3 인스턴스


# CloudWatch 경보 생성
aws cloudwatch put-metric-alarm \
  --alarm-name high-cpu \
  --alarm-description "CPU above 70%" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 70 \
  --comparison-operator GreaterThanThreshold

# 단계 확장 정책 생성
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name step-scaling-cpu \
  --policy-type StepScaling \
  --adjustment-type PercentChangeInCapacity \
  --metric-aggregation-type Average \
  --step-adjustments '[
    {"MetricIntervalLowerBound": 0, "MetricIntervalUpperBound": 20, "ScalingAdjustment": 1},
    {"MetricIntervalLowerBound": 20, "ScalingAdjustment": 2}
  ]'

3. 단순 확장(Simple Scaling) - 레거시

한 번에 하나의 조정만 수행

쿨다운 기간 대기 필요

권장하지 않음 (Step Scaling 사용 권장)

4. 예약 확장(Scheduled Scaling)

예측 가능한 트래픽 패턴에 사용


# 평일 오전 9시에 확장
aws autoscaling put-scheduled-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name morning-scale-up \
  --recurrence "0 9 * * 1-5" \
  --desired-capacity 10

# 평일 오후 6시에 축소
aws autoscaling put-scheduled-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name evening-scale-down \
  --recurrence "0 18 * * 1-5" \
  --desired-capacity 4

5. 예측 확장(Predictive Scaling)

머신러닝으로 과거 패턴을 분석하여 미리 확장

과거 데이터 분석:
매주 월요일 오전 9시 트래픽 급증
→ 월요일 오전 8시 50분에 미리 확장

확장 쿨다운(Scaling Cooldown)

확장 작업 후 대기 시간

새 인스턴스가 안정화될 시간 제공

기본값: 300초 (5분)

작동 방식

1. CPU 80% → 인스턴스 추가
2. 쿨다운 시작 (5분)
3. 5분 동안 추가 확장 작업 차단
4. 5분 후 다시 평가

최적화

인스턴스가 빠르게 준비되면 쿨다운 시간 단축

AMI에 애플리케이션 미리 포함

User Data 스크립트 최적화

실전 아키텍처 패턴

패턴 1: 기본 웹 애플리케이션

Internet
    ↓
[Application Load Balancer]
    ↓
[Auto Scaling Group]
├── [EC2-1] AZ-A
├── [EC2-2] AZ-A
├── [EC2-3] AZ-C
└── [EC2-4] AZ-C
    ↓
[RDS Multi-AZ]

설정:

Minimum: 2 (각 AZ에 1개)

Desired: 4

Maximum: 10

Target Tracking: CPU 50%

패턴 2: 마이크로서비스

Internet
    ↓
[ALB - Main]
    ↓
├─→ /api/users    → [ALB - Users]  → [ASG - User Service]
├─→ /api/orders   → [ALB - Orders] → [ASG - Order Service]
└─→ /api/products → [ALB - Products] → [ASG - Product Service]

패턴 3: 스팟 인스턴스 혼합

[Auto Scaling Group]
├── On-Demand: 2개 (기본 용량)
└── Spot: 0-8개 (확장 용량)
    └── Instance Types:
        - t3.medium (40%)
        - t3a.medium (30%)
        - t2.medium (30%)

비용 절감:

스팟 인스턴스로 최대 90% 절감

다양한 인스턴스 타입으로 가용성 확보


# 혼합 인스턴스 정책
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-mixed-asg \
  --mixed-instances-policy '{
    "LaunchTemplate": {...},
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 2,
      "OnDemandPercentageAboveBaseCapacity": 0,
      "SpotAllocationStrategy": "capacity-optimized"
    },
    "Overrides": [
      {"InstanceType": "t3.medium"},
      {"InstanceType": "t3a.medium"},
      {"InstanceType": "t2.medium"}
    ]
  }'

연결 드레이닝(Connection Draining)

인스턴스 제거 시 진행 중인 요청 완료 대기

새 요청은 차단하고 기존 요청만 처리

기본값: 300초

1. ASG가 인스턴스 제거 결정
2. ELB가 새 요청 차단
3. 기존 요청 처리 완료 대기 (최대 300초)
4. 인스턴스 종료

모니터링 및 알림

CloudWatch 대시보드 구성

주요 지표:

GroupDesiredCapacity: 원하는 인스턴스 수 - GroupInServiceInstances: 서비스 중인 인스턴스 - GroupMinSize / GroupMaxSize: 최소/최대 크기 - TargetResponseTime: 응답 시간 - UnHealthyHostCount: 비정상 호스트 수

SNS 알림 설정


# ASG 알림 설정
aws autoscaling put-notification-configuration \
  --auto-scaling-group-name my-asg \
  --topic-arn arn:aws:sns:region:account-id:my-topic \
  --notification-types \
    "autoscaling:EC2_INSTANCE_LAUNCH" \
    "autoscaling:EC2_INSTANCE_TERMINATE" \
    "autoscaling:EC2_INSTANCE_LAUNCH_ERROR" \
    "autoscaling:EC2_INSTANCE_TERMINATE_ERROR"

비용 최적화 전략

1. 적절한 인스턴스 타입 선택


# AWS Compute Optimizer로 권장 사항 확인
aws compute-optimizer get-auto-scaling-group-recommendations \
  --auto-scaling-group-arns arn:aws:autoscaling:...

2. 스팟 인스턴스 활용

개발/테스트 환경: 100% 스팟

프로덕션: 온디맨드 + 스팟 혼합

3. 예약 인스턴스

최소 용량은 예약 인스턴스로 커버

확장 용량은 온디맨드/스팟

4. 스케줄링 최적화

근무 시간 (9시-18시): Desired 10
야간 (18시-9시): Desired 2
주말: Desired 2

트러블슈팅

문제 1: 인스턴스가 계속 종료됨

원인:

헬스 체크 실패

애플리케이션 시작 시간 부족

해결:


# 헬스 체크 유예 기간 증가
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --health-check-grace-period 600

문제 2: 확장이 느림

원인:

긴 User Data 스크립트

큰 AMI 크기

해결:

애플리케이션을 AMI에 미리 포함

스크립트 최적화

워밍업 준비 (Warm Pool 사용)

문제 3: 비용 증가

원인:

축소 정책 부재

쿨다운 시간 과다

해결:

스케일 인(축소) 정책 추가

CloudWatch로 사용률 모니터링

비정상 확장 패턴 분석

💡

ELB와 Auto Scaling은 현대적인 클라우드 아키텍처의 필수 요소

ALB로 Layer 7 트래픽 라우팅

NLB로 고성능 Layer 4 처리

ASG로 자동 확장 및 고가용성 확보

Target Tracking이 가장 간단하고 효과적

스팟 인스턴스로 비용 최적화

Contents

# ALB 생성 aws elbv2 create-load-balancer \ --name my-alb \ --subnets subnet-12345678 subnet-87654321 \ --security-groups sg-12345678 # 대상 그룹 생성 aws elbv2 create-target-group \ --name my-targets \ --protocol HTTP \ --port 80 \ --vpc-id vpc-12345678 \ --health-check-path /health # 리스너 생성 aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:... \ --protocol HTTP \ --port 80 \ --default-actions Type=forward,TargetGroupArn=arn:...

# 시작 템플릿 생성 aws ec2 create-launch-template \ --launch-template-name my-template \ --version-description "Version 1" \ --launch-template-data file://template.json # ASG 생성 aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name my-asg \ --launch-template LaunchTemplateName=my-template \ --min-size 2 \ --max-size 10 \ --desired-capacity 4 \ --vpc-zone-identifier "subnet-12345678,subnet-87654321" \ --health-check-type ELB \ --health-check-grace-period 300 \ --target-group-arns arn:aws:elasticloadbalancing:...

# 대상 추적 정책 생성 aws autoscaling put-scaling-policy \ --auto-scaling-group-name my-asg \ --policy-name target-tracking-cpu \ --policy-type TargetTrackingScaling \ --target-tracking-configuration '{ "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" }, "TargetValue": 50.0 }'

# CloudWatch 경보 생성 aws cloudwatch put-metric-alarm \ --alarm-name high-cpu \ --alarm-description "CPU above 70%" \ --metric-name CPUUtilization \ --namespace AWS/EC2 \ --statistic Average \ --period 300 \ --evaluation-periods 2 \ --threshold 70 \ --comparison-operator GreaterThanThreshold # 단계 확장 정책 생성 aws autoscaling put-scaling-policy \ --auto-scaling-group-name my-asg \ --policy-name step-scaling-cpu \ --policy-type StepScaling \ --adjustment-type PercentChangeInCapacity \ --metric-aggregation-type Average \ --step-adjustments '[ {"MetricIntervalLowerBound": 0, "MetricIntervalUpperBound": 20, "ScalingAdjustment": 1}, {"MetricIntervalLowerBound": 20, "ScalingAdjustment": 2} ]'

# 평일 오전 9시에 확장 aws autoscaling put-scheduled-action \ --auto-scaling-group-name my-asg \ --scheduled-action-name morning-scale-up \ --recurrence "0 9 * * 1-5" \ --desired-capacity 10 # 평일 오후 6시에 축소 aws autoscaling put-scheduled-action \ --auto-scaling-group-name my-asg \ --scheduled-action-name evening-scale-down \ --recurrence "0 18 * * 1-5" \ --desired-capacity 4

# 혼합 인스턴스 정책 aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name my-mixed-asg \ --mixed-instances-policy '{ "LaunchTemplate": {...}, "InstancesDistribution": { "OnDemandBaseCapacity": 2, "OnDemandPercentageAboveBaseCapacity": 0, "SpotAllocationStrategy": "capacity-optimized" }, "Overrides": [ {"InstanceType": "t3.medium"}, {"InstanceType": "t3a.medium"}, {"InstanceType": "t2.medium"} ] }'

# ASG 알림 설정 aws autoscaling put-notification-configuration \ --auto-scaling-group-name my-asg \ --topic-arn arn:aws:sns:region:account-id:my-topic \ --notification-types \ "autoscaling:EC2_INSTANCE_LAUNCH" \ "autoscaling:EC2_INSTANCE_TERMINATE" \ "autoscaling:EC2_INSTANCE_LAUNCH_ERROR" \ "autoscaling:EC2_INSTANCE_TERMINATE_ERROR"