Diagrama de arquitectura de streaming de vídeo: subida, transcodificación, empaquetado y entrega

«Diseña YouTube» es una pregunta de diseño de sistemas muy querida porque las partes interesantes no están donde la gente espera. Los servidores web son normales. El trabajo difícil es mover gigabytes desde un móvil al almacenamiento de forma fiable, convertir una subida en una docena de versiones que se reproduzcan en cualquier dispositivo y conexión, y servir esos bytes desde un CDN para que tus propios servidores apenas los vean.

Este artículo recorre esa tubería en orden: subida, transcodificación, empaquetado y entrega. Termina con un diagrama de arquitectura que puedes adaptar y con las decisiones que vale la pena escribir en él.

Dos sistemas, no uno

Una plataforma de vídeo son dos sistemas que comparten una base de datos:

• Ingesta: los creadores suben; la plataforma transcodifica y empaqueta. La latencia se mide en minutos y a nadie le importa.
• Reproducción: los espectadores pulsan play; el primer fotograma tiene que aparecer en un par de segundos y no puede atascarse.

Dibújalos como dos carriles. Escalan con señales distintas (subidas por hora frente a espectadores simultáneos) y fallan de forma distinta.

Subida: nunca a través de tus servidores de API

Los archivos de vídeo son grandes y las conexiones móviles se cortan. De ahí salen dos reglas:

1. Sube directamente al almacenamiento de objetos. La API de subida autentica al creador, crea un registro del vídeo y devuelve URL prefirmadas. El cliente envía los bytes directamente al bucket. Tu API nunca hace de intermediaria de gigabytes.
2. Hazla reanudable. Usa subidas multiparte para que una conexión cortada solo reintente la parte fallida. La subida multiparte de Amazon S3, por ejemplo, sube las partes de forma independiente y las une cuando el cliente completa la subida.

Cuando la subida termina, el evento de almacenamiento (o la llamada de finalización del cliente) pone un trabajo de transcodificación en una cola.

Transcodificación: una subida, una escalera de bitrate adaptativo

Los reproductores cambian la calidad según el ancho de banda, así que codificas cada vídeo varias veces: una escalera de bitrate adaptativo (ABR). Una escalera típica va de unos 240p o 360p hasta 1080p o 4K, cada peldaño con su propio bitrate.

La transcodificación consume mucha CPU y se paraleliza con facilidad:

• Divide la fuente en fragmentos de pocos segundos, en los fotogramas clave.
• Codifica cada fragmento y cada versión como un trabajo independiente en una flota de workers, normalmente con FFmpeg.
• Une los resultados o mantenlos como segmentos.

Así, una película de dos horas se transcodifica en minutos en lugar de horas, y un trabajo fallido solo reintenta un fragmento. Haz los trabajos idempotentes identificándolos por vídeo, versión y fragmento, para que un reintento sobrescriba en lugar de duplicar.

Una sola escalera para todo el contenido desperdicia bits: una presentación de diapositivas estática necesita mucho menos bitrate que un partido de fútbol. Netflix popularizó la codificación por título, que elige la escalera de cada vídeo según su complejidad. Puedes empezar con una escalera fija y pasar a la codificación por título más adelante.

Empaquetado: HLS, DASH y CMAF

Los reproductores no descargan un archivo enorme. Leen un manifiesto que lista las versiones y los segmentos, y luego piden segmentos de pocos segundos por HTTP normal.

CMAF es la razón por la que importa el empaquetador: con él guardas un solo conjunto de segmentos y escribes dos manifiestos en lugar de dos copias de cada vídeo. Los segmentos cortos arrancan antes y cambian de calidad antes; los más largos cuestan menos peticiones. La especificación de creación de HLS de Apple da recomendaciones concretas sobre duración de segmentos, fotogramas clave y escaleras.

El contenido de pago añade DRM. El empaquetador cifra los segmentos una vez con cifrado común (CENC), y el sistema DRM de cada plataforma (Widevine, FairPlay, PlayReady) emite licencias a los reproductores a través de un servidor de licencias.

Entrega: el CDN hace el trabajo

Los segmentos son archivos estáticos, y esa es la clave: un CDN los guarda en caché cerca de los espectadores, y un vídeo popular se sirve casi por completo desde las cachés del borde. El origen es el bucket de versiones, a menudo detrás de un origin shield, para que un fallo de caché en 50 ubicaciones del borde se convierta en una sola petición al almacenamiento.

