הגדרת HAProxy: פרוקסי TCP/HTTP, סיום SSL, הגבלת קצב

אנו מגדירים את HAProxy עבור עומסי ייצור — מפרוקסי L4 פשוטים ועד כללי L7 מורכבים עם הגבלת קצב וניתוב SNI. תצורת HAProxy זו מכסה פרוקסי TCP, מאזן עומסים HTTP, סיום SSL והגבלת קצב. אנו מתחילים מתרחישים אמיתיים: נקודת כניסה אחת למיקרוסרוויסים, סיום SSL עבור HTTPS, איזון עומסים של PostgreSQL מבוסס TCP. מצב טיפוסי: מפתחים פורסים ארכיטקטורת מיקרוסרוויסים, ובתוך שבוע הם מגלים ש-Nginx לא יכול להתמודד עם עומסי שיא של 30k RPS — חיבורים נופלים, זמן התגובה עולה. מעבר ל-HAProxy פותר את הבעיה: התפוקה קופצת ל-100k RPS, וזמן התגובה יורד ב-20%. לאחרונה, לקוח פינטק הגיע לתקרת 50k RPS על Nginx עם 32 ליבות — HAProxy על 8 ליבות סיפק 120k RPS ללא אובדנים. החיסכון במופעים הסתכם ב-40% ($2,000 לחודש). במבחני ביצועים, HAProxy עולה על Nginx פי 2 במספר החיבורים המקבילים המקסימלי (1M לעומת 500k) ומשתמש ב-30% פחות CPU עבור אותו עומס. להלן התצורות הטיפוסיות שאנו משתמשים בהן לאחר ביקורת תשתית.

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

L4 לעומת L7: מתי לבחור מה

פרוקסי TCP (frontend https bind *:443 ssl crt /etc/haproxy/certs/ mode http acl is_api hdr(host) -i api.example.com acl is_app hdr(host) -i app.example.com use_backend api_backend if is_api use_backend app_backend if is_app default_backend app_backend ) מיועד לפרוטוקולים שלא ניתן לנתח: PostgreSQL, Redis, MQTT, VPN. HAProxy פשוט מעביר את זרם הבתים ללא בדיקת תוכן. פרוקסי HTTP (example.com.pem) מיועד לתעבורת HTTP/HTTPS שבה יש צורך לנתח כותרות, עוגיות, כתובות URL והגבלת קצב. טעות נפוצה היא לנסות לאזן עומסים של PostgreSQL ב-frontend pg_front bind *:5432 mode tcp default_backend pg_back backend pg_back mode tcp balance source timeout connect 5s timeout server 3600s option tcp-check server pg-primary 10.0.0.30:5432 check server pg-replica 10.0.0.31:5432 check backup : HAProxy ינסה לנתח HTTP, והחיבורים יישברו. באופן דומה, אל תשתמשו ב-frontend http bind *:80 mode http stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur http-request track-sc0 src acl too_many_requests sc_http_req_rate(0) gt 100 http-request deny deny_status 429 if too_many_requests acl too_many_conns sc_conn_cur(0) gt 20 http-request deny deny_status 429 if too_many_conns default_backend app_back עבור HTTPS כאשר נדרש ניתוב מבוסס מארח או סיום SSL.

מדוע בוחרים ב-HAProxy לעומס גבוה?

HAProxy מתוכנן לביצועי L4 מקסימליים. במבחן ביצועים, HAProxy מתמודד עם עד מיליון חיבורים מקבילים על מופע יחיד ללא ירידה בביצועים. Nginx תחת אותו עומס מתחיל להפיל חיבורים בשל מגבלות ארכיטקטוניות. עבור פרויקטים בעומס גבוה, HAProxy הוא הסטנדרט בתעשייה. מעבר ל-HAProxy מפחית עלויות תפעול ב-25–30% הודות לפחות מופעים. זמינות מובטחת של 99.99% מושגת באמצעות בדיקות בריאות ותצורת failover. עלות טיפוסית: הגדרה בסיסית מ-$500; ביקורת מלאה + תצורה מ-$2,000. התצורות המפורטות שלנו כוללות רישום, סטטיסטיקות בזמן אמת דרך socket, וטעינות מחדש חלקות.

