Prácticas recomendadas para cargas de trabajo de medios

Cloud Storage te permite almacenar y entregar recursos de audio y video, a la vez que optimizas el rendimiento de la transmisión, minimizas la latencia de reproducción y administras los costos. Para admitir flujos de trabajo de contenido multimedia, puedes integrar Cloud Storage con productos deGoogle Cloud , como Media CDN, la API de Live Stream, la API de Transcoder y la API de Video Stitcher. En este documento, se describen las prácticas recomendadas para usar Cloud Storage en cargas de trabajo de contenido multimedia.

Descripción general de las cargas de trabajo de contenido multimedia

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 un uso intensivo de procesamiento y, a menudo, usan GPU 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 escalar 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 final.
  • Administración de recursos multimedia: Incluye la organización de tus recursos 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 de transmisión en vivo. Durante el VOD, cuando los usuarios solicitan contenido que no está almacenado en caché en la red de distribución de contenidos (CDN), el contenido se recupera de los buckets de Cloud Storage. En el caso de 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 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 en las mismas regiones dobles que los recursos de procesamiento. Este método ayuda a optimizar el rendimiento, ya que reduce las latencias de lectura y escritura de 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 de los buckets.

Clase de almacenamiento

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

  • Para administrar recursos 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 necesidades de disponibilidad o acceso distintas.
  • Para las cargas de trabajo de producción de contenido multimedia y entrega de contenido, ya que los datos se leen con frecuencia desde un bucket de Cloud Storage, debes almacenarlos 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 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, lo que incluye establecer un tiempo de actividad (TTL) para los objetos, conservar las versiones no actuales de los objetos y cambiar a una versión inferior las clases de almacenamiento de los objetos para ayudar a administrar los costos.

Cuando los patrones de acceso a los datos son predecibles, puedes establecer la configuración del ciclo de vida de un bucket. En el caso de patrones de acceso desconocidos o impredecibles para tus datos, puedes configurar 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

Para las cargas de trabajo de VOD y de transmisión en vivo, el objetivo es evitar cualquier error de reproducción, retraso 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 escalamiento de las lecturas para dar cuenta de una gran cantidad de usuarios simultáneos. En todos los casos, las lecturas del tráfico de los 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

Usar una red de distribución de contenidos (CDN) frente al bucket de Cloud Storage mejora la experiencia del usuario final, ya que la CDN almacena en caché el contenido, lo que reduce la latencia y aumenta la eficiencia del ancho de banda. Una CDN te permite reducir el costo total de propiedad (TCO) disminuyendo los costos de ancho de banda, optimizando el uso de recursos y mejorando el 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 para que funcione como la fuente de otras CDN de terceros. Con otras CDN, aún obtienes una 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 varias 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 establece una CDN:

Selecciona la ubicación de la protección del origen

La ubicación de Origin Shield es una caché entre la CDN y Cloud Storage. Si tu CDN te permite seleccionar la ubicación de Origin Shield, sigue los lineamientos de la CDN para saber si se recomienda elegir Origin Shield para que esté más cerca de la región de tu bucket de Cloud Storage o de la ubicación de concentración del tráfico de los usuarios finales. Un escudo de origen es una medida de protección que evita que tu servidor de origen se sobrecargue. Las CDN con protección de origen ayudan a aumentar la transferencia 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 diseñada para minimizar el llenado de caché de forma activa siempre que sea posible.

Habilita la combinación de solicitudes

Asegúrate de que la contracción de solicitudes esté habilitada para tu CDN. Contraer varias solicitudes en una sola reduce el costo operativo 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 contraer varias solicitudes de usuarios finales en una sola solicitud al origen. Por ejemplo, Media CDN contrae 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 que se realizan 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 realizar 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 reintentar 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 se almacenan en caché en la CDN, como la entrega de contenido y la distribución de un contenido de tipo VoD, ten en cuenta los siguientes factores cuando selecciones una ubicación para tu bucket:

  • Para optimizar el costo, los buckets creados en una sola región tienen el costo de almacenamiento más bajo.
  • Para optimizar la disponibilidad, ten en cuenta lo siguiente:
    • Para la mayoría de las cargas de trabajo de contenido multimedia, se recomienda usar buckets birregionales, ya que replican tus objetos en dos regiones para obtener una mejor disponibilidad.
    • En los casos de uso que requieren entrega de contenido y análisis con redundancia geográfica, usa buckets multirregión para obtener la mayor disponibilidad.
  • Para optimizar la latencia y reducir los costos de red, ten en cuenta lo siguiente:
    • Para el VOD, elige las regiones más cercanas a donde se encuentran la mayoría de tus usuarios finales o la región con la mayor concentración de tráfico.
    • Durante la transmisión en vivo, los buckets reciben solicitudes de escritura de los transcodificadores y solicitudes de lectura de una CDN que almacena en caché y distribuye el contenido a los usuarios finales. Para mejorar el rendimiento de la transmisión, elige buckets regionales que se encuentren en la misma ubicación que los recursos de procesamiento que se usan para la transcodificación.

