Gestion à chaud : Modifier les flux live sans interruption

Ajoutez, supprimez et modifiez les sorties sur des routes de streaming en direct sans aucune perturbation. Le fonctionnement de Vajra Cast.

Qu’est-ce que la gestion à chaud ?

La gestion à chaud est la capacité de modifier une route de streaming en direct — ajouter des sorties, en supprimer, changer de destinations, activer ou désactiver des connexions — sans interrompre le flux ni affecter les autres sorties de la même route. Le flux continue de circuler vers toutes les destinations non affectées pendant que vous effectuez vos modifications.

Cela semble être une fonctionnalité de base. Ce n’en est pas une. La plupart des serveurs de streaming nécessitent un rechargement de configuration, un redémarrage de l’application ou une reconstruction complète de la route pour changer les destinations de sortie. Pendant ce redémarrage, chaque sortie de la route est coupée pendant quelques secondes. Pour un serveur gérant 20 routes avec 5 sorties chacune, un redémarrage pour modifier une seule sortie affecte 100 flux.

Vajra Cast a été conçu dès le départ pour supporter la gestion à chaud sur chaque opération de route.

Pourquoi la gestion à chaud est essentielle

La réalité de la production live

Pendant une diffusion en direct, les besoins changent constamment :

  • Un sponsor demande son propre flux dédié 5 minutes avant l’antenne
  • Un réseau social doit être ajouté en cours d’émission
  • Une sortie dysfonctionne et doit être supprimée
  • Un point d’entrée CDN doit être remplacé par une autre région
  • Une sortie de test utilisée pendant la répétition doit être nettoyée
  • Une destination d’enregistrement de secours doit être ajoutée par précaution

Sans gestion à chaud, chacune de ces modifications nécessite d’arrêter la route, de modifier la configuration et de redémarrer. Pendant le redémarrage, toutes les sorties sont coupées. En production live, c’est inacceptable.

Avec la gestion à chaud, chaque modification est atomique : elle n’affecte que la sortie spécifique en cours de modification. Toutes les autres sorties continuent sans interruption.

Environnements multi-locataires

Pour les plateformes faisant transiter plusieurs flux clients par une seule instance Vajra Cast (voir streaming OTT), la gestion à chaud est indispensable. Ajouter une sortie pour le Client A ne doit pas affecter les flux du Client B. Sans gestion à chaud, un rechargement de configuration pour un client interromprait momentanément tous les clients.

Opérations supportées

Ajouter une sortie

Ajoutez une nouvelle sortie à une route en cours d’exécution. Le flux existant est immédiatement distribué vers la nouvelle destination en parallèle de toutes les sorties actuelles.

Cas d’usage :

  • Ajouter une plateforme de réseau social pendant un événement live
  • Ajouter une destination d’enregistrement de secours
  • Ajouter un tap de monitoring pour la vérification de qualité

La nouvelle sortie se connecte et commence à recevoir le flux en quelques secondes. Les autres sorties ne sont pas affectées.

Supprimer une sortie

Supprimez une sortie d’une route en cours d’exécution. La connexion vers cette destination est fermée proprement, et toutes les autres sorties continuent sans interruption.

Cas d’usage :

  • Supprimer une sortie de test après la répétition
  • Déconnecter une destination en échec pour nettoyer les logs d’erreur
  • Retirer un flux temporaire à la fin d’un segment d’événement

Activer / Désactiver une sortie

Basculez une sortie entre activée et désactivée sans la supprimer de la configuration de la route. Une sortie désactivée conserve ses paramètres mais arrête d’envoyer des données. La réactiver reprend le flux.

Cas d’usage :

  • Pré-configurer les sorties avant une diffusion et les activer au moment du lancement
  • Mettre temporairement en pause une sortie pendant la reconfiguration de la destination
  • Désactiver une sortie pendant une coupure publicitaire et la réactiver pour le segment suivant

Déplacer une sortie

Changez la destination d’une sortie. L’ancienne connexion est fermée et une nouvelle connexion est établie vers la nouvelle destination. Les autres sorties ne sont pas affectées.

Cas d’usage :

  • Basculer un endpoint CDN d’une région à une autre
  • Rediriger un flux d’un serveur de test vers le serveur de production
  • Déplacer une sortie RTMP d’une plateforme vers une autre

Modifier les paramètres d’une sortie

Changez les paramètres spécifiques au protocole d’une sortie (débit, chiffrement, latence) sans la supprimer et la recréer.

Cas d’usage :

  • Ajuster la latence SRT en réponse à l’évolution des conditions réseau
  • Mettre à jour une clé de flux RTMP pour une plateforme qui change ses clés régulièrement
  • Modifier la durée des segments HLS en fonction des retours des spectateurs

Comment ça fonctionne en interne

L’architecture de Vajra Cast rend la gestion à chaud possible grâce à sa conception de routage interne :

Multicast interne zero-copy

Quand un flux est ingéré, Vajra Cast crée une représentation interne que plusieurs sorties peuvent lire simultanément. Cette couche de multicast interne est la clé de la gestion à chaud :

