Seminario Web MongoDB-Paradigma: Cree aplicaciones más escalables utilizando microservicios

Seminario WebMongoDB & Paradigma

Desarrolle aplicaciones más escalables utilizando microservicios

Ruben TerceñoSenior Solutions ArchitectMongoDB

Miguel GarridoSenior Solutions Architect Paradigma Digital

Agenda

Introducción a los microservicios:¿Por qué han surgido? ¿Qué beneficios aportan frente a arquitecturas tradicionales?

Nuevas tecnologías que ayudan en arquitecturas de microservicios

¿Qué beneficios aporta el uso de MongoDB en este tipo de arquitecturas?

INTRODUCCIÓN A LOS MICROSERVICIOS

5

Definición de microservicio“Microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.”

6

Un poco de historiaEquipo de desarrollo

Arquitecturas monolíticas (pre-SOA)

Arquitecturas SOA Microservicios

En arquitecturas monolíticas cualquier cambio afecta al producto completo y todos los equipos deben estar de acuerdo en implementarlo.

Los elementos en SOA se desarrollan de manera más autónoma pero los equipos deben coordinarse con otros para que los cambios encajen en el diseño general.

El nuevo paradigma de desarrollo

7

• Alto nivel de acoplamiento

• Complejidad de código

• Un pequeño cambio de código en la aplicación implica un despliegue

completo

• Escalado ineficiente

• Menos especialización

Arquitecturas monolíticas

8

• Menor acoplamiento entre servicios

• Bus de servicios que mapea el servicio lógico y llama al servicio físico

• Se premia la reusabilidad, lo que puede llevar a que contengan

demasiado código

• Los servicios tienen estado

• Suelen utilizar modelos de datos relacionales

• En algunos casos, es complicado separar la funcionalidad entre

servicios

Arquitecturas SOA

9

Arquitecturas de microservicios

• Principio de responsabilidad única

• Desarrollo eficiente

• Escalado elástico

• Ciclo de vida independiente

• Menor Time-to-Market (Continuous Delivery)

• Facilidad de integración con otros sistemas

10

Retos de una arquitectura de microservicios

• ¿Dónde se encuentran desplegados los servicios?

• ¿Qué pasa si alguno falla?

• ¿Cómo se configuran?

• ¿Dónde se guardan las trazas?

• ¿Cómo los monitorizamos?

• ¿Cómo los desplegamos?

• Gestionar el aumento del tráfico internoPaaS

Microservicio 1

Microservicio 2

Microservicio 3

Microservicio 4

Servicio de enrutamiento

Almacenamiento

Servicio de orquestación

Servicio de descubrimiento

Registro de contenedores

Consumidores

Servicios de logging / monitorización

Servicio de configuración

Herramienta de CI

Control de versiones

Alejandro Asensio González

Representar los retos sin nombres, de manera genérica.

11

Herramientas

Microservicio 1

Microservicio 2

Microservicio 3

Microservicio 4


Docker registry



Devops

Consumidores



12

Herramientas

Microservicio 1

Microservicio 2

Microservicio 3

Microservicio 4


Docker registry



Devops

Consumidores



Encargado del pipeline de

Continuous Delivery

Gestión del código fuente de los

microservicios

Gestión de imágenes docker de los

diferentes microservicios

Motor de base de datos

13

Ejemplo de una arquitectura de microservicios

PaaS

Consumidor 1

CPD 1

Node 1

Gestión de pedidos

Gestión de clientes

Gestión de artículos

Gestión de usuarios

Node 2

EurekaGestión de clientes

CPD 2

Node 3

Gestión de pedidos

Node 4

Gestión de clientes

Gestión de artículos

Gestión de usuarios

Zuul

Zuul

Spring Cloud ConfigEurekaSpring Cloud

Config

MongoDBMongoDB

CPD 3 (virtual)

MongoDBArbiter

Master 1 Master 2

MongoDBMongoDB

Master 3

