אירועים בזמן אמת ב-Fleet Engine

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

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

במסמך הזה מוסבר איך מפתחים יכולים להפוך אותות מ-Mobility services ב-Google Maps Platform (Last Mile Fleet Solution‏ (LMFS) או On-demand Rides and Deliveries Solution‏ (ODRD)) לאירועים מותאמים אישית שאפשר לפעול לפיהם. בנוסף, נסביר על מושגי מפתח והחלטות עיצוביות של Fleet Events Reference Solution שזמין ב-GitHub.

המסמך הזה רלוונטי ל:

  • ארכיטקטים שמכירים את שירותי Mobility של Google Maps Platform ואת אחד מהרכיבים העיקריים שלה, Fleet Engine. אם אתם חדשים בתחום של "שירותי ניידות", אנחנו ממליצים לכם להכיר את Last Mile Fleet Solution או את On-demand Rides and Deliveries Solution, בהתאם לצרכים שלכם.
  • אדריכלים שמכירים את Google Cloud. אם אתם חדשים ב-Google Cloud, מומלץ לקרוא קודם את המאמר בניית צינורות עיבוד נתונים בסטרימינג ב-Google Cloud.
  • אם אתם מטרגטים סביבות או סטאקים אחרים של תוכנות, התמקדו בהבנת נקודות השילוב ונקודות מרכזיות של Fleet Engine, שעדיין אמורים להיות רלוונטיים.
  • כל מי שמתעניין באופן כללי בדרכים ליצור אירועים מציים ולהשתמש בהם.

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

סקירה כללית על פתרון לדוגמה לאירועים ב-Fleet

פתרון הייחוס Fleet Events הוא פתרון בקוד פתוח שמאפשר ללקוחות ולשותפים של Mobility ליצור אירועים מרכזיים על גבי רכיבי Fleet Engine ו-Google Cloud. נכון לעכשיו, פתרון הייחוס תומך בלקוחות שמשתמשים ב-Last Mile Fleet Solution, ובהמשך תהיה תמיכה ב-On-demand Rides and Delivery.

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

  • שינוי זמן ההגעה המשוער למשימה
  • שינוי יחסי בזמן ההגעה המשוער למשימה
  • הזמן שנותר עד להגעה למשימה
  • המרחק שנותר עד להגעה למשימה
  • שינוי בסטטוס של TaskOutcome

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

אבני בניין לוגיות

דיאגרמה : הדיאגרמה הבאה מציגה את אבני הבניין הכלליות שמרכיבות את פתרון הייחוס של Fleet Events.

סקירה כללית של Fleet Events ואבני הבניין הלוגיות

פתרון הייחוס כולל את הרכיבים הבאים:

  • מקור האירוע: המקום שממנו מגיע מקור האירועים המקורי. גם Last Mile Fleet Solution וגם On-demand Rides and Deliveries Solution משולבים עם Cloud Logging, כדי לעזור להפוך את יומני הקריאות ל-RPC של Fleet Engine לזרמי אירועים שזמינים למפתחים. זה המקור העיקרי שצריך להשתמש בו.
  • עיבוד: יומני קריאות RPC גולמיים מומרים לאירועים של שינוי מצב בתוך הבלוק הזה, שמבצע חישובים על זרם של אירועים ביומן. כדי לזהות שינוי כזה, הרכיב הזה דורש מאגר מצבים, כך שניתן יהיה להשוות בין אירועים נכנסים חדשים לאירועים קודמים כדי לזהות שינוי. לא תמיד האירועים כוללים את כל המידע שמעניין אתכם. במקרים כאלה, יכול להיות שהבלוק הזה יבצע קריאות חיפוש לקצוות עורפיים לפי הצורך.
    • מאגר מצב: חלק ממסגרות העיבוד מספקות נתוני ביניים שנשמרים באופן עצמאי. אבל אם לא, כדי לאחסן את המצב בעצמכם, מכיוון שהמצב צריך להיות ייחודי לסוג הרכב ולסוג האירוע, שירות לשמירת נתונים מסוג K-V מתאים לכך.
  • כיור (אירועים בהתאמה אישית): שינוי המצב שזוהה צריך להיות זמין לכל אפליקציה או שירות שיכולים להפיק ממנו תועלת. לכן, הבחירה הטבעית היא לפרסם את האירוע בהתאמה אישית במערכת להעברת אירועים, כדי שיהיה אפשר להשתמש בו בהמשך.
  • שירות במורד הזרם: קוד שצורך את האירועים שנוצרו ומבצע פעולות שייחודיות לתרחיש לדוגמה שלכם.

