Prácticas recomendadas para cargas de trabajo de medios

En esta página, se describen las prácticas recomendadas cuando se usa Cloud Storage para cargas de trabajo de contenido multimedia. Estas cargas de trabajo suelen incluir varios Google Cloud productos como Media CDN, la API de Live Stream, la API de Transcoder y la API de Video Stitcher.

Descripción general

Google Cloud ofrece soluciones para optimizar los siguientes tipos de cargas de trabajo de contenido multimedia:

  • Producción de contenido multimedia: Incluye cargas de trabajo como la posproducción de películas, incluida la edición de video, que requieren mucha capacidad de procesamiento y, a menudo, usan GPUs para la computación de alto rendimiento. A menudo, las aplicaciones que se ejecutan en Compute Engine o Google Kubernetes Engine procesan los datos relacionados con el contenido multimedia que residen en Cloud Storage, y el resultado de este proceso se vuelve a escribir en Cloud Storage. Estas cargas de trabajo requieren el ajuste de la capacidad de procesamiento de lectura y escritura agregada de Cloud Storage a un clúster de procesamiento con un tiempo de inactividad de GPU más bajo. También requieren latencias de lectura y escritura bajas, ya que es fundamental para reducir la latencia de cola.
  • Administración de recursos de contenido multimedia: Incluye la organización de tus recursos de contenido multimedia para un almacenamiento, una recuperación y un uso eficientes.
  • Entrega y distribución de contenido: Incluye la transmisión de contenido multimedia a los usuarios, incluidos los servicios de video on demand (VoD) y transmisión en vivo. Durante el VoD, cuando los usuarios solicitan contenido que no está almacenado en caché en la red de entrega de contenido (CDN), el contenido se recupera de los buckets de Cloud Storage. Para las solicitudes de transmisión en vivo, el contenido se escribe en el bucket de Storage y se lee desde la CDN de forma simultánea.

Prácticas recomendadas para las cargas de trabajo de contenido multimedia

Para conocer las prácticas recomendadas que se aplican a las cargas de trabajo de contenido multimedia, consulta las siguientes secciones.

Transferencia de datos

Usa el Servicio de transferencia de almacenamiento para subir más de 1 TiB de archivos de contenido multimedia sin procesar desde una fuente local, como una cámara de video o un almacenamiento local, a Cloud Storage. El Servicio de transferencia de almacenamiento permite el movimiento de datos sin interrupciones entre los sistemas de almacenamiento de objetos y archivos. Para transferencias más pequeñas, elige el servicio para transferir datos hacia y desde Cloud Storage o entre sistemas de archivos según tu situación de transferencia.

Ubicación del bucket

Para las cargas de trabajo que requieren recursos de procesamiento, como la producción de contenido multimedia, debes crear buckets en la misma región o regiones dobles que los recursos de procesamiento. Este método ayuda a optimizar el rendimiento, ya que reduce las latencias de lectura y escritura para tus cargas de trabajo de procesamiento, el costo y el ancho de banda. Para obtener más orientación sobre cómo elegir la ubicación del bucket, consulta Consideraciones sobre la ubicación del bucket.

Clase de almacenamiento

Según el tipo de carga de trabajo de contenido multimedia, la clase de almacenamiento que debes seleccionar difiere. Los tipos de clase de almacenamiento recomendados para diferentes cargas de trabajo de contenido multimedia son los siguientes:

  • Para administrar recursos de contenido multimedia, como videos de archivo, la clase de almacenamiento predeterminada de un bucket debe ser Archive Storage. Puedes especificar una clase de almacenamiento diferente para los objetos que tienen diferentes necesidades de disponibilidad o acceso.
  • Para las cargas de trabajo de producción de contenido multimedia y entrega de contenido, como los datos se leen con frecuencia desde un bucket de Cloud Storage, debes almacenar los datos en Standard Storage.

Para obtener más orientación sobre cómo elegir la clase de almacenamiento para tu bucket, consulta Clase de almacenamiento.

Administración del ciclo de vida de los datos

