Prácticas recomendadas para cargas de trabajo multimedia

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

Información general

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

  • Producción de contenido multimedia: incluye cargas de trabajo como la posproducción de películas, incluida la edición de vídeo, que requieren muchos recursos informáticos y suelen usar GPUs para la informática de alto rendimiento. A menudo, las aplicaciones que se ejecutan en Compute Engine o Google Kubernetes Engine procesan los datos relacionados con contenido multimedia que se encuentran en Cloud Storage, y el resultado de este proceso se vuelve a escribir en Cloud Storage. Estas cargas de trabajo requieren escalar el rendimiento de lectura y escritura agregados de Cloud Storage a un clúster de computación 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.
  • Gestión de recursos multimedia: incluye la organización de tus recursos multimedia para que se puedan almacenar, recuperar y usar de forma eficiente.
  • Servicio y distribución de contenido: incluye la emisión de contenido multimedia a los usuarios, incluidos los servicios de vídeo bajo demanda y de emisión en directo. Durante el vídeo bajo demanda, cuando los usuarios solicitan contenido que no está almacenado en la caché de la red de distribución de contenido (CDN), el contenido se obtiene de los cubos de Cloud Storage. En el caso de las solicitudes de emisión en directo, el contenido se escribe en el bucket de Storage y se lee de la CDN simultáneamente.

Prácticas recomendadas para cargas de trabajo multimedia

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

Transferencia de datos

Usa Storage Transfer Service para subir más de 1 TiB de archivos multimedia sin procesar desde una fuente local, como una cámara de vídeo o un almacenamiento local, a Cloud Storage. El Servicio de transferencia de Storage permite mover datos fácilmente entre sistemas de almacenamiento de objetos y archivos. Para transferencias más pequeñas, elija el servicio para transferir datos a Cloud Storage y desde Cloud Storage o entre sistemas de archivos en función de su situación.

Ubicación del segmento

En el caso de las cargas de trabajo que requieren recursos de computación, como la producción multimedia, debes crear los contenedores en la misma región o en las mismas regiones duales que los recursos de computación. Este método ayuda a optimizar el rendimiento al reducir las latencias de lectura y escritura de tus cargas de trabajo de procesamiento, el coste y el ancho de banda. Para obtener más información sobre cómo elegir la ubicación del segmento, consulta Cuestiones importantes sobre la ubicación del segmento.

Clase de almacenamiento

En función del tipo de carga de trabajo multimedia, la clase de almacenamiento que debes seleccionar varía. Estos son los tipos de clases de almacenamiento recomendados para diferentes cargas de trabajo multimedia:

  • Para gestionar recursos multimedia, como vídeos de archivo, la clase de almacenamiento predeterminada de un segmento debe ser Archive Storage. Puede especificar una clase de almacenamiento diferente para los objetos que tengan diferentes necesidades de disponibilidad o acceso.
  • En el caso de las cargas de trabajo de producción multimedia y de servicio de contenido, como los datos se leen con frecuencia de un segmento de Cloud Storage, debe almacenarlos en el almacenamiento Estándar.

Para obtener más información sobre cómo elegir la clase de almacenamiento de tu segmento, consulta el artículo Clase de almacenamiento.

Gestión del ciclo de vida de los datos

Para gestionar sus recursos multimedia, debe gestionar el ciclo de vida de los objetos de sus contenedores definiendo una configuración del ciclo de vida. Con la función Administración del ciclo de vida de los objetos, puedes gestionar el ciclo de vida de los datos, lo que incluye definir un tiempo de vida (TTL) para los objetos, conservar versiones no actuales de los objetos y cambiar a clases de almacenamiento inferiores para gestionar los costes.

Cuando los patrones de acceso a los datos son predecibles, puedes configurar el ciclo de vida de un segmento. Si los patrones de acceso a tus datos son desconocidos o impredecibles, puedes configurar la función Autoclass en tu segmento. 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 cargas de trabajo de servicio y distribución de contenido

En el caso de las cargas de trabajo de vídeo a la carta y de streaming en directo, 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 vídeo en el reproductor de vídeo de los usuarios finales. Estas cargas de trabajo también requieren que se escale el número de lecturas para dar cabida a un gran número de usuarios simultáneos. En todos los casos, el tráfico de clientes debe pasar por una CDN.

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

Usar la CDN de forma eficaz

