ארכיטקטורת RTSP Streaming עם Auto-Scaling, בקרים כפולים ואפס אובדן מנות
פלטפורמת מעקב נדרשה להרחיב את תשתית ה-video streaming שלה באופן דינמי — לטפל בכל מקום בין 10 ל-200+ מצלמות IP עם מאות צופים בו-זמנית ועובדי AI לביצוע עיבודים — תוך הבטחת אפס אובדן מנות במהלך פעולות הרחבה ושמירה על כתובות URL יציבות של זרמים שלעולם אינן משתנות.
דון בפרויקט שלך
האתגר
תשתית streaming קבועה לא יכלה להתמודד עם הדרישות המשתנות של פלטפורמת מעקב גדלה:
- שונות בקנה מידה — מספר המצלמות ודרישת הצופים השתנו באופן דרמטי לאורך היום (יחס שיא לשפל של פי 10)
- עלות הקצאת יתר — הקצאה לעומס שיא משמעותה 70%+ משאבים בטלים בשעות השפל
- אובדן מנות במהלך הרחבה — הוספה או הסרה של שרתי streaming גרמה להפרעות בזרם, והפילה פריימים עבור עובדי AI עיבוד
- חוסר יציבות של URL — מצלמות וצופים שהוגדרו עם IP ספציפיים של שרתים נדרשו לתצורה מחדש כאשר התשתית השתנתה
- צרכי הרחבה שונים — צריכת מצלמות והפצת צופים היו בעלי דפוסי עומס שונים במהותם, שדרשו הרחבה עצמאית
- שיבוש עובדי AI — צינורות עיבוד AI קרסו כאשר שרת הזרם המקורי שלהם הוקטן
הפתרון שלנו
תכננו ארכיטקטורת streaming עם Auto-Scaling ובקרים כפולים עם אשכולות נפרדים לצריכה והפצה, תהליך כיבוי הדרגתי ב-5 שלבים לאפס אובדן מנות, כתובות URL יציבות מבוססות DNS, וחיבור מחדש אוטומטי של עובדי AI.
ארכיטקטורה
- שרת Streaming: MediaMTX לתמיכה בפרוטוקולי RTSP/WebRTC/HLS
- אשכול צריכה: 1-10 שרתים המקבלים זרמי RTSP ממצלמות
- אשכול הפצה: 2-20 שרתים המשרתים צופים (WebRTC/HLS) ועובדי AI (RTSP)
- בקרים כפולים: בקרים עצמאיים להרחבה עבור צריכה והפצה
- מאזני עומס (Load Balancers): מאזני עומס נפרדים לכל אשכול עם אלגוריתמים מתאימים לפרוטוקול
- רישום שירותים (Service Registry): Redis למצב שרתים, מיפויי זרמים ותיאום
- ניטור תקינות: בדיקות תקינות אקטיביות עם שחזור אוטומטי
- שכבת DNS: שמות מתחם יציבים המצביעים על מאזני עומס (Load Balancers) (כתובות URL אינן משתנות לעולם)
עיצוב בקר כפול
מדוע שני בקרים?
לצריכה והפצה יש מאפייני הרחבה שונים במהותם:
- צריכה מתרחבת עם מספר המצלמות ורוחב הפס הנכנס (צפוי, גדל בהתמדה)
- הפצה מתרחבת עם מספר הצופים ודרישת עובדי AI (תזזיתי, בלתי צפוי)
בקרים נפרדים מאפשרים לכל אחד להתרחב באופן עצמאי עם מדיניות, מדדים וסף מיוחדים — מבלי שהחלטות ההרחבה של אשכול אחד ישפיעו על השני.
בקר צריכה (Ingestion Orchestrator)
- מדד ראשי: חיבורי מצלמה לשרת
- מדד משני: ניצול רוחב פס נכנס
- הרחבה (Scale Up): כאשר ה-CPU עולה על הסף או שמספר המצלמות לשרת עולה על הקיבולת
- הקטנה (Scale Down): כאשר הניצול יורד מתחת לסף למשך תקופת התייצבות ממושכת
- טווח שרתים: 1 עד 10 שרתים
בקר הפצה (Distribution Orchestrator)
- מדד ראשי: חיבורי צופים + עובדי AI לשרת
- מדד משני: ניצול רוחב פס יוצא
- הרחבה (Scale Up): כאשר ה-CPU עולה על הסף או שמספר החיבורים לשרת עולה על הקיבולת
- הקטנה (Scale Down): כאשר הניצול יורד מתחת לסף למשך תקופה ממושכת (התייצבות ארוכה יותר מצריכה)
- טווח שרתים: 2 עד 20 שרתים (מינימום 2 לזמינות גבוהה)
אפס אובדן מנות: כיבוי הדרגתי ב-5 שלבים
כאשר שרת הפצה מתוכנן להסרה, תהליך בן 5 שלבים מבטיח שאף פריים לא יאבד:
שלב 1: התרעה מוקדמתהשרת מסומן כ-"DRAINING" (בהליך ניקוז) ברישום השירותים (service registry). משקל מאזן העומס מופחת כך שחיבורים חדשים ינותבו למקום אחר. התרעות Redis pub/sub ו-webhooks מתריעות בפני עובדי AI להתכונן להעברה.
שלב 2: עדכון מאזן עומסהשרת מוסר ממאגר ה-backend של מאזן העומס. אין חיבורים חדשים יכולים להגיע לשרת המתנקז. חיבורים קיימים ממשיכים ללא הפרעה.
שלב 3: העברת עובדי AIעובדי AI מתנתקים מהשרת המתנקז ומתחברים מחדש לשרתי הפצה תקינים. שמירת מצב מבוססת Checkpoint מבטיחה שהעיבוד יתחדש בדיוק מהפריים שבו הופסק. פער כולל: כ-3 שניות עם אפס פריימים שאבדו.
שלב 4: ניקוז צופיםחיבורי הצופים הנותרים מתנקזים באופן טבעי במהלך חלון זמן ניתן להגדרה. נגני וידאו מודרניים מתחברים מחדש אוטומטית לאותו URL יציב, אשר מנותב לשרתים תקינים. רוב הצופים לא חווים כל הפרעה.
שלב 5: ניקויוודא שכל החיבורים נסגרו. הסר את השרת מרישום השירותים (service registry). השמד את מופע ה-cloud. רשום מדדי הרחבה.
כתובות URL יציבות
ארכיטקטורת ה-URL מבטיחה שמצלמות ולקוחות לעולם לא יצטרכו תצורה מחדש:
- יעד פרסום מצלמה: שם מתחם צריכה (ingestion) יציב
- יעד גישה לצופים/AI: שם מתחם הפצה (distribution) יציב
- רשומות DNS מצביעות על כתובות IP של מאזני עומס (load balancers) (שהן קבועות)
- מאזני עומס מטפלים בניתוז לשרתי backend באופן שקוף
- שרתי Backend ניתנים להוספה, הסרה או החלפה ללא שינויים ב-URL
רישום שירותים (Redis)
מופע Redis מרכזי מתאם את המערכת כולה:
- מעקב אחר מצב שרתים (פעיל, מתנקז, לא מקוון)
- מיפוי זרם לשרת (איזו מצלמה נמצאת באיזה שרת צריכה)
- מצב עובדי AI ונתוני checkpoint
- מדדי עומס לשרת עבור החלטות הרחבה
- ערוצי pub/sub לאירועי תיאום בזמן אמת
חיבור מחדש של לקוח AI
ספריית לקוח AI מספקת חיבור מחדש חלק:
- מאזין להודעות הסרת שרת באמצעות Redis pub/sub
- Checkpointing אוטומטי של פריימים במרווחי זמן קבועים
- חיבור מחדש לשרת הפצה תקין עם קבלת הודעה
- המשך עיבוד מ-checkpoint עם פער מינימלי
- דיווח מדדים עבור אירועי חיבור מחדש
ניטור תקינות
- בדיקות תקינות אקטיביות בכל שרת במרווחי זמן קבועים
- עדכוני מאזן עומס אוטומטיים במקרה של כשל שרתים
- הפעלת שחזור אוטומטי עבור שרתים שאינם מגיבים
- מעקב אחר זמן פעולה ודיווח זמינות
תכונות עיקריות
- בקרים כפולים — הרחבה עצמאית לאשכולות צריכה והפצה
- אפס אובדן מנות — כיבוי הדרגתי ב-5 שלבים עם העברת עובדי AI
- כתובות URL יציבות — ניתוב מבוסס DNS מבטיח שכתובות URL לעולם לא ישתנו במהלך הרחבה
- חיבור מחדש של עובדי AI — העברה מבוססת Checkpoint עם פער של כ-3 שניות ואפס אובדן פריימים
- הרחבה עצמאית — צריכה והפצה מתרחבות על בסיס המדדים שלהן
- רישום שירותים — תיאום מבוסס Redis למצב שרתים ומיפויי זרמים
- ניטור תקינות — בדיקות אקטיביות עם שחזור אוטומטי
- אופטימיזציה של עלויות — הקטנה אוטומטית בתקופות של ביקוש נמוך
תוצאות
מחסנית טכנולוגית
caseStudyDetail.more מקרי בוחן
גלה עוד מהיישומים הטכניים שלנו
פלטפורמת Catant לניהול משאבי אנוש וכוח אדם
Catant היא פלטפורמה מודולרית לניהול משאבי אנוש וכוח אדם המסייעת לארגונים לנהל עובדים, שכר, נוכחות ועמידה בתקנים מתוך לוח מחוונים אחד.
Kickly: פלטפורמת פרויקטים מבוססת AI לסטארט-אפים
Kickly היא פלטפורמת ניהול פרויקטים מבוססת AI שנבנתה עבור סטארט-אפים — המשלבת אוטומציה חכמה של משימות, שיתוף פעולה בצוות, ומעקב אחר התקדמות בזמן אמת במוצר אחד.
שאלות נפוצות
חברת MicrocosmWorks יישמה תכנון dual orchestrator מסוג active-active שבו שני ה-orchestrators שומרים על מצב מסונכרן לגבי stream assignments ו-worker health, עם failover אוטומטי המעביר את stream management ל-orchestrator שנותר פעיל תוך שניות אם אחד מהם כושל. זה מבטל את נקודת הכשל הבודדת שממנה סובלים תכנוני single-orchestrator מסורתיים, ומבטיח אפס packet drop במהלך תחזוקת ה-orchestrator או קריסות בלתי צפויות.
MicrocosmWorks תכננה מנגנון ניקוז הדרגתי (graceful drain mechanism) שבו עובדים פורשים ממשיכים לשרת את הזרמים (streams) שהוקצו להם עד שכל החיבורים מועברים בצורה נקייה לעובדים חדשים באמצעות רצפי RTSP TEARDOWN ו-re-SETUP. עובדים חדשים מאותחלים במלואם ונבדקים בריאותית (health-checked) לפני קבלת הקצאות זרמים (stream assignments), והמעבר משתמש בחלונות חופפים (overlapping windows) שבהם גם עובדים ישנים וגם חדשים משרתים לזמן קצר את אותו הזרם כדי למנוע כל הפרעה.
MicrocosmWorks בחרה ב-MediaMTX עבור פרויקט זה מכיוון שהוא קל משקל, בקוד פתוח, ותוכנן במיוחד עבור הזרמת RTSP מחדש עם תקורה מינימלית של משאבים לכל זרם בהשוואה לשרתי מדיה עתירי תכונות. הוא תומך ביצירת זרמים דינמית באמצעות API, פועל ביעילות בקונטיינרים עבור סקיילינג אוטומטי מבוסס Kubernetes, ונמנע מעלויות רישוי לכל זרם של חלופות מסחריות כמו Wowza שעלולות להיות יקרות מדי בקנה מידה רחב.
MicrocosmWorks פרסה מערך תצפיתיות מקיף שעוקב אחר מדדים לכל זרם, כולל שיעור איבוד מנות, ג'יטר, ספירת חיבורים מחדש, וחביון מקצה לקצה, עם התראות שמופעלות לפני שהידרדרות הופכת גלויה למשתמשי קצה. מערכת הניטור עוקבת גם אחר מדדי קבלת החלטות של מתזמר, כמו אירועי קנה מידה, משכי זמן של העברת זרמים, ומגמות ניצול ה-workers כדי לאפשר תכנון קיבולת יזום.
כן, MicrocosmWorks תכננה את ה-worker nodes לתמיכה בפלט RTSP מקבילי עבור צופים חיים והקלטה מפולחת (segmented recording) ל-object storage, עם הקצאת משאבים עצמאית לכל workload. הקלטה משתמשת ב-write path נפרד אשר אוגר segments באופן מקומי לפני העלאתם, כך ש-I/O spikes של האחסון לעולם אינם משפיעים על live stream delivery, וה-auto-scaler מביא בחשבון את דרישת המשאבים המשולבת של שני ה-workloads בעת קבלת החלטות scaling.
מוכן לשנות את העסק שלך?
בואו נדון כיצד נוכל ליישם פתרונות דומים לאתגרים שלך.