Optimiza la duración de los segmentos 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 se refieren 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 uses un tamaño de segmento de video más largo.

Para brindarles a los usuarios la mejor experiencia, se recomienda usar la estrategia de reintentos y la cobertura de solicitudes para las escrituras en los transcodificadores con el objetivo de mitigar las latencias de cola larga de más de dos segundos para las escrituras en Cloud Storage y experimentar con tiempos de margen entre citas más largos de aproximadamente diez segundos.

Aumenta las QPS de forma gradual

Los buckets de Cloud Storage tienen una capacidad de E/S inicial de 1,000 operaciones de escritura de objetos por segundo y 5,000 operaciones de lectura de objetos por segundo. Para las cargas de trabajo de transmisión en vivo, el lineamiento es escalar tus solicitudes de forma gradual, comenzando con 1,000 escrituras por segundo y 5,000 lecturas por segundo, y duplicar de forma incremental el porcentaje de solicitudes cada 20 minutos. Este método permite que Cloud Storage redistribuya la carga entre 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 escalamiento en tu bucket, ya sea precalentándolo o habilitando el espacio de nombres jerárquico en él. Antes de implementar el escalamiento 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 mayor que la capacidad de IO inicial.

Supervisa las QPS y soluciona cualquier error de escalamiento

Debes supervisar las QPS y solucionar problemas de escalamiento. 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 Recuento total de solicitudes de lectura/lista/obtención y el gráfico Recuento total de solicitudes de escritura, respectivamente, en la consola deGoogle Cloud . Si escalas las QPS en los buckets más rápido que los lineamientos de aumento gradual especificados en la sección anterior, es posible que encuentres el error 429 Demasiadas solicitudes. Obtén información para resolver el error 429 Demasiadas solicitudes.

En las siguientes secciones, se describe cómo escalar tu bucket para obtener una mayor cantidad de QPS después de estimar las QPS para el origen.

Implementa el escalamiento de QPS en tu bucket con el precalentamiento

Puedes acelerar el proceso de escalamiento antes de un evento de transmisión en vivo precalentando tu bucket. Antes del evento de transmisión en vivo, genera tráfico sintético a tu bucket que coincida con el máximo de QPS que esperas que reciba el servidor de origen de la CDN para el evento, más 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 para tu origen son 10,000, tu tráfico simulado debería apuntar a 15,000 solicitudes por segundo para preparar tu origen para el evento.

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

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

El servidor de origen mantiene la capacidad hasta que el tráfico sea constante. La capacidad del servidor de origen disminuye de forma gradual hasta su nivel de referencia durante 24 horas. Si tu servidor de origen experimenta brechas 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 el espacio de nombres jerárquico habilitado proporcionan hasta ocho veces más 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 el espacio de nombres jerárquico habilitado, consulta Limitaciones.

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

Con el escalamiento de QPS, las solicitudes se redistribuyen entre varios servidores. Sin embargo, es posible que encuentres cuellos de botella de rendimiento cuando todos los objetos usen un prefijo no aleatorio o secuencial. Usar nombres completamente aleatorios en lugar de nombres secuenciales te brinda la mejor distribución de carga. Sin embargo, 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 con un valor de hash antes del número de secuencia o la marca de tiempo. Por ejemplo, si el nombre del objeto original que quieres 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 prefijo al nombre del objeto. El objeto nuevo 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 una mayor cantidad de QPS.

Usa buckets diferentes para cada transmisión en vivo

En el caso de las transmisiones en vivo simultáneas, usar buckets diferentes para cada transmisión en vivo te ayudará a escalar la carga de lectura y escritura de manera eficaz sin alcanzar los límites de E/S del bucket. El uso de diferentes buckets para cada transmisión en vivo disminuye las latencias de valores atípicos grandes debido a retrasos en el escalamiento.

¿Qué sigue?