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 [...]"*

* 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)

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

¿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?

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:

Tienes el Particionado y tienes la disponibilidAd pero no tienes la Consistencia(*)

Al menos la consistencia sequencial no se cumple

Akka y la arquitectura gossip

Otra visión del teorema CAP

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)

• 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, 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

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?

Gracias