Problema

En pipelines que combinan After Effects (AE) con render farms en la nube, es frecuente que la arquitectura se centre en la escalabilidad de los nodos y el coste de Spot Instances, pero se pasen por alto estados implícitos del entorno de AE. Cuando varios idiomas comparten capas de texto, AE puede perder metadatos de tipografía (peso, estilo) entre pasadas. El resultado es un video que visualmente parece correcto en la previsualización, pero que al entregarse muestra fuentes en Regular en lugar de Bold o Medium. Este tipo de corrupción silenciosa se vuelve crítico en campañas multilingües donde la consistencia de marca es obligatoria.

El patrón típico es:

  1. Un diseñador envía un lote de render con 30‑40 idiomas.
  2. Cada idioma se procesa en un worker aislado (g4dn.xlarge, Tesla T4) bajo Spot.
  3. Después de varios renders, algunos idiomas presentan cambios de tipografía no esperados.
  4. La falla se detecta solo en producción, después de la entrega al cliente.

Aparte del problema de fuentes, los pipelines suelen carecer de:

  • Alertas automáticas para trabajos fallidos o cancelados.
  • Un almacenamiento de salida duradero y versionado.
  • Un control de versiones de la infraestructura que garantice que lo que está en producción coincide con el código fuente.
  • Un flujo de CI/CD que impida despliegues accidentales desde ramas de desarrollo.

Estos gaps convierten una arquitectura “MVP” en una fuente de incidentes operacionales.

Causa

1. Estado local de After Effects

AE mantiene la información de fuentes en la caché del proceso aerender. Cuando se reutiliza la misma instancia para varios idiomas, la caché no se reinicializa por completo y los pesos de fuente pueden sobrescribirse. En entornos locales los diseñadores suelen cerrar y volver a abrir AE entre idiomas, lo que “limpia” la caché; en la nube, los workers permanecen vivos y el problema se manifiesta.

2. Falta de aislamiento de job metadata

Los jobs de Deadline Cloud solo almacenan la salida en un prefijo temporal del CAS (Content Addressable Store). Si el prefijo caduca o la entrega a Google Drive falla, no hay rastro de qué archivo corresponde a cada idioma. La ausencia de un manifiesto impide la deduplicación y la auditoría.

3. Monitoreo insuficiente de estados de job

El Lambda post‑render se dispara únicamente para estados SUCCEEDED. Los estados FAILED, CANCELED o TIMEOUT quedan sin notificación, lo que obliga a una revisión manual y rompe el SLA.

4. Despliegues sin control de rama

Los pipelines CI/CD que disparan despliegues de Lambda en cualquier push pueden propagar código no probado a producción. Sin una política de “protected branch” o “release tag”, la drift entre main y develop se vuelve inevitable.

5. Dependencias de plugins y fuentes en la AMI

Una AMI personalizada puede reducir el tiempo de arranque, pero si no se versiona y parchea de forma automática, los workers pueden ejecutar versiones desalineadas de plugins críticos, generando errores intermitentes.

Solución

A. Asegurar aislamiento de estado de AE

  1. Snapshot de capas antes de cada idioma: antes de lanzar aerender, exporta la lista de capas y sus atributos de fuente a un JSON temporal.
  2. Restauración post‑render: una vez finalizado el render, restaura los atributos originales mediante un script de After Effects (ExtendScript) que recorra el JSON y aplique los valores correctos.
  3. Reinicio forzado del proceso: si la carga de trabajo lo permite, finaliza el proceso aerender después de cada idioma y vuelve a iniciarlo. Esto garantiza una caché limpia.

