MQTT הוא פרוטוקול תקני של OASIS לאפליקציות של מכשירים מחוברים, שמספק העברת הודעות דו-כיוונית באמצעות ארכיטקטורת ברוקר של פרסום והרשמה. פרוטוקול ה-MQTT הוא קל משקל כדי לצמצם את התקורה ברשת, והלקוחות של MQTT הם קטנים מאוד כדי למזער את השימוש במשאבים במכשירים מוגבלים. פתרון אחד לארגונים שרוצים לתמוך באפליקציות של מכשירים מחוברים ב-Google Cloud הוא להריץ ברוקר MQTT עצמאי ב-Compute Engine או ב-GKE. כדי לפרוס ברוקר MQTT בארגון, צריך לקבל כמה החלטות חשובות שמשפיעות על הארכיטקטורה הכוללת, במיוחד על איזון העומסים ועל סביבת הפריסה. במאמר הזה מתוארת ארכיטקטורה לפריסה של ברוקר MQTT, שהוא אפליקציית הליבה בפריסת MQTT, ב- Google Cloud. בנוסף, מוסבר בו על ההחלטות שצריך לקבל כשפורסים את ברוקר ההרשאות הזה, ואיך הן משפיעות על הארכיטקטורה.
המסמך הזה הוא חלק מסדרת מסמכים שמספקים מידע על ארכיטקטורות של IoT ב- Google Cloud. מסמכים אחרים בסדרה הזו כוללים את:
- ארכיטקטורות של מכשירים מחוברים Google Cloud סקירה כללית
- ארכיטקטורת ברוקר MQTT עצמאי ב- Google Cloud (המסמך הזה)
- ארכיטקטורת מוצר של פלטפורמת IoT ב- Google Cloud
- שיטות מומלצות להרצת קצה עורפי של IoT ב- Google Cloud
- מכשיר בארכיטקטורת Pub/Sub ל Google Cloud
- שיטות מומלצות להקצאה ולהגדרה אוטומטיות של מערכות ושרתים מסוג Edge ו-Bare Metal
בתרשים הבא מוצגת ארכיטקטורת ברוקר MQTT שפועלת ב-Google Cloud.
הארכיטקטורה בתמונה שלמעלה מורכבת מהרכיבים הבאים:
- ה-MQTT broker נפרס כאשכול של שלוש מכונות שמחוברות לשירות Cloud Load Balancing. כשמדובר במאזן עומסים בענן, אפשר לבחור מתוך כמה מוצרים לאיזון עומסים, שמתוארים בהמשך המאמר.
- אוסף השרתים של הברוקר כולל מאגר של פרטי כניסה למכשירים ושירות לאימות והרשאה של מכשירים. האשכול מתחבר לעומסי העבודה של הקצה העורפי באמצעות Dataflow או Pub/Sub.
- בצד הלקוח, שערים של Edge מספקים תקשורת דו-כיוונית בין מכשירי Edge לבין אשכול ברוקרים של MQTT באמצעות MQTT over TLS.
באופן כללי, מומלץ לפרוס את אפליקציית ברוקר MQTT עבור הארכיטקטורה הזו באשכול כדי להשיג יכולת הרחבה. ההטמעות הספציפיות של ברוקרים מטפלות בגורמים כמו פונקציונליות של אשכולות, ניהול אשכולות בהגדלה ובהקטנה, סנכרון נתונים וטיפול במחיצות ברשת.
שיקולים ובחירות אדריכליים
בקטעים הבאים מתוארות הבחירות האדריכליות השונות והשיקולים שצריך לקחת בחשבון כשיוצרים ארכיטקטורה של ברוקר MQTT עצמאי, וגם ההשפעה של הבחירות האלה על הארכיטקטורה.
מכשירים מחוברים
מכשירי קצה שמחוברים לאינטרנט מפרסמים את אירועי הטלמטריה שלהם ומידע אחר בשרת MQTT. כדי להטמיע את ארכיטקטורת ברוקר MQTT עצמאי שמתוארת במסמך הזה, במכשיר צריך להיות לקוח MQTT, המפתח הציבורי של אישור השרת לאימות TLS והאישורים שנדרשים לאימות מול ברוקר MQTT.
בנוסף, למכשירי קצה יש בדרך כלל מחברים לחיישנים מקומיים, למערכות נתונים מקומיות ולמכשירים אחרים שאין להם גישה לאינטרנט או קישוריות IP. לדוגמה, מכשיר הקצה יכול לשמש כשער למכשירים מקומיים מוגבלים אחרים שמחוברים לשער באמצעות BLE, חיבור קווי או פרוטוקול אחר של תקשורת טווח קצר. מפרט מפורט של ארכיטקטורת המכשיר המחובר לא נכלל במדריך הזה.
איזון עומסים
בארכיטקטורה, מוגדר שירות חיצוני לאיזון עומסים בין הרשת הציבורית לבין אשכול ברוקר MQTT. השירות הזה מספק כמה פונקציות חשובות של רשת, כולל חלוקה של חיבורים נכנסים בין צמתי קצה עורפיים, הצפנה של סשנים ואימות.
Google Cloud תומך בכמה סוגים של מאזני עומסים. כדי לבחור את מאזן העומסים הכי טוב לארכיטקטורה שלכם, כדאי להביא בחשבון את הגורמים הבאים:
mTLS. mTLS מטפל בהצפנה ובשיטות אימות של מכשירים, בעוד ש-TLS רגיל מטפל רק בהצפנה ודורש שיטת אימות נפרדת של מכשירים:
- אם האפליקציה משתמשת ב-mTLS לאימות המכשיר וצריך לסיים את מנהרת ה-TLS, מומלץ להשתמש במאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ברמה אזורית או במאזן עומסי רשת חיצוני לשרת proxy עם שרת proxy של TCP ליעד. מאזני עומסים חיצוניים של רשתות proxy מסיימים את סשן ה-TLS ומעבירים את החיבור לצומת הברוקר, יחד עם כל פרטי האימות שכלולים בהודעה. אם אתם צריכים את פרטי החיבור של הלקוח כחלק מסכמת האימות, אתם יכולים לשמור אותם בחיבור לקצה העורפי על ידי הפעלת פרוטוקול ה-PROXY.
- אם האפליקציה שלכם לא משתמשת ב-mTLS, מומלץ להשתמש במאזן עומסי רשת בשרת proxy חיצוני עם שרת proxy של SSL ליעד כדי להעביר את העיבוד של TLS ו-SSL חיצוניים למאזן העומסים. מאזני עומסים חיצוניים של רשתות proxy מסיימים את סשן ה-TLS ומעבירים את החיבור לצומת הברוקר, יחד עם כל פרטי האימות שכלולים בהודעה. אם אתם צריכים את פרטי החיבור של הלקוח כחלק מסכמת האימות, אתם יכולים לשמור אותם בחיבור לקצה העורפי על ידי הפעלת פרוטוקול ה-PROXY.
נקודות קצה (endpoints) של HTTP(S). אם אתם צריכים לחשוף נקודות קצה של HTTP(S), מומלץ להגדיר מאזן עומסים של אפליקציות (ALB) חיצוני נפרד לנקודות הקצה האלה.
מידע נוסף על סוגי מאזני העומסים שנתמכים ב-Cloud Load Balancing זמין במאמר סיכום של מאזני עומסים. Google Cloud
אסטרטגיית איזון עומסים
כל שירות איזון עומסים מחלק את החיבורים ממכשירי קצה בין הצמתים באשכול בהתאם לאחד מכמה אלגוריתמים או מצבי איזון. ב-MQTT, אסטרטגיית איזון עומסים של זיקה להפעלת אירועים עדיפה על איזון עומסים אקראי. חיבורי לקוח-שרת ב-MQTT הם סשנים דו-כיווניים מתמשכים, ולכן המצב נשמר בצומת המתווך שמפסיק את החיבור. בהגדרה של אשכול, אם לקוח מתנתק ואז מתחבר מחדש לצומת אחר, מצב הסשן מועבר לצומת החדש, מה שמוסיף עומס לאשכול. אפשר להימנע מהבעיה הזו במידה רבה באמצעות איזון עומסים של שיוך סשנים. אם הלקוחות משנים לעיתים קרובות את כתובות ה-IP שלהם, יכול להיות שהחיבור ייפסק, אבל ברוב המקרים עדיף להשתמש בזיקה להפעלת אינטראקציה ב-MQTT. התכונה 'שמירת זיקה להפעלת משתמש' זמינה בכל מוצרי Cloud Load Balancing.
אימות מכשירים וניהול פרטי כניסה
אפליקציות של שרת MQTT מטפלות באימות מכשירים ובבקרת גישה בנפרד מ Google Cloud. אפליקציית ברוקר מספקת גם מאגר משלה של פרטי כניסה וממשק ניהול. פרוטוקול MQTT תומך באימות בסיסי של שם משתמש וסיסמה בחבילת הנתונים הראשונית של Connect, והשדות האלה משמשים לעיתים קרובות גם בהטמעות של ברוקרים כדי לתמוך בשיטות אימות אחרות, כמו אימות באמצעות אישור X.509 או JWT. בנוסף, ב-MQTT 5.0 יש תמיכה בשיטות אימות משופרות שמשתמשות באימות בסגנון של אתגר ותגובה. שיטת האימות שבה משתמשים תלויה באפליקציית ברוקר ה-MQTT שנבחרה ובתרחיש לדוגמה של המכשיר המחובר.
לא משנה באיזו שיטת אימות הברוקר משתמש, הוא שומר מאגר של פרטי כניסה למכשיר. המאגר הזה יכול להיות מסד נתונים מקומי של SQL או קובץ שטוח. חלק מהברוקרים תומכים גם בשימוש בשירות מנוהל של מסד נתונים כמו Cloud SQL. אתם צריכים שירות נפרד כדי לנהל את מאגר האישורים של המכשיר ולטפל בשילובים עם שירותי אימות אחרים, כמו IAM. פיתוח השירות הזה לא נכלל במדריך הזה.
מידע נוסף על אימות וניהול פרטי כניסה זמין במאמר שיטות מומלצות להפעלת קצה עורפי של IoT ב- Google Cloud.
עומסי עבודה בקצה העורפי
כל תרחיש לדוגמה של מכשיר מחובר כולל אפליקציה אחת או יותר של קצה עורפי שמשתמשת בנתונים שנקלטים מהמכשירים המחוברים. לפעמים, האפליקציות האלה צריכות גם לשלוח פקודות ועדכוני הגדרות למכשירים. בארכיטקטורה של ברוקר MQTT עצמאי שמתוארת במסמך הזה, הנתונים הנכנסים והפקודות היוצאות מנותבים דרך ברוקר MQTT. יש נושאים שונים בהיררכיית הנושאים של הברוקר כדי להבדיל בין הנתונים לבין הפקודות.
אפשר לשלוח נתונים ופקודות בין הברוקר לבין אפליקציות ה-Backend בכמה דרכים. אם האפליקציה עצמה תומכת בפרוטוקול MQTT, או שאפשר לשנות אותה כך שתתמוך בפרוטוקול MQTT, האפליקציה יכולה להירשם ישירות ל-broker כלקוח. הגישה הזו מאפשרת לכם להשתמש ביכולת של MQTT Pub/Sub לשליחת הודעות דו-כיוונית ישירות, באמצעות האפליקציה שלכם, כדי לקבל נתונים מהמכשירים המחוברים ולשלוח להם פקודות.
אם האפליקציה שלכם לא תומכת ב-MQTT, יש כמה אפשרויות אחרות. באדריכלות שמתוארת במסמך הזה, Apache Beam מספק מנהל התקן MQTT, שמאפשר אינטגרציה דו-כיוונית עם Dataflow ועם פריסות אחרות של Beam. לרבים מהברוקרים יש גם יכולות פלאגין שתומכות בשילוב עם שירותים כמו Google Pub/Sub. בדרך כלל מדובר בשילובים חד-כיווניים לצורך שילוב נתונים, אבל חלק מהברוקרים תומכים בשילוב דו-כיווני.
תרחישים לדוגמה
ארכיטקטורת ברוקר MQTT מתאימה במיוחד לתרחישי השימוש במכשירים שמתוארים בקטעים הבאים.
קליטת נתונים מבוססת-תקנים ממכשירים הטרוגניים
כשרוצים לאסוף ולנתח נתונים מ-Fleet גדול של מכשירים הטרוגניים, בדרך כלל פתרון טוב הוא ברוקר MQTT. MQTT הוא תקן שנעשה בו שימוש נרחב, ולכן מכשירים רבים כוללים תמיכה מובנית בו. בנוסף, יש לקוחות MQTT קלי משקל שאפשר להוסיף למכשירים שלא תומכים ב-MQTT. הפרדיגמה של פרסום והרשמה היא גם חלק מתקן MQTT, כך שמכשירים עם תמיכה ב-MQTT יכולים ליהנות מהארכיטקטורה הזו בלי עבודת הטמעה נוספת. לעומת זאת, במכשירים שמתחברים ל-Pub/Sub צריך להטמיע את Pub/Sub API או להשתמש ב-Pub/Sub SDK. הפעלת ברוקר MQTT שתואם לתקנים ב-Google Cloud מספקת פתרון פשוט לאיסוף נתונים ממגוון רחב של מכשירים.
אם המכשירים המחוברים לא נשלטים על ידי האפליקציה שלכם אלא על ידי צד שלישי, יכול להיות שלא תהיה לכם גישה לתוכנת המערכת של המכשיר, והאחריות לניהול המכשיר תהיה של הצד השלישי. במקרה כזה, מומלץ להפעיל ברוקר MQTT ולספק לצד השלישי פרטי אימות כדי להגדיר את ערוץ התקשורת בין המכשיר לבין הענן.
תקשורת דו-כיוונית לשילוב אפליקציות של צדדים מרובים
היכולת של MQTT לשלוח הודעות דו-כיווניות הופכת אותו למתאים מאוד לתרחישי שימוש באפליקציות לנייד עם כמה משתתפים, כמו משלוח אוכל על פי דרישה או אפליקציית צ'אט אינטרנטית בקנה מידה גדול. ל-MQTT יש תקורה נמוכה של פרוטוקול, והדרישות של לקוחות MQTT למשאבים נמוכות. ב-MQTT יש גם ניתוב של פרסום והרשמה, כמה רמות של איכות שירות (QoS), שמירת הודעות מובנית ותמיכה רחבה בפרוטוקולים. ברוקר MQTT יכול להיות רכיב הליבה של פלטפורמת הודעות ניתנת להרחבה לאפליקציות של שירותים על פי דרישה ולתרחישי שימוש דומים.
הודעות משולבות מקצה לקצה בענן
בגלל התקנון והתקורה הנמוכה ש-MQTT מציע, הוא יכול להיות גם פתרון טוב לשילוב של אפליקציות להעברת הודעות מקומיות ומבוססות-ענן. לדוגמה, מפעיל במפעל יכול לפרוס כמה ברוקרים של MQTT בסביבה המקומית כדי להתחבר לחיישנים, למכונות, לשערים ולמכשירים אחרים שנמצאים מאחורי חומת האש. ברוקר MQTT מקומי יכול לטפל בכל ההודעות הדו-כיווניות של פקודות, בקרה וטלמטריה בתשתית המקומית. אפשר גם לחבר את הברוקר המקומי באמצעות מינוי דו-כיווני לאשכול מקביל של ברוקר MQTT בענן, וכך לאפשר תקשורת בין הענן לסביבת ה-Edge בלי לחשוף את המכשירים והמערכות המקומיים לאינטרנט הציבורי.
המאמרים הבאים
- בקורס Intelligent Products Essentials תלמדו איך לחבר מכשירים ולפתח אפליקציות IoT ב- Google Cloud .
- מידע על שיטות מומלצות להקצאה אוטומטית ולהגדרה של מערכות ושרתים מסוג Edge ו-Bare Metal
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.