הגדרת פרוקסי הפוך של Nginx: איזון עומסים, SSL, WebSocket

הגדרת פרוקסי הפוך Nginx: היכן נשברת התגובה

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

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

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

לצד זה — הפניות שנאספו בבלוקים מותנים בתוך location, בלוקי server כפולים, תעודות שנדרשות ידנית ואחת הפעמים לא מתחדשות. בלוגים זה התפרצות אחת של תגובות 500 על רקע ירידה בשיעור ההצלחות.

הגדרת פרוקסי הפוך Nginx מתחילה מכך שהתצורה מפסיקה להיות ידנית: תבניות במקום עריכות על צומת חי, בדיקת תחביר לפני החלה, טעינה חלקה של workers עם פסק זמן המתנה, כדי שבקשות שהחלו יסתיימו.

בהמשך — כמה שרתי אפליקציה תחת שם upstream אחד, חזרה על בקשה לצומת אחר בעת שגיאה, בדיקת חיות נפרדת, סיום TLS עם חידוש תעודות אוטומטי.

חיבורים ארוכים ו-WebSocket עוברים במסלול נפרד: פסקי זמן סרק משלהם, חציצה מבוטלת, העברת כותרת Upgrade. בלי זה צ׳אט ותגובות סטרימינג נופלים אחרי דקת שקט, בעוד שדפים רגילים נפתחים כרגיל.

נפרק איך זה נסגר: מתרשים הניתוב והטיפול בכשלי צומת ועד אוטומציה של פריסת התצורה.

מה נותנת כניסה מנוהלת: מהירות ויציבות

כניסה מנוהלת — נקודה אחת שבה מוחלט לאן תגיע הבקשה. פרוקסי הפוך ב-nginx מפיץ אותן בין מאגר אפליקציות בהתחשב בחיות הצמתים: כל עוד השרת מגיב בתוך הסף שהוגדר, הוא מקבל את חלקו; בעת הרעה הוא מוצא מהרוטציה בעצמו.

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

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

הצפנת תעבורה נסגרת בכניסה: תעודות מתחדשות אוטומטית, פרוטוקולים מיושנים מושבתים, שירותים פנימיים מתקשרים בתוך ההיקף בלי הוצאות מיותרות על קריפטוגרפיה. נעלמת העבודה הידנית עם הנפקת תעודות והתקלה הטיפוסית "פספסנו — האתר לא זמין".

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

תרשימי איזון עומסים: אפשרויות, מגבלות, דקויות

צומת כניסה אחד עם Nginx — התרשים הפשוט ביותר ובו־זמנית השביר ביותר: עדכון תצורה מתוכנן או הפעלה מחדש של התהליך עוצרים את כל התעבורה החיצונית, ואיתם סיום ההצפנה וסשני WebSocket פתוחים. כל עוד הצומת אחד, כל עריכה של תצורת הכניסה היא חלון אי־זמינות.

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

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

סדר ההטמעה: מביקורת תעבורה ועד מסירה

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

1. ביקורת תעבורה. משרטטים מפה: דומיינים ותת־דומיינים, חלקי בקשות לפי סוגים, משך חיבורים, נפח סשני WebSocket ארוכים, חלונות שיא. בנפרד מתעדים היכן כעת מסתיים TLS ולאן מצביע DNS — זה קובע את תרשים המעבר.
2. תכנון התרשים. מגדירים נקודות סיום תעודות, קבוצות שרתי upstream, מדיניות איזון, פסקי זמן לחיבורים ארוכים, סדר טיפול בכותרים. מתאמים את התרשים עם הצוות שלכם לפני העריכה הראשונה של התצורה.
3. הגדרה בסביבת בדיקות. בונים תצורה לפי בלוקים ובודקים תחביר לפני החלה. מרימים עותק של התרשים בעמדה נפרדת, כדי לתפוס שגיאות בלי להשפיע על בקשות פעילות.
4. בדיקה תחת עומס. מזרימים פרופיל קרוב לפרודקשן, כולל WebSocket ותגובות איטיות של האפליקציה. בודקים איך גדל השיהוי, האם חיבורים מחזיקים כששרת אחד נופל, וכמה זמן לוקח המעבר.
5. מעבר בלי השבתה. מעבירים תעבורה בהדרגה: קודם חלק מהבקשות, אחר כך הנפח המלא. התרשים הישן נשאר פעיל ומוכן לחזרה, עד שמדדים חדשים יאשרו יציבות.
6. מסירה לתפעול. מוסרים תצורות במאגר, תרשים קשרים, מדיניות עדכון תעודות, דשבורדים וכללי התראות, הוראות חזרה אחורה. עורכים תדריך עם צוות התורנות, כדי שתקלות טיפוסיות ייסגרו בלעדינו.

תצורות, תרשימי ניתוב ומדיניות גישה

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

