הגדרת Nginx Reverse Proxy: מטמון, איזון עומסים, SSL

תרחיש טיפוסי: 1000 RPS והשרת האחורי טובע

אפליקציה עמוסה (1000 RPS) מגיעה במהירות למגבלות מסד הנתונים או לצווארי בקבוק במעבד עקב חישובים חוזרים. שרתים אחוריים על Node.js או Python נאבקים עם כל בקשה, במיוחד אם יש שאילתות SQL חוזרות או תבניות כבדות. זמני התגובה עשויים להגיע ל-500ms, ו-P99 מזנק. פרוקסי הפוך מוגדר כראוי עם מטמון פותר מספר בעיות: סיום SSL, הגשת קבצים סטטיים, מטמון תגובות, ואיזון עומסים. אנו רואים לעתים קרובות פרויקטים שבהם השרת האחורי מגיש כל בקשה ישירות, ו-nginx משמש רק כמסיים SSL — דרך ישירה לעומס יתר.

המהנדסים שלנו עם ניסיון של 10+ שנים כיוונו מאות תצורות כאלה. תוצאה: זמן התגובה יורד ב-70% עבור בקשות הניתנות למטמון, עומס השרת האחורי יורד פי כמה. השוואה: מטמון nginx מגיש במיקרו-שניות לעומת Redis/Memcached במילי-שניות (מיקרו-שניות לעומת מילי-שניות). העלות של תצורה כזו היא החל מכמה שעות עבודה, בעוד חיסכון במשאבי שרת יכול להגיע לאלפי דולרים בחודש. לדוגמה, לאחר יישום מטמון, ניתן להפחית את מספר השרתים מ-5 ל-2, ולחסוך 3000 דולר בחודש.

תצורת פרוקסי הפוך בסיסית

upstream backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    keepalive 32;
}

server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/example.com.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
        proxy_buffering on;
        proxy_buffer_size 4k;
        proxy_buffers 8 4k;
    }
}

upstream backend { server 127.0.0.1:3000; server 127.0.0.1:3001; keepalive 32; } server { listen 443 ssl http2; server_name example.com; ssl_certificate /etc/ssl/certs/example.com.fullchain.pem; ssl_certificate_key /etc/ssl/private/example.com.key; location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 5s; proxy_read_timeout 60s; proxy_send_timeout 60s; proxy_buffering on; proxy_buffer_size 4k; proxy_buffers 8 4k; } } ו-keepalive 32 עם proxy_http_version 1.1 הם חובה לחיבורים מתמשכים. בלעדיהם, כל בקשה פותחת חיבור TCP חדש, מה שמוביל לאלפי שקעי Connection "" על שרת עמוס. לחיצת יד TLS אורכת כ-2ms, בעוד הגשה מהמטמון היא מתחת ל-0.1ms, ולכן חיבורים מתמשכים הם קריטיים.

מטמון תגובות מהשרת האחורי

http {
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=backend_cache:10m max_size=100m inactive=60m use_temp_path=off;
    server {
        location /api/ {
            proxy_cache backend_cache;
            proxy_cache_key "$scheme$host$request_uri";
            proxy_cache_valid 200 302 10m;
            proxy_cache_valid 404 1m;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            proxy_cache_lock on;
            add_header X-Cache-Status $upstream_cache_status;
            proxy_pass http://backend;
        }
    }
}