כיצד להגדיר סיום SSL ללא אובדן ביצועים?

עבור HTTPS, אנו משתמשים ב-X-Forwarded-* עם קשירת אישורים. חבילת הצפנה אופטימלית היא ECDHE+AESGCM עם TLS 1.2 מינימום. קטע תצורה:

frontend https
    bind *:443 ssl crt /etc/haproxy/certs/
    mode http
    acl is_api hdr(host) -i api.example.com
    acl is_app hdr(host) -i app.example.com
    use_backend api_backend if is_api
    use_backend app_backend if is_app
    default_backend app_backend

ספריית האישורים כולה נסרקת אוטומטית — הוסיפו example.com.pem ו-HAProxy יזהה אותה דרך SNI. תקורה של סיום SSL אינה עולה על 5% עם האצת חומרה.

איך אנחנו עושים את זה: מחסנית טיפוסית

אנו משתמשים בגרסאות היציבות העדכניות ביותר של HAProxy 2.8+, סקריפטים של Lua לבדיקות מותאמות אישית, ו-socat לניהול בזמן ריצה. התצורה נשמרת ב-Git ונפרסת דרך Ansible.

מתי להשתמש במצב TCP?

frontend pg_front
    bind *:5432
    mode tcp
    default_backend pg_back

backend pg_back
    mode tcp
    balance source
    timeout connect 5s
    timeout server 3600s
    option tcp-check
    server pg-primary 10.0.0.30:5432 check
    server pg-replica 10.0.0.31:5432 check backup

עבור חיבורים ארוכי טווח (PostgreSQL, Redis), balance source (דביקות לפי IP) וזמני timeout של שרת > שעה חשובים.

הגבלת קצב והגנה

frontend http
    bind *:80
    mode http
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    acl too_many_requests sc_http_req_rate(0) gt 100
    http-request deny deny_status 429 if too_many_requests
    acl too_many_conns sc_conn_cur(0) gt 20
    http-request deny deny_status 429 if too_many_conns
    default_backend app_back

מניפולציית כותרות ו-ACL

אנו מוסיפים כותרות X-Forwarded-*, מסירים כותרות מסוכנות (כמו X-Forwarded-For שלקוחות עלולים לזייף), ומגדירים ניתוב לפי URL או WebSocket. דוגמת תצורה מלאה זמינה בתיעוד לאחר סיום הפרויקט.

תוצרים

תהליך

1. ניתוח — זיהוי נקודות כשל בודדות, פרוטוקולים נדרשים, SLA.
2. עיצוב — בחירת מצב (TCP/HTTP), שיטת איזון, הגדרות timeout.
3. יישום — כתיבת תצורה, הכנת תפקיד Ansible.
4. בדיקות — הרצת מבחני עומס (לדוגמה, 100k משתמשים וירטואליים), אימות failover.
5. פריסה — החלת תצורה דרך socat ללא הפעלה מחדש.
6. תמיכה — ניטור, טיפול בתקלות לפי SLA (זמינות 99.9%).

לוחות זמנים משוערים

העלות נקבעת באופן אישי לאחר ביקורת. צרו קשר להערכה מוקדמת — זה לוקח יום אחד.

טעויות נפוצות בתצורת HAProxy

1. בחירת מצב שגויה — שימוש ב-TCP במקום HTTP עבור HTTPS עם SNI (אובדן ניתוב מבוסס מארח) או להיפך.
2. בדיקות בריאות חסרות — אם שרת נופל, HAProxy ממשיך לשלוח תעבורה.
3. maxconn לא מוגדר — תחת עומס שיא, HAProxy עלול להיגמר בזיכרון אם החיבורים לא מוגבלים.
4. התעלמות מ-stick-tables — הגבלת קצב לא תעבוד ללא טבלה.

לצוות שלנו יש ניסיון של למעלה מ-7 שנים בהפעלת HAProxy על פרויקטים עם עומסים של עד 100k RPS. קבלו ייעוץ — כתבו לנו, ונשלח לכם הערכה של התוכנית שלכם תוך יום אחד. הזמינו הגדרת HAProxy מאנשי מקצוע — אנו מבטיחים יציבות וביצועים.