He tenido la suerte de poder migrar muchas bases de datos: Oracle, MySQL, MariaDB, MemSQL, Microsoft SQL Server, etc… pero nunca lo había realizado con tanta facilidad como cuando me tocó migrar, recientemente, un MemSQL de tamaño monstruoso hacia AWS RDS Aurora. Utilizando, para ello, el servicio DMS de AWS.
Para explicar un poco más y centrando éste artículo solo en RDS Aurora, puedo decir que estamos hablando de una Base de Datos con base MySQL 5.6 pero muy tuneada y personalizada para convertirla en un auténtico PaaS. Destacamos lo siguiente:
- Muy Alto Desempeño. Según se dice, puede tener cinco veces más performance que un MySQL instalado de forma nativa. Aunque por las diferentes pruebas que he podido realizar previamente y ya luego, en producción, es correcta la afirmación pero el tallaje tiene que ser bastante alto, por ejemplo: db.r3.large, db.r3.xlarge o más todavía.
- Escalado automático. Esta es la mejor parte ya que te olvidas del escalado de instancias, una parte muy crítica cuando estás en entornos muy complejos que requieren de mucha computación, ya sea por query complejas o por un alto throughput de datos.
- Escalado automático de almacenamiento. Otro punto para RDS Aurora ya que podemos olvidarnos de los famosos “tablespace” ya que el volúmen de disco que utiliza crece de forma automática y cuando se requiere.
- Aurora Read Replica. Por ejemplo, cuando tenemos procesos de negocio que graban (write) podemos ejecutarlos contra su nodo primario pero, también, cuando tenemos procesos que solo leen, una API por ejemplo, pues podemos crear nodos réplica en modo lectura/slave que aumentaran nuestra performance e independizaran sus recursos.
Podríamos seguir hablando de algunos de sus mayores beneficios, como los despliegues de las instancias en Multi-AZ, snapshots automáticos (backups), aislamiento de red en diferentes segmentos o la tolerancia a errores. Pero en este caso quería profundizar un poco más con la situación que me encontré y que RDS Aurora me facilitó la vida para la migración de datos.
En éste caso, me encontré con una base de datos monstruosa, MemSQL, donde la necesidad de tener un alto cómputo de datos debido a una construcción incorrecta de la mayoría de las query hacía que se requiriese no solo una enorme computación de CPU sinó también de memória RAM para poder ejecutar, al vuelo, dichas consultas. Y no estaba en Cloud, sinó en una máquina física.
Con esta situación, era casi improbable una migración a una base de datos Tradicional basada en Cloud. Solo su coste hubiera sido el doble o triple del actual. ¿Qué podíamos hacer entonces?
Lo primero fue estudiar query a query para ver los motivos que habían llevado a su construcción, su comportamiento (slow query) y performance en el sistema “actual” y un test sobre una plataforma futura para ver cuál podría ser su comportamiento. Aunque, más del 90% de query se tuvieron que refacturizar, no solamente como SQL, sinó también como lógica de negocio.
A partir de este trabajo, es cuando entonces se pudieron dibujar los procesos de negocio, identificando los que sólo eran de consulta y los que también requerían de acceso de escritura. Se dibujo un nuevo Modelo de Datos ya basado en el trabajo anterior donde se identificaron relaciones entre Tipologías y Topologías de Datos. Porque los datos merecen la oportunidad de guardarse y/o tratarse en aquella Base de Datos que mejor pueda hacerlo. Diferenciando entre SQL y NoSQL. Ni todo debe ser SQL ni todo debe ser NoSQL.
Gracias a éste trabajo, se puedo afrontar la migración física de los datos, la implementación de los nuevos procesos de negocio y, hoy: podemos contarlo. Realmente la combinación entre RDS Aurora y el Database Migration Service (DMS) fueron nuestra mayor herramienta para conseguirlo y todo en menos de 1 mes de intenso trabajo.
