Si ha visto una película taquillera en los últimos cinco años, es probable que haya sido testigo del trabajo de efectos visuales y animación realizado por los excepcionalmente talentosos artistas de Method Studios en Melbourne. Nuestro trabajo abarca todos los géneros cinematográficos, desde "Aquaman" y "Terminator: Dark Fate" a "Jumanji: El siguiente nivel" y "John Wick: Capítulo 3 - Parabellum y series episódicas, como la ganadora del premio Emmy "Batalla de los Bastardos" de la sexta temporada de "Juego de Tronos" de HBO Reflexionando sobre nuestro trabajo, la serie de Disney "Christopher Robin"resultó ser una de las empresas más memorables, dada la hazaña de dar vida a Winnie-the-Pooh, el cariñoso coprotagonista de la película. Encargarse de este proyecto no sólo supuso para el equipo la obtención de un Premio Creativo de la Academia Asiática, sino que también marcó el inicio de nuestra colaboración con AWS.
Ganar la licitación para "Christopher Robin" en 2017 fue emocionante, pero intimidante, ya que la representación de un oso completo-CG, que a menudo aparece en primeros planos, es un reto. Habíamos utilizado Thinkbox Plazo para gestionar nuestra granja de renderizado durante muchos años, antes de que Thinkbox Software fuera adquirida por AWS. Cuando empezamos a preparar "Christopher Robin", el AWS Thinkbox nos ayudó a crear un flujo de trabajo de prueba de concepto para el renderizado en ráfagas en la nube. Antes de empezar, tuvimos que pensar cómo presentar los datos a los nodos de renderizado en la nube, dónde almacenarlos y cómo integrar la computación en la nube con nuestra granja local.
Hemos considerado varias opciones para presentar las texturas y la geometría a los usuarios Amazon Elastic Compute Cloud (Amazon EC2) instancias. El enfoque más sencillo consistía en presentar nuestro servidor NFS (Network File System) local directamente a través de nuestro servidor NFS AWS Direct Connect a la Flota de Amazon EC2 Spot en la región de Sídney. Dicho esto, queríamos aprovechar cientos de instancias que crearan decenas de gigabits de tráfico. Conseguir ese tipo de rendimiento a través de una red privada virtual (VPN) es un reto y un coste prohibitivo en términos de tráfico de salida. En su lugar, optamos por Amazon Elastic File System (Amazon EFS), un servicio NFS administrado basado en la nube. La instalación de Amazon EFS fue sencilla y la configuración predeterminada podía reducirse para minimizar los costes cuando no se utilizara. Aunque se trata de un enfoque menos automatizado, acabamos utilizando la configuración de rendimiento provisionado para obtener un rendimiento más predecible.
En los años transcurridos desde "Christopher Robin", los requisitos técnicos de renderización no han hecho más que aumentar, por lo que hemos seguido perfeccionando nuestro flujo de trabajo y el modo en que utilizamos los servicios de AWS. Hoy en día, los proyectos requieren renderizar fotogramas con una resolución de 4,5K, por lo que el acceso informático basado en la nube con mucha RAM y núcleos de CPU resulta muy rentable. Los fotogramas que podrían tener dificultades para renderizarse con hardware local pueden aprovechar esas grandes instancias de Amazon EC2, con todo el cómputo gestionado utilizando la misma instancia de Deadline. A medida que los trabajadores de Amazon EC2 se conectan, están disponibles dinámicamente en Control de plazos junto a nuestra granja.
Una de las ventajas menos obvias que encontramos al irrumpir en AWS es un menor impacto en el almacenamiento on-premise. Los requisitos de entrada/salida (E/S) de una gran actividad de renderización pueden afectar considerablemente a los artistas, ya que es difícil seguir siendo productivo cuando el almacenamiento no puede seguir el ritmo. Trasladar esa pesada carga de trabajo de E/S a EFS ha protegido el rendimiento de nuestros artistas y, como resultado, ha aumentado la productividad y la moral en el estudio. Además de EFS, hemos añadido un socio de AWS totalmente flash Qumulo para acelerar el arranque de las aplicaciones.
Para garantizar que los datos correctos lleguen a la nube para el renderizado y vuelvan a las estaciones de trabajo de los artistas en cuanto termine de renderizarse un fotograma, creamos un sistema para generar mediante programación una lista de los activos dependientes y el software necesario para renderizar una toma determinada. Nuestro conjunto de herramientas ya podía rastrear las dependencias, así que sólo tardamos dos semanas en crear la infraestructura y el software básicos. Hoy utilizamos una base de datos para rastrear los archivos almacenados en la nube. Antes de transferir datos, consultamos esa base de datos para ver si es necesario sincronizar un activo. Todo lo que no esté ya en la base de datos se añade a la cola, que alimenta una granja de trabajadores de sincronización que mueven los datos a/desde el almacenamiento en la nube. Deadline captura cualquier error resultante de los activos que faltan, que luego envía automáticamente una solicitud para recuperar los archivos que faltan. La tarea fallida espera a que lleguen los datos y se reanuda una vez que los archivos han llegado al almacenamiento en la nube.
Dado que utilizamos la nube para aumentar nuestra capacidad de renderizado local, necesitábamos poder escalar rápidamente sin intervención manual y, con la misma facilidad, escalar hacia abajo para no pagar por recursos un segundo más de lo que los necesitamos. Para lograrlo, creamos herramientas para vigilar las tareas en cola de Deadline. Ahora, cuando se agota nuestra capacidad de renderizado local, podemos ampliar fácilmente nuestro Spot Fleet y empezar a renderizar en la nube en cuestión de minutos. Tan pronto como no hay más tareas en cola, Deadline apaga las máquinas inactivas, por lo que sólo pagamos por el cómputo en uso. Seguimos y controlamos el gasto mediante paneles de control y etiquetas de asignación de costes. De este modo siempre tenemos visibilidad de nuestro gasto, y una alerta preestablecida nos avisa si estamos superando el presupuesto previsto.
Ocasionalmente, nuestro sistema de sincronización de activos puede fallar a la hora de copiar algo necesario para un renderizado, por lo que creamos una estación de trabajo virtual utilizando un Instancia de Amazon EC2 G4dn (GPU) que se configura exactamente igual que una estación de trabajo local. Cada vez que necesitamos solucionar un problema de renderización, nos conectamos a la estación de trabajo basada en la nube e iniciamos una escena como si la estuviéramos ejecutando en nuestro estudio para identificar rápidamente cualquier problema. Cuando un renderizado finaliza en AWS, el fotograma o los datos terminados se sincronizan en las instalaciones para que el artista pueda revisarlos. Para asegurarnos de que los renderizados son los esperados, creamos una aplicación web que permite a los artistas previsualizar los fotogramas mientras se están renderizando. Aprovechamos todas las métricas que salen de Amazon CloudWatch y utilizar paneles de control Grafana para realizar un seguimiento de las métricas de Amazon EC2, almacenamiento, ancho de banda, costes y cualquier otra cosa que podamos imaginar.
Tras más de tres años en la nube, hemos comprobado que el renderizado en AWS forma parte integral de nuestra estrategia de granja de renderizado. Hemos dejado de centrarnos en las compras de capital o la contratación de equipos y ahora nos centramos en la nube. En este momento, hemos automatizado la mayor parte de la administración de la infraestructura de AWS y dedicamos mucho menos tiempo a montar servidores, administrar actualizaciones de firmware y sustituir hardware averiado. Nuestro objetivo es seguir reduciendo el tiempo que se tarda en entregar un cuadro terminado a los artistas, de modo que podamos seguir subiendo el listón en términos de calidad y plazo de entrega para los clientes.
How Winnie-the-Pooh Sparked Method Melbourne's Journey to Cloud Rendering, se publicó en el Blog de medios de AWS el 20 de abril de 2021. Sobre el autor: Jon Stanley es Director de Sistemas de Estudios Method en Melbourne cargo que ocupa desde 2017. Con casi 20 años de experiencia en ingeniería de sistemas para estudios de VFX y postproducción, también ha trabajado en Iloura, Lipsync Post y Framestore.
Más información
De la animación y la producción a distancia a la distribución qumulo para medios de comunicación y entretenimiento
Escala ilimitada y programabilidad API, Nube Q para AWS
Póngase en contacto con nosotros
Prueba de conducción. Demuestra Qumulo en nuestros Laboratorios Prácticos interactivos.
Suscribirse al blog de Qumulo para conocer historias de clientes, perspectivas técnicas, tendencias del sector y noticias sobre productos.