MongoDB en AWS, Arquitectura rápida de Data Sharding

MongoDB en AWS, Arquitectura rápida de Data Sharding

MongoDB, quizás, es una de las bases de datos NoSQL más conocidas. El siguiente post quiere dar una pincelada rápida a una construcción simple, escalable y en formato [sharding](https://en.wikipedia.org/wiki/Shard_(database_architecture) en AWS.

AWS dispone de una template de AWS Cloud Formation para hacernos la vida un poco más simple, pero veamos primero que partes tendría la Arquitectura, para así poder entenderla mucho mejor.

Primero tendremos que obviar, no es recomendable, la seguridad más perimetral. Ya que se debería hacer un trabajo prévio y muy preciso para poder encontrar cuál debería ser la configuración más personalizable ya que podría llegar a impactar tanto en tiempos de latencia en respuestas o bien en riesgos sobre la seguridad.

MongoDB on AWS

Si nos disponemos a lanzar la template de AWS Cloud Formation tendremos una Arquitectura totalmente separa de nuestros recursos ya que, automáticamente, creará una nueva VPC donde se desplegarán los distintos recursos. Naturalmente, ésta, desplegará más recursos de networking como son los NAT gateway para garantizar la publicación a Internet pero nos fijaremos en los recursos más de sistema.

Es muy importante lo que referencia a los grupos de seguridad (Security Groups) para así poder garantizar la comunicación dentro de la VPC y limitar los accesos a solo los puertos y protocolos publicados, por ejemplo el puerto 27017.

La Arquitectura de MongoDD tendrá un conjunto de instancias con un claro objetivo: poder tener un conjunto de réplicas. Éstas replicaciones consisten en la posibilidad de poder garantizar una alta disponibilidad en caso que una o varias instancias pudieran dejar de funcionar. Ésta Arquitectura nos permite construir un conjunto de uno o tres conjuntos de réplicas. Si nuestra elección es tres, se emplementaran tres instancias en tres zonas de disponibilidad distintas para así garantizar un despliegue MultiAZ. Los Roles de las instancias, por ejemplo, podrían ser: principal o master, secundario 1 y secundario 2.

La arquitectura de MongoDB es que sus nodos secundarios interactúen con su nodo principal para todas aquellas operaciones de lectura y escritura. Una de las ventajas es que podremos escoger un nodo secundario como preferencia para nuestras operaciones de lectura y así descargar el principal, aunque aquellas operaciones que sean de escritura siempre, siempre, se van a realizar a nuestro nodo principal y se replican de forma asíncrona en el resto de nodos secundarios. Hay que decir que ésta propuesta de Arquitectura está pensada para entornos de Producción, para otros entornos seguramente no haría falta tener una arquitectura tan compleja.

Otra de las principales ventajas, por ejemplo, es que cuando una instancia principal falla o tiene una indisponibilidad de servicio, otra de las instancias secundarias podrá convertirse en el nuevo nodo principal y, de este modo, garantizar la continuidad del servicio.

MongoDB Nexus Architectures

También, la fragmentación de los datos nos permitirá tener un almacenamiento distribuido de éstos, es decir, repartirlos entre los distintos nodos para así tener una mayor escalabilidad horizontal y mayor performance en operaciones de lectura y escritura. Cuando tenemos un volúmen bastante grande de datos, disponer de un solo nodo podría ocasionar que él mismo pudiera sufrir un efecto cuello de botella es por eso que la fragmentación resuelve este problema reduciendo el número de operaciones de las que se encarga cada nodo, mejorando la performance global del sistema. Cierto es que, de entrada, la solución por defecto que trae MongoDB no nos permite tener éste factor de fragmentación de datos pero si un Índice o “ReplicaShardIndex” el cual permite catalogar o unir los distintos conjuntos de réplicas.

Naturalmente uno de los mayores impactos será crear aplicaciones y/o productos que tengan las capacidades de poder usar este poder de fragmentación de datos, bien, si, podemos crear endpoints únicos de conexión pero, la gracia, es poder controlarlo desde una capa de servicio y dejar atrás el control directamente en las capas más físicas: aquí es donde dejamos atrás la construcción de arquitecturas relacionales, un gran paso.

Autor: Joakim Vivas

comments powered by Disqus