הגדרת מאזן עומסים של Cloudflare: ניתוב גיאוגרפי ו-failover

הערה: ככל שהפרויקט שלך גדל ומשתמשים מפוזרים ברחבי העולם, שרת יחיד לא יכול לעמוד בקצב. אנו רואים לעתים קרובות תרחיש כזה: לקוח באוסטרליה מקבל תשובה לאחר 800 אלפיות השנייה כי השרתים נמצאים רק באירופה. אנו מגדירים את Cloudflare Load Balancer כחלופה למאזני עומס קלאסיים L4/L7 — זהו פתרון מבוסס DNS הפועל על גבי רשת ה-Anycast הגלובלית של Cloudflare. התוצאה: זמן האחזור יורד ל-100–150 אלפיות השנייה עבור אזורים מרוחקים, וסובלנות לתקלות מובטחת באמצעות מעבר אוטומטי. לדוגמה, עבור פרויקט מסחר אלקטרוני עם קהלים באסיה ובאירופה, הפחתנו את זמן טעינת הדף ב-40% לאחר יישום ניתוב גיאוגרפי. Cloudflare LB מגן גם מפני DDoS ואינו דורש ניהול תוכנת שרת.

בעיות שאנו פותרים

• אחזור גיאוגרפי. מקור במרכז נתונים אחד, לקוחות ביבשות אחרות סובלים מאחזור גבוה. Cloudflare מנתב אוטומטית בקשות למאגר הבריא הקרוב ביותר (ניתוב גיאוגרפי).
• כשלי מקור. השרת נופל — התעבורה עוברת אוטומטית למקור הבריא הבא הודות לבדיקות בריאות. זמן המעבר הוא עד 120 שניות עם הגדרות ברירת מחדל.
• סשנים דביקים. צריך זיקה לשרת? Cloudflare תומך בזיקת סשן באמצעות עוגיית __cflb. אנו מגדירים זאת כך שעגלת המשתמש לא תיאבד במהלך האיזון.
• ניהול ידני. ניתן לשנות מאגרים ידנית לפי אזור, אך אנו ממכנים באמצעות Terraform — שינויים מיושמים ללא השבתה.

כיצד Cloudflare Load Balancer שונה מפתרונות קלאסיים

בניגוד למאזני עומס חומרתיים (F5, HAProxy באתר יחיד), Cloudflare משתמש בניתוב מבוסס DNS ובחלוקת תעבורה ברשת ה-Edge. בקשת המשתמש עוברת דרך נקודת ה-PoP הקרובה ביותר של Cloudflare, שמפנה אותה למקור בריא במאגר שנבחר. זה מספק הגנה מובנית מפני DDoS ומפחית עומס על המקור. בהשוואה למאזני עומס DNS רגילים, Cloudflare LB מזהה תקלות פי 3 מהר יותר הודות לרשת בדיקה מבוזרת.

למה להשתמש בניתוב גיאוגרפי?

נניח שיש לך שרתים בפרנקפורט ובסינגפור. ללא ניתוב גיאוגרפי, משתמש מטוקיו מקבל תשובה ב-400 אלפיות השנייה כי DNS עשוי להחזיר את ה-IP של השרת האירופי. Cloudflare LB מזהה את האזור של הלקוח (למשל, דרום מזרח אסיה) ומפנה אותו למאגר סינגפור — זמן האחזור יורד ל-50 אלפיות השנייה. לפי Cloudflare, זה מפחית את זמן טעינת הדף ב-35–70% עבור אזורים מרוחקים. מחקרים מראים ש-53% מהמשתמשים עוזבים אתר אם לוקח יותר מ-3 שניות לטעון אותו. ניתוב גיאוגרפי מקצר את זמן התגובה לממוצע של 200 אלפיות השנייה.

מבנה: מאגר → מקור → בדיקת בריאות

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)

# 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"
    }
  }
}

