¬¬¬
Akka sharding
=============
¬¬
¬¬¬
## Sobre el ponente
### Nombre: **Miguel Rafael Esteban Martín**
### Ingeniero de plataformas en ING
#### Blog : [Logicaalternativa.com](http://www.logicaalternativa.com)
#### GitHub: [github/logicaalternativa](https://github.com/logicaalternativa)
#### Twitter: [@MiguelREsteban](https://twitter.com/MiguelREsteban)
##### Diapositivas de esta presentación: [https://wwww.logicaalternativa.com/slides/akka-sharding](https://wwww.logicaalternativa.com/slides/akka-sharding)
¬
###### Akka sharding
----------------------------------------------------------------
¬
## Que vamos a ver ##
¬
- Que es Akka Sharding y su relación con Domain Driven
Development.
- Los fundamentos técnicos en los que está soportado
- Ejemplos prácticos (codificados en Scala)
¬
###### Conceptos clave sobre actores
----------------------------------------------------------------
## Actor = _"Comportamiento y estado"_ ##
¬
###### Conceptos clave sobre actores
----------------------------------------------------------------
## "¿Qué define a un actor?"
¬
¬
"_[...] Los actores son objetos que encapsulan estado y
comportamiento y que sólo se comunican intercambiando
mensajes [...]_"*
¬
¬
Derivado de esto: implica también"**_identidad_**"
¬
¬
###### * __Documentación de Akka__
###### Conceptos clave sobre actores
----------------------------------------------------------------
## Glosario y características de Akka
### Mailbox
Todos los actores tienen su propio buzón donde se almacenan los
mensajes.
### ActorRef
Es en realidad una URI o dirección lógica del actor. Es
serializable y se puede enviar entre actores. Esto permite la
**ubicación transparente** en el sistema de actores.
### Dispatcher
Es el encargado de gestionar los mensajes con un grupo de hilos
asignado.
Símil de la "_torre de control_": los **hilos** son las pistas de
aterrizaje, los **mensajes** son los aviones que esperan a tomar
tierra y el **dispatcher** sería la torre de control.
Se puede asignar un dispatcher a uno o varios actores.
### Patrones de estabilidad
Akka "_out of the box_" implementa patrones de estabilidad com
"_Bulkheading_", "_Circuit breaker_", "_bounded mailbox_",
Supervisores, Confirmación de entrega (confirmando la entrega de
al menos un mensaje), etc..
¬
###### Conceptos clave sobre DDD
----------------------------------------------------------------
## Entidades en DDD (Domain Driven Desing)
[](img/quicklyDDD.png)
###### Domain-Driven Design Quickly
###### Conceptos clave sobre DDD
----------------------------------------------------------------
## Entidades y agregados en DDD ##
_"[...] implementar entidades en software significa crear identidad
[...]"_ *
¬
### Entidades ###
- Son la base de DDD
- Tienen **identidad**
··· + En el dominio, sólo existe un objeto entidad con ese
identificador
- Tienen un ciclo de vida
··· + Contienen **estado** y **lógica** de negocio
¬
###### (*) Domain-Driven Design Quickly
###### Conceptos clave sobre DDD
----------------------------------------------------------------
## Entidades y agregados en DDD ##
### Agregados ###
¬
- Se considera una unidad con respecto a los cambios de los datos
(= _¿transacción?_)
··· + Un agregado puede estar formado por varias entidades y
objetos valor relacionados entre si.
- Como raíz tienen una entidad que es su interfaz hacia fuera.
··· + Desde fuera no son accesible el resto de objetos.
En resumen : Además de **estado** y **lógica** sólo se puede
acceder a través de una interfaz pública que enmascara la lógica
interna.
¬
###### Conceptos clave sobre DDD
----------------------------------------------------------------
## Entidades y agregados en DDD ##
¬
Ahora nos podemos hacer la pregunta
### _¿Se podría implementar en un sistema de actores?_ ###
¬
###### Conceptos clave sobre DDD
----------------------------------------------------------------
## Entidades y agregados en DDD ##
¬
### _¿Se podría implementar en un sistema de actores?_ ###
- Entidades reflejan estado y comportamiento
··· + _Los actores también_
- Cada instancia de una entidad es única en el dominio
··· + _Un actor es único en el sistema de actores_
- Tienen una interfaz pública de acceso
··· + _En los actores esa interfaz es la mensajería_
¬
###### Desafíos
----------------------------------------------------------------
## Desafíos de tener una entidad única en un cluster
¬
###### Desafíos
----------------------------------------------------------------
## Desafíos de tener una entidad única en un cluster
- **Transparencia referencial**: Para poder usar una entidad, no debe
ser necesario saber en que nodo está alojada.
¬¬¬
###### Desafíos
----------------------------------------------------------------
## Desafíos de tener una entidad única en un cluster
- Transparencia referencial: Para poder usar una entidad, no debe
ser necesario saber en que nodo está alojada.
- **Distribuir las entidades uniformemente en el cluster**.
¬¬¬
###### Desafíos
----------------------------------------------------------------
## Desafíos de tener una entidad única en un cluster
- Transparencia referencial: Para poder usar una entidad, no debe
ser necesario saber en que nodo está alojada.
- Distribuir las entidades uniformemente en el cluster.
- **Creación dinámica de las entidades**, pasivarlas y recrearlas
cuando sea necesario.
¬¬¬
###### Desafíos
----------------------------------------------------------------
## Desafíos de tener una entidad única en un cluster
- Transparencia referencial: Para poder usar una entidad, no debe
ser necesario saber en que nodo está alojada.
- Distribuir las entidades uniformemente en el cluster.
- Creación dinámica de las entidades, pasivarlas y recrearlas
cuando sea necesario.
- **Resistencia a fallos**
··· + Asegurar que sólo y sólo un actor es reflejo de una
instancia de la entidad dentro del cluster.
··· + Si un nodo está caído, que sea posible generarlo en otro
nodo del cluster.
¬
###### Desafíos
----------------------------------------------------------------
## Desafíos de tener una entidad única en un cluster
- Transparencia referencial: Para poder usar una entidad, no debe
ser necesario saber en que nodo está alojada.
- Distribuir las entidades uniformemente en el cluster.
- Creación dinámica de las entidades, pasivarlas y recrearlas
cuando sea necesario.
- Resistencia a fallos
··· + Asegurar que sólo y sólo un actor es reflejo de una
instancia de la entidad dentro del cluster.
··· + Si un nodo está caído, que sea posible generarlo en otro
nodo del cluster.
- "**Persistir el estado**" de estas entidades (*)
###### (*) _Usando Akka Persistence_
###### Akka Sharding
----------------------------------------------------------------
## Akka Sharding ##
¬
###### Akka Sharding
----------------------------------------------------------------
## Akka Sharding en pocas palabras... ##
¬
- Abstrae el concepto de entidad en un **ActorRef**
¬
###### Akka Sharding
----------------------------------------------------------------
## Akka Sharding en pocas palabras... ##
¬
- Abstrae el concepto de entidad en un **ActorRef**
- La **creación** o el **acceso** a cada una de las instancias
de las entidades se hará a través de la mensajería.
··· + _"¿Cómo?"_ Se deberá definir una función para esto.
··· + Incluye también el concepto de **factoría**/**repositorio**
de DDD.
¬
###### Akka Sharding
----------------------------------------------------------------
## Akka Sharding en pocas palabras... ##
¬
- Abstrae el concepto de entidad en un **ActorRef**
- La **creación** o el **acceso** a cada una de las instancias
de las entidades se hará a través de la mensajería.
··· + _"¿Cómo?"_ Se deberá definir una función para esto.
··· + Incluye también el concepto de **factoría**/**repositorio**
de DDD.
- Permite la **distribución** de las diferentes instancias en
**regiones lógicas**.
··· + _"¿Cómo?"_ También a través de función.
¬
###### Akka Sharding
----------------------------------------------------------------
## Akka Sharding en pocas palabras... ##
¬
- Abstrae el concepto de entidad en un **ActorRef**
- La **creación** o el **acceso** a cada una de las instancias
de las entidades se hará a través de la mensajería.
··· + _"¿Cómo?"_ Se deberá definir una función para esto.
··· + Incluye también el concepto de **factoría**/**repositorio**
de DDD.
- Permite la **distribución** de las diferentes instancias en
**regiones lógicas**.
··· + _"¿Cómo?"_ También a través de función.
- Permite **pasivar** las instancias que no se utilicen.
¬
###### Akka Sharding
----------------------------------------------------------------
## Akka Sharding en pocas palabras... ##
¬
- Abstrae el concepto de entidad en un **ActorRef**
- La **creación** o el **acceso** a cada una de las instancias
de las entidades se hará a través de la mensajería.
··· + _"¿Cómo?"_ Se deberá definir una función para esto.
··· + Incluye también el concepto de **factoría**/**repositorio**
de DDD.
- Permite la **distribución** de las diferentes instancias en
**regiones lógicas**.
··· + _"¿Cómo?"_ También a través de función.
- Permite **pasivar** las instancias que no se utilicen.
- Está soportada por **Akka Cluster**.
··· + *Consecuencia*: Es necesario entender como funciona.
¬
###### Akka Sharding
----------------------------------------------------------------
## ¿Qué es Akka Cluster? ##
¬
`"[..] Akka Cluster proporciona un servicio de cluster
descentralizado basado en peer-to-peer, tolerante a fallos, sin
ningún punto único de fallos o cuellos de botella. `
`Lo hace usado protocolos gossip y un detector automático de
fallos[..]"`
¬
¬
¬
###### (*) Documentación akka
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Arquitectura gossip ##
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Sistema **distribuido** ##
¬
- No existen maestros/esclavos __←__ _Particionado_
- Existen **réplicas** __←__ _Alta disponibilidad_
- No conserva la consistencia secuencial __←__ Consistencia "_relajada_"
¬
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Teorema CAP: ##
[] (img/cap.png)
Tienes el **_P_articionado** y tienes la **disponibilid_A_d**
pero **no** tienes la ~~**_C_onsistencia**~~_(*)_
###### Al menos la consistencia _sequencial_ no se cumple
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Otra visión del teorema CAP ##
[] (img/dial.svg )
En realidad puedes estar más o menos cerca de la consistencia
o por el contrario de la disponibilidad.
###### Se puede lograr con akka-distributed-data(__*__) y también con akka-persistence(__**__)
¬
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Sesiones gossip ##
Intercambio de mensajes gossip entre réplicas.
### Consiste:
- Sincronizar y actualizar relojes lógicos (Vector clocks)
[](img/vectorTimestampReloj.png)
- Intercambiar valores de los logs
¬
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Ejemplo de intercambio de logs ##
Imaginemos tres nodos `A`, `B` y `C` y una sesión gossip entre
`A`, `B`
### Antes
- Log y sumario de `A` de un determinado valor antes del
intercambio gossip
······· +===++----+----+----+ +===++----+
······· | A || a1 | a2 | a3 | → | A || a3 |
······· +===++----+----+----+ +===++----+
······· | B || b1 | → | B || b1 |
······· +===++----+ +===++----+
······· | C || c1 | → | C || c1 |
······· +===++----+ +===++----+
······· Log Sumario
- Log y sumario de `B` del mismo valor antes del intercambio
gossip
······· +===++----+ +===++----+
······· | A || a1 | → | A || a1 |
······· +===++----+----+ +===++----+
······· | B || b1 | b2 | → | B || b2 |
······· +===++----+----+----+ +===++----+
······· | C || c1 | c2 | c3 | → | C || c3 |
······· +===++----+----+----+ +===++----+
······· Log Sumario
###### Time Stamped Anti-Entropy (TSAE) protocol. Richard A. Golding (Diciembre 1992)
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Ejemplo de intercambio de logs ##
Tres nodos `A`, `B` y `C`. Sesión gossip entre `A`, `B`
### Durante
Intercambio de sumarios y valores entre los dos nodos
······· NODO A NODO B
······· +===++----+ +===++----+
······· | A || a3 | a2, a3 → | A || a1 |
······· +===++----+ +===++----+
······· | B || b1 | ← b2 | B || b2 |
······· +===++----+ +===++----+
······· | C || c1 | ← c2, c3 | C || c3 |
······· +===++----+ +===++----+
¬
###### Time Stamped Anti-Entropy (TSAE) protocol. Richard A. Golding (Diciembre 1992)
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Ejemplo de intercambio de logs ##
Tres nodos `A`, `B` y `C`. Sesión gossip entre `A`, `B`
### Después
······· NODO A NODO B
······· +===++----+----+----+ +===++----+----+----+
······· | A || a1 | a2 | a3 | | A || a1 | a2 | a3 |
······· +===++----+----+----+ +===++----+----+----+
······· | B || b1 | b2 | | B || b1 | b2 |
······· +===++----+----+----+ +===++----+----+----+
······· | C || c1 | c2 | c3 | | C || c1 | c2 | c3 |
······· +===++----+----+----+ +===++----+----+----+
······· Log Log
¬
###### Time Stamped Anti-Entropy (TSAE) protocol. Richard A. Golding (Diciembre 1992)
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Akka y la arquitectura gossip ##
### Conflict Free Replicated Data Types (CRDTs) ###
Usa funciones monótonas para resolver confictos de actualización
- Utilizados en **Akka Distributed Data**
·· + Tipos de datos soportados
····- Contadores: [`GCounter`](img/vectorTimestampReloj.png), `PNCounter`
····- Conjuntos: `GSet`, `ORSet`
····- Mapas: `ORMap`, `ORMultiMap`, `LWWMap`, `PNCounterMap`
····- Registros: `LWWRegister`, `Flag`
Por defecto se utiliza **Akka Distributed Data** para guardar el
estado del Cluster Sharding
¬
###### Akka y la arquitectura gossip
----------------------------------------------------------------
## Akka y la arquitectura gossip ##
### Akka Distributed Data y teorema CAP (Niveles de consistencia) ###
- **Local**
··+ `WriteLocal`. Escribir sólo en la replica local y diseminado después
por gossip
··+ `ReadLocal`. Leer sólo el valor de la replica local
- **To(n)**
··+ `WriteTo(n)`. Escribir inmediatamente en _al menos_ `n` replicas
··+ `ReadTo(n)`. Valor leído y combinado en _al menos_ `n` replicas
- **Majority**
··+ `WriteMajority`. Escribir inmediatamente en `N/2 + 1` replicas
(_N_ es el número de nodos)
··+ `ReadMajority` Valor leído y combinado en al menos `N/2 + 1`
replicas
- **All**
··+ `WriteAll`. Escribir inmediatamente _en todas_ las replicas
··+ `ReadAll`. Valor leído y combinado _en todas_ las replicas
¬
###### Conceptos clave
----------------------------------------------------------------
## Detección de fallos ##
###### Detención de fallos
----------------------------------------------------------------
## Convergencia gossip ##
_"Cuando un nodo puede demostrar, que el estado del clúster
que está observando, ha sido observado por todos los demás
nodos del clúster"_
### Consecuencias ###
- No se puede obtener convergencia si hay nodos "_inaccesibles_"
¬
###### Detención de fallos
----------------------------------------------------------------
## Nodo líder ##
Nodo que administra la convergencia del cluster y las
transiciones de los nodos a los que pertenece.
- Si hay convergencia gossip, todos los nodos saben quien es el
líder.
- Sólo es un rol y puede cambiar por la convergencia.
·· + Es el primer nodo de una lista que se crea cuando entran y
salen los nodos del cluster.
¬
###### Detención de fallos
----------------------------------------------------------------
## Información del estado de los nodos del cluster ##
Se emiten eventos del cluster, que permiten conocer el estado de
cada nodo que pueden escuchar los diferentes integrantes del
cluster.
·····························----
····························|····|
····joining > [weakly up] >·| up | > leaving / exiting > down > removed
····························|····|
···························· ----
El cluster envía mensajes periódicos de heartbeats para
comprobar que otros nodos están disponibles.
Estados:
- De disponible a no disponible `=> ureacheable`
- Vuelta a estar disponible `=> reacheable`
¬
###### Detención de fallos
----------------------------------------------------------------
## Necesidad de un split brain resolver ##
[] (img/1-to-3-arrows.png)
¬
###### Detención de fallos
----------------------------------------------------------------
## Posible de denegación de servicio ##
Cuando por ejemplo por problemas de red parte de los nodos del
cluster no pueden "_ver_" otros nodos del cluster.
Por lo tanto hay nodos _inaccesibles_.
- No hay convergencia
··+ No se puede ni añadir, ni eliminar nodos del cluster.
- Se puede llegar a denegación de servicio
·· + No **encontrar** ni poder **recrear** el actor que está en
el nodo "_inaccesible_""
¬
###### Detección de fallos
----------------------------------------------------------------
## Necesidad de un split brain resolver ##
### Opción _auto-down_
`Los nodos inaccesibles son dados de baja al cabo de un tiempo
configurable.`
No es viable:
- Con el tiempo te puedes encontrar con varios cluster de un
sólo nodo.
¬
###### Detección de fallos
----------------------------------------------------------------
## Necesidad de un split brain resolver ##
### Otras opciones: ###
#### **Manualmente**
·· Utilizando akka-management
#### **Solución comercial**
·· Akka split brain resolver
#### **Crear una solución propia**
·· Escuchando eventos del cluster
¬
###### Detección de fallos
----------------------------------------------------------------
## Directrices de Akka split brain resolver ##
Las decisiones deben ser tomadas en un tiempo finito.
¬
###### Detección de fallos
----------------------------------------------------------------
## Directrices de Akka split brain resolver ##
_Las decisiones deben ser tomadas en un tiempo finito._
- Un fallo temporal o permanente es indistinguible.
·· + Fallo de la máquina virtual
·······- Interesa retirar cuanto antes el nodo del cluster
·· + Fallo de red
·······- Tenemos la esperanza que es un problema temporal pero
no esperamos por un tiempo indefinido.
·······- Continuaremos con los nodos de una parte de la
partición y apagaremos los nodos de la otra parte.
·· + CPU, garbage collector.
¬
###### Detección de fallos
----------------------------------------------------------------
## Directrices de Akka split brain resolver ##
_Las decisiones deben ser tomadas en un tiempo finito._
- Un fallo temporal o permanente es indistinguible.
·· + Fallo de la máquina virtual
·······- Interesa retirar cuanto antes el nodo del cluster
·· + Fallo de red
·······- Tenemos la esperanza que es un problema temporal pero
no esperamos por un tiempo indefinido.
·······- Continuaremos con los nodos de una parte de la
partición y apagaremos los nodos de la otra parte.
·· + CPU, garbage collector.
- La única señal para tomar decisiones: "_**no responder en un
tiempo dado a los mensajes heartbeats**_".
¬
###### Detección de fallos
----------------------------------------------------------------
## Estrategias de Akka split brain resolver ##
¬
###### Detección de fallos
----------------------------------------------------------------
## Estrategias de Akka split brain resolver ##
- **Quorum estático**. Las particiones que no cumplan el número
mínimo de nodos serán eliminadas del cluster.
¬
###### Detección de fallos
----------------------------------------------------------------
## Estrategias de Akka split brain resolver ##
- **Quorum estático**. Las particiones que no cumplan el número
mínimo de nodos serán eliminadas del cluster.
- **Mantener la mayoría**. Se mantendrá la partición que tenga
mayor número de nodos.
¬
###### Detección de fallos
----------------------------------------------------------------
## Estrategias de Akka split brain resolver ##
- **Quorum estático**. Las particiones que no cumplan el número
mínimo de nodos serán eliminadas del cluster.
- **Mantener la mayoría**. Se mantendrá la partición que tenga
mayor número de nodos.
- **El más antiguo**. Mantener la partición que contiene el nodo
más antiguo.
¬
###### Detección de fallos
----------------------------------------------------------------
## Estrategias de Akka split brain resolver ##
- **Quorum estático**. Las particiones que no cumplan el número
mínimo de nodos serán eliminadas del cluster.
- **Mantener la mayoría**. Se mantendrá la partición que tenga
mayor número de nodos.
- **El más antiguo**. Mantener la partición que contiene el nodo
más antiguo.
- **Mantener al árbitro**. La partición que sobrevive es la que
contiene a un nodo árbitro que se define por configuración.
¬
###### Ejemplo práctico
----------------------------------------------------------------
## Ejemplo final con Akka Sharding
¬
###### Ejemplo práctico
----------------------------------------------------------------
## Ejemplo usando Akka Sharding
### ¿Qué se va a hacer?
Un ejemplo bancario: cuentas corrientes y transferencias.
- Crear un actor y entidad cuenta y también una transferencia
combinando dos cuentas.
- Se hará un bosquejo de CQRS separando lecturas y escrituras y
de Event Sourcing que existe en DDD.
¬
###### Ejemplo práctico
----------------------------------------------------------------
## Ejemplo usando Akka Sharding
### Objetivos
- Ver como funciona Akka Sharding y Akka Cluster.
- **Bonus track**: Utilización de akka-management y escuchar los
eventos del cluster
¬
###### Ejemplo práctico
----------------------------------------------------------------
## Ejemplo usando Akka Sharding
# Tiempo de demo
¬
###### Ejemplo práctico
----------------------------------------------------------------
## ¿Preguntas?
¬
/