Una historia de MongoDB: 3 Tradeoffs claves para migrar hacia DocumentDB con AWS DMS | DocDB Series parte 4

9 min readApr 9, 2021

Escucha en modo AudioBlog este artículo

https://soundcloud.com/karlosgnr_22/una-historia-de-mongodb-tradeoffs-de-una-migracion-hacia-document-db-con-aws-dms

En el post anterior, aprendimos a usar AWS DMS, creando una tarea de migración, pero realmente qué ganamos o qué perdemos usando una herramienta o servicio auto gestionado para esta acción? Si lo podemos realizar manualmente en un ambiente offline como lo vamos a ver y comparar hoy.

MongoDB, es una base de datos no relacional, que se encuentra en la versión 4.4, y que se distingue en muchas características de su hermano gemelo en AWS, DocumentDB.

Empecé a usar MongoDB hace 8 años cuando por casualidades de la vida, Juan Carlos Costilla, uno de mis grandes amigos de toda la vida, me invitó a llevar un curso gratuito de MongoDB University. Claro que nunca se apareció en la primera reunión, que fue un Domingo a las 5 de la tarde , y conocí al líder de la comunidad de MongoDB Perú, Jorge Puente Sarrín seguido por Raul Hugo quiénes tenían ya una pasión por hacer comunidad y compartir conocimiento para evitar que me vaya por el lado oscuro de la fuerza.

En esos tiempos del 2013, nadie daba ni un sol por MongoDB, apenas pocas organizaciones y empresas lo usaban en cargas de trabajo productivas de manera correcta. Una de ellas fue mi primer trabajo en el mundo del Cloud Computing como Sysadmin en un periódico peruano llamado “EC” y donde aprendí que MongoDB era más que solo una base de datos documental más, debido a la variedad de casos de uso distintos según la necesidad de la aplicación y criticidad. Sufrimos y nos amanecimos migrando a MongoDB a la manera tradicional y vimos cómo fue evolucionando a través de los años.

En el 2015, en el sexto cumpleaños de Mongo DB, Azure lanzó DocumentDB, luego cambiando de nombre a Cosmos DB. Durante el veranillo del 2016, MongoDB lanza Atlas, su servicio autogestionado de su propia base de datos revolucionando el mercado. Y poco después ya en el 2019, casi empezando el año, Amazon Web Services lanzó DocumentDB, para soportar la versión 3.6 con el motor Wired Tiger. Enhorabuena, hace unos 6 meses, se actualizó para poder usar la hermosa versión de 4.0

🧩TradeOff #1: Minimizar o permitir caídas?

La continuidad operativa es necesaria para el negocio, e implementarla puede ser una tarea retadora. Recordemos que al realizar una tarea manual o por scripting como la que hemos visto, necesita que la base de datos tenga una pantalla de mantenimiento y tenga que estar fuera de línea varias horas. A esto le llamamos el método offline mientras que una Online se enfoca en evitar estar fuera de línea y migrar los datos continuamente para optimizar y reducir el tiempo de caída de pase a producción de base de datos.

Quieren tener su base de datos productiva apagada sin que nuestros clientes puedan ser atendidos? ¿Hay alguna opción para que esto suceda? Tener una base de datos de réplica?

Las malas lenguas, dicen que de la implementación sin alta disponibilidad, sin balanceo de carga y sin un plan de recuperación de desastres son indicios de que un verdadero caos se avecina. Para eso debemos evitar los puntos únicos de fallo en nuestra base de datos, implementar tolerancia a fallos con instancias de réplica o sincronización en otra región

No les voy a decir cuál César es, pero, César nos hacía recordar que no debemos decir:

“Si funciona no lo toques”.

Vaya suceder, que sucede cuando sucede. Que no sabemos qué va a pasar si se reinicia la base de datos, o si se podrá volver a prender sin que nada se rompa. Ayúdanos Dios del Serengueti, Amo de los ñúes, que realizan migraciones más peligrosas que la de una base de datos.

Pero yo uso tareas programadas a medianoche, Eso me salva de este tradeoff, ¿verdad?. Son las soluciones típicas en donde no hay demasiada saturación de manera que por unas horas los bloqueos en los procedimientos almacenados se cansan de trabajar. La hora perfecta para evitar una vez más que los del área de Inteligencia de Negocios no sobrecarguen la base de datos en pleno día. Entonces es un buen momento para un backup completo. Esto nos llevará más abajo a nuestro 2do tradeoff.

🧩 Como es una tarea manual de migración?

Solo la punta del iceberg de muchas discusiones, pero es necesario revisar punto a punto. Aquí veremos unos de muchos casos de uso.

