ארכיטקטורה של ברוקר MQTT עצמאי ב-Google Cloud

Last reviewed 2024-08-09 UTC

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

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

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

תרשים ארכיטקטורה של ברוקר MQTT (מוסבר בטקסט הבא).

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

  • ה-MQTT broker נפרס כאשכול של שלושה מופעים שמחוברים לשירות Cloud Load Balancing. אפשר לבחור מבין כמה מוצרים לאיזון עומסים, שמתוארים בהמשך המסמך הזה, כדי להשתמש בהם לאיזון עומסים בענן.
  • אשכול הברוקר כולל מאגר של פרטי כניסה למכשירים ושירות אימות והרשאה למכשירים. האשכול מתחבר לעומסי העבודה של ה-Backend דרך Dataflow או Pub/Sub.
  • בצד הלקוח, שערים של Edge מספקים תקשורת דו-כיוונית בין מכשירי Edge לבין אשכול ברוקרים של MQTT באמצעות MQTT over TLS.

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

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

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

מכשירים מחוברים

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

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

איזון עומסים

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

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

מידע נוסף על סוגי מאזני העומסים שנתמכים ב-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 broker מתאימה במיוחד לתרחישי השימוש במכשירים שמתוארים בקטעים הבאים.

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

אם רוצים לאסוף ולנתח נתונים מ-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 בלי לחשוף את המכשירים והמערכות המקומיים לאינטרנט הציבורי.

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