Consumidor 2 Consumidor 3 Consumidor 4 Consumidor 5 Consumidor 6

14

• Como hemos visto, la manera de comunicarse entre microservicios son los protocolos de red, especialmente el

protocolo http, definiendo APIs REST como interfaz de comunicación. Estas APIs proporcionan:

– Organizan sistemas internos para dar apoyo a nuevos proyectos innovadores de una manera uniforme.

– Reducen costes de mantenimiento.

– Incrementan la agilidad en los procesos de transformación.

– Acercan la omnicanalidad a la empresa

Microservicios y APIs

Servicio

API

15

JSON como formato de intercambio

• JSON son las siglas de JavaScript Object Notation, y fue originalmente pensado para llevar la notación nativa

usada para declarar objetos en JavaScript a otros lenguajes. Proporciona:

– Flexibilidad

– Ligereza

– Evita transformaciones con bases de datos en formato JSON

– Modelo de datos autoexplicativo

16

Proyecciones y expansiones

• Funcionamiento similar a MongoDB

• Minimizan el tráfico y optimizan el servicio en casos de acceso a múltiples datastores

• Ejemplo de llamada con proyección: rest/api/content?type=page&spaceKey=TEST&projections=version, history

• Proporcionan mayor rendimiento y menor consumo, limitando el número de llamadas a un API

• Permiten la expansión de campos e items embebidos de un recurso

• Ejemplo de llamada con expansión: rest/api/content?type=page&spaceKey=TEST&expand=version,history.lastUpdated

Proyecciones Expansiones

17

Transaccionalidad en microserviciosLa división de los datos en diferentes repositorios (base de datos, colas de mensajes, etc) y su accesibilidad a través de servicios que los envuelven supone perder la transaccionalidad nativa a nivel de base de datos:

Existen diversos patrones que permiten tratar esta situación:

• Reintentar: en situaciones de caída puntual o no disponibilidad parcial del servicio (caída de un nodo por ejemplo), reintentar la operación puede ser una solución válida.

• Abortar la operación completa: en esta situación, debe existir una operación de ‘compensación’ para volver a un estado de consistencia.

• Transacción distribuida: basa su funcionamiento en la la existencia de un proceso de gobierno de la transacción (‘transaction manager’).

Ok

Servicio 1

Servicio 2

Servicio 3

Servicio 3

Ok

Reintento

Servicio 1

Servicio 2

Servicio 3

Deshacer

Coordinador

Servicio 2

Servicio 3

Preparar

Servicio 1 Commit

TECNOLOGÍAS MICROSERVICIOS

19

Cloud, IaaS y PaaS

• Ayudan con la gestión eficiente de recursos

• Posibilitan escalado ilimitado

• Delegación de responsabilidad en piezas propias (balanceo de

carga, enrutamiento, descubrimiento, seguridad...etc)

• Monitorización de servicios

• Logs centralizados

• Trazabilidad de servicios

• Despliegue automatizado con estrategias de balanceo

automáticas

20

Docker containers

• Proveen entornos aislados gestionados por procesos (hypervisor) con el mínimo kernel de sistema operativo en cada contenedor

• Con el mismo hardware se pueden ejecutar más contenedores que con máquinas virtuales

• Docker ha conseguido un gran seguimiento de la comunidad con un repositorio público de imágenes, Docker Hub, que contiene sobre 400.000 imágenes

21

Broker de mensajería

• Broker de mensajería publisher / subscriber con persistencia en disco

• Conecta microservicios

• Desacopla llamadas entre microservicios

• Proporciona alta disponibilidad

Microservicio 1 Microservicio 2

Almacenamiento

Microservicio 1 Microservicio 2

Almacenamiento

- Dependencia entre servicios- Gestión de errores y reintentos en el servicio llamante

- Añadir un nuevo servicio implica sólo suscripción- Gestión de reintentos en Kafka- Desacoplamiento entre servicios

MICROSERVICIOS Y MONGODB

23

Bases de datos NoSQL

Lenguaje de búsqueda expresivoÍndices secundarios

