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 medios. 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 medios:

  • Producción de medios: 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 el procesamiento de alto rendimiento. A menudo, las aplicaciones que se ejecutan en Compute Engine o Google Kubernetes Engine procesan los datos relacionados con los medios que residen en Cloud Storage, y el resultado de este proceso se vuelve a escribir en Cloud Storage. Estas cargas de trabajo requieren escalar el rendimiento agregado de lectura y escritura de Cloud Storage a un clúster de procesamiento con un menor tiempo de inactividad de la GPU. También requieren latencias de lectura y escritura bajas, ya que son fundamentales para reducir la latencia final.
  • Administración de recursos multimedia: Incluye la organización de tus recursos multimedia para un almacenamiento, recuperación y 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 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 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 desde la CDN de forma simultánea.

Prácticas recomendadas para cargas de trabajo de medios

Para conocer las prácticas recomendadas que se aplican a las cargas de trabajo de medios, 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 fluido de datos entre 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 medios, debes crear buckets en la misma región o en regiones duales 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 medios, la clase de almacenamiento que debes seleccionar varía. Los tipos de clases de almacenamiento recomendados para diferentes cargas de trabajo de medios 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.
  • Para las cargas de trabajo de producción de medios y entrega de contenido, como los datos se leen con frecuencia desde un bucket de Cloud Storage, debes almacenarlos en el almacenamiento estándar.

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 definir una configuración del ciclo de vida para administrar el ciclo de vida de los objetos de tus buckets. 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 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. Si los patrones de acceso a tus datos son 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 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 escala de las lecturas para tener en cuenta una gran cantidad de usuarios simultáneos. En todos los casos, el tráfico de los clientes debe 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) delante del 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é de 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 publicas contenido desde esta caché de Media CDN en lugar de hacerlo 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 Clouda 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 pueden configurar cuando se establece una CDN:

Selecciona la ubicación de la protección del 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 saber 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 del tráfico de usuarios finales. Un escudo de origen es una medida de protección que evita la sobrecarga del servidor de origen. 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 fusión de solicitudes

Asegúrate de que el CDN tenga habilitada la reducción de solicitudes. Contraer varias solicitudes en una sola reduce el costo de las operaciones 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 realizadas a los buckets.

Configura el comportamiento de reintento en la CDN

Asegúrate de configurar los reintentos 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 reintentar las solicitudes sin éxito 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 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 publicación de contenido y la distribución de contenido de tipo VOD, ten en cuenta los siguientes factores cuando selecciones una ubicación para tu bucket:

  • Para optimizar los costos, 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 medios, se recomienda usar buckets birregionales porque replican tus objetos en dos regiones para una mejor disponibilidad.
    • Para los casos de uso que requieren entrega de contenido y análisis con redundancia geográfica, usa buckets en varias regiones para obtener la mayor disponibilidad.
  • Para optimizar la latencia y reducir los costos de red, considera lo siguiente:
    • En el caso del VOD, elige las regiones más cercanas a 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

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 larga cola 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 reducción de riesgos de solicitudes para las escrituras en los transcodificadores, de modo que se mitiguen 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 el QPS de forma gradual

Los buckets de Cloud Storage tienen una capacidad de E/S inicial de 1,000 escrituras de objetos por segundo y 5,000 lecturas de objetos por segundo. En el caso de las cargas de trabajo de transmisión en vivo, el lineamiento es aumentar las solicitudes de forma gradual. Para ello, comienza con 1,000 escrituras por segundo y 5,000 lecturas por segundo, y duplica 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 probabilidades de que se produzcan problemas de reproducción.

Para un evento de transmisión en vivo con una mayor cantidad de QPS, debes implementar el escalamiento en tu bucket precalentándolo o habilitando el espacio de nombres jerárquico en él. Antes de implementar el ajuste de escala 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 un porcentaje de acierto de caché del 99.0%, el tráfico resultante a Cloud Storage será del 1%. Las QPS serán el 1% de la cantidad 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 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 Total read/list/get request count y Total write request count, respectivamente, en la consola deGoogle Cloud . Si ajustas la escala de las QPS en 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 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 mayor QPS después de haber estimado el QPS al origen.

Implementa el ajuste de QPS en tu bucket precalentándolo

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 el QPS máximo esperado que recibirá 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 de tu origen son de 10,000, tu tráfico simulado debería tener como objetivo 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 todo el proceso de calentamiento.

Cuando generes este tráfico simulado, sigue un enfoque de escalamiento gradual, comenzando con 5,000 solicitudes por segundo y aumentando progresivamente hasta alcanzar tu objetivo. Asigna tiempo suficiente antes del evento para alcanzar la carga estimada. Por ejemplo, alcanzar 15,000 solicitudes por segundo, duplicando la carga cada 20 minutos a partir de 5,000 solicitudes por segundo iniciales, 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 gradualmente hasta su nivel de referencia en un plazo de 24 horas. Si tu servidor de origen experimenta interrupciones de varias horas entre los eventos de la 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 una cantidad alta de QPS iniciales

Los buckets de Cloud Storage con el 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 el espacio de nombres jerárquico habilitado, consulta Limitaciones.

Evita usar nombres secuenciales para los segmentos de video y, así, escalar las QPS

Con el ajuste de QPS, las solicitudes se redistribuyen entre varios servidores. Sin embargo, es posible que encuentres cuellos de botella en el rendimiento cuando todos los objetos usan un prefijo no aleatorio o secuencial. Usar nombres completamente aleatorios en lugar de nombres secuenciales 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 agregando 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 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 el uso de nombres secuenciales para los segmentos de video, usa buckets con el espacio de nombres jerárquico habilitado para obtener una mayor cantidad de QPS.

Usa diferentes buckets para cada transmisión en vivo

En el caso de las transmisiones en vivo simultáneas, usar diferentes buckets para cada transmisión 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 atípicas grandes debido a las demoras en el escalamiento.

¿Qué sigue?