Auto-Skalierungs RTSP-Streaming-Architektur mit doppelten Orchestratoren & null Paketverlust
Eine Überwachungsplattform musste ihre Video-Streaming-Infrastruktur dynamisch skalieren – um 10 bis über 200 IP-Kameras mit Hunderten von gleichzeitigen Betrachtern und AI-Verarbeitungs-Workern zu verwalten –, während null Paketverlust bei Skalierungsvorgängen garantiert und stabile Stream-URLs beibehalten wurden, die sich nie ändern.
Ihr Projekt besprechen
Die Herausforderung
Feste Streaming-Infrastruktur konnte die variablen Anforderungen einer wachsenden Überwachungsplattform nicht bewältigen:
- Skalierungsvariabilität — Die Anzahl der Kameras und die Nachfrage der Betrachter schwankten im Laufe des Tages dramatisch (10-faches Verhältnis von Spitze zu Tal)
- Kosten für Überprovisionierung — Die Bereitstellung für Spitzenlast bedeutete über 70% ungenutzte Ressourcen außerhalb der Spitzenzeiten
- Paketverlust während der Skalierung — Das Hinzufügen oder Entfernen von Streaming-Servern führte zu Stream-Unterbrechungen, wodurch Frames für AI-Verarbeitungs-Worker verloren gingen
- URL-Instabilität — Kameras und Betrachter, die mit spezifischen Server-IPs konfiguriert waren, erforderten eine Neukonfiguration bei Infrastrukturänderungen
- Unterschiedliche Skalierungsanforderungen — Die Kamera-Ingestion und Betrachter-Distribution hatten grundlegend unterschiedliche Lastmuster, die eine unabhängige Skalierung erforderten
- AI-Worker-Unterbrechung — AI-Verarbeitungs-Pipelines stürzten ab, wenn ihr Quell-Stream-Server heruntergefahren wurde
Unsere Lösung
Wir haben eine auto-skalierende Streaming-Architektur mit zwei Orchestratoren entworfen, mit separaten Ingestion- und Distribution-Clustern, einem 5-phasigen ordentlichen Herunterfahren für null Paketverlust, stabilen DNS-basierten URLs und automatischer AI-Worker-Wiederverbindung.
Architektur
- Streaming-Server: MediaMTX für RTSP/WebRTC/HLS-Protokollunterstützung
- Ingestion Cluster: 1-10 Server, die Kamera-RTSP-Streams empfangen
- Distribution Cluster: 2-20 Server, die Betrachter (WebRTC/HLS) und AI-Worker (RTSP) bedienen
- Doppelte Orchestratoren: Unabhängige Skalierungs-Controller für Ingestion und Distribution
- Load Balancers: Separate Load Balancer pro Cluster mit protokollgerechten Algorithmen
- Service Registry: Redis für Serverstatus, Stream-Mappings und Koordination
- Health Monitoring: Aktive Gesundheitsprüfungen mit automatischer Wiederherstellung
- DNS-Schicht: Stabile Domainnamen, die auf Load Balancer zeigen (URLs ändern sich nie)
Design mit zwei Orchestratoren
Warum zwei Orchestratoren
Ingestion und Distribution haben grundlegend unterschiedliche Skalierungscharakteristika:
- Ingestion skaliert mit der Anzahl der Kameras und der eingehenden Bandbreite (vorhersehbar, wächst stetig)
- Distribution skaliert mit der Anzahl der Betrachter und der AI-Worker-Nachfrage (stoßweise, unvorhersehbar)
Separate Orchestratoren ermöglichen es jedem, unabhängig mit spezialisierten Richtlinien, Metriken und Schwellenwerten zu skalieren – ohne dass die Skalierungsentscheidungen eines Clusters den anderen beeinflussen.
Ingestion Orchestrator
- Primäre Metrik: Kameraverbindungen pro Server
- Sekundäre Metrik: Auslastung der eingehenden Bandbreite
- Hochskalieren: Wenn die CPU einen Schwellenwert überschreitet oder die Kameras pro Server die Kapazität überschreiten
- Herunterskalieren: Wenn die Auslastung über einen längeren Stabilisierungszeitraum unter einen Schwellenwert fällt
- Serverbereich: 1 bis 10 Server
Distribution Orchestrator
- Primäre Metrik: Betrachter- + AI-Worker-Verbindungen pro Server
- Sekundäre Metrik: Auslastung der ausgehenden Bandbreite
- Hochskalieren: Wenn die CPU einen Schwellenwert überschreitet oder die Verbindungen pro Server die Kapazität überschreiten
- Herunterskalieren: Wenn die Auslastung über einen längeren Zeitraum unter einen Schwellenwert fällt (längere Stabilisierung als bei Ingestion)
- Serverbereich: 2 bis 20 Server (mindestens 2 für hohe Verfügbarkeit)
Null Paketverlust: 5-phasiges ordentliches Herunterfahren
Wenn ein Distribution-Server zur Entfernung vorgesehen ist, sorgt ein 5-phasiger Prozess dafür, dass keine Frames verloren gehen:
Phase 1: Vorab-BenachrichtigungServer in der Service Registry als „DRAINING“ (wird entleert) markiert. Das Gewicht des Load Balancers wird reduziert, sodass neue Verbindungen anderswohin geleitet werden. Redis pub/sub-Benachrichtigungen und Webhooks informieren AI-Worker, sich auf die Migration vorzubereiten.
Phase 2: Load Balancer UpdateServer aus dem Backend-Pool des Load Balancers entfernt. Keine neuen Verbindungen können den entleerenden Server erreichen. Bestehende Verbindungen werden ununterbrochen fortgesetzt.
Phase 3: AI-Worker-MigrationAI-Worker trennen die Verbindung vom entleerenden Server und verbinden sich wieder mit fehlerfreien Distribution-Servern. Die Checkpoint-basierte Statussicherung gewährleistet, dass die Verarbeitung genau ab dem Frame fortgesetzt wird, an dem sie aufgehört hat. Gesamtverzögerung: ungefähr 3 Sekunden ohne Frame-Verlust.
Phase 4: Entleerung der BetrachterVerbleibende Betrachterverbindungen werden über ein konfigurierbares Fenster auf natürliche Weise entleert. Moderne Videoplayer verbinden sich automatisch mit derselben stabilen URL, die zu fehlerfreien Servern weiterleitet. Die meisten Betrachter erleben keine Unterbrechung.
Phase 5: BereinigungÜberprüfen, ob alle Verbindungen geschlossen wurden. Server aus der Service Registry entfernen. Cloud-Instanz zerstören. Skalierungsmetriken aufzeichnen.
Stabile URLs
Die URL-Architektur stellt sicher, dass Kameras und Clients niemals neu konfiguriert werden müssen:
- Kamera-Veröffentlichungsziel: Ein stabiler Ingestion-Domainname
- Betrachter-/AI-Zugriffsziel: Ein stabiler Distribution-Domainname
- DNS-Einträge zeigen auf Load Balancer IPs (die permanent sind)
- Load Balancer übernehmen die transparente Weiterleitung an Backend-Server
- Backend-Server können hinzugefügt, entfernt oder ersetzt werden, ohne dass sich die URLs ändern
Service Registry (Redis)
Eine zentrale Redis-Instanz koordiniert das gesamte System:
- Verfolgung des Serverstatus (aktiv, wird entleert, offline)
- Stream-zu-Server-Mapping (welche Kamera auf welchem Ingestion-Server ist)
- AI-Worker-Status und Checkpoint-Daten
- Lastmetriken pro Server für Skalierungsentscheidungen
- Pub/sub-Kanäle für Echtzeit-Koordinationsereignisse
AI-Client-Wiederverbindung
Eine AI-Client-Bibliothek bietet eine nahtlose Wiederverbindung:
- Lauscht auf Serverentfernungsbenachrichtigungen über Redis pub/sub
- Automatische Frame-Checkpointing in regelmäßigen Abständen
- Wiederverbindung zu einem fehlerfreien Distribution-Server bei Benachrichtigung
- Fortsetzung der Verarbeitung ab Checkpoint mit minimaler Unterbrechung
- Metrikberichterstattung für Wiederverbindungsereignisse
Health Monitoring
- Aktive Gesundheitsprüfungen auf jedem Server in regelmäßigen Abständen
- Automatische Load Balancer Updates bei Serverausfällen
- Auto-Recovery-Trigger für nicht reagierende Server
- Uptime-Verfolgung und Verfügbarkeitsberichterstattung
Hauptmerkmale
- Doppelte Orchestratoren — Unabhängige Skalierung für Ingestion- und Distribution-Cluster
- Null Paketverlust — 5-phasiges ordentliches Herunterfahren mit AI-Worker-Migration
- Stabile URLs — DNS-basiertes Routing stellt sicher, dass sich URLs während der Skalierung nie ändern
- AI-Worker-Wiederverbindung — Checkpoint-basierte Migration mit ~3 Sekunden Unterbrechung und null Frame-Verlust
- Unabhängige Skalierung — Ingestion und Distribution skalieren basierend auf ihren eigenen Metriken
- Service Registry — Redis-basierte Koordination für Serverstatus und Stream-Mappings
- Health Monitoring — Aktive Prüfungen mit automatischer Wiederherstellung
- Kostenoptimierung — Automatisches Herunterskalieren in Zeiten geringer Nachfrage
Ergebnisse
Technologie-Stack
caseStudyDetail.more Fallstudien
Entdecken Sie mehr unserer technischen Implementierungen
KI-gestützte Rechnungsverarbeitung mit OCR und QuickBooks-Integration
Ein mittelständisches Unternehmen, das monatlich Hunderte von Lieferantenrechnungen verarbeitete, musste die manuelle Dateneingabe eliminieren, indem es Rechnungsdaten automatisch mithilfe von AI/OCR extrahierte und diese direkt mit QuickBooks für die Buchhaltung und Zahlungsverfolgung synchronisierte.
Clientseitige Anzeigeninsertion (CSAI) mit SCTE-35 Marker-Parsing & Multi-Plattform-Player-Integration
Eine Video-Streaming-Plattform musste die Clientseitige Anzeigeninsertion (CSAI) über Web-, Mobil- und Connected TV-Apps hinweg implementieren – was personalisierte, gerätespezifische Anzeigenerlebnisse mit vollständiger Unterstützung der Anzeigeninteraktion (anklickbare Overlays, Companion-Banner, Skip-Buttons) ermöglicht, die serverseitige Insertion nicht bieten kann.
Bereit, Ihr Unternehmen zu transformieren?
Lassen Sie uns besprechen, wie wir ähnliche Lösungen für Ihre Herausforderungen anwenden können.