Настройка автоскейлинга серверов веб-приложения

Отметим: когда ваш веб-сервис внезапно получает пиковую нагрузку — например, после успешного email-рассылки или рекламной кампании, — серверы могут лечь, а пользователи уйдут к конкурентам. Вы добавляете мощности вручную, но это медленно и дорого. Автоскейлинг решает проблему, но его неправильная настройка приводит к thrashing и перерасходу средств. Мы, команда инженеров с многолетним опытом в инфраструктуре, помогли более 50 проектам внедрить горизонтальное масштабирование с экономией до 30–40% на облачных ресурсах. Мы гарантируем, что вы будете платить только за реально используемые ресурсы, а пользователи не заметят пиков. Получите консультацию — мы оценим ваш проект и предложим оптимальную архитектуру.

Почему простого скейлинга по CPU недостаточно?

CPU-метрика запаздывает: сервер сначала тормозит, потом скейлится. Для типичного веб-приложения комбинируют CPU и количество запросов в секунду (RPS). Это даёт более быструю реакцию на всплески трафика и предотвращает простои. Правильный выбор метрик — основа эффективного автоскейлинга, и именно на этом этапе многие допускают ошибки, ведущие к перерасходу или падению производительности.

Как выбрать метрики для автоскейлинга?

CPU-метрика запаздывает — сервер сначала тормозит, потом скейлится. RPS-метрика реагирует быстрее. Для типичного веб-приложения комбинируют CPU + Request Count.

Настройка в облачных платформах

AWS Auto Scaling Group

Самый распространённый сценарий — EC2 ASG с Application Load Balancer. В одном конфиге объединяем Launch Template, ASG и политики целевого отслеживания:

# Terraform: Launch Template + ASG + Target Tracking Policies
resource "aws_launch_template" "app" {
  name_prefix = "myapp-"
  image_id = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  user_data = base64encode(<<-EOF
    #!/bin/bash
    cd /var/www/myapp
    git pull origin main
    systemctl restart php8.3-fpm
    systemctl reload nginx
  EOF
  )
  network_interfaces {
    associate_public_ip_address = false
    security_groups = [aws_security_group.app.id]
  }
  iam_instance_profile {
    name = aws_iam_instance_profile.app.name
  }
  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "app" {
  name = "myapp-asg"
  vpc_zone_identifier = aws_subnet.private[*].id
  target_group_arns = [aws_lb_target_group.app.arn]
  health_check_type = "ELB"
  health_check_grace_period = 300
  min_size = 2
  max_size = 20
  desired_capacity = 2
  launch_template {
    id = aws_launch_template.app.id
    version = "$Latest"
  }
  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 50
    }
  }
  tag {
    key = "Name"
    value = "myapp-app"
    propagate_at_launch = true
  }
}

# Target Tracking Policy: CPU
resource "aws_autoscaling_policy" "cpu" {
  name = "myapp-cpu-tracking"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 65.0
    scale_in_cooldown = 300
    scale_out_cooldown = 60
  }
}

# Target Tracking Policy: ALB Request Count per Target
resource "aws_autoscaling_policy" "rps" {
  name = "myapp-rps-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.main.arn_suffix}/${aws_lb_target_group.app.arn_suffix}"
    }
    target_value = 1000.0
  }
}

ECS Fargate Auto Scaling

Для контейнерных приложений ECS Fargate проще — нет EC2, только задачи. Настраиваем целевой ресурс и политику по CPU и длине очереди SQS:

resource "aws_appautoscaling_target" "ecs" {
  max_capacity = 50
  min_capacity = 2
  resource_id = "service/${aws_ecs_cluster.main.name}/${aws_ecs_service.app.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace = "ecs"
}

resource "aws_appautoscaling_policy" "ecs_cpu" {
  name = "myapp-ecs-cpu"
  policy_type = "TargetTrackingScaling"
  resource_id = aws_appautoscaling_target.ecs.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension
  service_namespace = aws_appautoscaling_target.ecs.service_namespace

  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
    target_value = 60.0
    scale_in_cooldown = 300
    scale_out_cooldown = 30
  }
}