Consistencia Fuerte

Integración con herramientas de gestión

Escalable y distribuido• Escalabilidad horizontal• Cloud

Rendimiento• Usuarios globales• Muy alta disponibilidad

Flexibilidad• Esquema flexible• Datos no estructurados• Sin relaciones complejas

24

MongoDB Nexus Architecture

Lenguaje de búsqueda expresivoÍndices secundarios

Consistencia Fuerte

Integración con herramientas de gestión

The only NoSQL Database that combines best of RDBMS + NoSQL

Escalable y distribuido• Escalabilidad horizontal• Cloud

Rendimiento• Usuarios globales• Muy alta disponibilidad

Flexibilidad• Esquema flexible• Datos no estructurados• Sin relaciones complejas

25

Modelo de datos flexible

Consumidor A Consumidor B

Microservicio 1

• El esquema flexible de MongoDB permite que cada consumidor del servicio pueda tener una percepción propia de un modelo común, sin afectar esto a la morfología del dato en MongoDB

• La propagación de los cambios en el modelo de datos de los consumidores es automática

• Las vistas read-only permiten exponer el modelo de datos de forma polimórfica y realizar ofuscación

26

Redundancia

Debido a la naturaleza distribuida de los microservicios, estos tienen que ser diseñados teniendo en cuenta la redundancia del dato. MongoDB encaja perfectamente en este requerimiento, ya que proporciona de base redundancia a través de sus replica set.

Es muy importante destacar MongoDB permite que la política de redundancia puede ser variable por petición y por criticidad del dato

CloudCPD 2CPD 1

Replica set

Nodo 1 Nodo 2 ArbiterNodo 3 Nodo 4

Los microservicios no se pueden interrumpir para hacer cambios en su esquema de datos. MongoDB puede adaptarse a cambios en el esquema de datos sin ninguna pérdida de servicio. Su arquitectura independiente de la plataforma proporciona facilidad de portabilidad.

Frontend Applications

Digital & Mobile Apps

Backend Applications … Operational & BI

Reporting

Application Layer

API Access Layer

MicroservicesLayer

Database Layer

Flexibilidad para modelar estructuras de datos cambiantes sin necesidad de parar la plataforma para realizar mantenimiento.

1

MongoDB and Microservices – Flexibility

La habilidad de escalar rapidamente para adaptarse a una demanda cambiante es un atributo clave de los microservicios. La arquitectura de MongoDB permite escalado y alta disponibilidad de forma nativa.




Reporting

Application Layer

API Access Layer

MicroservicesLayer

Database Layer

2 La escalabilidad y alta disponibilidad nativas se dan la mano con el alto rendimiento necesario en una plataforma de microservicios.

MongoDB and Microservices – Scalability

MongoDB proporciona funcionalidad de autenticación, control de acceso, auditoría y cifrado para proteger los despliegues de MongoDB. Las vistas read-only permiten exponer el modelo de datos de forma polimórfica y realizar ofuscación.




Reporting

Application Layer

API Access Layer

MicroservicesLayer

Database Layer

3 Seguridad nativa que protege los datos y facilita el desarrollo de aplicaciones al asumir el control de accesos y la visibilidad.

MongoDB and Microservices – Security

Nuestra receta:

Orquestación de MongoDB con Docker

Gestiona y provisiona los contenedores

Convierte un grupo de contenedores en un único servicio

Define una aplicación multicontenedor en un único fichero de descripción

PS

S

Ecosistema Docker

OrquestaciónCoordina los contenedores de MongoDB para realizar un despliegue según las mejores prácticas.

Control de RecursosDimensionado de cada instancia (y cada clúster) para evitar contención de recursos

Docker

5x más rápido que Kubernetes para lanzar un

nuevo contenedor

7x más rápido que Kubernetes en listar

los contenedores activos

Evaluación de plataformas a gran escala

1000 instancias EC2 en un clúster

¿Rendimiento?

¿Capacidad operativa?

