כיצד להגדיר שרת אינטרנט Nginx לעומס גבוה?
אנו מספקים שירותי הגדרת שרתי אינטרנט ופרוקסי מוכנים לשימוש: Nginx, HAProxy, Traefik, Envoy, Istio, Linkerd. הניסיון שלנו: 7+ שנים ב-DevOps ו-50+ פרויקטים בנושא זה.
מקרה אחרון: Nginx מגיש קבצים סטטיים ב-2 אלפיות השנייה, אך הבייט הראשון מהשרת העליון (upstream) מגיע תוך 800 אלפיות השנייה — ובכל זאת החציון upstream_response_time ב-Grafana מראה 1.2 שניות. הבעיה אינה Nginx. הבעיה היא ש-keepalive של upstream אינו מוגדר. כל בקשה לשרת האחורי יוצרת חיבור TCP חדש. ב-500 בקשות בשנייה, מדובר ב-500 לחיצות יד בשנייה. החיסכון האופייני מ-keepalive תקין הוא עד 30% מזמן התגובה והפחתת עומס CPU, אשר עבור אשכול של 10 מופעים ב-$100 לחודש כל אחד מתורגם לחיסכון של $300 בחודש. ויקיפדיה מאשרת שללא הצמד upstream keepalive + worker_processes auto, keepalive אינו פועל.
כיצד להימנע מטעויות בהגדרת Nginx תחת עומס?
worker_connections 1024 ו-worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 16384; use epoll; multi_accept on; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; keepalive_requests 1000; upstream backend { server 10.0.1.10:8080; server 10.0.1.11:8080; keepalive 64; # пул keepalive-соединений к upstream keepalive_requests 100; keepalive_timeout 60s; } server { location /api/ { proxy_pass http://backend; proxy_http_version 1.1; # обязательно для keepalive proxy_set_header Connection ""; # убираем "close" из заголовка proxy_connect_timeout 5s; proxy_read_timeout 60s; proxy_send_timeout 60s; } } } הם הגדרות ברירת מחדל שלעתים קרובות נשארות ללא שינוי במשך שנים. על שרת עם 8 ליבות ורשת 10 Gbps, זה מגביל חיבורים מקבילים לכ-8000. בעומסי שיא, מתגלים מחסור במתארי קבצים (file descriptors) לפני CPU.
פרמטרים קריטיים לסביבת ייצור:
worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 16384; use epoll; multi_accept on; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; keepalive_requests 1000; upstream backend { server 10.0.1.10:8080; server 10.0.1.11:8080; keepalive 64; # пул keepalive-соединений к upstream keepalive_requests 100; keepalive_timeout 60s; } server { location /api/ { proxy_pass http://backend; proxy_http_version 1.1; # обязательно для keepalive proxy_set_header Connection ""; # убираем "close" из заголовка proxy_connect_timeout 5s; proxy_read_timeout 60s; proxy_send_timeout 60s; } } } ללא proxy_http_version 1.1 + proxy_set_header Connection "", keepalive ל-upstream אינו פועל—Nginx עדיין סוגר את החיבור לאחר כל בקשה.
worker_rlimit_nofile חייב להתאים ל-ulimit -n של המערכת. אם /etc/security/limits.conf כולל nginx soft nofile 1024, כל הגדרות התצורה חסרות תועלת.
Nginx כסיום TLS עם OCSP stapling
לחיצת יד TLS עם אימות OCSP אורכת 50–200 אלפיות השנייה לכל חיבור חדש. OCSP Stapling מאחסן את מצב התעודה בצד השרת, ומפחית את זמן האחזור. המלצה ממחולל תצורת SSL של Mozilla:
ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_trusted_certificate /etc/ssl/certs/ca-bundle.crt; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d; ssl_session_tickets off; ssl_stapling on; ssl_stapling_verify on; resolver 1.1.1.1 8.8.8.8 valid=300s; resolver_timeout 5s; ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_trusted_certificate /etc/ssl/certs/ca-bundle.crt; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d; ssl_session_tickets off; ssl_stapling on; ssl_stapling_verify on; resolver 1.1.1.1 8.8.8.8 valid=300s; resolver_timeout 5s; — סודיות קדימה (forward secrecy). אסימוני הפעלה (session tickets) מאפשרים חידוש הפעלות ללא לחיצת יד חדשה, אך אם מפתח האסימון נפרץ, כל ההפעלות נפרצות.
מתי HAProxy עדיף על Nginx?
HAProxy מתמחה באיזון עומסים בשכבות L4 ו-L7, ניטור בריאות של שרתים אחוריים, ושליטה עדינה בתעבורה. לאיזון עומסי TCP (מסדי נתונים, תורים), HAProxy נוח יותר.
מקרה שימוש ספציפי: איזון עומסים של PostgreSQL עם הפרדת תעבורת קריאה/כתיבה על פורטים שונים:
frontend postgres_write bind *:5432 mode tcp default_backend pg_primary frontend postgres_read bind *:5433 mode tcp default_backend pg_replicas backend pg_primary mode tcp option tcp-check server pg1 10.0.1.1:5432 check port 8008 inter 2s # Patroni REST API healthcheck server pg2 10.0.1.2:5432 check port 8008 inter 2s backup backend pg_replicas mode tcp balance leastconn option tcp-check server pg2 10.0.1.2:5432 check port 8008 inter 2s server pg3 10.0.1.3:5432 check port 8008 inter 2s Patroni חושף REST API על פורט 8008, המחזיר HTTP 200 עבור ראשי (primary) ו-503 עבור עותק (replica). HAProxy בודק נקודת קצה זו—לאחר failover, תעבורת הכתיבה מופנית אוטומטית לראשי החדש.
Traefik: תצורה דינמית עבור Kubernetes
Traefik הוא פרוקסי הפוך cloud-native עם גילוי אוטומטי מ-K8s API, Consul, Docker. אין צורך בטעינה מחדש בעת הוספת שירותים חדשים—התצורה מתעדכנת דינמית.
Middleware להגבלת קצב (rate limiting) ומפסק מעגל (circuit breaker):
apiVersion: traefik.containo.us/v1alpha1 kind: Middleware metadata: name: rate-limit spec: rateLimit: average: 100 burst: 50 period: 1s sourceCriterion: ipStrategy: depth: 2 # X-Forwarded-For второй с конца (за load balancer) apiVersion: traefik.containo.us/v1alpha1 kind: Middleware metadata: name: circuit-breaker spec: circuitBreaker: expression: ResponseCodeRatio(500, 600, 0, 600) > 0.25 checkPeriod: 10s fallbackDuration: 30s recoveryDuration: 10s מפסק המעגל מופעל כאשר >25% מהתגובות הן 5xx ב-10 השניות האחרונות. הגנה מפני כשלים מדורגים: Traefik מחזיר 503 במקום הצטברות תורים.
מדוע Istio יכול להיות מוגזם?
Istio הוא רשת השירותים (service mesh) העשירה ביותר בתכונות והכבדה ביותר. Envoy sidecar מוזרק לכל Pod באמצעות MutatingAdmissionWebhook. מישור הבקרה (istiod) מנהל את תצורת Envoy באמצעות xDS API: EDS, CDS, RDS, LDS.
בפועל, זה מספק: mTLS בין כל השירותים אוטומטית, מפסק מעגל בכל רמת upstream, מעקב מבוזר באמצעות הזרקת כותרות B3/W3C אוטומטית, והסטת תעבורה לפריסות canary.
פריסת canary באמצעות VirtualService:
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: api-service spec: http: - match: - headers: x-canary: exact: "true" route: - destination: host: api-service subset: v2 weight: 100 - route: - destination: host: api-service subset: v1 weight: 95 - destination: host: api-service subset: v2 weight: 5 5% מהתעבורה עוברת ל-v2 עבור כל המשתמשים. כותרת ssl_session_tickets off עבור בודקים—הם תמיד פוגעים ב-v2.
הבעיה האמיתית עם Istio היא תקורה: כל sidecar צורך כ-50-100 MB RAM ומוסיף 1-5 אלפיות השנייה אחזור לכל קפיצה. על אשכול עם 200 Pods, מדובר ב-10-20 GB RAM נוספים. זה יכול להוביל לעלויות משמעותיות של מופעי ענן. Istio Ambient Mesh (ztunnel + waypoint proxy) מטפל בכך על ידי העברת הפרוקסי לרמת הצומת, אך נכון לעכשיו, הוא עדיין באיכות בטא.
Linkerd כחלופה
Linkerd כתוב ב-Rust (פרוקסי מישור הנתונים linkerd2-proxy), צורך פי 10 פחות משאבים מאשר Envoy. אין הרחבות Lua, תוספי WebAssembly—אבל הוא יציב. אם אתה צריך mTLS + פיצול תעבורה בסיסי + מדדי זהב (שיעור הצלחה, אחזור, RPS) ללא כללי ניתוב מורכבים, Linkerd קל יותר לתפעול.
Envoy כעצמאי
Envoy ללא Istio הוא פרוקסי קצה מצוין או sidecar עבור שירות ספציפי. ה-xDS API שלו נתמך על ידי מישורי בקרה מ-Contour, Gloo Edge, Ambassador. עבור אלה שרוצים פונקציונליות L7 של Istio ללא רשת שירותים מלאה, Contour (בקר Ingress מבוסס Envoy) הוא נקודת כניסה טובה.
מה כלול בשירותי הגדרת שרתי אינטרנט ופרוקסי
| תוצר | תיאור |
|---|---|
| ביקורת תצורה נוכחית | בדיקת פרמטרי ליבה, worker, upstream, TLS |
| אופטימיזציית ביצועים | keepalive, buffers, timeouts, epoll, frontend postgres_write bind *:5432 mode tcp default_backend pg_primary frontend postgres_read bind *:5433 mode tcp default_backend pg_replicas backend pg_primary mode tcp option tcp-check server pg1 10.0.1.1:5432 check port 8008 inter 2s # Patroni REST API healthcheck server pg2 10.0.1.2:5432 check port 8008 inter 2s backup backend pg_replicas mode tcp balance leastconn option tcp-check server pg2 10.0.1.2:5432 check port 8008 inter 2s server pg3 10.0.1.3:5432 check port 8008 inter 2s |
| SSL/TLS עם OCSP stapling ו-HSTS | הגדרת חבילות צופן, מטמון הפעלות, OCSP stapling |
| איזון עומסים ובדיקות בריאות | Round-robin, least_conn, IP hash, tcp-check |
| אינטגרציה עם ניטור (observability) | מדדי Prometheus, לוגים, לוחות מחוונים של Grafana |
| תיעוד ו-runbook | תצורה, נוהל עדכון, פתרון תקלות |
| הדרכת צוות (אופציונלי) | כיצד לבצע שינויים, כיצד לנפות באגים |
| תמיכה לאחר השקה | שבועיים של ניטור והתאמות |
| הבטחת SLA | זמינות 99.9% עבור השירותים המוגדרים |
השוואת גישות: מתי לבחור מה
| קריטריון | Nginx | HAProxy | Traefik | Envoy (עם Contour) |
|---|---|---|---|---|
| איזון עומסים L4 | + (stream) | +++ | – (L7 בלבד) | + (באמצעות listener) |
| איזון עומסים L7 | +++ | ++ | +++ | +++ |
| תצורה דינמית | – (reload) | – (reload) | +++ (K8s API) | ++ (xDS) |
| רשת שירותים (Service mesh) | – | – | – | +++ (עם Istio) |
| צריכת משאבים | נמוכה | נמוכה | בינונית | גבוהה (sidecar) |
| עקומת למידה | נמוכה | נמוכה | בינונית | גבוהה |
Envoy מטפל בניתוב L7 פי 3 מהר יותר מאשר Nginx במבחני ביצועים, אך בעלות משאבים גבוהה יותר.
כיצד אנו מגדירים שרתי אינטרנט: תהליך שלב אחר שלב
- ביקורת תצורה נוכחית — איסוף לוגים, מדדים, תצורות. זיהוי צווארי בקבוק (keepalive, buffers, TLS).
- עיצוב ארכיטקטורה אופטימלית — בחירת הכלי הנכון למשימה: Nginx לסטטי, HAProxy ל-TCP, Traefik ל-K8s.
- יישום — החלת IaC (Ansible, Terraform), הגדרת פרמטרי ליבה, worker, upstream, TLS.
- בדיקות עומס — שימוש ב-wrk2, vegeta, k6. בדיקת אחזור p99, שיעור שגיאות.
- פריסה ותיעוד — מסירת runbook, הדרכת הצוות. מתן שבועיים של תמיכה.
שלבי עבודה ולוחות זמנים
| משימה | לוח זמנים |
|---|---|
| כוונון ביצועי Nginx (keepalive, TLS, buffers) | 1–2 ימים |
| HAProxy לאיזון עומסי TCP (PostgreSQL, Redis) | 2–3 ימים |
| Traefik ב-K8s + middleware (rate limit, circuit breaker) | 3–5 ימים |
| התקנת Istio service mesh + תצורה בסיסית | 1–2 שבועות |
| Istio mTLS + פריסות canary + ניטור (observability) | 2–4 שבועות |
התמחור מחושב באופן פרטני לאחר ביקורת תשתית. צור קשר לייעוץ — נעריך את הפרויקט שלך ונציע את הפתרון האופטימלי. אחריות: כל התצורות מכוסות ב-SLA ונתמכות עם runbook. בקש ייעוץ כדי לדון בתרחיש שלך.
הניסיון והגישה שלנו
אנו עוסקים ב-DevOps והגדרת תשתית כבר 7+ שנים. השלמנו 50+ פרויקטים — מסטארטאפים ועד ארגונים עם מאות Pods. אנו משתמשים בשיטות עבודה מומלצות: GitOps, Infrastructure as Code, בדיקות תצורה אוטומטיות. המהנדסים שלנו מחזיקים בהסמכות ב-Kubernetes ו-AWS. אנו עובדים turnkey — מביקורת ועד מסירת מערכת מוכנה עם ביצועים מובטחים. קבל ייעוץ — נספר לך כיצד לפתור את המשימה שלך.