Настройка Cloudflare Load Balancer: гео-маршрутизация и failover

Отметим: когда ваш проект растёт, а пользователи разбросаны по миру, один сервер перестаёт справляться. Мы часто видим ситуацию: клиент из Австралии получает ответ через 800 мс, потому что серверы только в Европе. Мы настраиваем Cloudflare Load Balancer как альтернативу классическим L4/L7 балансировщикам — это DNS-based решение, работающее поверх глобальной Anycast-сети Cloudflare. Результат: задержка падает до 100–150 мс для удалённых регионов, а отказоустойчивость обеспечивается автоматическим failover. Например, для e-commerce проекта с аудиторией в Азии и Европе мы снизили время загрузки на 40% после внедрения geo-routing. Cloudflare LB также защищает от DDoS и не требует управления серверным ПО.

Проблемы, которые решаем

• Гео-задержки. Origin в одном датацентре — клиенты на других континентах страдают от высокой латентности. Cloudflare автоматически направляет запросы к ближайшему здоровому пулу (гео-маршрутизация).
• Отказы origin. Сервер упал — трафик автоматически переключается на следующий здоровый origin благодаря health checks. Время failover — до 120 секунд при стандартных настройках.
• Sticky sessions. Требуется сессионная привязка к серверу? Cloudflare поддерживает session affinity через cookie __cflb. Настроили — и корзина пользователя не теряется при балансировке.
• Ручное управление. Пул регионов можно менять вручную, но мы автоматизируем через Terraform — изменения применяются без downtime.

Как Cloudflare Load Balancer отличается от классических решений?

В отличие от аппаратных балансировщиков (F5, HAProxy на одной площадке), Cloudflare использует DNS-based маршрутизацию и распределение трафика на Edge-сети. Запрос пользователя проходит через ближайший PoP Cloudflare, который перенаправляет его на здоровый origin в выбранном пуле. Это даёт встроенную DDoS-защиту и снижает нагрузку на origin. По сравнению с обычными DNS-балансировщиками, Cloudflare LB в 3 раза быстрее обнаруживает сбой благодаря распределённой сети проверок.

Почему стоит использовать гео-маршрутизацию?

Предположим, у вас серверы во Франкфурте и Сингапуре. Без гео-маршрутизации пользователь из Токио получит ответ через 400 мс, так как DNS может вернуть IP европейского сервера. Cloudflare LB по региону клиента (например, Southeast Asia) направляет его в сингапурский пул — задержка падает до 50 мс. По данным Cloudflare, это сокращает время загрузки на 35–70% для удалённых регионов. Согласно исследованиям, 53% пользователей покидают сайт, если загрузка дольше 3 секунд. Гео-маршрутизация сокращает время отклика до 200 мс в среднем.

Структура: Pool → Origin → Health Check

Load Balancer
├── Pool: EU (eu-primary)
│   ├── Origin: amsterdam-1 (10.0.1.10:443)
│   ├── Origin: frankfurt-1 (10.0.2.10:443) weight=0.5
│   └── Health Check: HTTPS /healthz, 30s interval
├── Pool: Asia (asia-primary)
│   ├── Origin: singapore-1 (10.1.1.10:443)
│   └── Health Check: HTTPS /healthz, 30s interval
└── Fallback Pool: US (us-fallback)
    └── Origin: virginia-1 (10.2.1.10:443)

Настройка через Terraform (Cloudflare Provider)

# Health Check
resource "cloudflare_healthcheck" "backend" {
  zone_id = var.cloudflare_zone_id
  name = "backend-healthcheck"
  type = "HTTPS"
  address = "origin.example.com"
  path = "/healthz"
  port = 443
  interval = 60
  timeout = 5
  retries = 2
  expected_codes = "200"
  method = "GET"
  follow_redirects = false
  headers = [{ header = "Host" values = ["example.com"] }]
}

# Origin Pool — EU
resource "cloudflare_load_balancer_pool" "eu" {
  account_id = var.cloudflare_account_id
  name = "eu-origins"
  description = "EU origin servers"
  enabled = true
  minimum_origins = 1
  origins {
    name = "amsterdam-1"
    address = "185.12.34.10"
    enabled = true
    weight = 1
  }
  origins {
    name = "frankfurt-1"
    address = "185.12.34.20"
    enabled = true
    weight = 0.5 # Получает вдвое меньше трафика
  }
  load_shedding {
    default_percent = 0
    default_policy = "random"
  }
  health_checks = [cloudflare_healthcheck.backend.id]
  notification_email = "[email protected]"
}

