A finales de 2023, AWS nos informó que nuestros servidores Aurora necesitaban ser migrados debido al fin del soporte de la versión community de MySQL 5.7 y se recomendaba migrar a la versión 8.0.

[!cite] Anuncio de AWS

[!note] Ver post de cómo las empresas no están al tanto de estos costos y cómo esto podría estar afectando su facturación: Incremento de costos debido al Soporte Extendido de RDS en AWS

Imagen de costo del soporte de AWS RDS

Ese día durante nuestra reunión diaria, el Scrum Master y el CTO me asignaron la tarea de evaluar el impacto de esta notificación e inmediatamente hice saber preocupación sobre los costos que la empresa tendría que pagar si no migramos antes de cumplirse el plazo. En principio no parecía una gran cosa - $0,1 por VCPU - por lo que decidí invertir ese día en obtener todos los números para asegurarme de que todos entendieran el impacto de esta notificación de migracion.

El siguiente día durante mi turno en la reunión diaria expliqué los números a la equipo, qué servicios estaban involucrados y mi plan de acción para completar la migración. La siguiente tabla muestra los costos adicionales que tendríamos que pagar cada mes:

Tipo de instancia Instancias VCPUs Costo adicional mensual 1er & 2do Año Costo adicional mensual 3ro Año
db.r5.4xlarge 2 32 (16x2) $2,380 ($0,1 x 32VCPU x 744H) $4,761,6 ($0,2 x 32VCPU x 744H)
db.t3 pequeña 12 24 (2x12) $1,785.6 ($0,1 x 24VCPU x 744H) $3,571,2 ($0,2 x 24VCPU x 744H)
Total 56 $4,165,6 $8,332,8
Total Anual $49,987,2 $99.974.4

Esto era dos y tres veces el presupuesto mensual de bases de datos en ese momento, y después de discutir los números, obtuve un la aprobación y la migración paso a tener una prioridad alta.

Si nos fijamos en el número de instancias, había muchos servidores de MySQL que debían migrarse y mi plan de acción era lo siguiente:

  1. Comenzar a migrar ambientes de desarrollo primero (DEV, QA, STAGGING, PRE-PROD).
  2. Migrar un servicio diariamente.
  3. Crear copias de seguridad antes de migrar.
  4. Notificar a los miembros del equipo de IT sobre las migraciones de los ambiente antes de migrar cualquier motor.
  5. Después de la migración:
    • Medir el tiempo de inactividad del servicio.
    • Verificar si hubo incidentes después de migrar.
    • Verificar los logs de aplicación relacionados con cada servicio migrado.
    • Verificar el uso de CPU y RAM.
  6. Si todo estaba bien, comenzar a migrar otro ambiente de desarrollo.
  7. Después de migrar todos los ambientes de desarrollo:
    • Esperar una semana antes de migrar la producción.
    • Verificar si hubo incidentes después de migrar.
    • Verificar los registros de aplicación relacionados con cada motor migrado.
    • Verificar el uso de CPU y RAM.

Esta fue una gran experiencia con bases de datos y espero que en el futuro cercano podamos tener algunos videos de tutorial explicando cómo realizar las migraciones.