¿Facilidad de soporte?

https://medium.com/on-docker/evaluating-container-platforms-at-scale-5e7b44d93f2c#.k2fxds8c2

https://www.docker.com/survey-2016

Porqué Swarm?

swarm-node-2

swarm-node-3swarm-node-1

¿Cómo conectamos los diferentes procesos mongod?• Swarm proporciona redes host a host • Utiliza el hostname definido en el archivo Compose

magicmagic

magic

Redes multi host de Swarm

SECONDARY

cgroup/docker

cgroup/docker cgroup/docker cgroup/docker

cgroup/docker cgroup/docker

cgroup/dockercgroup/docker cgroup/docker




PRIMARY SECONDARY SECONDARY

PRIMARY SECONDARY

PRIMARYSECONDARY SECONDARY




Tendremos un primario y al menos dos secundarios por aplicación.

Definiremos reglas de afinidad en Docker Compose para evitar que los miembros de un mismo replicaset se desplieguen el en mismo servidor físico.

Con Linux cgroups aislaremos los recursos (RAM / CPU / BlockIO) a lo que tendrá acceso cada mongod.

MongoDB Ops/Cloud Manager es clave en este proceso ya que permite la provisión programática !

MACHINE 1

AP

P 1

MACHINE 2 MACHINE 3

AP

P 2

AP

P 3

AP

P 4

AP

P 5

AP

P 6

SECONDARY

Despliegue en alta disponibilidad

SECONDARY

cgroup/docker

cgroup/docker cgroup/docker cgroup/docker

cgroup/docker cgroup/docker





PRIMARY PRIMARY SECONDARY

PRIMARY PRIMARY





MACHINE 1

AP

P 1

MACHINE 2 MACHINE 3

AP

P 2

AP

P 3

AP

P 4

AP

P 5

AP

P 6

SECONDARY

En caso de fallo a nivel de servidor alguno de los nodos secundarios tomará el rol de primario.

Cuando los contenedores de la máquina en fallo se vuelvan a levantar, siempre que respeten los nombres la arquitectura se resincroniza.

Evento de HA (La ley de Murphy)



Backend Applications

… Operational & BI Reporting

Application Layer

API Access Layer

Microservices

Layer

DatabaseApplicatio

n

Storage

Modelo Uno:Contenedores para todos

Pros:• Se despliega como un todo• Se migra fácilmente entre

entornos

Cons:• El storage debe ser

persistente• La comunicación intra nodo es

más compleja• Más difícil de debugear

Arquitectura de referencia



Backend Applications

… Operational & BI Reporting

Application Layer

API Access Layer

Microservices

Layer

Database Cluster

Modelo Dos:Contenedores para la aplicación

Pros:• Permite a la base de datos

manejear su propia HA y escalado

• Permite la separación entre las capas lógicas y de datos (Seguridad)

• Más fácil de debuguear

Cons:• La base de datos se

provisiona de forma independiente.

Arquitectura de referencia

• Nuevos clústers en segundos

• Despliegues con redundancia y alta disponibilidad

• Completamente elástico, sin pérdida de servicio

• Parches automáticos y acceso inmediato a nuevas funcionalidades

• Con autenticación y cifrado

• Backup continuo con recuperación a la carta

• Alertas personalizables y monitorización fina

Completamente seguro

Ya lo hacemos nosotros

• Pago or uso. Facturación por horas

• Soporte multi cloud (AWS ahora mismo, Azure & Google Cloud antes de verano)

• Fácil migración mediante herramientas a despliegues cloud, on premise o híbridos.

Sin trucos

MongoDB AtlasBase de datos como servicio de MongoDB

Preguntas

Gracias.

[email protected]

@mongodb

www.mongodb.com

mailto:[email protected]

Seminario Web MongoDB-Paradigma: Cree aplicaciones más escalables utilizando microservicios

Data & Analytics

Transcript of Seminario Web MongoDB-Paradigma: Cree aplicaciones más escalables utilizando microservicios