Comment le modèle à double orchestrateur prévient-il les points de défaillance uniques dans l'infrastructure de streaming RTSP ?

MicrocosmWorks a implémenté une architecture d'orchestrateur double actif-actif où les deux orchestrateurs maintiennent un état synchronisé concernant les attributions de flux et la santé des workers, avec un basculement automatique qui transfère la gestion des flux à l'orchestrateur survivant en quelques secondes si l'un d'eux tombe en panne. Cela élimine le point de défaillance unique dont souffrent les architectures traditionnelles à orchestrateur unique, assurant zéro perte de paquets pendant la maintenance de l'orchestrateur ou des pannes inattendues.

Comment l'architecture d'auto-mise à l'échelle évite-t-elle toute perte de paquets lors de l'ajout ou de la suppression de workers de streaming ?

MicrocosmWorks a conçu un mécanisme de désactivation progressive où les workers en cours de retrait continuent de servir leurs flux attribués jusqu'à ce que toutes les connexions soient proprement migrées vers de nouveaux workers via des séquences RTSP TEARDOWN et re-SETUP. Les nouveaux workers sont entièrement initialisés et vérifiés avant de recevoir des attributions de flux, et la transition utilise des fenêtres de chevauchement où les anciens et les nouveaux workers servent brièvement le même flux pour éviter toute interruption.

Pourquoi utiliser MediaMTX comme serveur de streaming principal au lieu d'alternatives comme Wowza ou Ant Media ?

MicrocosmWorks a sélectionné MediaMTX pour ce projet car il est léger, open-source, et conçu spécifiquement pour le re-streaming RTSP avec une surcharge de ressources minimale par flux comparé aux serveurs multimédia complets. Il prend en charge la création de flux dynamique via API, fonctionne efficacement dans des conteneurs pour l'auto-scaling basé sur Kubernetes, et évite les coûts de licence par flux des alternatives commerciales comme Wowza qui peuvent devenir prohibitifs à grande échelle.

Quel monitoring et quelle alerte sont nécessaires pour maintenir la fiabilité d'une plateforme de streaming RTSP auto-évolutive ?

MicrocosmWorks a déployé une stack d'observabilité complète qui suit les métriques par flux, incluant le taux de perte de paquets, le jitter, le nombre de reconnexions et la latence de bout en bout, avec des alertes qui se déclenchent avant que la dégradation ne devienne visible pour les utilisateurs finaux. Le système de monitoring suit également les métriques de prise de décision de l'orchestrateur, telles que les événements de scaling, les durées de migration de flux et les tendances d'utilisation des workers, afin de permettre une planification proactive de la capacité.

Cette architecture RTSP auto-scaling peut-elle gérer à la fois la visualisation en direct et les charges de travail d'enregistrement simultané ?

Oui, MicrocosmWorks a conçu les worker nodes pour prendre en charge la sortie RTSP concurrente pour les spectateurs en direct et l'enregistrement segmenté vers le stockage d'objets, avec une allocation de ressources indépendante pour chaque charge de travail. L'enregistrement utilise un chemin d'écriture séparé qui met en mémoire tampon les segments localement avant de les télécharger, de sorte que les pics d'E/S de stockage n'impactent jamais la diffusion en direct, et l'auto-scaler tient compte de la demande de ressources combinée des deux charges de travail lors des décisions de mise à l'échelle.

Auto-Scaling RTSP Streaming Architecture with Dual Orches...

L'infrastructure de streaming fixe ne pouvait pas gérer les demandes variables d'une plateforme de surveillance en croissance :

Variabilité de l'Échelle — Le nombre de caméras et la demande des spectateurs fluctuaient de manière spectaculaire tout au long de la journée (ratio de crête à creux de 10x)
Coût de Surprovisionnement — Le provisionnement pour la charge de pointe signifiait plus de 70% de ressources inactives pendant les heures creuses
Perte de Paquets Pendant la Mise à l'Échelle — L'ajout ou le retrait de serveurs de streaming provoquait des interruptions de flux, perdant des images pour les travailleurs de traitement AI
Instabilité des URL — Les caméras et les spectateurs configurés avec des IP de serveur spécifiques nécessitaient une reconfiguration lorsque l'infrastructure changeait
Besoins de Mise à l'Échelle Différents — L'ingestion des caméras et la distribution des spectateurs avaient des modèles de charge fondamentalement différents nécessitant une mise à l'échelle indépendante
Perturbation des Travailleurs AI — Les pipelines de traitement AI se crashaient lorsque leur serveur de flux source était réduit