Usar una red de distribución de contenido (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 coste total de propiedad (TCO) al reducir los costes de ancho de banda, optimizar la utilización de los recursos y mejorar el rendimiento. Si usas Media CDN, se reduce el coste total de propiedad de servir contenido a los usuarios finales, ya que el coste de llenado de la caché de Media CDN es cero. Puedes usar Media CDN como fuente de otras CDNs de terceros. Con otras CDNs, también se reduce el coste total de propiedad al servir contenido desde la caché de Media CDN en lugar de desde el origen.

Si usas una CDN de terceros, CDN Interconnect permite que determinados proveedores establezcan enlaces de peering directos 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 enlaces se beneficia de la conectividad directa con los proveedores de CDN admitidos y se factura automáticamente con precios reducidos. Para ver una lista de proveedores aprobados, consulta Proveedores de servicios aprobados por Google.

A continuación, se indican las opciones que puede configurar al configurar una CDN:

Selecciona la ubicación del escudo de origen

La ubicación de protección 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 las directrices de la CDN para saber si es recomendable elegir que el escudo de origen esté más cerca de la región de tu segmento de Cloud Storage o de la ubicación de concentración del tráfico de tus usuarios finales. La protección de origen es una medida de protección que evita que el servidor de origen se sobrecargue. Las CDNs con protección de origen ayudan a aumentar la descarga del origen añadiendo una caché adicional entre el origen y la CDN. Por ejemplo, Media CDN ofrece una infraestructura perimetral de niveles profundos diseñada para minimizar activamente el relleno de la caché siempre que sea posible.

Habilitar la coalescencia de solicitudes

Asegúrate de que la combinación de solicitudes esté habilitada en tu CDN. Al combinar varias solicitudes en una sola, se reduce el coste de las operaciones de clase B de Cloud Storage. Las CDNs tienen cachés distribuidas por todo el mundo, pero ofrecen una forma de combinar varias solicitudes de usuarios finales en una sola solicitud al origen. Por ejemplo, Media CDN combina activamente varias solicitudes de relleno de caché iniciadas por el usuario para la misma clave de caché en una única solicitud de origen por nodo perimetral, lo que reduce el número de solicitudes enviadas a los contenedores.

Configurar 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 y 504) en tu CDN. Las CDNs admiten reintentos de origen, lo que permite reintentar las solicitudes fallidas al origen. La mayoría de las CDNs te permiten especificar el número de reintentos del origen actual. Para obtener información sobre cómo volver a intentar las solicitudes de origen en Media CDN, consulta Volver a intentar 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 el servicio de contenido y la distribución de contenido de tipo VOD, ten en cuenta los siguientes factores al seleccionar una ubicación para tu segmento:

  • Para optimizar los costes, los contenedores creados en una sola región tienen el coste de almacenamiento más bajo.
  • Para optimizar la disponibilidad, ten en cuenta lo siguiente:
    • En la mayoría de las cargas de trabajo multimedia, se recomienda usar segmentos birregionales, ya que replican los objetos en dos regiones para mejorar la disponibilidad.
    • En los casos prácticos que requieren servir contenido y analíticas con redundancia geográfica, utilice segmentos en varias regiones para conseguir la máxima disponibilidad.
  • Para optimizar la latencia y reducir los costes de red, ten en cuenta lo siguiente:
    • En el caso del vídeo bajo demanda, elija las regiones más cercanas a la mayoría de sus usuarios finales o la región con la mayor concentración de tráfico.
    • Durante la emisión en directo, los contenedores 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 del streaming, elige contenedores regionales que estén ubicados en el mismo lugar que los recursos de computación que se usen para la transcodificación.

Optimizar la duración de los segmentos de vídeo en emisiones en directo

En el caso de las emisiones en directo, el tamaño de segmento mínimo recomendado es de dos segundos, ya que los segmentos de vídeo cortos son más sensibles a las latencias de escritura de larga duración. Las latencias de escritura de cola larga hacen referencia a las operaciones de escritura lentas o retrasadas de contenido al que se accede con poca frecuencia o que tiene un volumen de solicitudes bajo.

La distancia física entre la ubicación del contenedor y la ubicación de reproducción de los usuarios finales afecta al tiempo de transmisión. Si los usuarios finales están lejos de la ubicación del contenedor, te recomendamos que el tamaño del segmento de vídeo sea mayor.

Para ofrecer la mejor experiencia a los usuarios, se recomienda usar la estrategia de reintentos y la cobertura de solicitudes para las escrituras en los transcodificadores con el fin de mitigar las latencias de larga duración de más de dos segundos para las escrituras en Cloud Storage y experimentar con tiempos de almacenamiento en búfer más largos, de unos diez segundos.

Aumentar el número de consultas por segundo de forma gradual

Los segmentos de Cloud Storage tienen una capacidad de E/S inicial de 1000 escrituras de objetos por segundo y 5000 lecturas de objetos por segundo. En el caso de las cargas de trabajo de emisión en directo, la directriz es escalar las solicitudes de forma gradual. Para ello, empieza con 1000 escrituras por segundo y 5000 lecturas por segundo, y duplica de forma incremental la tasa 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 segmento, ya que reduce las probabilidades de que se produzcan problemas de reproducción.

En el caso de los eventos de emisión en directo con un valor de QPS más alto, debes implementar el escalado en tu contenedor. Para ello, puedes preparar el contenedor o habilitar el espacio de nombres jerárquico en él. Antes de implementar el escalado en tu contenedor, debes realizar las siguientes tareas:

