Настройка балансировки нагрузки (AWS ALB/ELB) для сайта

Настройка балансировки нагрузки через AWS ALB и ELB

Сайт падает под нагрузкой? 502 ошибки при пиковых запросах в день акции? Мы сталкивались с этим в проектах с трафиком 100k+ RPS. Балансировка нагрузки через AWS ALB — стандартное решение для высоконагруженных проектов. Настраиваем ALB/ELB под ключ: target groups, listener rules, SSL, интеграция с Auto Scaling. Опыт 7+ лет, 50+ настроенных балансировщиков. Правильная конфигурация ALB критична для доступности и скорости сайта — существенная экономия на инфраструктуре при грамотной настройке.

AWS предоставляет управляемые балансировщики нагрузки без необходимости поддерживать собственный сервер. Application Load Balancer (ALB) работает на уровне HTTP/HTTPS с маршрутизацией по пути и заголовкам. Network Load Balancer (NLB) — L4 TCP/UDP с минимальной задержкой. Classic ELB устарел и не рекомендуется для новых проектов.

Почему стоит выбрать ALB вместо NLB?

ALB лучше NLB для HTTP/HTTPS: он поддерживает интеллектуальную маршрутизацию, интеграцию с WAF и отдачу статического контента. NLB незаменим для TCP-сервисов, требующих статических IP и минимальной задержки. Если у вас веб-приложение на React/Vue или API на Node.js — ваш выбор ALB. Для GameServer или VoIP — NLB. Мы часто комбинируем их: ALB для веба, NLB для WebSocket.

Как работает ALB с Auto Scaling?

Привяжите target group ALB к Auto Scaling Group. При масштабировании новые инстансы автоматически регистрируются и начинают получать трафик. Health check ALB (путь /health, порог 2 успешных ответов) определяет, когда инстанс готов принимать запросы. Это обеспечивает zero-downtime деплой. Для критичных сервисов используем таргет-группы с deregistration_delay в 30 секунд, чтобы успевающие запросы завершились.

Пошаговая настройка ALB через Terraform

1. Создайте ALB с указанием security groups и подсетей.
2. Настройте HTTPS listener с сертификатом ACM и редирект с HTTP.
3. Определите target groups с health check и stickiness.
4. Добавьте listener rules для маршрутизации по путям, заголовкам или хостам.
5. Привяжите target group к вашему сервису (EC2, ECS, Lambda).
6. Включите access logs и мониторинг.

Полный пример конфигурации ниже.

Application Load Balancer

ALB — стандартный выбор для веб-приложений. Маршрутизирует по пути, хосту, HTTP-заголовкам, методу, query string. Интегрируется с ECS, EKS, Lambda, Auto Scaling Groups. Ниже полная конфигурация с AWS ALB, маршрутизацией и ACM.

# Terraform: полная конфигурация ALB + routing + ACM

resource "aws_lb" "main" {
  name               = "myapp-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = aws_subnet.public[*].id

  enable_deletion_protection       = true
  enable_cross_zone_load_balancing = true
  drop_invalid_header_fields       = true

  access_logs {
    bucket  = aws_s3_bucket.alb_logs.bucket
    prefix  = "alb"
    enabled = true
  }

  tags = { Name = "myapp-alb" }
}

# HTTPS Listener
resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.main.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = aws_acm_certificate.main.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web.arn
  }
}

# HTTP → HTTPS redirect
resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.main.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type = "redirect"
    redirect {
      port        = "443"
      protocol    = "HTTPS"
      status_code = "HTTP_301"
    }
  }
}

# Target Group для веб-приложения
resource "aws_lb_target_group" "web" {
  name        = "myapp-web-tg"
  port        = 8080
  protocol    = "HTTP"
  vpc_id      = aws_vpc.main.id
  target_type = "ip"  # для ECS Fargate

  health_check {
    enabled             = true
    path                = "/health"
    healthy_threshold   = 2
    unhealthy_threshold = 3
    timeout             = 5
    interval            = 10
    matcher             = "200"
  }

  deregistration_delay = 30

  stickiness {
    type            = "lb_cookie"
    cookie_duration = 86400
    enabled         = false
  }
}

