De tipologías de Arquitectura de infraestructura hay muchas pero, así de entrada, podemos diferenciar entre: “High Performance” y “High Availability”. Que por cierto, podemos implementar las dos en una misma, por ejemplo, nuestro post de hoy. Vamos a ver una arquitectura, bastante económica, para poder tener el siguien esquema lógico: Acceso de los usuarios > Validaciones > Retorno de datos > Ingestión de información (Evento) > Transformación de la Información >Indexación > Visualización (Explotación). En el siguiente diagrama lo podemos ver representado, a continuación, comentaremos brevemente los pasos.

Acceso de usuarios + Validaciones iniciales

Imaginemos que nuestros usuarios acceden a nuestro servicio, pero que antes necesitaremos recogerles una información para servirles un contenido más adecuadas. Estamos hablando por ejemplo de servicios que sirven contenido distinto según zona geográfica, tipo de dispositivo móvil, tipo de suscripcion, etc… Una vez recogida esta información, que a través de una pieza de networking (no representada en el diagrama) se conducirá a una function o AWS Lambda en nuestro caso.

Ésta tendrá la misión de realizar la validación del servicio y, vemos en el diagrama, lo realizará contra una base de datos en memoria del tipo Redis (AWS ElastiCache), por ejemplo. También, importante, podemos ver (flechas amarillas) que tendrá la posibilidad auto-escalarse (High Availability) de forma automática y según necesidad de nuestro servicio. ¿Qué pasaría si acceden miles de usuarios a nuestro servicio? ¡Pues tenemos que tenerlo controlado!.

Data Stream

Una vez realizadas las validaciones, capturaremos el o los distintos eventos (event-driven), que serán recogidos por proceso basado en Streams y utilizando AWS Kinesis (o Kafka) para ello. Dentro del mismo proceso en Streams podremos aplicarle un proceso de transformación (EMR) del dato para convertir, si requerimos, el RAW Data recogido en un dato normalizado o entendible para nuestra Solución (opcional); sinó, entregaremos el dato tal cual al siguiente componente.

Indexación de la información + Visualización

En nuestro ejemplo de hoy no estamos sirviendo la información a una aplicación, sinó a la necesidad de tener controlados los accesos a los servicios y es por eso que el siguiente componente es otra base de datos en memoria pero, basada en índices. ¿Motivo?, el poder tener la información categorizada por necesidades. Es decir: podemos imaginar que tendremos un indice global o por tipología de servicio, etc… irá en función de nuestras necesidades. La idea será, luego, podemos recuperarlo en formato visualización mediante un Kibana u otra herramienta de Data Visualization.

La suma de los componentes de Elasticsearch y Viewer (ELK) nos van a permitir tener controlado, en casi realtime, nuestros servicios y que usos se les están dando.

Lo más importante de todo es que esta Arquitectura, en AWS, tendrá un coste aproximado de 500€/mensuales, bastante asumible para empreses que requieren un tratamiento alto de información y que su gran Valor es el poder tratarla como tal: en realtime.

Autor: Joakim Vivas