Para administrar tus recursos de contenido multimedia, debes administrar el ciclo de vida de los objetos de tus buckets definiendo una configuración del ciclo de vida. Con la función Administración del ciclo de vida de los objetos, puedes administrar el ciclo de vida de los datos, incluido el establecimiento de un tiempo de actividad (TTL) para los objetos, la retención de versiones anteriores de objetos y el cambio a una versión anterior de las clases de almacenamiento de objetos para facilitar la administración de los costos.

Cuando los patrones de acceso a los datos son predecibles, puedes establecer la configuración del ciclo de vida para un bucket. Para patrones de acceso desconocidos o impredecibles para tus datos, puedes establecer la función Autoclass para tu bucket. Con Autoclass, Cloud Storage mueve automáticamente los datos a los que no se accede con frecuencia a clases de almacenamiento más frías.

Prácticas recomendadas para las cargas de trabajo de entrega y distribución de contenido

Tanto para las cargas de trabajo de VoD como para las de transmisión en vivo, el objetivo es evitar errores de reproducción, retrasos en el inicio de la reproducción o almacenamiento en búfer mientras se reproduce un video en el reproductor de video de los usuarios finales. Estas cargas de trabajo también requieren el ajuste de las lecturas para tener en cuenta una gran cantidad de usuarios simultáneos. En todos los casos, las lecturas de tráfico de clientes deben pasar por una CDN.

Para conocer las prácticas recomendadas que se aplican a las cargas de trabajo de entrega y distribución de contenido, consulta las siguientes secciones.

Usa la CDN de manera eficaz

El uso de una red de entrega de contenido (CDN) frente al bucket de Cloud Storage mejora la experiencia del usuario final, ya que la CDN almacena contenido en caché, lo que reduce la latencia y aumenta la eficiencia del ancho de banda. Una CDN te permite reducir el costo total de propiedad (TCO) mediante la reducción de los costos de ancho de banda, la optimización del uso de los recursos y la mejora del rendimiento. El uso de Media CDN ayuda a reducir el TCO para entregar el contenido a los usuarios finales, ya que el costo de llenado de caché para Media CDN es cero. Puedes usar Media CDN como fuente de otras CDN de terceros. Con otras CDN, aún obtienes cierta reducción del TCO cuando entregas contenido desde esta caché de Media CDN en lugar de desde el origen.

Si usas una CDN de terceros, CDN Interconnect permite que los proveedores seleccionados establezcan vínculos de intercambio de tráfico directo con la red perimetral de Google en diferentes ubicaciones. El tráfico de red que sale de Google Cloud a través de uno de estos vínculos se beneficia de la conectividad directa con los proveedores de CDN compatibles y se factura automáticamente con precios reducidos. Para obtener una lista de los proveedores aprobados, consulta Proveedores de servicios aprobados por Google.

A continuación, se enumeran las opciones que se deben configurar cuando se configura una CDN:

Selecciona la ubicación del escudo de origen

La ubicación del escudo de origen es una caché entre la CDN y Cloud Storage. Si tu CDN te permite seleccionar la ubicación del escudo de origen, sigue los lineamientos de la CDN sobre si se recomienda elegir el escudo de origen para que esté más cerca de la región de tu bucket de Cloud Storage o de la ubicación de concentración de tráfico del usuario final. Un escudo de origen es una medida de protección que protege tu servidor de origen de la sobrecarga. Las CDN con protección de origen ayudan a aumentar la descarga de origen agregando una caché adicional entre el origen y la CDN. Por ejemplo, Media CDN proporciona una infraestructura de perímetro con muchos niveles que está diseñada para minimizar el llenado de caché de forma activa siempre que sea posible.

Habilita la fusión de solicitudes

Asegúrate de que la reducción de solicitudes esté habilitada para tu CDN. La reducción de varias solicitudes en una sola reduce el costo de la operación de clase B de Cloud Storage. Las CDN tienen cachés distribuidas implementadas en todo el mundo, pero proporcionan una forma de reducir varias solicitudes de usuarios finales en una sola solicitud al origen. Por ejemplo, Media CDN reduce de forma activa varias solicitudes de llenado de caché generadas por el usuario para la misma clave de caché en una sola solicitud de origen por nodo perimetral, lo que reduce la cantidad de solicitudes realizadas a los buckets.

