Data Scaling Architectures & Data Caching Architectures en AWS (Hazelcast vs Elasticsearch vs Memcached)

Data Scaling Architectures & Data Caching Architectures en AWS (Hazelcast vs Elasticsearch vs Memcached)

Hoy en día uno de nuestros grandes retos es poder escalar, en el momento oportuno y durante el tiempo necesario (no más de lo necesario, por su impacto en costes). Para poder dar solución, por lo general, nuestras arquitecturas han ído sufriendo cambios, introduciendo balanceadores de carga, para distribuir el tráfico de forma horizontal (que no vertical) y introduciendo también caché en la cap de publicación.

Con la introducción del Cloud y más concretamente de sus servicios PaaS, nos hemos podido “olvidar” un poco de estos escalados tanto en la parte de publicación como también en la parte de base de datos, que es mucho más complejo el escalado ya que, la aplicación también debe estar preparada para atacar a “múltiples” bases de datos. No siempre pasa eso. Pero, al final, podíamos tener rápidamente esta situación:

  • Una capa de balanceo para la publicación, que a partir de múltiples nodos con escalado horizontal podían asumir el tráfico web y servirlo a nuestros visitantes.
  • Una base de datos monolítica con crecimiento vertical y, máximo, máximo, varias bases de datos que dan servicio según componente pero, al final, siguen siendo una base de datos con opciones de reader/writer para cubrir las necesidades.

Esto, a la larga, no era sostenible o bien, los costes en infraestructura se disparan por la necesidad de tener tallas muy grandes para poder sostenerlo. Es por ello que podemos tener varias soluciones que podrían aportar mucha luz y una importante reducción de costes si se aplica de forma correcta, veamos dos posibilidades:

Data Scaling Architectures

Data Scaling

En ésta primera imagen tenemos un primer paso a transformar lo que comentamos anteriormente, es decir, preparar nuestra aplicación para poder atacar a un sistema de base de datos que escala, también. Pero que no solamente escala en vertical, sinó también en horizontal y según su caraterística.

En un primera paso, definimos que una instancia de base de datos de talla “X” será la Master, es decir, será que la haga el write de los datos.

En un segundo paso, definiremos una o varias, según nuestras necesidades, que de forma predeterminada estarán operativas para tener una Read replica de la base de datos Master. Por lo tanto, solo aceptaran procesos de lectura.

Este simple cambio en nuestra arquitectura, de entrada, nos permitirá una serie de mejoras, hagamos un pequeño listado:

  • Poder escalar de forma automatizada una base de datos en modo Read Replica para poder dar servicio a la capa de publicación que, mayormente, hacen sólo ataques de lectura. Estamos hablando de páginas de información o procesos de consulta.
  • Poder configurar una Read Replica según compontente, posiblemente tengamos componentes de nuestra aplicación, por ejemplo APIs, que deban tener una preferencia mayor respecto de otros. Pues démosles esa preferencia con recursos casi dedicados o dedicados y autoescalados también.
  • Poder tener una instancia writer dedicada sólo y exclusivamente a esa función, separando así un % muy elevado de uso de la base de datos que, seguramente y siguiendo las afirmaciones anteriores, sólo son procesos de lectura.

En la imagen que acompaña el caso sólo mostramos los componente de publicación básicos y las bases de datos, naturalmente piezas como balanceadores, etc… no figuran en el diagrama. En este caso, tampoco las APIs, en el dibujo del caso siguiente, si visualizaremos las APIs.

Data Caching Architectures

Data Caching

En esta segunda imagen, tenemos un diagrama distinto al anterior ya que, damos menos importancia a la capa de base de datos e introducimos un nuevo componente: Data Cache.

Quiero hacer un incapié en Data Cache ya que no estamos hablando de un cache en la capa de publicación, como podría ser Vasnish. Estamos hablando de una capa “más inteligente”, como podría ser: Elasticache con un Redis en su interio o Elasticsearch Service, ambos servicios de AWS u otras cosas como Hazelcast.

La gente de Hazelcast tienen un interesante artículo de comparativa entre sus servicios y otros, aquí mencionados.

No entraré a comparar las soluciones, me interesa más explicar los fundamentos. Por lo tanto, veamos con más detalle la imagen anterior:

  • Por un lado continuamos teniendo el mismo modelo de entrada, donde “N” nodos autoescalados darán servicio de publicación de nuestra aplicación, con sus balanceadores, etc…
  • Y por otro lado, tendremos un API Gateway, para aquellos accesos programáticos que podamos tener.

Dejando a parte piezas que, con mucho más detalle se tendrían que treabajar, por ejemplo las APIs, entraremos a explicar el fundamento. Veamos de nuevo:

Al establecer una capa de Data Cache podremos, por ejemplo, volcar en ella nuestro Modelo de datos o Domain Model. Para no solamente hacer un simple cache de datos, sinó tambien poder indexar y establecer ciertos criterios de negocio e inteligencia.

A su vez, podremos establecer procesos que hagan una publicación de datos hacia la Data Cache y otros que hagan un consumo (Subscriber). Por lo tanto, dejaremos a la capa de Data Cache la interacción al 100% con la o las bases de datos que podamos tener tras ella.

También, esta capa de Data Cache podría interactuar con otras tipologías de arquitecturas como: REST (ara las APIs). Estaríamos hablando que el tiempo de cache que tienen los sistemas más tradicionales, aquí no se vería afectado ya que al tener también los cambios podría entregar realtime para su consumo.

Review

Naturalmente, hay que trabajar con mucho más detalle cada punto de los aquí comentados, pero me agradaría que pudieran ser utilizados como inicio. Espero poder continuar trabajando al respecto y añadir nuevos capítulos a éste post para explicar casos de forma mucho más ampliada.

Autor: Joakim Vivas

comments powered by Disqus