עומס איזון וכישלון

טען איזון וכישלון

1) מטרות ומונחים

איזון מפיץ תנועה על פני מקרים/אזורים/אזורים לצורך ביצועים והתאוששות.
כשל מבוקר.
RTO/RPO - אובייקט זמן התאוששות ואובדן נתונים מתקבל על הדעת.
SLO: רמת היעד של זמינות/latency; משמש כ ”שער” עבור הילובר אוטומטי וחזרה.

2) איזון שכבות

2. 1 L4 (TCP/UDP)

מקצוענים: ביצועים, פשטות, מעבר TLS. אין דרך הבנה/עוגיות.
דוגמאות: NLB/GLB, HAPROXY/Envoy L4, IPVS.

2. 2 L7 (HTTP/gRPC)

מקצוענים: ניתוב נתיב/כותרות, משקולות כנריות, דביקות. חסרונות: יותר יקר במעבד/Latency.
דוגמאות: NGINX/HAPROXY/Envoy/Cloud ALB/API Gateway.

2. 3 גלובלי

DNS/GSLB: בדיקות בריאות + תגובה גיאו/משוקללת.
Anycast/BGP: IP אחד בכל העולם, נקודת ההכרזה הקרובה ביותר.
CDN/Edge: Cache/Feilover על המתחם.

3) אלגוריתמי הפצה

סיבוב רובין/משוקלל - בסיסי.
לפחות חיבורים/איחור לבקשות ”כבדות”.
חשיש עקבי - דביקות משתמש/דייר ללא הפעלת מרכז.
מקום מבוסס חשיש למטמונים ושירותים מדינתיים.

4) הפעלות ודביקות

L7 LB קובע עוגייה כדי לחזור לדוגמה.
ב-L4, גרוע יותר עם NAT/CGNAT.
חשיש עקבי: טוב יותר עבור מטמונים אופקיים/צ 'אטים.
מטרה: אם אפשר, לעשות שירות חסר מדינה, אחרת - להוציא את המדינה (הפעלות ברדיס/DB) כדי לפשט כשלים.

5) אמינות: בדיקות בריאות והסרה מהסבב

בדיקות פעילות: HTTP 200/Grows נתיב עסקי עמוק (למשל '/בריאה/לסגת עם תלויות).
פליטה לאחור ב-5xx/פסק זמן.
חימום: הכללה חלקה של מקרים חדשים (התחלה איטית).
ניקוז חינני הסר מהבריכה פי המתנה לבקשות להשלים.

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6) ניהול ליקויים: פסק זמן/ריטרי/שבירת מעגל

פסקי זמן: קצר יותר מאשר זמן לקוח; לציין כל מסלול.
חזרות: 1-2 עם ג 'יטר ואידמפוטנטיות; איסור על מגשים מחדש בפוסט ללא מפתחות אידמפוטנציה.
מפסק מעגל: מגביל בקשות/שגיאות סימולטניות; התאוששות ”פתוחה למחצה”.
תקציבים: מגש מחדש מגביל/מיזוג של פרצים כדי לא לארגן DDOS עצמי.

7) תבניות קוברנטס

Clought IP/NodePort/LoadBalancer/Ingress - פרימיטיבים בסיסיים.
תנועה רק על לוחות מוכנים.
תקציב PodGood לא יכול לרדת N העתקים באותו הזמן.
HPA/VPA: קנה מידה על ידי מדדי CPU/RED, קישור ל LB.
טופולוגיה/טופולוגיה מודעת: מקום אחר אזור.
סוג השירות = LailBalancer (zonal): לפחות 2 העתקים בכל AZ.

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8) חוצה-אזור ותנועה חוצה-אזורית

Multi-AZ (בתוך האזור): התפלגות שווה (zonal LB), אחסון - העתקים סינכרוניים.

• Active-Active: שני האזורים משרתים את התנועה; יותר מורכב - צריך שכפול נתונים, עקביות וניתוב גיאוגרפי.
• אקטיבי-פסיבי: אזור ראשי משרת, שמורה - "חם/חם/קר. "קל יותר, מהר יותר החלפה, אבל גבוה יותר RPO.

• Geo-DNS (האזור הקרוב ביותר).
• DNS משוקלל (חלוקה מחדש של קנריות).
• מבוסס latency (מדידות RTT).
• כשל = על ידי אותות בריאות/זמינות (הסתברות מנקודות תצפית מרובות).

9) נתונים וכישלונות

