ארכיטקטורת מוצר של פלטפורמת IoT ב-Google Cloud

Last reviewed 2024-08-09 UTC

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

המסמך הזה הוא חלק מסדרת מסמכים שמספקים מידע על ארכיטקטורות של IoT ב- Google Cloud. מסמכים אחרים בסדרה הזו כוללים את:

בתרשים הבא מוצגת ארכיטקטורה לדוגמה עם מוצר פלטפורמת IoT כללית שפועל ב- Google Cloud.

ארכיטקטורה כללית של פלטפורמת IoT (הסבר על רצף האירועים מופיע בטקסט הבא).

כפי שמוצג בתרשים הקודם, פלטפורמת ה-IoT פורסת ברוקר או נקודת קצה של MQTT לקישוריות של מכשירים. פלטפורמת ה-IoT מקושרת למאזן עומסי רשת בשרת proxy חיצוני כדי להפיץ תנועה ממכשירי הקצה. אפליקציות IoT נוספות יכולות להתחבר לפלטפורמת ה-IoT באמצעות Pub/Sub, או באמצעות מחבר Dataflow MQTT.

פלטפורמת ה-IoT מספקת קבוצה של שירותים לניהול מכשירים. כפי שמוצג בתרשים, השירותים האלה הם:

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

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

שיקולים ובחירות אדריכליים

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

נקודות קצה להטמעת נתונים

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

פרוטוקול MQTT

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

  • מחבר בין MQTT לבין שירות הודעות אחר
  • שרת MQTT שמטמיע את המפרט המלא של MQTT

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

במקרים מסוימים, נקודת הקצה של MQTT מחברת רק את לקוחות MQTT לשירות העברת הודעות בקצה העורפי, כמו Kafka או Pub/Sub. בדרך כלל, נקודת קצה מסוג כזה לא מיישמת את המפרט המלא של פרוטוקול MQTT, ולרוב היא לא כוללת תכונות כמו רמות QoS 1 ו-2 או מינויים משותפים. היתרון בגישה הזו הוא שהיא מפחיתה את המורכבות בפלטפורמת IoT, כי אין אפליקציית ברוקר MQTT נפרדת. העלויות התפעוליות נמוכות יותר, והתחזוקה פשוטה יותר מאשר אם הפלטפורמה משתמשת בברוקר MQTT נפרד. עם זאת, בגלל התמיכה המצומצמת בתכונות מתקדמות יותר של פרוטוקול MQTT, הגישה הזו אומרת שיש פחות גמישות ופונקציונליות להעברת הודעות MQTT מאשר בברוקר MQTT עצמאי שמיישם את המפרט המלא של MQTT.

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

פרוטוקול HTTPS ופרוטוקולים משלימים אחרים

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

‫HTTPS הוא פרוטוקול חלופי נפוץ ל-MQTT לתרחישי שימוש במכשירים מחוברים. התקורה שלו גבוהה יותר מזו של MQTT, אבל הוא נתמך באופן נרחב יותר במכשירים ניידים כמו טלפונים, בדפדפני אינטרנט ובאפליקציות אחרות. הוא נמצא בשימוש תדיר באפליקציות מסוימות של מכשירים מחוברים, והוא נתמך בפלטפורמות קוד פתוח כמו Eclipse Hono ובהרבה מוצרים מסחריים.

הרבה אפליקציות למכשירים מוגבלים משתמשות ב-Constrained Application Protocol (CoAP), שמוגדר ב-RFC 7252, כחלופה ל-MQTT. פרוטוקול CoAP מיועד ללקוחות עם תקורה נמוכה וטביעת רגל קטנה במכשירים מוטמעים ובחיישנים. הרבה אפליקציות של פלטפורמות מסחריות ל-IoT מספקות גם נקודת קצה של CoAP.

איזון עומסים

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

אימות מכשירים וניהול פרטי כניסה

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

