Prácticas recomendadas para cargas de trabajo de contenido multimedia

En esta página, se describen las prácticas recomendadas para usar Cloud Storage en cargas de trabajo de contenido multimedia. Estas cargas de trabajo suelen incluir varios Google Cloud productos, como la CDN de Media, la API de Live Stream, la API de Transcoder y laAPI 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 postproducción de películas, incluida la edición de video, que requieren mucho procesamiento y, a menudo, usan GPUs para el procesamiento 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 se encuentra 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 la 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 organizar tus recursos multimedia para un almacenamiento, una recuperación y un uso eficientes.
  • Publicación 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 la transmisión de video on demand (VoD), cuando los usuarios solicitan contenido que no está almacenado en caché en la red de distribución de contenido (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 de la CDN de forma simultánea.

Prácticas recomendadas para 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 problemas entre sistemas de almacenamiento de objetos y archivos. Para transferencias más pequeñas, elige el servicio para transferir datos desde y hacia Cloud Storage o entre sistemas de archivos según tu situación de transferencia.

Ubicación del bucket

En el caso de 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 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 la 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 multimedia, la clase de almacenamiento que debes seleccionar varía. 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 diferentes necesidades de disponibilidad o acceso.
  • En el caso de 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 almacenarlos en almacenamiento estándar.

Para obtener más orientación sobre cómo elegir la clase de almacenamiento de 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, retener versiones anteriores de los objetos y cambiar a una versión inferior de las clases de almacenamiento de objetos para facilitar la administración de costos.

Cuando los patrones de acceso a los datos son predecibles, puedes configurar el ciclo de vida de un bucket. Si tus datos tienen patrones de acceso desconocidos o impredecibles, 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 en frío.

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

En el caso de las cargas de trabajo de VoD y 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 escalamiento de las operaciones de lectura para tener en cuenta una gran cantidad de usuarios simultáneos. En todos los casos, las operaciones de lectura del tráfico del cliente deben pasar por una CDN.

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

Usa la CDN de manera eficaz

El uso de una red de distribución de contenido (CDN) frente al bucket de Cloud Storage mejora la experiencia del usuario final, ya que la CDN almacena en caché el contenido reduciendo la latencia y aumentando 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 la entrega de contenido a los usuarios finales, ya que el costo de llenado de caché de Media CDN es cero. Puedes usar Media CDN como fuente de otras CDN de terceros. Con otras CDN, aún obtienes una reducción del TCO cuando se entrega 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 debes configurar cuando configuras 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 para determinar 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 de los usuarios finales. Un escudo de origen es una medida protectora que protege tu servidor de origen de sobrecargas. Las CDN con protección de origen ayudan a aumentar la descarga del 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 fusión de solicitudes

Asegúrate de que el colapso de solicitudes esté habilitado para tu CDN. La contracción de varias solicitudes en una sola reduce el costo de operación de clase B de Cloud Storage. Las CDN tienen cachés distribuidas en todo el mundo, pero proporcionan una forma de contraer varias solicitudes del usuario final 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 la 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 que se vuelvan a realizar solicitudes al origen que no se completaron correctamente. 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 solicitudes de origen en Media CDN, consulta Reintenta las solicitudes de origen.

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

En el caso de las cargas de trabajo que leen datos de Cloud Storage que no están almacenados en caché en la CDN, como la distribución y la publicación de 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 mejorar la disponibilidad.
    • Para los casos de uso que requieren estadísticas y entrega de contenido con redundancia geográfica, usa buckets en varias regiones para obtener la mayor disponibilidad.
  • Para optimizar la latencia y reducir los costos de red, ten en cuenta lo siguiente:
    • Para VoD, elige las regiones más cercanas a la ubicación de la mayoría de tus usuarios finales o la región con la mayor concentración de tráfico.
    • Durante las transmisiones en vivo, los buckets reciben solicitudes de escritura de 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 los buckets regionales que se encuentran 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

En el caso de las transmisiones en vivo, el tamaño de segmento más bajo 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 demoradas 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 proporcionarles a los usuarios la mejor experiencia, se recomienda usar la estrategia de reintento y solicitar la cobertura para las operaciones de escritura en los transcodificadores para mitigar las latencias de cola larga de más de dos segundos para las operaciones de escritura en Cloud Storage y experimentar con tiempos de búfer más largos de aproximadamente diez segundos.

Aumenta el QPS de forma gradual

Los buckets de Cloud Storage tienen una capacidad inicial de E/S 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 transmisiones en vivo, el lineamiento es escalar tus solicitudes de forma gradual, comenzando con 1,000 operaciones de escritura por segundo y 5,000 operaciones de lectura por segundo, y duplicar de forma incremental el porcentaje 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 probabilidades 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. Para ello, preacondiciona tu bucket o habilita el espacio de nombres jerárquico en tu bucket. Antes de implementar el escalamiento en tu bucket, debes realizar las siguientes tareas:

Estima tu 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 aciertos en la 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 E/S inicial.

Supervisa el QPS y soluciona los errores de escalamiento

Debes supervisar las QPS y solucionar los errores 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 los gráficos Cantidad total de solicitudes de lectura, lista o obtención y Cantidad total de solicitudes de escritura, respectivamente, en la consola de Google Cloud. Si escalas el QPS en los buckets más rápido que los lineamientos de aumento especificados en la sección anterior, es posible que obtengas el error 429 Too many requests. Obtén más información para resolver el error 429 Demasiadas solicitudes.

En las siguientes secciones, se describe cómo escalar tu bucket para obtener un QPS más alto después de que hayas estimado el QPS en el origen.

Implementa el escalamiento de QPS en tu bucket calentándolo previamente

Puedes acelerar el proceso de escalamiento antes de un evento de transmisión en vivo si precalientas tu bucket. Antes del evento de transmisión en vivo, genera tráfico sintético en tu bucket que coincida con la QPS máxima esperada que el servidor de origen de la CDN recibirá en 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 de tu origen son 10,000, tu tráfico simulado debe orientarse a 15,000 solicitudes por segundo para preparar tu origen para el evento.

Para este tráfico simulado, puedes usar los archivos del 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 alcanzar tu objetivo. Asigna tiempo suficiente antes del evento para lograr la carga estimada. Por ejemplo, llegar a 15,000 solicitudes por segundo, duplicando la carga cada 20 minutos a partir de 5,000 solicitudes por segundo iniciales, llevará aproximadamente 30 minutos.

El servidor de origen mantiene la capacidad hasta que el tráfico es coherente. La capacidad del servidor de origen disminuye gradualmente a su nivel de referencia en un período de 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 el espacio de nombres jerárquico habilitado proporcionan hasta ocho veces la QPS inicial en comparación con los buckets sin el espacio de nombres jerárquico. 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 de los buckets con espacio de nombres jerárquico habilitado, consulta Limitaciones.

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

Con la escalamiento de QPS, las solicitudes se redistribuyen en 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 cargas. 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 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 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 los 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

En el caso de las transmisiones en vivo simultáneas, usar buckets diferentes para cada una 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 buckets diferentes para cada transmisión en vivo disminuye las latencias de valores atípicos grandes debido a las demoras en la escala.

¿Qué sigue?