Auto Scaling (자동 확장) | KAITRUST AI 백과사전

📖 상세 설명

Auto Scaling은 실시간 수요에 따라 컴퓨팅 리소스를 자동으로 확장(Scale Out)하거나 축소(Scale In)하는 기술입니다. 트래픽이 증가하면 인스턴스를 추가하고, 감소하면 제거하여 비용 최적화와 고가용성을 동시에 달성합니다. 클라우드의 핵심 장점인 "탄력성(Elasticity)"을 구현하는 핵심 메커니즘입니다.

AWS에서는 EC2 Auto Scaling이 가장 대표적입니다. 2009년 EC2와 함께 출시되어 15년 이상의 역사를 가지고 있습니다. 현재는 ECS Service Auto Scaling, DynamoDB Auto Scaling, Application Auto Scaling 등 다양한 서비스로 확장되었습니다.

Auto Scaling의 핵심 개념은 세 가지입니다. 첫째, Launch Template(또는 Launch Configuration)으로 새 인스턴스의 사양을 정의합니다. 둘째, Auto Scaling Group(ASG)으로 최소/최대/희망 인스턴스 수를 관리합니다. 셋째, Scaling Policy로 언제 확장/축소할지 결정합니다. Target Tracking(목표 추적), Step Scaling(단계별), Simple Scaling(단순) 세 가지 정책 유형이 있습니다.

실무에서 Auto Scaling은 트래픽 패턴이 예측 불가능한 웹 서비스, 배치 처리 시스템, 이벤트 기반 워크로드에서 필수입니다. 잘 설정된 Auto Scaling은 평소 비용을 최소화하면서도 트래픽 급증 시 자동으로 대응하여 서비스 안정성을 보장합니다.

💻 코드 예제

# 1. Launch Template 생성
aws ec2 create-launch-template \
  --launch-template-name my-app-template \
  --version-description "v1" \
  --launch-template-data '{
    "ImageId": "ami-0c55b159cbfafe1f0",
    "InstanceType": "t3.medium",
    "KeyName": "my-key",
    "SecurityGroupIds": ["sg-12345678"],
    "IamInstanceProfile": {
      "Arn": "arn:aws:iam::123456789:instance-profile/my-app-role"
    },
    "UserData": "IyEvYmluL2Jhc2gKY2QgL2hvbWUvZWMyLXVzZXIKLi9zdGFydC5zaA=="
  }'

# 2. Auto Scaling Group 생성
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-app-asg \
  --launch-template LaunchTemplateName=my-app-template,Version='$Latest' \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 2 \
  --vpc-zone-identifier "subnet-abc123,subnet-def456" \
  --target-group-arns "arn:aws:elasticloadbalancing:ap-northeast-2:123456789:targetgroup/my-tg/xxx" \
  --health-check-type ELB \
  --health-check-grace-period 300

# 3. Target Tracking Scaling Policy (CPU 70% 유지)
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-app-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 70.0,
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

# 4. Scheduled Scaling (예: 평일 오전 9시 확장)
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name my-app-asg \
  --scheduled-action-name scale-out-morning \
  --recurrence "0 0 * * 1-5" \
  --desired-capacity 5 \
  --min-size 3

# ASG 상태 확인
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names my-app-asg \
  --query 'AutoScalingGroups[0].{Min:MinSize,Max:MaxSize,Desired:DesiredCapacity,Instances:Instances[*].InstanceId}'

# EC2 Auto Scaling Group - Terraform 예제

# Launch Template
resource "aws_launch_template" "app" {
  name_prefix   = "my-app-"
  image_id      = data.aws_ami.amazon_linux_2.id
  instance_type = "t3.medium"

  vpc_security_group_ids = [aws_security_group.app.id]

  iam_instance_profile {
    arn = aws_iam_instance_profile.app.arn
  }

  user_data = base64encode(<<-EOF
    #!/bin/bash
    yum update -y
    amazon-linux-extras install docker
    systemctl start docker
    docker run -d -p 80:80 my-app:latest
  EOF
  )

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "my-app"
    }
  }

  lifecycle {
    create_before_destroy = true
  }
}

# Auto Scaling Group
resource "aws_autoscaling_group" "app" {
  name                = "my-app-asg"
  vpc_zone_identifier = var.private_subnet_ids
  target_group_arns   = [aws_lb_target_group.app.arn]
  health_check_type   = "ELB"
  health_check_grace_period = 300

  min_size         = 2
  max_size         = 10
  desired_capacity = 2

  # 새 인스턴스가 트래픽을 받기 전 준비 시간
  default_instance_warmup = 120

  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }

  # Instance Refresh (무중단 배포)
  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 75
      instance_warmup        = 120
    }
  }

  # Mixed Instances Policy (Spot + On-Demand)
  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 2
      on_demand_percentage_above_base_capacity = 25
      spot_allocation_strategy                 = "capacity-optimized"
    }
    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.app.id
        version            = "$Latest"
      }
      override {
        instance_type = "t3.medium"
      }
      override {
        instance_type = "t3.large"
      }
    }
  }

  tag {
    key                 = "Environment"
    value               = "production"
    propagate_at_launch = true
  }
}