B. Persistencia y versionado de salidas

  • Bucket S3 como capa de salida definitiva: configura el Lambda post‑render para copiar el archivo final a un bucket S3 con una clave estructurada (s3://renders/<campaign>/<language>/<timestamp>.mp4).
  • Manifiesto en DynamoDB: registra cada render con su jobId, language, s3Key y checksum. El manifiesto sirve como fuente de verdad y permite re‑intentos idempotentes.
  • Política de retención: habilita versionado en el bucket y define una regla de ciclo de vida que archive versiones antiguas después de 90 días.

C. Alertas y manejo de fallos

  • EventBridge rule para estados de job: crea una regla que capture FAILED, CANCELED y TIMEOUT y la dirija a un SNS tópico.
  • Notificaciones a Telegram/Slack: suscribe el tópico a una Lambda que formatee el mensaje y lo envíe al canal de operaciones.
  • DLQ para entregas a Drive: si el proceso de subida a Google Drive falla, envía el mensaje a una Dead‑Letter Queue y genera una métrica en CloudWatch.

D. Control de despliegues

  • Protección de ramas en GitLab: habilita protected para main y permite merges solo mediante Merge Requests aprobados.
  • Deploy desde tags: el pipeline debe empaquetar la Lambda solo cuando se crea un tag vX.Y.Z. Usa immutable image tags en ECR.
  • Rollback documentado: guarda la versión del artefacto en S3 y mantén un script que pueda revertir a la última versión estable con un solo comando.

E. Gestión de infraestructura como código

  • Terraform con terraform import: importa todos los recursos creados manualmente (Deadline fleet, EventBridge, SNS, S3) al estado de Terraform. Así se elimina la drift.
  • Módulo de AMI: si se decide usar una AMI personalizada, encapsúlala en un módulo que incluya user_data para instalar plugins vía Conda y que sea versionado mediante ami_id en variables.

Cuándo aplicar esta solución

  • Síntomas: cambios inesperados de tipografía en renders multilingües, archivos faltantes en el bucket de entrega, ausencia de notificaciones tras fallos de job, o despliegues que no coinciden con el código en main.
  • Entornos: pipelines de render que usan Deadline Cloud o cualquier otro gestor de render distribuido, especialmente cuando se trabaja con Spot Instances y se busca minimizar coste.
  • No aplicable: proyectos donde cada idioma se procesa en una máquina física aislada y se controla manualmente la salida; o cuando la única salida es un archivo local sin necesidad de auditoría.

Código

# EventBridge rule que captura estados de job fallidos y envía a SNS
aws events put-rule \
  --name "DeadlineJobFailureRule" \
  --event-pattern '{
    "source": ["aws.deadline"],
    "detail-type": ["Deadline Job State Change"],
    "detail": {
      "state": ["FAILED","CANCELED","TIMEOUT"]
    }
  }' \
  --role-arn arn:aws:iam::123456789012:role/EventBridgeInvokeSNS

aws events put-targets \
  --rule "DeadlineJobFailureRule" \
  --targets '[
    {
      "Id": "NotifyOps",
      "Arn": "arn:aws:sns:us-east-1:123456789012:deadline-failure"
    }
  ]'

Verificación

  1. Prueba de aislamiento de fuentes

    • Envía un lote con dos idiomas que usen la misma capa de texto pero pesos diferentes.
    • Descarga los renders y verifica que los pesos coinciden con los esperados (puedes usar ffprobe para extraer metadatos de texto si el video los contiene).

  2. Manifiesto en DynamoDB

    • Ejecuta un render y consulta la tabla DynamoDB.
    • Confirma que la fila contiene jobId, language, s3Key y checksum.

  3. Alertas

    • Fuerza un job a fallar (por ejemplo, elimina temporalmente el binario aerender).
    • Verifica que el mensaje llega al canal de Telegram y que la métrica DeadlineJobFailures incrementa en CloudWatch.

  4. Rollback

    • Despliega una versión nueva con un bug intencional.
    • Ejecuta el script de rollback y comprueba que la Lambda vuelve a la versión anterior sin errores.

Notas adicionales

  • Cache de fuentes en Windows: en instancias Windows, la carpeta %APPDATA%\Adobe\After Effects\<version>\ contiene la caché de fuentes. Limpiar esta carpeta al iniciar cada worker elimina gran parte de la drift.
  • Coste de Spot vs On‑Demand: mantén una pequeña proporción de on‑demand (p. ej., 5 %) como fallback para evitar interrupciones cuando la capacidad Spot se agota.
  • Monitoreo de latencia de arranque: registra el tiempo entre la asignación de la Spot Instance y el primer aerender exitoso. Si supera los 2 min, considera pre‑warm con una AMI personalizada.
  • Seguridad de claves: revoca cualquier IAM user legacy y migra a Identity Center. Usa políticas de “least privilege” para los workers, limitando el acceso a S3 a los prefijos necesarios.