Nous avons conçu une architecture de streaming à mise à l'échelle automatique avec double orchestrateurs avec des clusters d'ingestion et de distribution séparés, une extinction progressive en 5 phases pour zéro perte de paquets, des URL stables basées sur DNS, et une reconnexion automatisée des travailleurs AI.

Architecture

Serveur de Streaming : MediaMTX pour le support des protocoles RTSP/WebRTC/HLS
Cluster d'Ingestion : 1-10 serveurs recevant les flux RTSP des caméras
Cluster de Distribution : 2-20 serveurs desservant les spectateurs (WebRTC/HLS) et les travailleurs AI (RTSP)
Double Orchestrateurs : Contrôleurs de mise à l'échelle indépendants pour l'ingestion et la distribution
Équilibreurs de Charge : Équilibreurs de charge séparés par cluster avec des algorithmes adaptés aux protocoles
Registre de Services : Redis pour le statut des serveurs, les mappages de flux, et la coordination
Surveillance de la Santé : Vérifications de santé actives avec récupération automatisée
Couche DNS : Noms de domaine stables pointant vers les équilibreurs de charge (les URL ne changent jamais)

Conception du Double Orchestrateur

Pourquoi Deux Orchestrateurs

L'ingestion et la distribution ont des caractéristiques de mise à l'échelle fondamentalement différentes :

Ingestion s'adapte au nombre de caméras et à la bande passante entrante (prévisible, croît régulièrement)
Distribution s'adapte au nombre de spectateurs et à la demande des travailleurs AI (éclaté, imprévisible)

Des orchestrateurs séparés permettent à chacun de s'adapter indépendamment avec des politiques, des métriques et des seuils spécialisés — sans que les décisions de mise à l'échelle d'un cluster n'affectent l'autre.

Orchestrateur d'Ingestion

Métrique Principale : Connexions de caméras par serveur
Métrique Secondaire : Utilisation de la bande passante entrante
Mise à l'Échelle Vers le Haut : Lorsque le CPU dépasse le seuil ou que les caméras par serveur dépassent la capacité
Mise à l'Échelle Vers le Bas : Lorsque l'utilisation tombe en dessous du seuil pendant une période de stabilisation soutenue
Plage de Serveurs : 1 à 10 serveurs

Orchestrateur de Distribution

