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

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

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

למה זו ההחלטה החשובה

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

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

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

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

מה חייב להיות בקצה

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

כל פונקציה שאי אפשר לעכב. בקרה שחייבת להגיב בזמן קצוב, עצירה בעת מצב חריג, או תגובה לאירוע פיזי. רשת מוסיפה השהיה שאינה מובטחת, ולכן פונקציה שתלויה בזמן אינה יכולה להסתמך עליה. במערכות Real-Time Embedded זה אינו שיקול אלא אילוץ.

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

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

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

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

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

מה שייך לענן

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

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

אחסון היסטורי. מכשיר יכול לשמור ימים או שבועות; ניתוח מגמות דורש חודשים ושנים. האחסון ארוך הטווח שייך לענן.

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

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

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

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

השכבה שבאמצע: השער

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

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

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

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

השיקולים שקובעים את החלוקה

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

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

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

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

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

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

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

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

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

דפוסי חלוקה נפוצים

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

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

הטעויות שחוזרות

מהניסיון, כמה טעויות חוזרות בתכנון החלוקה, וכולן ניתנות למניעה.

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

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

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

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

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

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

איך מגיעים להחלטה

התהליך המעשי אינו מורכב, אך הוא דורש להישאל בסדר הנכון.

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

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

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

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

שאלות נפוצות

מה חייב להיות בקצה ולא בענן?

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

מה הענן עושה טוב יותר?

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

למה קשה לשנות את החלוקה בהמשך?

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

מתי נדרש שער מקומי?

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

אילו שיקולים מכריעים את החלוקה?

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

מהי הטעות הנפוצה ביותר?

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

איך בודקים שהחלוקה נכונה?

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

מי צריך לקבל את ההחלטה הזו?

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

היתרון של TandemG: החלוקה נקבעת מתוך ראייה מערכתית

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

היכולת לעשות זאת נובעת מכך שאנו מכסים את כל השכבות: פיתוח חומרה ואלקטרוניקה, שבו נקבע אם למעבד יש כוח לעבד בקצה; מערכות Real-Time Embedded לפונקציות שאינן יכולות להמתין לרשת; Embedded Linux לשערים ולעיבוד מקומי מורכב; ופתרונות IoT מקצה לקצה שכוללים את התקשורת, הענן, וממשקי הניהול. מכיוון שאותו גוף אחראי על שני הצדדים, ההחלטה אינה נופלת בין הכיסאות.

צוותי המהנדסים שלנו פועלים כ-AI-powered developers ומשתמשים בכלי AI מתקדמים כמו Claude ו-GitHub Copilot כדי לקצר את תהליכי הפיתוח, לשפר את איכות הקוד, ולהאיץ את סקירות הארכיטקטורה, מה שמאפשר לבחון יותר חלופות לפני שההחלטה נקבעת.

הפרויקט הבא שלכם מתחיל בשיחה

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

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