Ingest --> Tampon interne (mémoire partagée)
              |
              |--> Sortie 1 (SRT) : lit depuis le tampon
              |--> Sortie 2 (RTMP) : lit depuis le tampon
              |--> Sortie 3 (HLS) : lit depuis le tampon
              |
              |--> [Nouvelle Sortie 4] : se connecte au tampon (ajoutée à chaud)

Ajouter une nouvelle sortie signifie créer un nouveau lecteur sur le tampon existant. Supprimer une sortie signifie fermer un lecteur. Aucune de ces opérations n’affecte le tampon ni les autres lecteurs.

Isolation des processus

Chaque sortie s’exécute comme un processus ou thread indépendant. Cela signifie :

  • Une sortie en échec n’affecte pas les autres sorties
  • Ajouter une sortie démarre un nouveau processus
  • Supprimer une sortie ne termine que ce processus
  • Aucun état partagé entre les sorties ne peut provoquer de défaillances en cascade

Opérations pilotées par API

Toutes les opérations de gestion à chaud sont disponibles via l’API REST :

# Ajouter une sortie à la route "abc123"
POST /api/routes/abc123/outputs
{
  "protocol": "rtmp",
  "url": "rtmp://live.twitch.tv/app/stream-key"
}

# Désactiver une sortie
PATCH /api/routes/abc123/outputs/output-5
{
  "enabled": false
}

# Supprimer une sortie
DELETE /api/routes/abc123/outputs/output-5

Les mêmes opérations sont disponibles via le tableau de bord web avec une interface visuelle.

Gestion à chaud et failover

La gestion à chaud s’applique également aux chaînes de failover d’entrée. Pendant un flux en direct, vous pouvez :

  • Ajouter une entrée de secours pour renforcer la chaîne de failover
  • Supprimer une entrée dégradée qui provoque des basculements inutiles
  • Reprioriser les entrées en modifiant l’ordre de failover
  • Remplacer une entrée en panne par une nouvelle source sans reconstruire la route

C’est particulièrement précieux pour les événements en direct où les conditions réseau changent et les sources de secours doivent être ajustées en temps réel.

Scénarios pratiques

Scénario 1 : Ajouter une plateforme en cours de diffusion

Votre diffusion en direct envoie vers YouTube et votre site web. L’équipe marketing vous demande d’ajouter Twitch et Facebook en milieu d’émission.

Sans gestion à chaud : Arrêter la route, ajouter les sorties, redémarrer. YouTube et le site web sont coupés pendant 3-5 secondes. Les spectateurs voient du buffering.

Avec gestion à chaud : Ajoutez les sorties Twitch et Facebook depuis le tableau de bord. Les flux YouTube et site web ne sont pas affectés. Twitch et Facebook commencent à recevoir le flux en quelques secondes.

Scénario 2 : Failover CDN

Votre CDN principal rencontre des problèmes de latence. Vous devez basculer vers le CDN de secours.

Sans gestion à chaud : Arrêter la route, changer l’endpoint CDN, redémarrer. Tous les spectateurs sont déconnectés pendant le basculement.

Avec gestion à chaud : Ajoutez le CDN de secours comme nouvelle sortie (il commence à recevoir immédiatement). Vérifiez qu’il fonctionne. Désactivez ou supprimez la sortie CDN principal. Impact total pour les spectateurs : zéro.

Scénario 3 : Scaling pendant un événement viral

Votre flux reçoit soudainement 10 fois le trafic prévu. Vous devez ajouter des endpoints CDN dans des régions supplémentaires.

Sans gestion à chaud : Chaque nouvel endpoint CDN nécessite un redémarrage, perturbant les spectateurs existants.

Avec gestion à chaud : Ajoutez chaque nouvel endpoint CDN comme sortie. Chacun se connecte indépendamment sans affecter les sorties existantes. Scalez selon vos besoins, en temps réel.

Scénario 4 : Remplacement d’entrée en urgence

Pendant une diffusion en direct, votre encodeur principal développe des problèmes. Un technicien a mis en ligne un encodeur de remplacement mais avec une adresse IP différente.

Sans gestion à chaud : Modifier la configuration d’ingest, redémarrer la route. Toutes les sorties sont coupées.

Avec gestion à chaud : Ajoutez le nouvel encodeur comme entrée de secours. Une fois vérifié, promouvez-le en entrée principale. Supprimez l’ancienne entrée. La transition est fluide et contrôlée, et les sorties restent ininterrompues tout au long de l’opération.

Suivi des modifications à chaud

Chaque opération de gestion à chaud est :

  • Journalisée avec horodatage, identification de l’opérateur et modification spécifique effectuée
  • Reflétée en temps réel dans le tableau de bord (les nouvelles sorties apparaissent immédiatement, les sorties supprimées disparaissent)
  • Exportée comme métriques vers Prometheus (changements du nombre de sorties, événements de connexion)
  • Disponible via API pour l’intégration avec vos outils d’exploitation

Cette trace d’audit est essentielle pour la revue post-événement et le dépannage.

Prochaines étapes

← Retour au guide principal