שרתי אינטרנט
nginx: שרת האינטרנט שמתרחב בזכות לולאות אירועים
nginx מטפל ביותר מתעבורת האינטרנט מכל שרת אחר מסיבה מבנית: הוא פותר את בעיית C10K במודל א-סינכרוני מונחה אירועים במקום thread לכל חיבור. בפועל הוא ממלא שני תפקידים בו-זמנית, שרת קבצים סטטיים קליל ו-reverse proxy שהוא ברירת המחדל של התעשייה, ורוב הפריסות האמיתיות הן המקרה השני. המשמעת התפעולית סביבו (בדיקת קונפיגורציה, מעקב אחר לוגים, אוטומציה של TLS) היא שקובעת אם העוצמה הזו שקטה או שברירית.
נקודות עיקריות
- ארכיטקטורת event loop היא כל הטיעון: מספר קטן של תהליכי worker מטפל באלפי חיבורים עם החלפת הקשר זולה, ולכן nginx מצטיין ב-proxying של לקוחות איטיים רבים (נכסים סטטיים, משתמשי מובייל במורד הזרם) בלי לשרוף זיכרון לכל חיבור כמו בתכנוני thread-per-request.
- שני תפקידים בבינארי אחד: בלוקי server מגישים תוכן סטטי ומחילים rewrites; בלוקי proxy_pass מסיימים TLS ומעבירים לשירותי upstream, עם התנהגויות קרובות לבדיקות בריאות (max_fails, timeouts, buffering) שהן משטח קונפיגורציה ולא מודולים, וזה שינוי ההרגל הגדול ביותר לעומת חשיבה של Apache.
- משמעת קונפיגורציה משעממת והכרחית: nginx -t אחרי כל עריכה, קובץ include אחד לכל אתר כדי שהחזרות יהיו כירורגיות, ו-reload (לא restart) כפעולת השינוי על מערכת חיה; פרסום קונפיגורציה שנכשלת בבדיקת תחביר הוא תקלה שעולה חצי יום אבל נמנעת לחלוטין.
- TLS הוא שכבה לכל דבר: בחירות פרוטוקול מודרניות, הגדרות session resumption ו-OCSP stapling, עם acme.sh או certbot לאוטומציה של ההנפקה; hook חידוש מוגדר שגוי שנכשל בשקט 60 יום הוא תקלת ה-nginx הקלאסית, לכן התריעו לפי גיל התעודה ולא לפי תאריך התפוגה.
- הגבולות הכנים: אין מערכת מודולים דינמית כמו ב-Apache (מודולים סטטיים בזמן קומפילציה, כך שתכונות צד שלישי דורשות בנייה מחדש או חבילות של ההפצה), ומשטח ה-reverse proxy רזה בכוונה, כי התשובה של nginx למורכבות היא לעתים קרובות להעמיד כלי נוסף מלפנים (הגבלת קצב ב-nginx ועוד WAF בשכבות בסגנון modsecurity).
- עבודת ביצועים מתחילה במציאות ולא בפולחן: worker_processes = auto, worker_connections בגודל שמתאים לזיכרון ולמעטפת העומס, proxy_buffering מובן (buffering דלוק הוא ברירת המחדל והנכון גם לרוב ה-API), gzip/brotli על סוגי טקסט, ולוגים שנסקרים לעמודי 499/504 לפני שספי הדשבורד מצלצלים.
הערת שטח
הקונפיגורציה של nginx שלימדה לקוח הכי הרבה הייתה קובץ אחד: reverse proxy עם HSTS, כותרות caching הוגנות ובלוקי server לכל שירות, הכול מתחת ל-200 שורות. ה-stack הקודם שלהם הכיל 4,000 שורות של include כפולים ו-reload ששבר משהו בכל רבעון. גינון קונפיגורציה נחשב להנדסה.
שאלות נפוצות
nginx מול Apache: מתי nginx הוא בבירור הבחירה הנכונה?
ב-reverse proxying עם מקביליות גבוהה, בתעבורה עתירת תוכן סטטי ובסיום TLS בקנה מידה, שם בדיוק event loop משתלם. ל-shared hosting מבוסס .htaccess עם קונפיגורציה לכל תיקייה, Apache נשאר נוחות (המאמר שלנו על nginx מול apache מכסה את העסקה בכנות).
מהו הכלל של reload מול restart?
Reload (חינני: workers ישנים מסיימים לשרת חיבורים קיימים בזמן שהקונפיגורציה החדשה נכנסת לתוקף) הוא הפעולה היומיומית; restart הוא לשינויי גרסת מנוע ולכל דבר ש-reload לא תופס; ואף אחד מהם לא מחליף הרצה מוקדמת של nginx -t.
למה אתרים מסוימים שמים Apache מאחורי nginx?
זה ה-stack ההיברידי הקלאסי: nginx מסיים TLS, מגיש תוכן סטטי מהר ומעביר בקשות דינמיות ל-Apache, שם .htaccess וכלים בסגנון mod_php מצפים להתנהגות מסורתית; המחיר הוא חלק נע נוסף לנטר ולכוון באופן עקבי.
מהן שלוש טעויות הכיוונון הראשונות שכדאי להימנע מהן?
העתקה והדבקה של ערכי worker ו-buffer מפוסטים בבלוג בלי בדיקת עומס, השארת proxy_buffering כבוי אחרי שמישהו אמר שזה איטי (buffering הוא בדרך כלל ברירת המחדל המהירה), ודילוג על בדיקת קונפיגורציה לפני reload; שלושתן נמנעות עם המשמעת שתוארה למעלה.
איך Kinetikatech מסייעת לך ב-שרתי אינטרנט
נתקלנו בזה מספיק פעמים: תצורה, אופטימיזציה ואבטחה של שרתי אינטרנט בסביבות פרודקשן ופיתוח. עם אופטימיזציה וניהול שרתים מקבלים את כל המחזור — הערכה, יישום, ניטור 24/7 ותגובה בתוך 30 דקות כשזה נחשב.