מטמון/מצב: אם אפשר - באופן זמני מקומי; עבור חשיש פעיל-פעיל - CRDT/עקבי.

• שכפול סינכרוני = RPO נמוך, Latency גבוה.
• Asynchronous = latency נמוך יותר, אבל RPO> 0.
• תורים: שיקוף/רב צבעים טופיקליים; שכפול אירועים.
• עיצוב אידמפוטנטיות של פעולות ומכניקה הילוך חוזר.

10) היקפי: DNS/Anycast/BGP/CDN

DNS: TTL קצר (30-60) + בדיקת בריאות מחוץ לרשת שלך.
בכל מקרה: כמה סוכריות עם איי-פי אחד - הקרוב ביותר מקבל תנועה, הנגיף הוא ברמת הניתוב.
CDN/Edge: cache ו- ”gateway” להגנה, static/media מופעלים כאשר המקור נופל; מקור-מגן + זה בריאות פופ.

11) תצורות מדגם

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12) כשל אוטומטי: אותות ושערים

טק-SLI: קצב 5xx, p95/p99, רוויה, לחיצות ידיים TLS, איפוס TCP.
הצלחה של הפקדות/תשלומים, ללא שגיאות תשלום ב-PSP.
שערים: אם הסף עולה על הסף, כבו את האזור/מקרה, הרימו את משקולות הבריכה היציבה, החליפו GSLB.
שלב אחר שלב, הדרכה על גלגיליות.

13) בדיקות וביקורות (כאוס וימי משחק)

בדיקות כאוס: השבתת אזורי AZ/AZES, השפלת מטמון DB/Detradation, סימולציה של אובדן חבילה.
משחק-יום: אימון פיילובר בהשתתפות קבוצות תורניות.
אבחון: התחקות מהיקף לקצוות אחוריים, התאמת הטלת שחרור ומדדים.

14) בטיחות וציות

MTLS בין LB↔servisy, WAF/Rate מגבלות על היקף.
אזורי כישלון/פיצול: בידוד רדיוס פיצוץ.
מדיניות: נקודת כשל אחת (SPOF) איסור, דרישות להעתק מינימלי של N/AZ.

15) אנטי דפוסים

אזור LB/אחד לכל התנועה (SPOF).
אין בדיקה עמוקה '/בריא '(ירוק - אבל תור DB/זמין).
מגש ללא אידמפוטנטיות * עסקאות כפולות/תשלומים.
דביק לכל איי-פי עם חוסר איזון מסה.
DNS feilover עם TTL גבוה (שעות לפני ההחלפה).
אין ניקוז חינני כאשר התרוקן - הפסקת בקשה.

16) רשימת מימושים (0-45 ימים)

0-10 ימים

פוסט מקרים של AZ-2; אפשר מוכנות/לביאה, בדיקות בריאות.
הגדרות L7-timeouts/retries (ניסיון 1), גילוי יוצא.
אפשר ניקוז חינני והתחלה איטית.

11-25 ימים

הזן GSLB (גיאו/משוקלל) או Anycast עבור ההיקף.
מדיניות משקולות/מסלול קנרית; דביק עם עוגייה/חשיש עקבי.
שערי SLO לפיילובר אוטומטי (p95/5xx + עסקים SLI).

26-45 ימים

DR אזורי: פעיל-פעיל או פעיל-פסיבי עם מבחן תרגום.
ימי כאוס עם אזורי AZ/off, RTO/RPO מדווח.
runbook אוטומטי 'ו- (pause/shift/rollback scripts).

17) מדדי בגרות

כיסוי מולטי-AZ ב-99% מהנתיבים הקריטיים.
DNS/GSLB/Anycast מיושמים עבור נקודות קצה ציבוריות.
MTTR כאשר AZ אחד נופל <5 דקות (p95).
RPO למטרה קריטית (לדוגמה, 30 שניות).
ימי משחק רבעוניים ופילובר מוצלח מתוכנן.

18) מסקנה

איזון וכשלונות אמינים הם ארכיטקטורה שכבתית: L7-policies מקומית (timeouts/reteries/CB, checks-health-checks), דבקות נכונה וחשיש, יציבות חוצה-אזורים, ועל ההיקף - GSLB/DNS/Anycast. הוספת שערי SLO, אידמפוטנטיות, ניקוז חינני ומבחני כאוס רגילים - וכל אובדן של צומת, אזור או אפילו אזור יהפוך לאירוע שניתן לנהל עם RTO/RPO צפוי.