# Scale by SQS queue depth (worker service)
resource "aws_appautoscaling_policy" "ecs_sqs" {
  name = "myapp-worker-sqs"
  policy_type = "TargetTrackingScaling"
  resource_id = aws_appautoscaling_target.worker.resource_id
  scalable_dimension = aws_appautoscaling_target.worker.scalable_dimension
  service_namespace = aws_appautoscaling_target.worker.service_namespace

  target_tracking_scaling_policy_configuration {
    customized_metric_specification {
      metric_name = "ApproximateNumberOfMessagesNotVisible"
      namespace = "AWS/SQS"
      statistic = "Sum"
      dimensions {
        name = "QueueName"
        value = aws_sqs_queue.jobs.name
      }
    }
    target_value = 100.0
  }
}

Kubernetes HPA и KEDA

Horizontal Pod Autoscaler работает с CPU и Memory из коробки. KEDA добавляет внешние метрики (SQS, RabbitMQ, Kafka).

Пример HPA с CPU и Memory, стабилизацией и поведением:

# HPA по CPU + Memory
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  namespace: myapp
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-web
  minReplicas: 2
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 75
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Pods
          value: 4
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60

Подробнее читайте в официальной документации HorizontalPodAutoscaler. KEDA ScaledObject для RabbitMQ:

# KEDA ScaledObject — RabbitMQ queue
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: myapp-worker-scaler
  namespace: myapp
spec:
  scaleTargetRef:
    name: myapp-worker
  minReplicaCount: 1
  maxReplicaCount: 30
  pollingInterval: 10
  cooldownPeriod: 60
  triggers:
    - type: rabbitmq
      metadata:
        host: amqp://rabbitmq.myapp.svc.cluster.local
        queueName: email-queue
        mode: QueueLength
        value: "50"

Graceful Shutdown

При scale-in инстанс получает сигнал завершения. Приложение должно успеть обработать текущие запросы. Пример для Node.js Express:

// Node.js Express
const server = app.listen(3000);
process.on('SIGTERM', () => {
  console.log('SIGTERM received, shutting down gracefully');
  server.close(() => {
    console.log('HTTP server closed');
    process.exit(0);
  });
  setTimeout(() => {
    console.error('Forced shutdown');
    process.exit(1);
  }, 30000);
});

Дополнительно настраиваем lifecycle hook в AWS для выполнения команд перед завершением инстанса. Подробнее — в документации AWS по Lifecycle Hooks.

Типичные проблемы и их решения

При внедрении автоскейлинга команды часто сталкиваются с thrashing — частым добавлением и удалением инстансов из-за слишком коротких cooldown. Решение — увеличить scale_in_cooldown до 300–600 секунд и использовать stabilizationWindowSeconds в HPA. Другая проблема — медленный старт приложения: новый инстанс создан, но трафик идёт до его готовности. Помогают health check grace period, readiness probe и Warm Pool. Также дорогой scale-in возникает, если удаляется инстанс с незавершёнными фоновыми задачами. Здесь выручает lifecycle hook с drain очереди перед CONTINUE. И наконец, неправильная метрика — например, CPU 20%, но приложение тормозит из-за I/O wait. В таких случаях используйте custom метрики, например p95 latency через CloudWatch или Prometheus.

Пошаговая настройка автоскейлинга в AWS

1. Создайте Launch Template с AMI, типом инстанса и user-data для развёртывания приложения.
2. Настройте Auto Scaling Group: укажите VPC, subnet, target group для ALB, задайте min, max, desired.
3. Добавьте политики Target Tracking по CPU и RPS, установите cooldown.
4. Настройте health checks: ELB health check, grace period.
5. Включите Instance Refresh для rolling-обновлений.
6. Проверьте graceful shutdown: lifecycle hook + drain.

Объём работ по настройке автоскейлинга

• Анализ текущей архитектуры и профиля нагрузки.
• Проектирование политик масштабирования (CPU, RPS, очередь).
• Настройка AWS Auto Scaling Group, ECS Service Auto Scaling или Kubernetes HPA/KEDA.
• Конфигурация health checks и graceful shutdown.
• Настройка мониторинга (CloudWatch, Grafana) и алертов.
• Документация по архитектуре и инструкции для команды.
• Обучение команды (1–2 сессии).
• Поддержка в течение 30 дней после внедрения.

Ориентировочные сроки

Мы имеем сертификаты AWS и Kubernetes, многолетний опыт на рынке и более 50 реализованных проектов. Свяжитесь с нами, чтобы обсудить ваш проект. Мы подготовим коммерческое предложение с точными сроками и стоимостью.