# Load Balancer
resource "cloudflare_load_balancer" "main" {
  zone_id = var.cloudflare_zone_id
  name = "example.com"
  fallback_pool_id = cloudflare_load_balancer_pool.us.id
  default_pool_ids = [
    cloudflare_load_balancer_pool.eu.id,
    cloudflare_load_balancer_pool.asia.id,
  ]
  proxied = true
  ttl = 30 # Только для non-proxied
  description = "Main load balancer"
  session_affinity = "cookie" # Sticky sessions через __cflb cookie
  session_affinity_attributes {
    samesite = "Auto"
    secure = "Auto"
    drain_duration = 300
  }
  # Geo-routing: EU клиенты → EU пул
  region_pools {
    region = "WEUR" # Western Europe
    pool_ids = [cloudflare_load_balancer_pool.eu.id]
  }
  region_pools {
    region = "SEAS" # Southeast Asia
    pool_ids = [cloudflare_load_balancer_pool.asia.id]
  }
  # Правила для специфического трафика
  rules {
    name = "bypass-lb-for-static"
    condition = "http.request.uri.path matches "^/static/""
    disabled = false
    overrides {
      default_pool_ids = [cloudflare_load_balancer_pool.eu.id]
      session_affinity = "none"
    }
  }
}

Пример выше показывает типичную конфигурацию для проекта с двумя регионами и fallback пулом в США. Мы используем веса для распределения трафика — например, даём серверу в Амстердаме вес 1, а во Франкфурте 0.5 (получает вдвое меньше запросов). Это полезно при разных мощностях серверов. Свяжитесь с нами для адаптации этого кода под ваш проект.

Health Checks: тонкости

Cloudflare проверяет origin с нескольких точек своей сети. Если хотя бы одна проверка неудачна — не считается упавшим. Origin помечается нездоровым только когда все проверки из разных PoP не отвечают. Согласно Cloudflare documentation, health checks выполняются из нескольких PoP.

Важный нюанс: health check Cloudflare идёт с IP-адресов Cloudflare, не от пользователей. Если у вас на origin стоят firewall-правила «разрешить только Cloudflare IP» — убедитесь, что health check IP тоже в whitelist. Актуальный список: Cloudflare IP ranges.

Также имейте в виду: timeout и interval влияют на скорость обнаружения проблем. Мы рекомендуем interval=60s, timeout=5s, retries=2 — это даёт обнаружение отказа в среднем за 2 минуты. Для более критичных приложений можно уменьшить до 30s (но увеличится нагрузка на origin).

# Проверить реальный IP origin из health check
curl -H "CF-Connecting-IP: 1.2.3.4" https://example.com/healthz

Failover и уведомления

При падении origin Cloudflare переключает трафик на следующий здоровый origin в пуле. Если весь пул упал — на fallback pool. Время обнаружения: interval * retries = 60s * 2 = 2 минуты.

Уведомления в Slack через Cloudflare Notifications:

resource "cloudflare_notification_policy" "lb_health" {
  account_id = var.cloudflare_account_id
  name = "Load Balancer Health Alert"
  enabled = true
  alert_type = "load_balancing_health_alert"

  email_integration {
    id = "[email protected]"
  }

  webhooks_integration {
    id = cloudflare_notification_policy_webhooks.slack.id
  }

  filters {
    pool_id = [
      cloudflare_load_balancer_pool.eu.id,
      cloudflare_load_balancer_pool.asia.id,
    ]
  }
}

Дополнительно можно настроить PagerDuty через Webhook.

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

1. Аудит текущей инфраструктуры — определяем точки отказа, географию пользователей, требования к session affinity.
2. Проектирование топологии — выбираем регионы, настраиваем health checks, правила geo-routing.
3. Реализация через Terraform — создаём пулы, балансировщик, уведомления; тестируем в staging.
4. Тестирование failover — симулируем отказы, проверяем переключение трафика.
5. Деплой и мониторинг — применяем в production, подключаем observability (Grafana + Prometheus для счётчиков трафика).
6. Документация и обучение — передаём runbook команде.

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

• Инфраструктурный код (Terraform) для всех регионов.
• Документация по архитектуре и процессу развёртывания.
• Настройка мониторинга health checks и алертов (Slack/Telegram/PagerDuty).
• Интеграция с существующим CI/CD (GitLab CI или GitHub Actions).
• Обучение команды процедуре постмортема и быстрому реагированию.

Сроки ориентировочно

Стоимость рассчитывается индивидуально после аудита текущей инфраструктуры и географии пользователей. Свяжитесь с нами для оценки вашего проекта. Средняя экономия на инфраструктурных затратах после внедрения Cloudflare LB составляет 30-50%.

Частые ошибки

Чек-лист перед деплоем

• [ ] Проверены пути health checks
• [ ] IP Cloudflare внесены в firewall
• [ ] Веса настроены корректно
• [ ] Уведомления подключены
• [ ] Сессионная аффинность настроена (если нужна)

Наш опыт

Мы настраиваем Cloudflare Load Balancer более 5 лет, участвовали в проектах с нагрузкой свыше 100 тыс. запросов в секунду. Более 50 успешных проектов. Гарантируем отказоустойчивость с SLA 99.99% и предоставляем поддержку после внедрения. Закажите настройку Cloudflare Load Balancer — получите готовое решение за 3–5 дней. Получите консультацию.