ארכיטקטורת RTSP Streaming עם Auto-Scaling, בקרים כפולים ואפס אובדן מנות

תכננו ארכיטקטורת 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 עם פער מינימלי
• דיווח מדדים עבור אירועי חיבור מחדש

ניטור תקינות

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

תכונות עיקריות

1. בקרים כפולים — הרחבה עצמאית לאשכולות צריכה והפצה
2. אפס אובדן מנות — כיבוי הדרגתי ב-5 שלבים עם העברת עובדי AI
3. כתובות URL יציבות — ניתוב מבוסס DNS מבטיח שכתובות URL לעולם לא ישתנו במהלך הרחבה
4. חיבור מחדש של עובדי AI — העברה מבוססת Checkpoint עם פער של כ-3 שניות ואפס אובדן פריימים
5. הרחבה עצמאית — צריכה והפצה מתרחבות על בסיס המדדים שלהן
6. רישום שירותים — תיאום מבוסס Redis למצב שרתים ומיפויי זרמים
7. ניטור תקינות — בדיקות אקטיביות עם שחזור אוטומטי
8. אופטימיזציה של עלויות — הקטנה אוטומטית בתקופות של ביקוש נמוך