הדוגמה למעלה מציגה תצורה טיפוסית לפרויקט עם שני אזורים ומאגר גיבוי בארה"ב. אנו משתמשים במשקלים לחלוקת תעבורה — לדוגמה, אנו נותנים לשרת אמסטרדם משקל 1 ולפרנקפורט משקל 0.5 (הוא מקבל חצי מהבקשות). זה שימושי כאשר לשרתים יש יכולות שונות. צור קשר כדי להתאים קוד זה לפרויקט שלך.

בדיקות בריאות: ניואנסים

Cloudflare בודק מקורות מנקודות מרובות ברשת שלו. אם רק בדיקה אחת נכשלת, המקור לא נחשב כמושבת. המקור מסומן כלא בריא רק כאשר כל הבדיקות מנקודות PoP שונות נכשלות. לפי התיעוד של Cloudflare, בדיקות בריאות מבוצעות מכמה נקודות PoP.

ניואנס חשוב: בדיקת הבריאות מגיעה מכתובות IP של Cloudflare, לא ממשתמשים. אם יש לך כללי חומת אש שמאפשרים רק כתובות IP של Cloudflare במקור שלך, ודא שכתובות ה-IP של בדיקות הבריאות גם הן ברשימת ההיתרים. רשימה עדכנית: טווחי ה-IP של Cloudflare.

כמו כן, זכור: זמן קצוב ומרווח משפיעים על מהירות זיהוי הבעיות. אנו ממליצים על interval=60s, timeout=5s, retries=2 — זה נותן זיהוי תקלות תוך כ-2 דקות. עבור יישומים קריטיים יותר, ניתן להפחית ל-30s (אבל זה מגביר עומס על המקור).

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

מעבר ונוטיפיקציות

כאשר מקור נופל, Cloudflare מעביר תעבורה למקור הבריא הבא במאגר. אם כל המאגר מושבת, התעבורה עוברת למאגר הגיבוי. זמן זיהוי: 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. ביקורת תשתית נוכחית — זיהוי נקודות כשל, גיאוגרפיית משתמשים, דרישות זיקת סשן.
2. עיצוב טופולוגיה — בחירת אזורים, הגדרת בדיקות בריאות, כללי ניתוב גיאוגרפי.
3. יישום באמצעות Terraform — יצירת מאגרים, מאזן עומס, נוטיפיקציות; בדיקות בסביבת staging.
4. בדיקת מעבר — סימולציית תקלות, אימות מעבר תעבורה.
5. פריסה וניטור — יישום בייצור, חיבור ניטור (Grafana + Prometheus למונה תעבורה).
6. תיעוד והדרכה — העברת ה-runbook לצוות.

מה כלול בעבודה

• קוד תשתית (Terraform) לכל האזורים.
• תיעוד על הארכיטקטורה ותהליך הפריסה.
• הגדרת ניטור בדיקות בריאות והתראות (Slack/Telegram/PagerDuty).
• אינטגרציה עם CI/CD קיים (GitLab CI או GitHub Actions).
• הדרכת צוות על נהלי postmortem ותגובה מהירה.

הערכות זמן

העלות מחושבת באופן אישי לאחר ביקורת על התשתית הנוכחית שלך וגיאוגרפיית המשתמשים. צור קשר להערכת פרויקט. חיסכון ממוצע בעלויות תשתית לאחר יישום Cloudflare LB הוא 30-50%.

טעויות נפוצות

רשימת בדיקה לפני פריסה

• [ ] נתיבי בדיקות בריאות אומתו
• [ ] כתובות IP של Cloudflare נוספו לחומת האש
• [ ] משקלים הוגדרו כראוי
• [ ] נוטיפיקציות מחוברות
• [ ] זיקת סשן הוגדרה (אם נדרש)

הניסיון שלנו

אנו מגדירים Cloudflare Load Balancer כבר למעלה מ-5 שנים והיינו מעורבים בפרויקטים עם עומסים העולים על 100,000 בקשות בשנייה. יותר מ-50 פרויקטים מוצלחים. אנו מבטיחים סובלנות לתקלות עם SLA של 99.99% ומספקים תמיכה לאחר פריסה. הזמינו הגדרת Cloudflare Load Balancer — קבלו פתרון מוכן תוך 3–5 ימים. קבלו ייעוץ.