TIME_WAIT הוא אחד הפרמטרים החשובים ביותר. בשגיאת שרת אחורי, nginx מגיש מטמון מיושן במקום 502. http { proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=backend_cache:10m max_size=100m inactive=60m use_temp_path=off; server { location /api/ { proxy_cache backend_cache; proxy_cache_key "$scheme$host$request_uri"; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; proxy_cache_lock on; add_header X-Cache-Status $upstream_cache_status; proxy_pass http://backend; } } } מגן מפני אפקט Thundering Herd: בזמן שבקשה אחת מרעננת את המטמון, אחרות מקבלות את הערך הישן. לפי תיעוד nginx הרשמי, זה מפתח למערכות בעומס גבוה. הוסף את כותרת proxy_cache_use_stale כדי לראות HIT, MISS, STALE, או EXPIRED.

כיצד לוודא שהמטמון עובד?

הוסף updating וחפש HIT, MISS, STALE וכו'. כמו כן, שים לב לירידה בזמן התגובה ובעומס השרת האחורי. זמן השהיה P99 צריך לרדת מ-500ms ל-50ms. לניטור, השתמש במדדי Prometheus מ-nginx stub_status.

אילו כותרות משפיעות על המטמון?

השרת האחורי שולט במטמון באמצעות כותרות HTTP. אם השרת האחורי מחזיר X-Cache-Status, nginx לא מאחסן את התגובה. לאימות כפוי, השתמש ב-API לניקוי:

location ~ /purge(/.*) { allow 127.0.0.1; deny all; proxy_cache_purge backend_cache "$scheme$host$1"; } 

השתמש ב-curl: add_header X-Cache-Status $upstream_cache_status;.

מטמון קבצים סטטיים והגשה ישירה

קבצים סטטיים (jpg, css, js וכו') יכולים להיות במטמון או מוגשים ישירות מ-nginx, תוך עקיפת השרת האחורי. הגשה ישירה מפחיתה את עומס המעבד של השרת האחורי ב-30–50%. דוגמה לקבצים סטטיים עם hash:

location /static/ {
    alias /var/www/app/public/static/;
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
    gzip_static on;
}

Cache-Control: no-cache אומר לדפדפן: הקובץ לעולם לא ישתנה, אל תבצע בקשות מותנות.

למה להשתמש ב-nginx למטמון במקום מטמון בשרת האחורי?

תהליך העבודה

1. ביקורת: ניתוח התצורה הנוכחית, לוגים, מדדים דרך location ~ /purge(/.*) { allow 127.0.0.1; deny all; proxy_cache_purge backend_cache "$scheme$host$1"; } או Prometheus. זיהוי צווארי בקבוק שבהם מטמון מביא את ההשפעה הגדולה ביותר.
2. תכנון: בחירת גודל מטמון, אזורים, כללי אימות. חישוב curl -X PURGE http://localhost/purge/api/products/123 ו-location /static/ { alias /var/www/app/public/static/; expires 1y; add_header Cache-Control "public, immutable"; access_log off; gzip_static on; } לפי גודל תגובה ממוצע (לדוגמה, אזור של 10M מאחסן כ-80,000 מפתחות).
3. יישום: פריסת פרוקסי הפוך עם מטמון, איזון עומסים, SSL. השתמש ב-Ansible או Terraform לפריסה חוזרת.
4. כיוונון: התאמת timeouts, buffers, keepalive לפי מאפייני השרת האחורי. לדוגמה, עבור שרת אחורי עם תגובות ארוכות, הגדל את immutable ל-120s.
5. בדיקות: בדיקת עומס עם wrk או k6. מטרה: זמן השהיה P99 < 100ms עבור בקשות הניתנות למטמון.

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

מה כלול

• תיעוד מלא של התצורה ומדריך תפעול.
• גישה למאגר עם תפקידי Ansible או מודולי Terraform.
• הדרכת צוות (שעתיים): כיצד לנקות מטמון, לקרוא לוגים, לכוון פרמטרים.
• אחריות ל-30 יום על התצורה.

בעיה טיפוסית: מטמון בקשות מאומתות

כברירת מחדל, nginx מאחסן תגובות ללא התחשבות בכותרת stub_status. משתמש אחד עשוי לקבל תגובה המיועדת למשתמש אחר. פתרון: הוסף Authorization או כלול proxy_cache_bypass $http_authorization; במפתח המטמון: Authorization. ודא שזה לא פוגע באבטחה.

כיצד לכוון כראוי את proxy_cache_use_stale?

proxy_cache_key "$scheme$host$request_uri$http_authorization"; מגדיר מתי להגיש מטמון מיושן כאשר השרת האחורי בעייתי. הערך proxy_cache_use_stale הוא מפתח למערכות בעומס גבוה. הוא מגן מפני אפקט Thundering Herd: nginx מאפשר לבקשה אחת לעדכן את המטמון, בעוד אחרות מקבלות את הערך המיושן מבלי לפגוע בשרת האחורי. אנו ממליצים תמיד להשתמש ב-updating בשילוב עם updating.

הזמן התקנה מקצועית — המהנדסים שלנו עם ניסיון של 10+ שנים יעזרו לפרוס פרוקסי הפוך מוכן לייצור עבור הפרויקט שלך. קבל ייעוץ היום: ננתח את התשתית שלך ונציע את התצורה האופטימלית.