Métrique Principale : Connexions de spectateurs + travailleurs AI par serveur
Métrique Secondaire : Utilisation de la bande passante sortante
Mise à l'Échelle Vers le Haut : Lorsque le CPU dépasse le seuil ou que les connexions par serveur dépassent la capacité
Mise à l'Échelle Vers le Bas : Lorsque l'utilisation tombe en dessous du seuil pendant une période soutenue (stabilisation plus longue que l'ingestion)
Plage de Serveurs : 2 à 20 serveurs (minimum 2 pour haute disponibilité)

Zéro Perte de Paquets : Extinction Progressive en 5 Phases

Lorsqu'un serveur de distribution est programmé pour être retiré, un processus en 5 phases garantit qu'aucune image n'est perdue :

Phase 1 : Pré-Notification

Serveur marqué comme "DRAINING" dans le registre de services. Poids de l'équilibreur de charge réduit pour que les nouvelles connexions se dirigent ailleurs. Notifications Redis pub/sub et webhooks alertent les travailleurs AI pour se préparer à la migration.

Phase 2 : Mise à Jour de l'Équilibreur de Charge

Serveur retiré du pool backend de l'équilibreur de charge. Aucune nouvelle connexion ne peut atteindre le serveur en vidange. Les connexions existantes continuent sans interruption.

Phase 3 : Migration des Travailleurs AI

Les travailleurs AI se déconnectent du serveur en vidange et se reconnectent à des serveurs de distribution sains. La préservation de l'état basée sur des points de contrôle garantit que le traitement reprend à partir de l'image exacte où il s'est arrêté. Écart total : environ 3 secondes avec zéro image perdue.

Phase 4 : Vidange des Spectateurs

Les connexions de spectateurs restantes se vident naturellement sur une fenêtre configurable. Les lecteurs vidéo modernes se reconnectent automatiquement à la même URL stable, qui dirige vers des serveurs sains. La plupart des spectateurs ne subissent aucune interruption.

Phase 5 : Nettoyage

Vérifiez que toutes les connexions sont fermées. Retirez le serveur du registre de services. Détruisez l'instance cloud. Enregistrez les métriques de mise à l'échelle.

URLs Stables

L'architecture des URL garantit que les caméras et les clients n'ont jamais besoin de reconfiguration :

Cible de publication de la caméra : Un nom de domaine d'ingestion stable
Cible d'accès des spectateurs/travailleurs AI : Un nom de domaine de distribution stable
Les enregistrements DNS pointent vers les IP des équilibreurs de charge (qui sont permanents)
Les équilibreurs de charge gèrent le routage vers les serveurs backend de manière transparente
Les serveurs backend peuvent être ajoutés, retirés ou remplacés sans changement d'URL

Registre de Services (Redis)

Une instance Redis centralisée coordonne l'ensemble du système :

Suivi du statut des serveurs (actif, en vidange, hors ligne)
Mappage des flux aux serveurs (quelle caméra est sur quel serveur d'ingestion)
État des travailleurs AI et données de point de contrôle
Métriques de charge par serveur pour les décisions de mise à l'échelle
Canaux pub/sub pour les événements de coordination en temps réel

Reconnexion des Clients AI

Une bibliothèque client AI fournit une reconnexion transparente :

Écoute les notifications de retrait de serveur via Redis pub/sub
Pointage de contrôle automatique des images à intervalles réguliers
Reconnexion à un serveur de distribution sain sur notification
Reprise du traitement à partir du point de contrôle avec un écart minimal
Rapport de métriques pour les événements de reconnexion

Surveillance de la Santé

Vérifications de santé actives sur chaque serveur à intervalles réguliers
Mises à jour automatiques de l'équilibreur de charge en cas de défaillance de serveur
Déclencheurs de récupération automatique pour les serveurs non réactifs
Suivi du temps de disponibilité et rapport de disponibilité

Caractéristiques Clés

Double Orchestrateurs — Mise à l'échelle indépendante pour les clusters d'ingestion et de distribution
Zéro Perte de Paquets — Extinction progressive en 5 phases avec migration des travailleurs AI
URLs Stables — Routage basé sur DNS garantit que les URL ne changent jamais pendant la mise à l'échelle
Reconnexion des Travailleurs AI — Migration basée sur des points de contrôle avec un écart d'environ 3 secondes et zéro perte d'image
Mise à l'Échelle Indépendante — L'ingestion et la distribution s'adaptent en fonction de leurs propres métriques
Registre de Services — Coordination basée sur Redis pour le statut des serveurs et les mappages de flux
Surveillance de la Santé — Vérifications actives avec récupération automatique
Optimisation des Coûts — Réduction automatique pendant les périodes de faible demande

Architecture de Streaming RTSP à Mise à l'Échelle Automatique avec Double Orchestrateurs & Zéro Perte de Paquets

Le Défi

Notre Solution

Architecture

Conception du Double Orchestrateur

Pourquoi Deux Orchestrateurs

Orchestrateur d'Ingestion

Orchestrateur de Distribution

Zéro Perte de Paquets : Extinction Progressive en 5 Phases

URLs Stables

Registre de Services (Redis)

Reconnexion des Clients AI

Surveillance de la Santé

Caractéristiques Clés

Résultats

Stack Technologique

caseStudyDetail.more Études de Cas

Plateforme de gestion des RH et du personnel Catant

Kickly: Plateforme de projet alimentée par l'AI pour les Startups

Prêt à Transformer Votre Entreprise ?

Traitement de factures assisté par l'IA avec OCR et intégration QuickBooks

Questions fréquemment posées