בחירת שירות

כשמטמיעים את פתרון העזר של Last Mile Fleet Solution או של On-demand Rides and Deliveries Solution (יושק בסוף הרבעון השלישי של 2023), בחירת הטכנולוגיה של "מקור" ו"כיור" היא פשוטה. לעומת זאת, בקטגוריה "עיבוד" יש מגוון רחב של אפשרויות. בפתרון לדוגמה נבחרו שירותי Google הבאים.

תרשים : בתרשים הבא מוצג שירות Google Cloud להטמעת פתרון העזר

אבני הבניין של פתרון לדוגמה ל-Fleet Events

פריסת פרויקט בענן

מומלץ להשתמש בפריסה בכמה פרויקטים כברירת מחדל. כך אפשר להפריד בצורה ברורה בין הצריכה של Google Maps Platform לבין הצריכה של Google Cloud, ולקשר אותן להסדר החיוב שבחרתם.

מקור האירוע

ב-Last Mile Fleet Solution וב-On-demand Rides and Deliveries Solution, המערכת כותבת את המטען הייעודי (payload) של בקשות ה-API והתגובות שלהן ב-Cloud Logging. ‫Cloud Logging מעביר את היומנים לשירות אחד או יותר לבחירתכם. ניתוב ל-Cloud Pub/Sub הוא בחירה מושלמת במקרה הזה, והוא מאפשר להמיר יומנים לזרם אירועים בלי לכתוב קוד.

כיור

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

בעיבוד

הרכיבים הבאים משתתפים בעיבוד האירועים. כמו שאר אבני הבניין, רכיבי העיבוד הם ללא שרת (serverless) וניתן לשנות את הגודל שלהם בקלות.

  • Cloud Functions כפלטפורמת מחשוב לגרסה הראשונית (*)
    • בלי שרת (serverless), עם אפשרות להגדיל ולהקטין את קנה המידה באמצעות פקדי התאמה לניהול העלויות
    • Java כשפת התכנות, בהתחשב בזמינות של ספריות לקוח לממשקי API שקשורים ל-Fleet Engine, שתורמות לקלות ההטמעה
  • Cloud Firestore כמאגר מצבים
    • מאגר מפתחות-ערכים ללא שרת (serverless)
  • Cloud Pub/Sub כנקודת שילוב עם רכיבים במעלה הזרם ובמורד הזרם
    • שילוב בצימוד חלש כמעט בזמן אמת

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

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

פריסה

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

מודולים של Terraform

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

המודולים שכלולים בפתרון לדוגמה:

  • הגדרת רישום ביומן של Fleet Engine: אוטומציה של ההגדרות שקשורות ל-Cloud Logging לשימוש עם Fleet Engine. בפתרון לדוגמה, הוא משמש לניתוב יומנים שקשורים ל-Fleet Engine לנושא Pub/Sub שצוין.
  • פריסת פונקציית הענן של Fleet Events: מכילה את פריסת הקוד של הפונקציה לדוגמה, ומטפלת גם באוטומציה של הגדרות ההרשאות שנדרשות לשילוב מאובטח בין פרויקטים.
  • פריסה של כל פתרון העזר: קוראת לשני המודולים הקודמים ועוטפת את כל הפתרון.

אבטחה

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

הפעולות הבאות

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

נספח

הכנת הדרישות

