☁️
클라우드
오토스케일링
Auto Scaling
부하에 따라 자동으로 서버 수를 조절하는 기능. 비용 최적화와 가용성 보장.
📖 상세 설명
오토스케일링(Auto Scaling)은 애플리케이션 부하에 따라 컴퓨팅 리소스를 자동으로 늘리거나 줄이는 기능입니다. 트래픽 급증 시 인스턴스를 추가하여 가용성을 유지하고, 트래픽이 줄면 인스턴스를 제거하여 비용을 절감합니다.
스케일 아웃(Scale Out)은 인스턴스 수를 늘리는 수평 확장, 스케일 업(Scale Up)은 인스턴스 사양을 높이는 수직 확장입니다. 클라우드에서는 주로 수평 확장을 사용하며, 이를 위해 애플리케이션이 stateless해야 합니다.
스케일링 정책에는 Target Tracking(CPU 70% 유지), Step Scaling(임계값별 단계적 확장), Scheduled Scaling(예약 확장), Predictive Scaling(ML 기반 예측)이 있습니다. 대부분의 경우 Target Tracking이 가장 효과적입니다.
Kubernetes에서는 HPA(Horizontal Pod Autoscaler)가 Pod 수를, VPA(Vertical Pod Autoscaler)가 리소스 요청을, Cluster Autoscaler가 노드 수를 자동 조정합니다. KEDA를 사용하면 큐 길이, HTTP 요청 등 다양한 메트릭으로 스케일링이 가능합니다.
💻 코드 예제
# Kubernetes HPA (Horizontal Pod Autoscaler)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 20
metrics:
# CPU 기반 스케일링
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
# 커스텀 메트릭 (Prometheus)
- type: Pods
pods:
metric:
name: http_requests_per_second
target:
type: AverageValue
averageValue: 1000
behavior:
scaleDown:
stabilizationWindowSeconds: 300 # 5분 안정화 기간
policies:
- type: Percent
value: 10
periodSeconds: 60
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Percent
value: 100
periodSeconds: 15
---
# AWS Auto Scaling Group (Terraform)
resource "aws_autoscaling_group" "app" {
name = "app-asg"
vpc_zone_identifier = aws_subnet.private[*].id
target_group_arns = [aws_lb_target_group.app.arn]
min_size = 2
max_size = 20
desired_capacity = 3
launch_template {
id = aws_launch_template.app.id
version = "$Latest"
}
health_check_type = "ELB"
health_check_grace_period = 300
# 인스턴스 워밍업 시간
default_instance_warmup = 120
tag {
key = "Name"
value = "app-instance"
propagate_at_launch = true
}
}
# Target Tracking 스케일링 정책
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
}
}🗣️ 실무에서 이렇게 말해요
DevOps: "블랙프라이데이 대비해서 min capacity를 5에서 10으로 올려놓겠습니다. 예열 시간도 고려해야 해요."
개발: "오토스케일링이 있는데 왜 미리 올려놔야 하나요?"
DevOps: "스케일 아웃에 2-3분 걸리거든요. 갑자기 10배 트래픽 오면 그 사이에 에러 날 수 있어요."
면접관: "오토스케일링을 적용하려면 애플리케이션에서 고려해야 할 점은?"
지원자: "애플리케이션이 stateless여야 합니다. 세션은 Redis 같은 외부 저장소에, 파일은 S3에 저장합니다. Graceful shutdown으로 진행 중인 요청을 완료한 후 종료되도록 하고, 헬스체크 엔드포인트도 구현해야 합니다."
리뷰어: "HPA의 minReplicas가 1인데, HA를 위해 최소 2개는 필요해요. 한 노드 장애 시 서비스 다운될 수 있어요."
작성자: "맞습니다. minReplicas를 2로, PodDisruptionBudget도 추가하겠습니다."
⚠️ 주의사항
- 스케일 아웃에는 시간이 걸립니다(2-5분). 트래픽 급증이 예상되면 Scheduled Scaling으로 미리 용량을 확보하세요.
- 너무 민감한 스케일링 정책은 빈번한 스케일 인/아웃을 유발합니다. stabilizationWindow로 안정화 기간을 설정하세요.
- Spot 인스턴스와 온디맨드를 혼합하면 비용을 50-70% 절감하면서도 안정성을 유지할 수 있습니다.