פריסת מודולי ML ב-Azure IoT Edge: מדריך מלא

מדוע מודולי Azure IoT Edge מאבדים קשר עם הענן

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

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

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

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

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

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

מה נותנת פריסה מנוהלת של מודולי ML

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

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

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

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

פריסה מנוהלת, התקנה ידנית והיברידי

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

מה משנה מצב אופליין של המכשיר

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

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

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

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

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

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

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

תצורות, תוכניות ונהלי עדכון

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

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

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

מקרה בוחן: ביטלנו נסיעות ידניות לאתרים מבוזרים

מה היה

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

מה שינינו

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

מה נהיה

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

במה שונה פריסת Edge מהסקה בענן?

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

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

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

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

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

שאלות טכניות נפוצות בנוגע להטמעה

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

מה קורה למערכת בלי אינטרנט?

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

איך נאספת הטלמטריה ומה נכלל בה?

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

מה נשאר אצלנו לאחר מסירת הפרויקט?

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

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

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

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

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

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

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