מומלץ לאסוף את הדרישות בשלב מוקדם יותר בתהליך.

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

  • איזה מידע נדרש כדי שזרם אירועים יהיה שימושי?
    • האם אפשר להפיק את התוצאה רק מנתונים שתועדו או נוצרו בשירותי Google? או שצריך להעשיר את הנתונים באמצעות מערכות חיצוניות משולבות? אם כן, מהן המערכות האלה ואילו ממשקי שילוב הן מציעות?
    • אילו מדדים אתם רוצים למדוד בעסק? איך מגדירים אותם?
    • אם אתם צריכים לחשב מדדים בכמה אירועים, איזה סוג של צבירה נדרש? נסו לפרט את השלבים הלוגיים. למשל: השוו בין זמן ההגעה המשוער (ETA) לזמן ההגעה בפועל (ATA) לבין יעדי רמת השירות (SLO) בקבוצת משנה של הצי בשעות השיא, כדי לחשב את הביצועים במגבלות המשאבים.
  • למה אתם מעוניינים במודל מבוסס-אירועים ולא במודל באצ'? האם זה כדי להפחית את זמן האחזור (זמן עד לפעולה) או כדי ליצור שילוב בצימוד חלש (גמישות)?
    • אם מדובר בזמן אחזור נמוך, צריך להגדיר את הערך "low". דקות? שניות? פחות משנייה? ומה לגבי זמן האחזור?
  • האם כבר השקעתם בסטאק תוכנות ובמיומנויות קשורות כצוות? אם כן, מהו ומהן נקודות השילוב שהוא מספק?
    • האם יש דרישות שהמערכות הנוכחיות שלכם לא יכולות לעמוד בהן או שעלולות להתקשות בעיבוד אירועים שמגיעים מהצי שלכם?

עקרונות העיצוב

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

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

מושגים שקשורים לסטרימינג

אם אתם חדשים יחסית בתחום של עיבוד מבוסס-אירועים או עיבוד בסטרימינג, יש כמה מושגי מפתח שכדאי להכיר, וחלקם שונים מאוד מעיבוד ברצף (batch processing).

  • קנה מידה : בניגוד לעיבוד באצווה, שבו בדרך כלל יש לכם מושג לגבי כמות הנתונים שצריך לעבד, בעיבוד בזמן אמת אין לכם מושג. פקק תנועה בעיר יכול ליצור פתאום הרבה אירועים מאזור מסוים, ועדיין צריך להיות מסוגלים לעבד אותם.
  • חלונות : במקום לעבד אירועים אחד אחרי השני, בדרך כלל תרצו לקבץ אירועים לאורך ציר זמן ל "חלונות" קטנים יותר כיחידה לחישוב. יש אסטרטגיות שונות של חלונות, כמו "חלונות קבועים (למשל, כל יום קלנדרי)", "חלונות נעים (5 הדקות האחרונות)", "חלונות סשן (במהלך הנסיעה הזו)", שצריך לבחור מביניהן. ככל שחלון הזמן ארוך יותר, כך העיכובים בהפקת התוצאות ארוכים יותר. בחרו את המודל וההגדרות שמתאימים לדרישות שלכם.
  • הפעלה : יש מקרים שבהם אין ברירה אלא להגדיר חלונות ארוכים יחסית. עם זאת, לא כדאי לחכות עד לסוף החלון כדי להפיק אירועים, אלא להפיק תוצאות ביניים בין לבין. אפשר ליישם את הקונספט הזה בתרחישים שבהם יש ערך להחזרת תוצאות מהירות קודם, ואז לתקן אותן מאוחר יותר. נניח שאתם רוצים לשלוח סטטוס ביניים כשהמשלוח מגיע ל-25%, 50% ו-75% מהדרך.
  • סדר : אירועים לא בהכרח מגיעים למערכת בסדר שבו הם נוצרו. במיוחד בתרחישים שבהם התקשורת מתבצעת דרך רשתות סלולריות, שמוסיפות עיכובים ונתיבי ניתוב מורכבים. חשוב להבין את ההבדל בין "זמן האירוע" (המועד שבו האירוע התרחש בפועל) לבין "זמן העיבוד" (המועד שבו האירוע הגיע למערכת), ולטפל באירועים בהתאם. באופן כללי, כדאי לעבד אירועים על סמך "זמן האירוע".
  • מסירת הודעות – פעם אחת לפחות לעומת פעם אחת בדיוק: פלטפורמות שונות של אירועים תומכות באפשרויות שונות. בהתאם לתרחיש לדוגמה, צריך להביא בחשבון אסטרטגיות של ניסיון חוזר או של ביטול כפילויות.
  • שלמות : כמו בשינוי הסדר, יש סיכוי שהודעות יאבדו. זה יכול לקרות בגלל שהאפליקציה או המכשיר נכבו כי נגמרה הסוללה, בגלל נזק לא מכוון לטלפון, בגלל אובדן הקישוריות בזמן נסיעה במנהרה או בגלל שהודעה התקבלה אבל רק מחוץ לחלון הזמן המקובל. איך חוסר שלמות ישפיע על התוצאות?

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

תורמים

‫Google מתחזקת את המסמך הזה. הכותבים הבאים כתבו אותו במקור.

מחברים ראשיים: