מכשיר בחיבור Pub/Sub ל-Google Cloud

Last reviewed 2024-08-09 UTC

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

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

ארכיטקטורה

בתרשים הבא מוצג שער או מכשיר צבירה מחובר שמחובר ישירות ל-Pub/Sub.

ארכיטקטורה של מכשיר או שער צבירה שמחוברים ל-Pub/Sub (הסבר על זרימת האירועים מופיע בטקסט הבא).

רצף האירועים בתרשים שלמעלה הוא כזה:

  • משתמשים בממשק ה-API של ניהול הזהויות והרשאות הגישה (IAM) כדי ליצור זוג מפתחות חדש לחשבון שירות. המפתח הציבורי מאוחסן ב-IAM. עם זאת, צריך להוריד את המפתח הפרטי בצורה מאובטחת ולאחסן אותו במכשיר השער כדי שאפשר יהיה להשתמש בו לאימות.
  • מכשיר הצבירה אוסף נתונים מכמה מכשירים וחיישנים מרוחקים אחרים שנמצאים ברשת מקומית מאובטחת. המכשירים המרוחקים מתקשרים עם השער באמצעות פרוטוקול מקומי של קצה הרשת, כמו MODBUS, ‏ BACNET, ‏ OPC-UA או פרוטוקול מקומי אחר.
  • מכשיר הצבירה שולח נתונים ל-Pub/Sub באמצעות HTTPS או gRPC. הקריאות ל-API האלה חתומות באמצעות המפתח הפרטי של חשבון השירות שמוחזק במכשיר האוסף.

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

‫Pub/Sub הוא שירות סטרימינג של נתונים ללא שרתים, ולכן אפשר להשתמש בו כדי ליצור מערכות דו-כיווניות שמורכבות ממפיקי אירועים ומצרכני אירועים (שנקראים גם מפרסמים ומנויים). במקרים מסוימים של מכשירים מחוברים, צריך רק שירות פרסום והרשמה שניתן להרחבה כדי ליצור ארכיטקטורת נתונים יעילה. בקטעים הבאים מפורטים השיקולים והבחירות שצריך לקחת בחשבון כשמטמיעים ארכיטקטורה של מכשיר ב-Pub/Sub ב- Google Cloud.

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

ב-Pub/Sub יש ספריות לקוח מוכנות מראש בכמה שפות שמיישמות את ממשקי ה-API ל-REST ול-gRPC. הוא תומך בשני פרוטוקולים להטמעת הודעות: REST (HTTP) ו-gRPC. כדי שמכשיר מחובר יוכל לשלוח ולקבל נתונים דרך Pub/Sub, הוא צריך להיות מסוגל ליצור אינטראקציה עם אחת מנקודות הקצה האלה.

הרבה אפליקציות תוכנה כוללות תמיכה מובנית ב-API בארכיטקטורת REST, ולכן לרוב הפתרון הכי פשוט הוא להתחבר ל-API בארכיטקטורת REST של Pub/Sub. עם זאת, במקרים מסוימים, gRPC יכול להיות חלופה יעילה ומהירה יותר. מכיוון ש-gRPC משתמש במאגרי אחסון לפרוטוקולים מסודרים (serialized) עבור מטען ייעודי (payload) של ההודעה במקום ב-JSON, ב-XML או בפורמט אחר מבוסס-טקסט, הוא מתאים יותר לאפליקציות עם רוחב פס נמוך, שנפוצות בתרחישי שימוש במכשירים מחוברים. חיבורי gRPC API גם מהירים יותר מ-REST להעברת נתונים, ו-gRPC תומך בתקשורת דו-כיוונית סימולטנית. במחקר אחד נמצא ש-gRPC מהיר עד פי שבעה מ-REST. לכן, בתרחישים רבים של מכשירים מחוברים, gRPC היא אפשרות טובה יותר אם יש מחבר gRPC או שאפשר להטמיע אותו באפליקציה של המכשיר המחובר.

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

‫Pub/Sub תומך במספר שיטות אימות לגישה מחוץ ל- Google Cloud.

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

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

אפליקציות לקצה העורפי

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

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

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

הטמעת נתונים בכמות גדולה ממערכת היסטורית של נתונים מקומיים

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

צבירת נתונים של שער מקומי במפעל

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

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

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

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