חברה ישראלית בתחום אבטחת המרחב האווירי מפעילה חיישני גילוי רחפנים של כמה ספקים, ולכל אחד פרוטוקול, התחברות ומודל נתונים משלו. הובלתי את התכנון והפיתוח של מערכת מרכזית שקולטת את כולם, הופכת כל גילוי לפורמט אירוע אחד, ומזרימה אותו בזמן אמת לדשבורד של המפעילים ולפלטפורמות לאומיות לניהול תעבורת רחפנים, כל אחת בפורמט שהיא מצפה לו.
החברה פורסת חיישני גילוי של יותר מספק אחד. האחד הוא רשת חיישני RF שמפרסמת איומים דרך GraphQL subscriptions מעל WebSocket, עם זרם פרטים נפרד לכל איום פעיל. השני דוחף מסלולי רחפנים ו־Remote ID בפרוטוקול WebSocket משלו, עם סשנים מבוססי טוקן. לכל אחד חוקי התחברות וחידוש טוקן משלו, דרכי כשל משלו, והגדרה משלו למה זה ”גילוי”.
בצד השני, הדשבורד של המפעילים, פלטפורמה לאומית לניהול תעבורת רחפנים (UTM) ושירות U-space מצפים כל אחד למבנה נתונים אחר, וחלקם רוצים זרם חי ואחרים קריאות HTTPS. חיבור ישיר של כל חיישן לכל צרכן היה נותן N × M אינטגרציות שבירות, כל אחת עם לוגיקת התחברות מחדש משלה.
התרשים רחב מהמסך: החליקו הצידה לצפייה בכולו →
שני השירותים רצים כקונטיינרים. שירות הקליטה מכיר רק חיישנים, ושירות ההפצה מכיר רק צרכנים. התור ביניהם מבטיח שצרכן איטי או מנותק לעולם לא יאט חיבור לחיישן, ושאפשר לפרוס כל צד מחדש בלי להפיל את השני.
חיבורים לחיישנים הם ארוכי טווח ויקרים להקמה מחדש, וצרכנים באים והולכים. SQS מפריד בין השניים, בולע פרצי עומס ומאפשר לכל צד לגדול ולהיפרס בנפרד. המחיר: עוד קפיצה בדרך ומסירה של at-least-once, שמזהי האירועים הופכים לגלויה.
כל גילוי הופך לאותה רשומה (מיקום, גובה, תדר, רמת איום, סיווג) עם הרחבה טיפוסית לפי ספק. לכל צרכן יש mapper שמתגלה בעליית השירות ונרשם לפי מפתח. המחיר: המודל המשותף הוא מכנה משותף, ולכן פרטים ייחודיים לספק יושבים בהרחבה ולא בליבה.
הספקים והצרכנים הפעילים, ערוץ התקשורת שלהם (WebSocket או HTTPS) וסוג ה־mapper נשמרים ברג׳יסטרי ב־DynamoDB. פרטי גישה ומפתחות API נשמרים ב־Secrets Manager. הוספת צרכן היא שורה וסוד, לא גרסה חדשה. המחיר: הרג׳יסטרי נקרא בעליית השירות, ולכן שינוי דורש restart.
לכל חיבור יש channel חסום משלו. לקוח שמפגר מאבד את המנות הישנות ביותר במקום להאט את כל השאר. בתמונת אוויר חיה, עדכני עדיף על שלם. המחיר: המסלול הזה אינו לוג ביקורת, וגרסה 1 בכוונה לא שומרת אירועים.
רוב העבודה האמיתית צצה רק אחרי שחיישנים אמיתיים התחברו. מבחר:
כשלא היה גילוי במשך זמן מה, ה־load balancer סגר חיבורי WebSocket בלי תעבורה, והלקוחות ראו פיד מת.
לולאת השליחה ממתינה לנתונים עם timeout של 30 שניות, ושולחת frame של keep-alive כשהוא פוקע, הרבה לפני חלון ה־idle של ה־load balancer.
רשת ה־RF מפרסמת את רשימת האיומים הפעילים ב־subscription אחד ואת הפרטים בשני, שצריך להוציא מחדש עם סט המזהים העדכני בכל פעם שהוא משתנה.
מידלתי את המזהים הפעילים כ־observable, ריסנתי שינויים ב־50 מילישניות והשתמשתי ב־Switch כך שכל סט מזהים חדש סוגר בצורה נקייה את ה־subscription הקודם.
תחת עומס חיישנים אמיתי צד ההפצה פיגר: כל הודעה התקבלה, נכתבה לכל סוקט ונמחקה אחת־אחת, והצבר הגיע לכ־186 אלף.
הגדלתי את מספר הפולרים המקבילים, עברתי למחיקה במנות של עד 10, והעברתי כל מנה שהתקבלה ל־channel בזיכרון לכל לקוח, כך שהיא יוצאת כפריים WebSocket אחד. הצבר התרוקן ונשאר על אפס.
חידוש הטוקן מול אחד הספקים נכשל בדרכים מוזרות. הספק מחזיר HTTP 200 גם כשהקריאה נכשלת, והתוצאה האמיתית נמצאת בגוף התשובה.
בודקים את קוד השגיאה בגוף התשובה, לא רק את הסטטוס. אם החידוש נכשל, הסשן נזרק והתחברות מחדש מתבצעת תחת נעילה, כדי שקריאות מקבילות לא יפעילו כמה התחברויות.
חריגות נרשמו ללוג ונבלעו בתוך ה־handlers של הזרם. ה־worker נראה תקין, אבל שום אירוע לא הגיע.
שגיאות מפילות עכשיו את הזרם, וה־worker נכנס ללולאת ההתחברות מחדש עם המתנה קבועה (3 ו־5 שניות לפי ספק). בדפדפן, הלקוח מתחבר מחדש עם back-off אקספוננציאלי משנייה אחת ועד 15 שניות.
פלטפורמת U-space מקבלת אירועים רק כקריאות HTTPS מאומתות, בזמן שהאחרים נרשמים לזרם.
הוספתי שדה ערוץ לרג׳יסטרי הצרכנים, ומפרסם ששולח כל מנה לכל יעדי ה־HTTPS במקביל, שומר טוקן לכל יעד ומתאמת מחדש פעם אחת על 401. יעד אחד שנכשל לא חוסם את האחרים.
אחרי פקיעת טוקן, שרת ה־GraphQL דיווח על כשל אימות כ־payload של שגיאה ב־subscription של הפרטים. שום דבר לא נזרק, ולכן ה־worker לא התחבר מחדש.
מזהים את קוד שגיאת האימות בתוך ה־payload ומפילים את הזרם בכוונה, מה שמפעיל התחברות מלאה מחדש.
מספר הקריאות שנדרש כדי להוציא מנה של 10 אירועים מהתור ולמסור אותה ללקוח מחובר אחד. נגזר מהקוד לפני ואחרי השינוי של 31 במאי, לא מבנצ׳מרק.
שיחת אבחון חינם · 30 דקות · ללא התחייבות
כתבו בכמה שורות: איזה תהליך או מערכת, מה כואב היום (זמן, טעויות, עלויות או פיילוט AI שנתקע) ומי עובד עם זה. אחרי שיחה קצרה מקבלים תוך כ־3 ימים תוכנית כתובה והצעת מחיר סגורה.
נפתח מייל מוכן מראש · מענה תוך יום עסקים
ה־AI קורא. הקוד סופר.
כל הפרויקטים