הגדרת פרוקסי Envoy: היכן נשבר התעבורה בעומסי שיא
כאשר פרוקסי הפוך תחת עומס מתנהג בצורה בלתי צפויה, חיפוש הסיבה באפליקציה הוא כמעט חסר תועלת: צוואר הבקבוק בנקודת הכניסה מתגלה עוד לפני שהבקשות מגיעות לשירותים.
חיבורים ארוכים — ייצוא בזרימה, דוחות כבדים, סשנים בזמן אמת — נשברים בעת הפעלה מחדש מתוכננת של התהליך, משום שהוא מסתיים מהר יותר משמספיקות להסתיים הבקשות שכבר התקבלו. ביומנים זה נראה כזינוק בתשובות שגיאה יש מאין, בלי ולו עריכה אחת בקוד.
המקור השני — חוסר סינכרון בתצורה בין הצמתים. חוקי הניתוב מתעדכנים בשרת אחד על ידי קריאה מחדש של הקובץ, ובשאר הם נשארים כשהיו. כל עוד התעבורה מופצת בין כל הצמתים, אותה כתובת נופלת פעם תחת הניתוב החדש ופעם תחת הישן: חלק מהלקוחות מקבלים תשובה תקינה, וחלק — שגיאת ניתוב. לשחזר זאת בסביבת בדיקה לא מצליחים — שם יש צומת אחד, ולפער אין פשוט מאיפה להיווצר.
הסוג השלישי של כשלים — עריכות ידניות תחת עומס. שינוי חוקים בשעת שיא מחייב קריאה מחדש של התצורה, ולעשות זאת בלי לנתק חיבורים שכבר הוקמו לא תמיד מצליח. כל פעולה כזו פותחת חלון שבו הולך לאיבוד חלק מהתעבורה, וככל שהנתיבים משתנים לעתים קרובות יותר, כך החלון הזה מתרחב.
בדיוק משום כך הגדרת פרוקסי Envoy מתחילה לא מקובץ התצורה, אלא מהתשובה לשאלה כיצד החוקים מגיעים לכל הצמתים בו-זמנית ומה קורה לחיבורים ברגע החלתם.
נבחן כיצד זה נסגר: מהפצה דינמית של התצורה ללא הפעלה מחדש ועד סיום מבוקר של חיבורים.
מה נותן פרוקסי הפוך מנוהל: האפקט במספרים
נקודת כניסה אחודה מסירה מהאפליקציות את עבודת שכבת הכניסה: בדיקת תעודות לקוח, הגבלת קצב בקשות, ניסיונות חוזרים לצמתים לא זמינים, תיאום הסכימה. השירות עוסק בלוגיקה שלו ולא בהובלה — ומפסיק לקרוס בגלל בקשה שגויה או בגלל שכן שלא השיב בזמן.
תפקיד כזה אנחנו מוסרים לפרוקסי Envoy, שבו נתיבים, חוקים ואימות הדדי באמצעות תעודות מתוארים באופן הצהרתי, ולא מרוחים על פני קוד האפליקציות.
מה משתנה במספרים
זמן החלת התצורה. בעבר עריכת נתיב חייבה בנייה מחדש של התמונה והפעלה מחדש — עשרות דקות וניתוק חיבורים. תצורה דינמית נקלטת תוך כדי תנועה: השינוי נכנס לתוקף בתוך שניות, חיבורים פעילים אינם נשברים, ואין צורך בהפעלה מחדש.
שיעור הכשלים תחת עומס. איזון עומסים בהתחשב במצב בפועל של הצמתים, ניסיונות חוזרים אוטומטיים במופע אחר ופתיחת המעגל לשירות לא בריא מסירים שגיאות מדורגות בזמן זינוק. היחלשות של מופע אחד מפסיקה להיות מורגשת למשתמש.
פעולות ידניות לפריסה. נתיבים, תעודות וחוקים מתוארים בסט קבצים מנוהל גרסאות ומיושמים בשינוי אחד — במקום סדרה של עריכות ידניות בכל צומת.
בנפרד נעלם סוג האירועים "עדכנו את שכבת הכניסה — חלק מהשירותים נפלו": עמידות שכבת הכניסה בפני תקלות מובטחת ברמת הפרוקסי עצמו, ולא במעשים הרואיים של התורן.
השוואת מצבי תצורה: סטטי, קבצים, דינמי
ב-Envoy התצורה נכנסת לתהליך באחד משלושה נתיבים: קובץ סטטי בעת ההפעלה, תצורה כקוד ממאגר עם החלה אוטומטית, או זרם משרת ניהול. ההבדל מתגלה במחיר העריכה — הפעלה מחדש עם ניתוק חיבורים לעומת עדכון נתיב על תעבורה חיה.
נתיב רביעי — לא להחזיק שכבת פרוקסי כלל, אלא לקחת מאזן עומסים ענני מוכן. להלן גבולות הישימות של כל אפשרות, כולל אלו שבהן הגישה נתקלת במגבלות של עצמה.
| אפשרות | מתי מתאימה | מגבלות הגישה |
|---|---|---|
| תצורה סטטית | סביבות בדיקה, שירותים בודדים, עריכות נתיבים נדירות | כל שינוי — הפעלה מחדש עם ניתוק חיבורים; אינה מתרחבת לעשרות צמתים |
| תצורה כקוד במאגר עם החלה אוטומטית | מעגל אחד או שניים, שינויים לפי לוח זמנים, יש צורך בביקורת ובחזרה אחורה דרך ההיסטוריה | ההחלה אורכת דקות; אין תגובה לנפילת צומת או לעלייה בעומס |
| הפצה דינמית של הגדרות משרת ניהול | שירותים רבים, מהדורות תכופות, סכימות קנרית, החלפה חמה של נתיבים | דורשת שרת ניהול ותצפיתיות שלו; שגיאה מתפשטת לכל הצמתים בבת אחת |
| מאזן עומסים ענני מוכן | לא רוצים להחזיק שכבת פרוקסי, התעבורה כבר עוברת דרך הענן | פחות שליטה על פסקי זמן, ניסיונות חוזרים ומדיניות mTLS; קשה יותר להחליף ספק |
בפועל משלבים בין האפשרויות: הסטטי מרים את הפרוקסי עצמו, והדינמי מעדכן נתיבים ותעודות. המגבלה המשותפת היא אחת — בלי בדיקת התצורה במעגל בדיקה ובלי פריסה מדורגת, השגיאה נופלת מיד על כל התעבורה.
סדר היישום: מביקורת תעבורה ועד מסירה
מתחילים במיפוי מלאי: אילו שירותים מקבלים תעבורה חיצונית, היכן מסתיים TLS והיכן נדרש אימות הדדי. בלי מפת זרימות, עריכת נתיבים הופכת לניחוש — תחילה מתעדים עובדות, ורק אחר כך נוגעים בתצורה.
- ביקורת תעבורה. משרטטים תמונה מיומנים ומטריקות: חלקי פרוטוקולים, ערכי שיא, חיבורים ארוכים, מקורות הבקשות. בתום — רשימת נתיבים עם בעלים ודרישות הצפנה.
- סכימת ניתוב. מתכננים listeners, clusters וחוקים: לפי דומיין, נתיב או כותרת, עם מדיניות mTLS, בדיקת תעודות ופסקי זמן. מתאמים את הסכימה לפני כתיבת התצורה.
- הגדרת צמתים. פורסים פרוקסי Envoy ומחברים תצורה דינמית, כדי שעריכות ייושמו בלי הפעלה מחדש ובלי ניתוק חיבורים. בנפרד בודקים את ההתנהגות כאשר מקור התצורה אינו זמין.
- בדיקה תחת עומס. מריצים פרופיל קרוב לזה של הייצור: בקשות שיא, ניתוק חיבור באמצע התשובה, כשל של צומת אחד. בוחנים את זמן התגובה ואת שיעור השגיאות, ומתקנים את המגבלות.
- העברה מדורגת של תעבורה. מעבירים זרימות בחלקים, מהפחות קריטיות לעיקריות, עם אפשרות להחזיר את הנתיב אחורה בעריכה אחת. בכל שלב משווים את המטריקות לבסיסיות.
- מסירת נהלים. מוסרים את הסכימה, את התצורה במערכת בקרת גרסאות, את סדר הוצאת השינויים ואת סדר החזרה אחורה, ומאמנים את התורנים.
מכאן והלאה, הנתיבים והתעודות משתנים על ידי הצוות שלכם — לפי חוקים מתועדים, בלי השבתות ובלעדינו.
חפצי תצורה: סכימות, מדיניות, נהלים
כמה תצורות פרוקסי שנערכות ביד בעורך מחזיקות מעמד בדיוק עד העזיבה הראשונה של מהנדס. הגדרת Envoy עובדת היא סט של חפצים מתואמים, שבו מתועדים נתיבים, חוקי גישה וסדר שינויים שלהם. להלן רשימה של מה שנשאר אצל הלקוח יחד עם גישה לסביבות הבדיקה.
- סכימות ניתוב: מפת מארחים וירטואליים, קידומות נתיבים ושירותי יעד עם זמן המתנה לתשובה, מספר ניסיונות חוזרים וחוקי חלוקת עומס.
- טופולוגיית צמתים: היכן נמצאים מופעי הפרוקסי, כיצד מופצת התצורה ומה קורה בעת אובדן הקשר עם מקורה.
- מדיניות גישה: חוקי בדיקה דו-כיוונית של תעודות, רשימות לקוחות מהימנים, הגבלות לפי מתודות ונתיבים, מגבלות קצב בקשות.
- תפקידים והרשאות: מי משנה נתיבים, מי רק קורא מטריקות, מי מנפיק תעודות, וסדר התיאום של פעולות כאלה.
- נוהל הוצאת שינויים: בדיקת תחביר, הרצה בסביבת בדיקה ביניימית, פריסה לפי צמתים, אישור התוצאה.
- נוהל חזרה אחורה: שמירת גרסאות קודמות, הסימן להתחלת החזרה והזמן שבו התצורה חוזרת להיות עובדת.
- הוראות למשמרת תורן: תסמינים אופייניים, פקודות אבחון, סדר הסלמה ופעולות שהתורן אינו מבצע בלי תיאום.
התיעוד יושב באותו מאגר שבו נמצאת התצורה, ומתעדכן יחד איתה — מהנדס חדש נכנס לעבודה בלי סיפורים מפה לאוזן, וכל שינוי נשאר ניתן לשחזור.
דוגמה מהפרקטיקה: מספרים לפני ואחרי השינוי
לקוח הגיע עם פלטפורמה של תשעה שירותים: הכניסה למעגל הייצור נשענה על צומת אחד עם תצורה שנערכה ביד. פריסת גרסה חדשה חייבה הפעלה מחדש — התעבורה נפלה לשגיאה למשך 1–3 דקות, ובמקרה של שגיאת הקלדה בנתיב החלון נמשך עד 20 דקות.
התעודות התעדכנו לפי לוח זמנים, ופעמיים ברבעון שברו את האימות ההדדי בין השירותים — מבחוץ זה נראה כמו כשלים יש מאין.
מה שינו
העבירו את הכניסה ל-Envoy עם תצורה דינמית: את הנתיבים ואת רשימת השירותים מספקת שכבת הניהול במנוי, ולכן החוק מיושם בלי הפעלה מחדש ובלי ניתוק חיבורים. את mTLS הגדירו עם הנפקה אוטומטית ורוטציה — תוקף קצר של התעודה והנפקה מחדש בלי מעורבות התורן. את הנתיבים ואת בדיקות הבריאות הוציאו לקבצים הצהרתיים, והשינויים עוברים בדיקה לפני יישום.
מה יצא
ההשבתה בזמן הפריסה נעלמה: התצורה משתנה על תעבורה חיה, ושיעור התשובות המוצלחות ברגע המהדורה אינו שונה מיום רגיל. הדרך מהעריכה ועד להשפעה על כל הצמתים התקצרה מ-25–40 דקות לדקה.
אירועים עם תעודות שפג תוקפן וחוסר סינכרון של צמתים הפסיקו לחזור על עצמם: במשך רבעון — אף השבתה לא מתוכננת בגלל שינוי בכניסה.
החזרה אחורה כעת היא החזרת הגרסה הקודמת של התצורה, ולא הפעלה מחדש בחירום עם חימום, ולכן זמן השחזור ירד מעשרות דקות לשתי דקות.
במה שונה אימות הדדי בצומת מבדיקה בשירות?
אימות הדדי בצומת ובדיקת האותנטיות של השירות הם שני רבדים שונים, ובלבול ביניהם יקר. בכניסה Envoy עונה על השאלה "מי הגיע": האם הוצגה תעודה שהונפקה על ידי רשות אישורים מהימנה, האם השרשרת מתכנסת עד לשורש, האם תוקפה לא פג והאם שם הבעלים תואם למצופה.
השירות עונה על שאלה אחרת — "מה מותר לקורא הזה": פעולה מסוימת, תפקיד, תחום גישה בנתונים. הראשון — על אותנטיות, השני — על סמכויות, והחלפה של האחד בשני שוברת את כל המודל.
אזור האמון מסתיים במקום שבו מסתיים החיבור המאובטח. אם משאירים את הבדיקה רק בקוד השירותים, כל אחד מהם גורר לוגיקה משל עצמו לניתוח השרשרת, לבקרת ביטול ולעדכון תעודות שורש — ובמוקדם או במאוחר אחד מהם מפגר בכך אחרי האחרים.
פער בחוקים משמעו שחלק מהפניות הפנימיות עוברות לפי דרישות מוחלשות, ואיש אינו שם לב לכך עד שמתחיל בירור האירוע.
פנייה פנימית נחשבת לכזו שעברה את שכבת הכניסה ונושאת תווית אזור מאומתת. בפועל זה נראה כך: קריאות יוצאות מיורטות ברמת הצומת, התעודה מוזרקת אוטומטית, והשירות כלל אינו מאחסן מפתחות פרטיים ואינו יודע לקרוא אותם.
גישה כזו מסירה סוג שלם של שגיאות — פסק זמן נשכח לבדיקת ביטול, תעודת שורש שנצרבה לתוך התמונה, מפתח בחתימה עצמית שנותר מהדיבוג.
לשכבת הכניסה מעבירים כל מה שניתן לבדוק בלי לדעת את הלוגיקה העסקית: את השרשרת, התוקפים, הביטול, את סט הפרוטוקולים והגרסאות המותרים, ואת ההגבלות לפי כתובות. בשירות נשארת ההרשאה — היא תלויה בתחום התוכן ובלעדיה אינה עובדת.
ההפרדה מאפשרת רוטציה של תעודות בלי בנייה מחדש של השירותים ונקודה אחודה שבה משתנה מדיניות מעגל האבטחה. לכן שני הרבדים אינם מחליפים אלא משלימים זה את זה.
ספקות טכניים: חזרה אחורה, דיבוג, עמידות בתקלות
ב-Envoy התצורה הדינמית מגיעה משרת ניהול, והחלתה אינה דורשת הפעלה מחדש של התהליך: מאזינים וקבצים מתעדכנים תוך כדי תנועה, והחיבורים שהוקמו מגיעים לסיום הבקשות הפעילות. אם הסט החדש התברר כפגום, הצומת חוזר לגרסה התקפה האחרונה בלי התערבות ידנית.
מה קורה לחיבורים שהוקמו בעת יישום תצורה חדשה?
המאזין עובר לסט חוקים חדש, אך הזרמים הפעילים אינם נשברים: החיבור חי עד לסגירה מצד הלקוח או עד לפקיעת פסק הזמן מהמדיניות. עבור סשנים ארוכים הזמן מוגדר בנפרד, כדי שהעדכון לא יקרע עבודה שוטפת.
כיצד מבצעים חזרה אחורה משינוי כושל?
התצורה מנוהלת גרסאות, ולכן החזרה אחורה היא החזרת הסט הקודם, ולא עריכה ידנית לפי הזיכרון. התרחיש מתורגל מראש: ידוע תוך כמה זמן הצומת חוזר למצב עבודה ואילו חיבורים שורדים את המעבר.
כיצד קוראים יומנים בעת בירור אירוע?
יומני הגישה, יומני הפרוקסי והמעקב מקושרים לפי מזהה הבקשה: לפיו רואים את הצומת, את החוק ואת סיבת הכשל. זה מספיק כדי להפריד בין שגיאת ניתוב לתקלה בשירות שמעליו.
מה יקרה אם צומת אחד ייפול?
הצמתים עובדים כקבוצה: כאשר אחד נופל, התעבורה עוברת לחיים, ובדיקות הזמינות מוציאות מופעים לא בריאים מהרוטציה. כל צומת מאחסן את התצורה מקומית, ולכן אי-זמינות של שרת הניהול אינה מפילה מעגל שכבר פועל.
נדון במשימה: מה נדרש מצדכם ומה אנחנו עושים
ההתחלה לא צריכה להפוך לשבוע של התכתבות: את הנתונים הראשוניים מתעדים מיד, כדי שההערכה תישען על מעגל אמיתי ולא על הנחות. להלן — מה נדרש מצדכם ומה אנחנו מכסים.
- הרשאות גישה. לקריאה בלבד — לצמתים שעליהם פועל הפרוקסי, למאגר עם התצורה הנוכחית, למערכת ניהול הסודות ולאזור ה-DNS. את רשימת החשבונות והתפקידים מעבירים מראש, ואיננו מבקשים דברים מיותרים.
- מיפוי מלאי של המעגל. אילו שירותים מפורסמים החוצה, היכן נקודות הכניסה, כמה סביבות יש וכיצד הן מבודדות. מכך תלויים מספר התצורות וסכימת הניתוב.
- זרימות ותעודות. דומיינים ונתיבים, מהיכן מגיעים הלקוחות, האם נדרשת בדיקה הדדית של תעודות בכניסה ומי מנפיק אותן — רשות האישורים שלכם או חיצונית.
- אספקת התצורה. האם היא נערכת כעת ביד או מסופקת אוטומטית, האם יש דרך לחזור לגרסה הקודמת ומי מוסמך לערוך בסביבת הייצור.
- תצפיתיות. לאן הולכים יומני הגישה, המטריקות והמעקב, אילו התראות כבר מוגדרות ולפי אילו ספים הן מופעלות.
- מגבלות. דרישות זמינות, חלונות שבהם שינויים אסורים, וסדר התיאום של עריכות.
התחום שלנו — תכנון ניתוב ומדיניות גישה, פיזור התצורה של Envoy לפי רבדים, עדכון בלי הפעלה מחדש של צמתים והסדר המתואר לחזרה אחורה. בתום הבירור נחזור עם הערכה ותוכנית עבודה: שלבים, סדר הפריסה, סיכונים ובדיקות בכל שלב.