Configura el comportamiento de reintento en la CDN

Asegúrate de configurar el reintento para cualquier problema del servidor con el código de respuesta HTTP 5xx (502, 503, 504) en tu CDN. Las CDN admiten reintentos de origen, lo que permite volver a intentar las solicitudes fallidas al origen. La mayoría de las CDN te permiten especificar la cantidad de reintentos para el origen actual. Para obtener información sobre cómo volver a intentar las solicitudes de origen en Media CDN, consulta Reintenta las solicitudes de origen.

Opciones de ubicación para la distribución de contenido

Para las cargas de trabajo que leen datos de Cloud Storage que no están almacenados en caché en la CDN, como la entrega y distribución de contenido de tipo VoD, ten en cuenta los siguientes factores cuando selecciones una ubicación para tu bucket:

Optimiza la longitud del segmento de video para las transmisiones en vivo

Para las transmisiones en vivo, el tamaño de segmento mínimo recomendado es de dos segundos, ya que los segmentos de video cortos son más sensibles a las latencias de escritura de cola larga. Las latencias de escritura de cola larga hacen referencia a las operaciones de escritura lentas o retrasadas para el contenido al que se accede con poca frecuencia o que tiene un volumen bajo de solicitudes.

La distancia física entre la ubicación del bucket y la ubicación de reproducción de los usuarios finales afecta el tiempo de transmisión. Si tus usuarios finales están lejos de la ubicación del bucket, te recomendamos que tengas un tamaño de segmento de video más largo.

Para brindar a los usuarios la mejor experiencia, se recomienda usar la estrategia de reintento y la cobertura de solicitudes para las escrituras en los transcodificadores para mitigar las latencias de cola larga de más de dos segundos para las escrituras en Cloud Storage y experimentar con tiempos de búfer más largos de aproximadamente diez segundos.

Aumenta las QPS de forma gradual

Los buckets de Cloud Storage tienen una capacidad de IO inicial de 1,000 escrituras de objetos por segundo y 5,000 lecturas de objetos por segundo. Para las cargas de trabajo de transmisión en vivo, el lineamiento es ajustar tus solicitudes de forma gradual comenzando con 1,000 escrituras por segundo y 5,000 lecturas por segundo, y duplicando de forma incremental la tasa de solicitudes cada 20 minutos. Este método permite que Cloud Storage redistribuya la carga en varios servidores y mejora la disponibilidad y la latencia de tu bucket, ya que reduce las posibilidades de que se produzcan problemas de reproducción.

Para un evento de transmisión en vivo con QPS más altas, debes implementar el ajuste en tu bucket, ya sea calentando previamente el bucket o habilitando el espacio de nombres jerárquico en tu bucket. Antes de implementar el ajuste en tu bucket, debes realizar las siguientes tareas:

Estima tus QPS al origen

Supongamos que, para una transmisión en vivo con un millón de usuarios, la CDN recibirá un millón de QPS. Si suponemos que tu CDN tiene una tasa de acierto de caché del 99.0%, el tráfico resultante a Cloud Storage será del 1%. Las QPS serán el 1% del total de usuarios (un millón), lo que equivale a 10,000 QPS. Este valor es más que la capacidad de IO inicial.

Supervisa las QPS y soluciona cualquier error de ajuste

Debes supervisar las QPS y solucionar cualquier error de ajuste. Para obtener más información, consulta Descripción general de la supervisión en Cloud Storage . Para supervisar las solicitudes de lectura y escritura, observa el gráfico Total read/list/get request count y el gráfico Total write request count , respectivamente, en la Google Cloud consola. Si ajustas las QPS en los buckets más rápido que los lineamientos de aumento especificados que se mencionan en la sección anterior, es posible que encuentres el error 429 Too many requests. Obtén información para resolver el error 429 Too many requests.

