[AWS] ELB와 ASG

확장성(Scalability)

수직 확장(Vertical Scaling)

• 인스턴스의 크기를 늘림

• t3.micro → t3.large → m5.xlarge

• 구현이 간단

• 애플리케이션 수정 불필요

• 확장 한계 존재

• 다운타임 발생

• 단일 장애점

수평 확장(Horizontal Scaling)

• 인스턴스의 개수를 늘림

• 1대 → 3대 → 10대

• 무제한 확장 가능

• 고가용성 확보

• 장애 격리

• 복잡한 설계 필요

• 로드 밸런서 필요

• 상태 관리 고려

ELB (Elastic Load Balancer)

• AWS 관리형 로드 밸런서

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

• 자동 확장 및 고가용성 제공

ELB의 주요 기능

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

• EC2 인스턴스의 부담 감소

• 중앙화된 인증서 관리

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

• 쿠키 기반 구현

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

ELB 타입 비교

1. Application Load Balancer (ALB) - Layer 7

• HTTP/HTTPS 트래픽 전용

• URL 경로 기반 라우팅

• 호스트 기반 라우팅

• 웹소켓, HTTP/2 지원

• 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

비활성화 시

활성화 시

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

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

• CLB: 기본 비활성화

Auto Scaling Group (ASG)

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

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

• 비용 최적화 + 가용성 보장

ASG 주요 구성 요소

• 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)

# 대상 추적 정책 생성
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)

# 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)

확장 쿨다운(Scaling Cooldown)

• 확장 작업 후 대기 시간

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

• 기본값: 300초 (5분)

작동 방식

최적화

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

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

• User Data 스크립트 최적화

실전 아키텍처 패턴

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

• Minimum: 2 (각 AZ에 1개)

• Desired: 4

• Maximum: 10

• Target Tracking: CPU 50%

패턴 2: 마이크로서비스

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

• 스팟 인스턴스로 최대 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초

모니터링 및 알림

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. 스케줄링 최적화

트러블슈팅

문제 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로 사용률 모니터링

• 비정상 확장 패턴 분석