La API de reproducción sigue siendo pequeña: comprueba que el espectador puede ver el vídeo, devuelve una URL de manifiesto (firmada si el contenido es privado) y registra los eventos de reproducción para la analítica.

El directo es otra tubería

El vídeo en directo reutiliza el empaquetado y el CDN, pero sustituye la ingesta. Un codificador envía un flujo por un protocolo como RTMP o SRT a un servidor de ingesta, que transcodifica la escalera en tiempo real y escribe segmentos nuevos cada pocos segundos. La latencia viene de la duración del segmento más el búfer del reproductor; los modos de baja latencia de HLS y DASH entregan partes de un segmento antes de que esté completo para acercarse a unos pocos segundos. Mantén el directo y el vídeo bajo demanda como tuberías separadas que comparten el CDN, el reproductor y los metadatos.

El diagrama de arquitectura

Cómo leerlo:

• Carril superior, ingesta: el creador obtiene una URL de subida de la API de subida (1), sube las partes directamente al bucket de subidas en bruto (2) y la subida completada encola trabajos de transcodificación (3). Los workers codifican la escalera, y el empaquetador escribe los segmentos en el bucket de versiones y marca el vídeo como listo en el almacén de metadatos.
• Carril inferior, reproducción: el espectador pide a la API de reproducción una URL de manifiesto y luego recibe los segmentos desde el CDN. Un fallo de caché lee del bucket de versiones.
• El DRM es punteado porque solo lo necesita el contenido protegido: el reproductor pide una licencia al servidor de licencias.
• El bloque Markdown muestra una escalera de ejemplo. Tus cifras deberían salir de tu contenido y del ancho de banda de tus espectadores.

Qué poner en el diagrama

• Por dónde van los bytes. Dibuja las subidas y los segmentos yendo al almacenamiento y al CDN, no a través de tu API.
• La unidad de trabajo. «Un trabajo por versión y fragmento» explica a quien revisa cómo funcionan los reintentos y el paralelismo.
• Formatos y protección. Nombra HLS, DASH o CMAF, y el DRM si lo usas.
• La señal de listo. Un vídeo no se puede reproducir hasta que termina el empaquetado; muestra dónde vive ese estado.

La misma forma de cola y workers aparece en el artículo sobre arquitectura orientada a eventos. Para la parte de nube, el diagrama de arquitectura multirregión en AWS trata cómo servir desde más de una región, y el diagrama de arquitectura serverless muestra cómo los eventos de almacenamiento pueden disparar funciones en lugar de una flota de workers.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade dos nodos Persona del pack Modelo C4 para el creador y el espectador.
3. Añade nodos Contenedor para la API de subida, los workers de transcodificación, el empaquetador y la API de reproducción, y una Base de datos para los metadatos de vídeo.
4. Añade dos nodos Almacenamiento de objetos y un CDN del pack Nube, una Cola del pack Datos para los trabajos de transcodificación y un Sistema externo para el servidor de licencias DRM.
5. Dibuja la ingesta en el carril superior y la reproducción en el inferior, numera los pasos de subida en las aristas y añade un bloque Markdown del pack Básico con tu escalera.

El ejemplo usa 13 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué es una escalera de bitrate adaptativo? El conjunto de versiones en que se codifica un vídeo, cada una con su resolución y su bitrate. El reproductor elige la mejor que puede sostener la conexión del espectador y cambia a medida que varía el ancho de banda.

¿Debo usar HLS o DASH? A menudo los dos. Empaqueta una vez como segmentos CMAF y escribe un manifiesto HLS y otro DASH, así cubres los dispositivos Apple y el resto de reproductores sin guardar dos copias.

¿Por qué subir directamente al almacenamiento de objetos? Los archivos grandes que pasan por tus servidores de API ocupan conexiones y memoria, y una conexión cortada reinicia la subida. Las subidas multiparte prefirmadas van directas al almacenamiento y se reanudan parte a parte.

¿Cómo se paraleliza la transcodificación? Divide la fuente en fragmentos en los fotogramas clave y codifica cada fragmento y cada versión como un trabajo independiente; después une o empaqueta los resultados.

¿Necesito un CDN para vídeo? Para cualquier audiencia que no sea pequeña, sí. Los segmentos son archivos estáticos, y un CDN sirve las peticiones repetidas desde cachés cercanas a los espectadores en lugar de desde tu almacenamiento.

Empieza gratis — un puesto, sin tarjeta de crédito.