Estimar las QPS al origen

Supongamos que, en una emisión en directo con un millón de espectadores, la CDN recibirá un millón de QPS. Si tu CDN tiene una tasa de aciertos de caché del 99%, el tráfico resultante a Cloud Storage será del 1%. Las CPS serán el 1% del total de los usuarios (un millón), lo que equivale a 10.000 CPS. Este valor es superior a la capacidad de PI inicial.

Monitorizar las QPS y solucionar los errores de escalado

Debes monitorizar las QPS y solucionar los errores de escalado. Para obtener más información, consulta Información general sobre la monitorización en Cloud Storage . Para monitorizar las solicitudes de lectura y escritura, consulta los gráficos Número total de solicitudes de lectura, lista y obtención y Número total de solicitudes de escritura, respectivamente, en la Google Cloud consola. Si aumenta el CPS de los segmentos más rápido que las directrices de aumento especificadas en la sección anterior, puede que se produzca el error 429 Too many requests (Demasiadas solicitudes). Consulta cómo solucionar el error 429 Too many requests.

En las siguientes secciones se describe cómo escalar su bucket para obtener un QPS más alto después de haber estimado el QPS al origen.

Implementa el escalado de las consultas por segundo en tu contenedor precalentándolo

Puedes acelerar el proceso de escalado antes de un evento de emisión en directo precalentando tu contenedor. Antes del evento de emisión en directo, genera tráfico sintético a tu contenedor que coincida con el QPS máximo esperado que recibirá el servidor de origen de la CDN del evento, más un 50% adicional para tener en cuenta la tasa de aciertos de caché esperada de tu CDN. Por ejemplo, si has estimado que el QPS de tu origen es de 10.000, el tráfico simulado debería dirigirse a 15.000 solicitudes por segundo para preparar tu origen para el evento.

Para este tráfico simulado, puede usar los archivos de feed en directo 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 escalado gradual. Empieza con 5000 solicitudes por segundo y aumenta progresivamente hasta alcanzar tu objetivo. Dedica suficiente tiempo antes del evento para alcanzar la carga estimada. Por ejemplo, para alcanzar las 15.000 solicitudes por segundo, duplicando la carga cada 20 minutos a partir de las 5000 solicitudes por segundo iniciales, se tardarán aproximadamente 30 minutos.

El servidor de origen mantiene la capacidad hasta que el tráfico sea constante. La capacidad del servidor de origen se reduce gradualmente hasta su nivel de referencia en un plazo de 24 horas. Si tu servidor de origen experimenta intervalos de varias horas entre los eventos de la emisión en directo, te recomendamos que simules el tráfico antes de cada evento.

Usar segmentos con el espacio de nombres jerárquico habilitado para obtener un QPS inicial alto

Los segmentos de Cloud Storage con el espacio de nombres jerárquico habilitado ofrecen hasta ocho veces el QPS inicial en comparación con los segmentos sin HNS. El mayor número de consultas por segundo inicial facilita el escalado de las cargas de trabajo que requieren un uso intensivo de datos y proporciona un mayor rendimiento. Para obtener información sobre las limitaciones de los contenedores con el espacio de nombres jerárquico habilitado, consulta Limitaciones.

Evita usar nombres secuenciales para los segmentos de vídeo si quieres aumentar las consultas por segundo

Con el escalado de QPS, las solicitudes se redistribuyen entre varios servidores. Sin embargo, puede que se produzcan cuellos de botella en el rendimiento cuando todos los objetos usen un prefijo no aleatorio o secuencial. Si usas nombres completamente aleatorios en lugar de nombres secuenciales, obtendrás la mejor distribución de la carga. Sin embargo, si quiere usar números secuenciales o marcas de tiempo como parte de los nombres de los objetos, añada un valor de hash antes del número de secuencia o de la marca de tiempo para introducir aleatoriedad en los nombres de los objetos. Por ejemplo, si el nombre del objeto original que quiere usar es my-bucket/2016-05-10-12-00-00/file1, puede calcular el hash MD5 del nombre del objeto original y añadir los seis primeros caracteres del hash como prefijo al nombre del objeto. El nuevo objeto será my-bucket/2fa764-2016-05-10-12-00-00/file1. Para obtener más información, consulta el artículo Usa una convención de nomenclatura que distribuya la carga de forma uniforme entre los intervalos de claves. Si no puedes evitar usar nombres secuenciales para los segmentos de vídeo, utiliza contenedores con el espacio de nombres jerárquico habilitado para obtener un QPS más alto.

Usar diferentes contenedores para cada emisión en directo

En el caso de las emisiones en directo simultáneas, usar diferentes contenedores para cada emisión te ayudará a escalar la carga de lectura y escritura de forma eficaz sin alcanzar los límites de E/S del contenedor. Si usas diferentes contenedores para cada emisión en directo, se reducen las latencias atípicas grandes debido a los retrasos en el escalado.

Siguientes pasos