Architecture de streaming RTSP à auto-mise à l'échelle avec orchestrateurs doubles et zéro perte de paquets
Une plateforme de surveillance devait faire évoluer dynamiquement son infrastructure de streaming vidéo — gérant entre 10 et plus de 200 caméras IP avec des centaines de spectateurs simultanés et de workers de traitement AI — tout en garantissant zéro perte de paquets pendant les opérations de mise à l'échelle et en maintenant des URL de stream stables qui ne changent jamais.
Discutez de Votre Projet
Le Défi
Une 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 considérablement tout au long de la journée (rapport pic-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 la suppression de serveurs de streaming provoquait des interruptions de stream, entraînant la perte d'images pour les workers 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 de caméras et la distribution aux spectateurs avaient des modèles de charge fondamentalement différents nécessitant une mise à l'échelle indépendante
- Interruption des workers AI — Les pipelines de traitement AI plantaient lorsque leur serveur de stream source était réduit
Notre Solution
Nous avons conçu une architecture de streaming à auto-mise à l'échelle avec orchestrateurs doubles, dotée de clusters d'ingestion et de distribution séparés, d'un arrêt gracieux en 5 phases pour zéro perte de paquets, d'URL stables basées sur DNS, et d'une reconnexion automatisée des workers AI.
Architecture
- Serveur de streaming : MediaMTX pour la prise en charge des protocoles RTSP/WebRTC/HLS
- Cluster d'ingestion : 1 à 10 serveurs recevant les streams RTSP des caméras
- Cluster de distribution : 2 à 20 serveurs desservant les spectateurs (WebRTC/HLS) et les workers AI (RTSP)
- Orchestrateurs doubles : 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 au protocole
- Registre de services : Redis pour l'état des serveurs, les mappages de stream et la coordination
- Surveillance de l'état de santé : Vérifications actives de l'état de santé avec récupération automatisée
- Couche DNS : Noms de domaine stables pointant vers les équilibreurs de charge (les URL ne changent jamais)
Conception des orchestrateurs doubles
Pourquoi deux orchestrateurs
L'ingestion et la distribution ont des caractéristiques de mise à l'échelle fondamentalement différentes :
- L'ingestion évolue en fonction du nombre de caméras et de la bande passante entrante (prévisible, croît régulièrement)
- La distribution évolue en fonction du nombre de spectateurs et de la demande des workers AI (irrégulière, 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 un seuil ou que le nombre de caméras par serveur dépasse la capacité
- Mise à l'échelle vers le bas : Lorsque l'utilisation tombe en dessous du seuil pendant une période de stabilisation prolongée
- Plage de serveurs : 1 à 10 serveurs
Orchestrateur de distribution
- Métrique principale : Connexions spectateurs + workers AI par serveur
- Métrique secondaire : Utilisation de la bande passante sortante
- Mise à l'échelle vers le haut : Lorsque le CPU dépasse un seuil ou que le nombre de connexions par serveur dépasse la capacité
- Mise à l'échelle vers le bas : Lorsque l'utilisation tombe en dessous du seuil pendant une période prolongée (stabilisation plus longue que pour l'ingestion)
- Plage de serveurs : 2 à 20 serveurs (minimum 2 pour une haute disponibilité)
Zéro perte de paquets : Arrêt gracieux en 5 phases
Lorsqu'un serveur de distribution est programmé pour être supprimé, un processus en 5 phases garantit qu'aucune image n'est perdue :
Phase 1 : Pré-notificationLe serveur est marqué comme "DRAINING" dans le registre de services. Le poids de l'équilibreur de charge est réduit afin que les nouvelles connexions soient acheminées ailleurs. Les notifications Redis pub/sub et les webhooks alertent les workers AI pour qu'ils se préparent à la migration.
Phase 2 : Mise à jour de l'équilibreur de chargeLe serveur est supprimé du pool backend de l'équilibreur de charge. Aucune nouvelle connexion ne peut atteindre le serveur en cours de désactivation. Les connexions existantes se poursuivent sans interruption.
Phase 3 : Migration des workers AILes workers AI se déconnectent du serveur en cours de désactivation et se reconnectent aux serveurs de distribution sains. La conservation de l'état basée sur des checkpoints garantit que le traitement reprend à partir de l'image exacte où il s'est arrêté. Délai total : environ 3 secondes avec zéro image perdue.
Phase 4 : Désactivation des spectateursLes connexions de spectateurs restantes se désactivent naturellement sur une fenêtre configurable. Les lecteurs vidéo modernes se reconnectent automatiquement à la même URL stable, qui est acheminée vers des serveurs sains. La plupart des spectateurs ne subissent aucune interruption.
Phase 5 : NettoyageVérifier que toutes les connexions sont fermées. Supprimer le serveur du registre de services. Détruire l'instance cloud. Enregistrer les métriques de mise à l'échelle.
URL 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 spectateur/AI : Un nom de domaine de distribution stable
- Les enregistrements DNS pointent vers les IP des équilibreurs de charge (qui sont permanentes)
- Les équilibreurs de charge gèrent le routage vers les serveurs backend de manière transparente
- Les serveurs backend peuvent être ajoutés, supprimés ou remplacés sans changement d'URL
Registre de services (Redis)
Une instance Redis centralisée coordonne l'ensemble du système :
- Suivi de l'état des serveurs (actif, en désactivation, hors ligne)
- Mappage stream-vers-serveur (quelle caméra est sur quel serveur d'ingestion)
- État des workers AI et données de checkpoint
- 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 du client AI
Une bibliothèque cliente AI fournit une reconnexion transparente :
- Écoute les notifications de suppression de serveur via Redis pub/sub
- Enregistrement automatique des checkpoints d'images à intervalles réguliers
- Reconnexion à un serveur de distribution sain sur notification
- Reprise du traitement à partir du checkpoint avec un écart minimal
- Rapport de métriques pour les événements de reconnexion
Surveillance de l'état de santé
- Vérifications actives de l'état de santé sur chaque serveur à intervalles réguliers
- Mises à jour automatiques des équilibreurs de charge en cas de défaillance des serveurs
- Déclencheurs de récupération automatique pour les serveurs ne répondant pas
- Suivi de la disponibilité et rapport d'accessibilité
Fonctionnalités clés
- Orchestrateurs doubles — Mise à l'échelle indépendante pour les clusters d'ingestion et de distribution
- Zéro perte de paquets — Arrêt gracieux en 5 phases avec migration des workers AI
- URL stables — Le routage basé sur DNS garantit que les URL ne changent jamais pendant la mise à l'échelle
- Reconnexion des workers AI — Migration basée sur des checkpoints avec un écart d'environ 3 secondes et zéro perte d'images
- 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 l'état des serveurs et les mappages de stream
- Surveillance de l'état de santé — Vérifications actives avec récupération automatique
- Optimisation des coûts — Réduction automatique de l'échelle pendant les périodes de faible demande
Résultats
Stack Technologique
caseStudyDetail.more Études de Cas
Découvrez plus de nos implémentations techniques
Traitement de factures assisté par l'IA avec OCR et intégration QuickBooks
Une entreprise de taille moyenne, traitant des centaines de factures fournisseurs chaque mois, devait éliminer la saisie manuelle des données en extrayant automatiquement les données des factures à l'aide de l'IA/OCR et en les synchronisant directement dans QuickBooks pour la tenue de livres et le suivi des paiements.
Insertion d'annonces côté client (CSAI) avec analyse des marqueurs SCTE-35 et intégration de lecteurs multiplateformes
Une plateforme de streaming vidéo devait implémenter l'insertion d'annonces côté client (CSAI) sur les applications web, mobiles et de télévision connectée — permettant des expériences publicitaires personnalisées au niveau de l'appareil avec un support complet d'interaction publicitaire (superpositions cliquables, bannières complémentaires, boutons de saut) que l'insertion côté serveur ne peut pas offrir.
Prêt à Transformer Votre Entreprise ?
Discutons de la façon dont nous pouvons appliquer des solutions similaires à vos défis.