הגדרת Canary Deployment למודלי ML: מדריך שלב אחר שלב

Canary deployment ML: מדוע העלאת מודל חדש שוברת את הפרודקשן

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

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

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

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

Canary deployment בדיוק עוסק בזה: הגרסה החדשה מקבלת חלק קטן מהתעבורה, בדרך כלל 1–5%, התחזיות מושוות למודל הייחוס לפי סגמנטים והתפלגויות, וסטייה מעל הסף מחזירה אוטומטית את הגרסה הקודמת.

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

העלאה מבוקרת של מודל: אפקט מדיד למוצר

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

שיעור התשובות השגויות והנראות של המודל

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

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

זמן ההחזרה לאחור וסוג תקלות שנעלם

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

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

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

סכמות ניתוב תעבורה ל-ML: השוואת מצבים

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

מה קובעים כללי הניתוב

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

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

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

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

מארז האספקה: קונפיגורציות, סכמות ונוהלי החזרה לאחור

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

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

קייס: מעבר של מודל המלצות להעלאה קנרית

איך היה לפני ההטמעה

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

מה שינו ומה התקבל

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

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

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

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

במה נבדלת העלאה קנרית ממצב צל?

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

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

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

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

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

ספקות טכניים: החזרה לאחור, איכות נתונים, עומס

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

כיצד להבדיל בין הידרדרות המודל לעונתיות של הנתונים?

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

האם נדרשת עיבוד מחדש של השירות לצורך חלוקת התעבורה?

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

כיצד הגרסה הקנרית משפיעה על העומס?

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

נדבר על משימת ההעלאה שלכם: נחזור עם הערכה ותוכנית

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

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

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