בניגוד ל-MQTT Broker עצמאי, פלטפורמת IoT מספקת שירותים משולבים לניהול הזהות ופרטי הכניסה של המכשיר. רוב פלטפורמות ה-IoT משתמשות באימות באמצעות אישור לקוח X.509 לצורך אימות, באימות מבוסס-אסימון JWT (לרוב בשילוב עם OAuth 2.0) ובאימות באמצעות שם משתמש וסיסמה. חלק מהפלטפורמות תומכות גם בשילוב עם ספק חיצוני של אימות LDAP.

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

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

מידע נוסף על אימות וניהול פרטי כניסה זמין במאמר שיטות מומלצות להפעלת קצה עורפי של IoT ב- Google Cloud.

ניהול המכשירים המחוברים

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

מומלץ שהארגון ישתמש בפלטפורמת IoT עם היכולות הבאות:

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

עומסי עבודה בקצה העורפי

רוב פלטפורמות ה-IoT מספקות יכולות אחסון והעברה של נתונים פנימיים, שמאפשרות לכם להתחבר לעומסי העבודה וליישומים של ה-Backend. פרוטוקולים כמו AMQP,‏ RabbitMQ ו-Kafka משמשים בדרך כלל להעברת נתונים פנימיים. אפשר להתחבר לכל הפרוטוקולים האלה ל-Pub/Sub באמצעות Pub/Sub SDK. אפשר גם להשתמש במערכת מסדי נתונים משולבת כמו PostgreSQL כדי לאחסן נתונים בפלטפורמה. במקרים רבים, אפשר להגדיר את פלטפורמת ה-IoT כך שתשתמש ישירות באחד ממוצרי Cloud Storage, כמו Cloud SQL,‏ Firebase או BigQuery.

אם פלטפורמת ה-IoT כוללת ברוקר MQTT מלא, אפליקציות בק-אנד יכולות גם לתקשר עם מכשירים באמצעות יכולת ה-MQTT של הפלטפורמה. אם האפליקציה תומכת בפרוטוקול MQTT, היא יכולה להתחבר לשרת כיישום רשום. אם אין תמיכה ב-MQTT, ‏ Apache Beam מספקת מנהל התקן MQTT, שמאפשר שילוב דו-כיווני עם Dataflow וגם עם פריסות Beam אחרות.

תרחישים לדוגמה

בקטעים הבאים מתוארים תרחישים לדוגמה שבהם פלטפורמת IoT היא בחירה ארכיטקטונית טובה יותר מאשר ברוקר MQTT עצמאי או חיבור ישיר ל-Pub/Sub.

ניהול מכשירי חשמל חכמים

אפליקציות שמנהלות כמה מכשירי חשמל חכמים מתאימות לפלטפורמת IoT. דוגמה לאפליקציה כזו היא פלטפורמה לניהול מכשירי מטבח כמו מדיחי כלים ומכונות קפה. המכשירים האלה בדרך כלל מתחברים לאפליקציה מבוססת-ענן, ישירות דרך Wi-Fi או דרך שער מקומי שמשתמש ב-Bluetooth עם צריכת אנרגיה נמוכה (BLE) או בפרוטוקול מקומי אחר. יכולות הניהול של פלטפורמת IoT חשובות כאן לצורך מעקב אחרי מצב כל מכשיר, ניהול עדכוני תוכנה ותיקוני אבטחה ותיעוד פעילות המכשיר כדי לספק מידע קריטי ליצרן וללקוח. היכולות האלה לא נכללות בברוקר MQTT בסיסי. כדי לבנות פלטפורמה מוצלחת של מכשירי חשמל חכמים, צריך לפחות מאגר מידע על המכשירים, מסד נתונים של מצב המכשיר, מאגר נתונים של טלמטריה וממשק ניתוח נתונים.

לוגיסטיקה ומעקב אחרי נכסים

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

המאמרים הבאים