• תצורות במערכת בקרת גרסאות — מחולקות לפי משמעות: פרמטרים גלובליים, תיאורי upstream, בלוק נפרד לכל דומיין. שינויים עוברים ריוויו ובתחילה נפרסים לעמדת בדיקות.
• תרשים ניתוב — מסלול הבקשה מנקודת הכניסה ועד לשירות מסוים: אילו דומיינים ונתיבים מנותבים לאן, היכן מסתיים TLS, ובאילו תנאים התעבורה עוברת ל-upstream רזרבי.
• מדיניות גישה — הגבלות לפי כתובות ותת־רשתות לאזורי ניהול, כללי אימות, הפרדה מפורשת בין נתיבים ציבוריים לפנימיים.
• מגבלות חיבורים ופסקי זמן — מספר מרבי של חיבורים במקביל לצומת ולקוח, גדלי חוצצים, זמן המתנה לתגובת upstream, ספי הגנה מהתפרצויות תעבורה.
• כללים ל-WebSocket ולחיבורים ארוכים — כותרות מעבר פרוטוקול תקינות, upstream נפרד בלי חציצה, פסקי זמן מוגדלים לנתיבים כאלה.
• נוהל תחזוקה — סדר חידוש תעודות, סבב לוגים, טעינת תצורה מחדש בלי לנתק חיבורים פעילים וחזרה לגרסה קודמת.
• מפת ניטור — אילו מדדים נאספים מהפרוקסי, אילו ערכים נחשבים לחירום, לאן עוברות התראות ומי מטפל בהן.

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

מקרה בוחן: איך הסרנו השבתה בפריסת ריליסים

לפני הארגון מחדש, ריליס נפרס באמצעות הפעלה מחדש של צומת יחיד: כל פריסה יצרה 4–6 דקות של אי־זמינות מלאה, וחלון הפריסה נבחר בלילה כדי להיכנס למינימום תעבורה. כשל צומת משמעו השבתה עד הגעת התורן — שחזור ארך עשרות דקות והחזיק את כל הצוות על הקו.

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

מדדים לפני ואחרי

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

במה שונה פרוקסי הפוך ממאזן עומסים?

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

פרוקסי הפוך אחראי לכל מה שקורה לפני הניתוב: מסיים TLS ומחדש תעודות, מציב כותרות Host ו-X-Forwarded-*, מגביל גודל גוף וקצב בקשות, דוחס תגובות, שומר סטטי במטמון, מעביר Upgrade עבור WebSocket. זה ניהול הכניסה, לא פיזור.

איזון עומסים מתחיל במקום שבו בתצורה מופיע upstream עם כמה שרתים: אלגוריתם בחירה (לפי סבב, לפי מספר חיבורים פעילים, הצמדה לפי IP), בדיקות זמינות, הוצאת צומת שנפל מהרוטציה, חזרה על בקשה לשרת שכן, שמירת סשן. בלי הרשימה הזו המילה "איזון עומסים" לא אומרת דבר — נשאר שם מארח אחד.

ב-Nginx שני התפקידים חיים באותו קונפיג: בלוק upstream מתחבר ל-server, ואותו צומת שסיים TLS מתחיל לפזר תעבורה. לכן השאלה היא לא "פרוקסי או מאזן עומסים", אלא כמה מופעי אפליקציה יש לכם והאם הם צריכים נקודת כניסה משותפת.

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

תעודות, חיבורים ארוכים ומגבלות: ספקות

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

איך יתנהגו WebSockets מאחורי פרוקסי הפוך?

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

מה עם מגבלות על מספר חיבורים בו־זמנית?

מחשבים מגבלות לפי מספר לקוחות בו־זמנית ומרווח להתפרצות, ולא "בעין", ומגבילים קצב בקשות מכתובת אחת. בעומס שיא התור לא גדל, ומשתמשים רגילים לא רואים סירובים.

האם יציאות שירות ולוחות ניהול נשארים פתוחים?

לא. הלוח והמדדים מאזינים רק לכתובת מקומית, החוצה מסתכלת כניסה יחידה. אזורי ניהול סגורים ברשימת כתובות מורשות ואימות נפרד, ואת השאר חוסם חומת אש.

נדון בתרשים שלכם ונחזור עם הערכה

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

• רשימת דומיינים ותת־דומיינים שיעברו דרך הפרוקסי, והיכן כעת מסתיים TLS: על nginx עצמו, על מאזן עומסים מעליו או בתוך האפליקציה.
• מאגר הבקאנדים: כתובות ופורטים של שירותים, מספרם ודרך חלוקת העומס המועדפת — לפי סבב, לפי מספר חיבורים פעילים, עם הצמדת לקוח לשרת.
• דרישות לחיבורים ארוכים: האם נדרשים WebSocket, סטרימינג של תגובה, אירועים, ואיזה ניתוק קשר נחשב לבלתי קביל.
• תרשים עמידות בתקלות: צומת אחד, זוג עם כתובת צפה או כמה מאחורי מאזן עומסים חיצוני; האם נדרשת הפעלה מחדש חלקה של התצורה בלי לקטוע בקשות פעילות.
• תעודות וסדר הנפקתן: מרכז חיצוני או פנימי, חידוש אוטומטי, אחת משותפת או נפרדת לכל דומיין.
• נראות: לאן נכתבים לוגים של גישה ושגיאות, אילו מדדים נאספים, האם יש אספן לוגים ואילו ספים הוגדרו להתראות.
• מגבלות והרשאות: רשתות מורשות, הגבלת קצב בקשות, הגנה מהתפרצויות, מי מנפיק הרשאות לשרתים ומשנה תצורה.

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

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