En las siguientes secciones, se describe cómo ajustar tu bucket para obtener QPS más altas después de haber estimado las QPS al origen.

Implementa el ajuste de QPS en tu bucket calentando previamente el bucket

Puedes acelerar el proceso de ajuste antes de un evento de transmisión en vivo calentando previamente tu bucket. Antes del evento de transmisión en vivo, genera tráfico sintético a tu bucket que coincida con las QPS máximas esperadas que esperas que reciba el servidor de origen de la CDN para el evento, además de un búfer adicional del 50% que tenga en cuenta la tasa de aciertos de caché esperada de tu CDN. Por ejemplo, si estimaste que las QPS a tu origen son de 10,000, tu tráfico simulado debería orientarse a 15,000 solicitudes por segundo para preparar tu origen para el evento.

Para este tráfico simulado, puedes usar los archivos de transmisión en vivo del evento anterior, como segmentos y manifiestos, o archivos de prueba. Asegúrate de tener archivos distintos durante todo el proceso de calentamiento.

Cuando generes este tráfico simulado, sigue un enfoque de ajuste gradual, comenzando con 5,000 solicitudes por segundo y aumentando de forma progresiva hasta alcanzar tu objetivo. Asigna tiempo suficiente antes del evento para alcanzar la carga estimada. Por ejemplo, alcanzar 15,000 solicitudes por segundo, duplicar la carga cada 20 minutos desde una solicitud inicial de 5,000 por segundo, tardará aproximadamente 30 minutos.

El servidor de origen mantiene la capacidad hasta que el tráfico sea coherente. La capacidad del servidor de origen disminuye de forma gradual a su nivel de referencia durante 24 horas. Si tu servidor de origen experimenta intervalos de varias horas entre los eventos de transmisión en vivo, te recomendamos que simules el tráfico antes de cada evento.

Usa buckets con espacio de nombres jerárquico habilitado para obtener QPS iniciales altas

Los buckets de Cloud Storage con espacio de nombres jerárquico habilitado proporcionan hasta ocho veces las QPS iniciales en comparación con los buckets sin HNS. Las QPS iniciales más altas hacen que sea más fácil escalar cargas de trabajo con una gran cantidad de datos y proporcionan una capacidad de procesamiento mejorada. Para obtener información sobre las limitaciones en los buckets con espacio de nombres jerárquico habilitado, consulta Limitaciones.

Evita los nombres secuenciales para los segmentos de video para ajustar las QPS

Con el ajuste de QPS, las solicitudes se redistribuyen en varios servidores. Sin embargo, es posible que encuentres cuellos de botella de rendimiento cuando todos los objetos usan un prefijo no aleatorio o secuencial. Usar nombres completamente aleatorios en lugar de nombres secuenciales te brinda la mejor distribución de cargas. Si deseas usar números secuenciales o marcas de tiempo como parte de los nombres de tus objetos, haz aleatorios los nombres de los objetos mediante un valor de hash antes del número de secuencia o la marca de tiempo. Por ejemplo, si el nombre del objeto original que deseas usar es my-bucket/2016-05-10-12-00-00/file1, puedes calcular el hash MD5 del nombre del objeto original y agregar los primeros seis caracteres del hash como un prefijo al nombre del objeto. El nuevo objeto se convierte en my-bucket/2fa764-2016-05-10-12-00-00/file1. Para obtener más información, consulta Usa una convención de nombres que distribuya las cargas de manera uniforme entre los rangos de claves. Si no puedes evitar la asignación de nombres secuenciales para los segmentos de video, usa buckets con espacio de nombres jerárquico habilitado para obtener QPS más altas.

Usa buckets diferentes para cada transmisión en vivo

Para las transmisiones en vivo simultáneas, usar buckets diferentes para cada transmisión en vivo te ayudará a ajustar la carga de lectura y escritura de manera eficaz sin alcanzar los límites de IO del bucket. El uso de buckets diferentes para cada transmisión en vivo disminuye las latencias atípicas grandes debido a los retrasos en el ajuste.

¿Qué sigue?