יישום אסטרטגיית פריסת עדכון מתגלגל

Rolling Update: מה נשבר בעת הפצת גרסה חדשה

התקלה הנפוצה ביותר בעת הפצת גרסה חדשה היא החלפת כל עותקי השירות בגל אחד.

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

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

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

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

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

האפקט של הפצה מבוקרת: מה משתנה במספרים

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

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

צ'קליסט של מה בודקים ומה מתעדים בדוח:

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

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

השוואת גישות: Rolling Update וחלופות

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

איך לבחור למסלול שלכם

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

איך אנחנו מטמיעים אסטרטגיה: שלבי עבודות הנדסיות

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

שלבי ההטמעה

1. ביקורת תשתית. סופרים עותקים ואת התפרסותם על צמתים, בודקים בדיקות מוכנות וחיות, מדיניות הפסקות, ואת האופן שבו מאזן העומסים מוציא צומת מהסבב.
2. תרשים ההפצה. קובעים כמה עותקים חדשים עולים בו-זמנית ואיזו ירידה בזמינות מותרת (maxSurge ו-maxUnavailable), ואיך הגרסאות מתחלפות בשירות.
3. כוונון פרמטרים. מתקנים בדיקות, זמן המתנה לעצירה, מטפל preStop וחזרות בקשות אצל לקוחות — אחרת עותק שנעצר קוטע חיבורים ממש בזמן ההפצה.
4. בדיקה תחת עומס. על סביבת בדיקה עם פרופיל תעבורה קרבית מריצים הפצה וחזרה: שיעור שגיאות, זמן תגובה בבקשות איטיות נדירות, וכמה זמן תופסת החזרה לגרסה הקודמת.
5. תיעוד. נוהל הפצה וחזרה, קריטריונים לעצירה בעת עליית שגיאות, מה לבדוק קודם כל.
6. מסירה לתפעול. מעבירים למשמרת התורנית מדדים והתראות על הפצה שנתקעה, עוברים על סדר הפעולות והגבול שמעבר לו קוראים לנו.

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

קונפיגורציות, תרשימים ונוהלי מהדורה

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

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

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

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

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

תרשים השחרור נבנה מחדש כ-rolling update ב-Kubernetes: אינסטנצים מוחלפים במנות, maxSurge ו-maxUnavailable קובעים כמה חדשים להעלות בו-זמנית וכמה ישנים מותר להסיר.

בדיקת Readiness לא מכניסה תעבורה לאינסטנס שמתחמם, ו-preStop-hook עם השהיה מאפשר לחיבורים פעילים להיסגר — בהחלפת גרסה לא הולכת לאיבוד אף בקשה.

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

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

מה לעשות אם השירות כבר פועל באשכול?

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

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

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

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

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

ספקות טכניים ומגבלות הגישה

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

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

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

איך לבצע חזרה אם המיגרציה כבר בוצעה?

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

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

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

מה כדאי לשלוח לפני הדיון:

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

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

תארו את המשימה ואת הסביבה הנוכחית — נחזור עם הערכה ותוכנית עבודה.