# API Target Group
resource "aws_lb_target_group" "api" {
  name     = "myapp-api-tg"
  port     = 3000
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    path    = "/api/health"
    matcher = "200"
  }
}

# Правила маршрутизации
resource "aws_lb_listener_rule" "api" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 10

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api.arn
  }

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }
}

# Маршрут по заголовку (версионирование API)
resource "aws_lb_listener_rule" "api_v2" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 5

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api_v2.arn
  }

  condition {
    http_header {
      http_header_name = "X-API-Version"
      values           = ["2", "2.0"]
    }
  }
}

# Weighted forwarding для Canary deployments
resource "aws_lb_listener_rule" "canary" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 20

  action {
    type = "forward"
    forward {
      target_group {
        arn    = aws_lb_target_group.web_stable.arn
        weight = 95
      }
      target_group {
        arn    = aws_lb_target_group.web_canary.arn
        weight = 5
      }
      stickiness {
        enabled  = true
        duration = 3600
      }
    }
  }

  condition {
    path_pattern { values = ["/*"] }
  }
}

# Сертификат ACM
resource "aws_acm_certificate" "main" {
  domain_name               = "example.com"
  subject_alternative_names = ["*.example.com"]
  validation_method         = "DNS"

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_route53_record" "cert_validation" {
  for_each = {
    for dvo in aws_acm_certificate.main.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  zone_id = aws_route53_zone.main.zone_id
  name    = each.value.name
  type    = each.value.type
  ttl     = 60
  records = [each.value.record]
}

resource "aws_acm_certificate_validation" "main" {
  certificate_arn         = aws_acm_certificate.main.arn
  validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

ALB + WAF

Подключаем WAF для защиты от OWASP top-10 и rate limiting.

resource "aws_wafv2_web_acl_association" "alb" {
  resource_arn = aws_lb.main.arn
  web_acl_arn  = aws_wafv2_web_acl.main.arn
}

resource "aws_wafv2_web_acl" "main" {
  name  = "myapp-waf"
  scope = "REGIONAL"

  default_action { allow {} }

  rule {
    name     = "AWSManagedRulesCommonRuleSet"
    priority = 1
    override_action { none {} }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesCommonRuleSet"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "CommonRuleSet"
      sampled_requests_enabled   = true
    }
  }

  rule {
    name     = "RateLimit"
    priority = 2
    action { block {} }

    statement {
      rate_based_statement {
        limit              = 2000
        aggregate_key_type = "IP"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "RateLimit"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "MyAppWAF"
    sampled_requests_enabled   = true
  }
}

ALB + ECS Fargate

Пример интеграции ALB с Fargate: сервис автоматически регистрируется в target group.

resource "aws_ecs_service" "app" {
  name            = "myapp-web"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = 3
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = aws_subnet.private[*].id
    security_groups  = [aws_security_group.app.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.web.arn
    container_name   = "web"
    container_port   = 8080
  }

  deployment_circuit_breaker {
    enable   = true
    rollback = true
  }

  deployment_controller {
    type = "ECS"
  }

  depends_on = [aws_lb_listener.https]
}

Network Load Balancer

NLB для TCP/UDP с статическими IP и минимальной задержкой.

resource "aws_lb" "nlb" {
  name               = "myapp-nlb"
  internal           = false
  load_balancer_type = "network"
  subnets            = aws_subnet.public[*].id

  enable_cross_zone_load_balancing = true
}

resource "aws_lb_listener" "nlb_tls" {
  load_balancer_arn = aws_lb.nlb.arn
  port              = 443
  protocol          = "TLS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = aws_acm_certificate.main.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.nlb_tcp.arn
  }
}

resource "aws_lb_target_group" "nlb_tcp" {
  name     = "myapp-nlb-tg"
  port     = 8080
  protocol = "TCP"
  vpc_id   = aws_vpc.main.id

  health_check {
    protocol            = "HTTP"
    path                = "/health"
    healthy_threshold   = 2
    unhealthy_threshold = 2
    interval            = 10
  }
}

Мониторинг ALB

Ключевые CloudWatch метрики: RequestCount, ActiveConnectionCount, TargetResponseTime (p50/p95/p99), HTTPCode_ELB_5XX_Count, HealthyHostCount, UnHealthyHostCount. Ставим алерты на 5xx и высокую задержку.

resource "aws_cloudwatch_metric_alarm" "target_5xx" {
  alarm_name          = "alb-5xx-errors"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "HTTPCode_Target_5XX_Count"
  namespace           = "AWS/ApplicationELB"
  period              = 60
  statistic           = "Sum"
  threshold           = 10
  alarm_actions       = [aws_sns_topic.alerts.arn]

  dimensions = {
    LoadBalancer = aws_lb.main.arn_suffix
  }
}

resource "aws_cloudwatch_metric_alarm" "latency" {
  alarm_name          = "alb-high-latency"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 3
  metric_name         = "TargetResponseTime"
  namespace           = "AWS/ApplicationELB"
  period              = 60
  extended_statistic  = "p95"
  threshold           = 2.0
  alarm_actions       = [aws_sns_topic.alerts.arn]

  dimensions = {
    LoadBalancer = aws_lb.main.arn_suffix
  }
}

Что входит в работу

• Проект балансировки: выбор типа (ALB/NLB), схема сети.
• Написание Terraform-кода с target groups, listener rules, ACM, WAF.
• Настройка мониторинга и алертов.
• Интеграция с CI/CD и Auto Scaling.
• Документация по эксплуатации и обучение команды.

Срок реализации

Типичные ошибки при настройке

• Не настроен health check — инстансы получают трафик до готовности.
• Отсутствует deletion protection — случайное удаление ALB.
• Неправильный SSL policy — уязвимости.
• Click-through на WAF — не включены managed rules.

Мы гарантируем стабильность и скорость. Получите консультацию по настройке ALB для вашего проекта. Свяжитесь с нами — рассчитаем сроки под ваш проект. Документация AWS ALB поможет глубже разобраться в возможностях.

Мы регулярно сталкиваемся с ситуацией: «Сайт не открывается» в 3 часа ночи — и выясняется, что disk full на VPS, потому что логи nginx не ротировались полгода. Или сервер лёг под нагрузкой в день запуска рекламной кампании, потому что на shared хостинге стоял лимит в 50 одновременных соединений. Настройка хостинга и деплоя — это не про «где дешевле», это про то, что происходит в момент, когда что-то идёт не так. Наша команда помогает избежать таких инцидентов, проектируя инфраструктуру с учётом реальных паттернов нагрузки.

Когда выбирать Vercel и Netlify?

Vercel создан под Next.js — деплой в один push, preview deployments для каждого PR, автоматический CDN, Edge Functions, ISR без конфигурации. Для фронтенд-проектов и JAMstack это оптимальный выбор: нет операционной нагрузки, time-to-deploy измеряется минутами.

Ограничения реальные: Vercel Serverless Functions запускаются в us-east-1 по умолчанию (latency для Европы +80–100ms), Function timeout 300 секунд на Pro, Bandwidth 1TB/месяц на Pro. Для тяжёлого backend — нужны воркеры или отдельный сервер.

Netlify ближе к статике и Edge Functions на базе Deno Deploy. Build minutes — основное ограничение на бесплатном тарифе.

Почему Docker — основа предсказуемого деплоя?

«Работает на моей машине» — классика. Docker решает это через контейнеризацию окружения. Но плохой Dockerfile создаёт новые проблемы.

Типичная ошибка: копировать всё в образ без .dockerignore, получать 800MB образ вместо 80MB. node_modules внутри образа весит столько же. Правильно: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Итоговый образ: 180MB вместо 1.2GB. Время сборки CI сокращается из-за layer caching — если package.json не изменился, слой с npm ci берётся из кэша.

Docker Compose для локальной разработки и простых продакшен-сценариев: приложение + PostgreSQL + Redis в одной конфигурации. Для production на одном сервере — вполне рабочий вариант, если нет требований горизонтального масштабирования.

Подробнее о контейнеризации — Wikipedia: Docker.

Как настроить Nginx как reverse proxy?

Nginx перед приложением — стандарт для VPS и выделенных серверов. Основные функции: SSL termination, gzip, static files, rate limiting, upstream балансировка.

Конфигурация, которую часто делают неправильно: worker_processes auto — количество процессов равно числу CPU. worker_connections 1024 — это 1024 на каждый воркер-процесс. При 4 CPU и 1024 connections = 4096 одновременных соединений. Для высоконагруженного сайта нужно worker_connections 4096 и настройка keepalive_timeout 65.

Для статических ассетов с хешем в имени файла:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable сообщает браузеру: не проверяй этот файл даже при hard refresh. Правильно работает только с content-hashed именами файлов (что делает Vite/webpack по умолчанию). Документация — Wikipedia: Nginx.

AWS: гибкость и сложность

EC2 + Auto Scaling Group — классика для горизонтального масштабирования. AMI с предустановленным приложением, Launch Template, ASG с min/desired/max instances, Application Load Balancer. При CPU > 70% на 3 минуты — scale out, при CPU < 30% на 15 минут — scale in. Health check через ALB исключает нездоровые инстансы из ротации.

ECS Fargate — контейнеры без управления EC2. Деплой Docker-образа, задаёте CPU/память (512 CPU units = 0.5 vCPU, от 512MB памяти), Fargate запускает. Дороже Lambda, но нет cold start и нет timeout-ограничений. Подходит для long-running процессов, WebSocket-серверов, тяжёлых воркеров.

RDS для PostgreSQL с Multi-AZ: автоматический failover за 1–2 минуты при падении primary. Read Replicas для масштабирования чтения. RDS Proxy для connection pooling — Lambda-функции не умеют держать долгосрочные соединения, прокси буферизует это.

Kubernetes: когда это оправдано

K8s добавляет значительную операционную сложность. Оправдан, когда: несколько команд деплоят независимые сервисы, нужна тонкая настройка ресурсов на сервис, canary deployments и blue/green без простоя — требование.

AWS EKS, GKE или managed k8s от Hetzner (дешевле). Helm charts для стандартных сервисов. Horizontal Pod Autoscaler по CPU и custom metrics (RPS через Prometheus).

Для большинства стартапов и средних проектов — Kubernetes избыточен. ECS или Fly.io дают 80% возможностей при 20% операционной сложности.

Мониторинг и alerting

Сервер без мониторинга — это ожидание инцидента. Минимальный стек: Prometheus + Grafana (или Grafana Cloud для managed), alerting на disk > 80%, memory > 85%, CPU > 90% за 5 минут, error rate > 1%. Uptime через Better Uptime или Upptime (self-hosted).

Logs: Loki + Grafana или CloudWatch Logs Insights. Структурированные JSON-логи (winston, pino) — обязательно, иначе поиск по логам превращается в боль.

Что входит в настройку хостинга

• Аудит текущей инфраструктуры и профилирование нагрузки
• Выбор целевой архитектуры (VPS, AWS, serverless, Kubernetes)
• Настройка CI/CD pipeline (GitHub Actions, GitLab CI) с автоматическим деплоем
• IaC через Terraform или Pulumi (инфраструктура как код)
• Конфигурация Nginx, SSL-сертификаты, HTTP/2, brotli
• Мониторинг и алертинг (Prometheus + Grafana, PagerDuty)
• Документация runbooks и обучение команды

Дополнительно: пишите, если нужна миграция с текущего хостинга или интеграция с внешними сервисами.

Процесс работы

1. Аудит текущей инфраструктуры (2–5 дней)
2. Выбор целевой архитектуры с обоснованием по нагрузке и бюджету (1–3 дня)
3. Настройка CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 дней)
4. IaC через Terraform или Pulumi (3–10 дней)
5. Настройка мониторинга и alerting (2–5 дней)
6. Документация runbooks и обучение команды (1–3 дня)

Наш опыт — 7 лет на рынке, более 50 проектов, гарантия работоспособности после деплоя.

Сроки

• Базовый деплой на VPS с Docker + Nginx + CI/CD: 1–2 недели.
• Настройка AWS инфраструктуры с Auto Scaling, RDS, CDN: 3–6 недель.
• Миграция на EKS с нуля: 6–12 недель.
• Настройка Vercel/Netlify для JAMstack: 3–5 дней.

Стоимость рассчитывается индивидуально в зависимости от сложности и объёма работ. Получите консультацию — оценим вашу архитектуру за один день.