Veamos cómo realizarlo por scripting rápidamente, para darnos cuenta de las diferencias y complicaciones que revisaremos más abajo.

Dónde:

EC2: docdb-bastion (sin ssl ni pwd)
DocumentDB: docdb2 (sin ssl)
IP Public: 52.89.199.68

Test de conexión a mi clúster de destino

mongo — host docdb2.cluster-cgyttffk8nhp.us-west-2.docdb.amazonaws.com:27017 — username ccortez — password ccortez,,123

Haciendo un mongodump

➜ sudo time mongodump — host 52.89.199.68 — port 27017 — db zips-db — out mongodump-2020–08–202020–08–20T19:48:26.295–0500 writing zips-db.zips to
2020–08–20T19:48:27.469–0500 [……………………] zips-db.zips 101/29353 (0.3%)
2020–08–20T19:48:30.472–0500 [……………………] zips-db.zips 101/29353 (0.3%)
2020–08–20T19:48:31.312–0500 [########################] zips-db.zips 29353/29353 (100.0%)
2020–08–20T19:48:31.314–0500 done dumping zips-db.zips (29353 documents)
 6.87 real 0.08 user 0.09 sys

Mongodump y Mongorestore

Creamos un directorio y hacemos un mongodump:

mkdir /var/lib/backupssudo time mongodump — db zips-db — out /var/lib/backups/mongodump-2020–08–192020–08–19T18:44:31.284+0000 writing zips-db.zips to
2020–08–19T18:44:31.340+0000 done dumping zips-db.zips (29353 documents)
0.04user 0.01system 0:00.06elapsed 79%CPU (0avgtext+0avgdata 25664maxresident)k
 0inputs+5432outputs (0major+4079minor)pagefaults 0swaps

Luego vamos a verificar los datos en :

ll /var/lib/backups/mongodump-2020–08–19/zips-db/total 2716
 -rw-r — r — 1 root root 2774134 Aug 19 18:44 zips.bson
 -rw-r — r — 1 root root 126 Aug 19 18:44 zips.metadata.json

Restauramos la data en el documentDB:

cd /var/lib/backups/mongodump-2020–08–19/

Usamos mongorestore:

sudo time mongorestore — host docdb2.cluster-cgyttffk8nhp.us-west-2.docdb.amazonaws.com:27017 — username ccortez — password ccortez,,123 — db zips-db — drop zips-db

Output de la consola:

2020–08–19T18:47:13.100+0000 the — db and — collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use — nsInclude instead
 2020–08–19T18:47:13.101+0000 building a list of collections to restore from zips-db dir
 2020–08–19T18:47:13.102+0000 reading metadata for zips-db.zips from zips-db/zips.metadata.json
 2020–08–19T18:47:13.119+0000 restoring zips-db.zips from zips-db/zips.bson
 2020–08–19T18:47:14.160+0000 no indexes to restore
 2020–08–19T18:47:14.160+0000 finished restoring zips-db.zips (29353 documents)
 2020–08–19T18:47:14.160+0000 done
 0.10user 0.02system 0:01.19elapsed 11%CPU (0avgtext+0avgdata 30228maxresident)k
 21376inputs+0outputs (44major+5214minor)pagefaults 0swaps

Debemos de realizar esta acción o colocarla en un CRON Job, para que se ejecute periódicamente en los servidores virtuales o en un docker container

Opcional — backup a AWS S3:

Vamos a la ruta donde estan nuestros backups de mongodb:

cd /var/lib/backups/

Compresión TAR.GZ: Usamos tar cvfv para generar un .tar.gz

sudo tar czfv mongodump-2020–08–19.tar.gz mongodump-2020–08–19mongodump-2020–08–19/
 mongodump-2020–08–19/zips-db/
 mongodump-2020–08–19/zips-db/zips.metadata.json
 mongodump-2020–08–19/zips-db/zips.bson

Upload a AWS S3

Necesitamos una tool o la cli de aws. En esta caso usaremos s3cmd.
También necesitaremos un AWS IAM User y sus credenciales en caso sea.
Si se usa AWS CLI dentro de un EC2 o Cloud9 con Instance Role, ya no será necesario.
Crear un bucket de s3: aws s3 mb s3://bucket-name

Instalar las dependencias necesarias:

sudo pip install s3cmds3cmd — configure
s3cmd lscd /var/lib/backups/

Correr Job de AWS S3

Empezaremos a sincronizar la información a un bucket s3

s3cmd sync mongodump-2020–08–19.tar.gz s3://backups-mongo-cdmx/zips-db/WARNING: Empty object name on S3 found, ignoring.
 upload: ‘mongodump-2020–08–19.tar.gz’ -> ‘s3://backups-mongo-cdmx/zips-db/mongodump-2020–08–19.tar.gz’ [1 of 1]
 879437 of 879437 100% in 0s 4.75 MB/s done
 Done. Uploaded 879437 bytes in 1.0 seconds, 858.83 KB/s.

y luego:

s3cmd ls — region us-west-2 s3://backups-mongo-cdmx/zips-db/2020–08–19 21:31 0 s3://backups-mongo-cdmx/zips-db/
2020–08–19 21:35 879437 s3://backups-mongo-cdmx/zips-db/mongodump-2020–08–19.tar.gz

🧩TradeOff #2: Homologar la BD vs Ingesta continua

Al usar un método de migración no automatizado, tenemos que programar actualizaciones antes de la puesta en marcha, debido a que la base de datos que se encuentra en datacenter, sigue insertando y modificando datos. La mayoría de veces, homologar una base de datos toma horas, hasta amanecidas configurandolo correctamente, y hay una probabilidad de que algo pueda salir mal y tengamos que presionar el botón de rollback que nadie quiere.

En MongoDB, se complica la homologación si nuestra arquitectura contiene, replica sets, árbitros, nodos ocultos, nodos de respaldo, particionamiento, diferentes tipos de índices a columnas con millones de registros y otras cosas más.

Es allí donde DocumentDB y AWS DMS con Change Data Capture y la instancia de replicación nos van a hacer la vida más sencilla con una ingesta continua

Solo tenemos que habilitar Change Streams primero en nuestro clúster antes de poder usar CDC en AWS DMS.

db.adminCommand({modifyChangeStreams: 1,
 database: “DB_NAME”,
 collection: “”, 
 enable: true});

Así vamos a poder descansar un poco mejor para no quedar muerto de tantas veces hacer la bendita homologación.

🧩TradeOff #3: Migración segura vs rápida

AWS DMS, nos provee de protección y cifrado durante la migración, ya sea de la fuente de datos hacia nuestra instancia de replicación como hacia nuestro destino, vía AWS KMS, para los datos que estén en reposo, antes de ser enviados hacia AWS S3, para luego ser enviados al destino. Uno mismo puede crear una llave personalizada usando KMS Custom Keys.

Y de la misma manera, para el cifrado de datos en tránsito, vía SSL con TLS. DMS es security compliance, así como el manejo de los accesos por IAM, llamada por Signature Version 4, para autenticar los requests hacia el API.

Es necesario colocarnos toda esa armadura y luchemos por una migración sin errores, y dejar de pensar que la seguridad se hace al último. Evitemos apresurarnos y adoptemos buenas prácticas de seguridad.

🧩Más allá de los tradeoffs

Refactorizar: Siempre piensa en modernizar nuestros procesos, arquitectura, infraestructura, desacoplar nuevos elementos que puedan mejorar la performance del sistema y sin tanto afectar los costos.

Comunicarte: Estar en contacto con otras áreas te hace tener mejor visión de los próximos pasos o dolores que puedan ocurrir, sea en el cargo que estés, Si eres un Arquitecto de Soluciones, pues integrarte con el equipo de UX o Diseño será enriquecedor.

Aceptarlo: Es necesario entender la realidad de lo que estamos construyendo, monitoreando y diseñando, pero si no es de tu agrado, lo primero es aceptar la realidad tal como es, dejar de sentirte frustrado de que todo está mal hecho, y luego investigar para preparar un gran cambio. Vas a estar mejor preparado para enfrentar estos tradeoffs, o evitarlos completamente.

Automatizar: Acuérdate que mientras más tiempo pases frente al servidor, más probable de que algo falle, mejor, diseña soluciones automáticas, programadas, que reduzcan el riesgo de que un humano siga con los dedos en producción. Aún es un problema latente que las empresas demoran en evolucionar hacia los pipelines de despliegue para integración contínua.

🧩 Conclusión

Ninguna herramienta es indispensable.

Debemos de estar en constante evolución y entendimiento del negocio, lo que nos permitirá saber cuál camino tomar hacia una correcta modernización de nuestros servicios. Esto está directamente relacionado con hacer o no hacer una migración. DocumentDB es una base de datos muy flexible y tiene componentes que podemos hacer escalables sin problemas. Si bien es cierto, no es un motor puro de MongoDB, considero que el equipo de AWS ha logrado replicar lo mejor de esta Base de datos NoSQL, haciéndolo escalable y altamente disponible, fácil de usar, con la facilidad de seguir usando sintaxis y consultas de este motor increíble.

Faltaría que nos habiliten el CDC bidireccional entre una DocumentDB y un MongoDB. Esto sí sería fenomenal para el diseño de una recuperación de desastres.