Налаштування 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 днів. Отримайте консультацію.