# Target Tracking Policy - CPU 기반
resource "aws_autoscaling_policy" "cpu" {
  name                   = "cpu-target-tracking"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 70.0
  }
}

# Target Tracking Policy - ALB Request Count 기반
resource "aws_autoscaling_policy" "request_count" {
  name                   = "request-count-tracking"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ALBRequestCountPerTarget"
      resource_label         = "${aws_lb.app.arn_suffix}/${aws_lb_target_group.app.arn_suffix}"
    }
    target_value = 1000.0  # 인스턴스당 1000 RPS
  }
}

# Predictive Scaling (예측 기반)
resource "aws_autoscaling_policy" "predictive" {
  name                   = "predictive-scaling"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type            = "PredictiveScaling"

  predictive_scaling_configuration {
    mode                         = "ForecastAndScale"
    scheduling_buffer_time       = 300

    metric_specification {
      target_value = 70
      predefined_load_metric_specification {
        predefined_metric_type = "ASGTotalCPUUtilization"
      }
      predefined_scaling_metric_specification {
        predefined_metric_type = "ASGAverageCPUUtilization"
      }
    }
  }
}

# Kubernetes HPA (Horizontal Pod Autoscaler)

# 기본 CPU 기반 HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  # CPU 사용률 기반 (70% 타겟)
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  # 메모리 사용률 기반 (80% 타겟)
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 5분간 안정화 후 축소
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60  # 1분에 최대 50% 축소
    scaleUp:
      stabilizationWindowSeconds: 0  # 즉시 확장
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15  # 15초에 최대 100% 확장
      - type: Pods
        value: 4
        periodSeconds: 15

---
# Custom Metrics 기반 HPA (Prometheus 연동)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-custom-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  # Prometheus에서 가져온 Custom Metric
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 1000  # Pod당 1000 RPS

---
# KEDA (Kubernetes Event-driven Autoscaling) 예제
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: my-app-scaledobject
spec:
  scaleTargetRef:
    name: my-app
  pollingInterval: 15
  cooldownPeriod: 300
  minReplicaCount: 0  # 0까지 축소 가능
  maxReplicaCount: 100
  triggers:
  # SQS 큐 메시지 수 기반
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.ap-northeast-2.amazonaws.com/123456789/my-queue
      queueLength: "5"  # 메시지 5개당 1 Pod
      awsRegion: "ap-northeast-2"
    authenticationRef:
      name: aws-credentials

🗣️ 실무에서 이렇게 말하세요

💬 용량 계획 회의에서

"블랙프라이데이 대비해서 Auto Scaling 설정을 점검해야 해요. 현재 max가 10개인데 작년 피크 때 8개까지 갔거든요. 마진을 고려해서 max를 20으로 늘리고, Scheduled Scaling으로 당일 아침에 min을 5개로 미리 올려놓읍시다. Predictive Scaling도 켜두면 이틀 전부터 패턴을 학습해서 미리 확장합니다."

💬 면접에서

"EC2 Auto Scaling에서 Target Tracking Policy를 주로 사용했습니다. CPU 70% 타겟으로 설정하고, Scale-in cooldown은 300초로 여유 있게 줬어요. ALB 헬스체크와 연동해서 unhealthy 인스턴스는 자동 교체되도록 했고, Mixed Instance Policy로 Spot과 On-Demand를 7:3 비율로 섞어서 비용을 40% 절감했습니다."

💬 장애 분석 회의에서

"어제 트래픽 급증 때 스케일 아웃이 느렸던 건 Instance Warmup이 300초라서 그래요. 새 인스턴스가 프로비저닝되는 데 2분, 앱 부팅에 1분 걸리니까 총 5분이나 된 거죠. Warm Pool 기능을 쓰면 미리 stopped 상태로 인스턴스를 대기시켜둘 수 있어요."

⚠️ 흔한 실수 & 주의사항

❌

Cooldown 기간 무시

스케일 아웃 직후 또 스케일 아웃되는 "thrashing" 현상이 발생할 수 있습니다. Scale-out cooldown은 60초, Scale-in cooldown은 300초 이상을 권장합니다. 새 인스턴스가 트래픽을 받기 시작하면 메트릭이 안정화될 시간이 필요합니다.

❌

헬스체크 설정 오류

ALB 헬스체크와 Auto Scaling 헬스체크가 따로 동작합니다. health-check-type을 ELB로 설정하지 않으면, ALB에서 unhealthy로 판단해도 ASG는 모르고 트래픽을 계속 보냅니다. health-check-grace-period도 앱 시작 시간보다 길게 설정해야 합니다.

✅

올바른 접근법

CPU만 보지 말고 Application Load Balancer Request Count Per Target도 함께 모니터링하세요. CPU는 낮아도 요청 대기열이 쌓이는 경우가 있습니다. 두 메트릭에 각각 Target Tracking Policy를 걸면 둘 중 하나라도 임계값을 넘으면 확장됩니다.

🔗 관련 용어

📚 더 배우기

📄 AWS EC2 Auto Scaling 공식 문서 🤖 Predictive Scaling 소개 (ML 기반) ☸️ Kubernetes HPA 가이드