Apache Kafka - I - Arquitectura y conceptos de alto nivel

En primer lugar, ¿qué es Apache Kafka? Una definición inicial sería "un sistema distribuido de mensajería de alto throughput". Descomponiendo:

  • Alto throughput: Una traducción aproximada de throughput, en el contexto de sistemas informáticos, sería "rendimiento". Sin embargo, es necesario aclarar que cuando se habla de throughput, se está aludiendo concretamente a la cantidad de elementos procesados por unidad de tiempo. Uno de los objetivos principales de Kafka es precisamente procesar la mayor cantidad posible de mensajes por unidades de tiempo, de forma escalable y tolerante a fallas. Por ejemplo, LinkedIn, que es donde se originó Kafka, necesita lograr throughputs del orden de 20 millones de mensajes por segundo, y 3 GB de datos por segundo..
  • Sistema distribuido de mensajería: En un sistema distribuido genérico, múltiples computadoras en red colaboran con un objetivo en común. En el caso particular de Kafka, ese objetivo es enviar datos desde los puntos A1, A2, ... AN,  hasta los puntos B1, B2, ... BM. Un beneficio de este tipo de sistemas que es esencial para el éxito de Kafka, es la escalabilidad horizontal: la habilidad de manejar volúmenes mayores de datos con sólo agregar nodos al sistema (no confundir con  escalabilidad vertical, la cual consiste en mejorar el hardware de los nodos).

El próximo interrogante sería: ¿por qué Kafka? La motivación principal es la manera en que Kafka enfrenta y supera los defectos de las herramientas de transporte de datos y sus enfoques. Particularmente, los problemas que surgen cuando el volumen de datos y su frecuencia crecen más allá de cierto umbral. Por lo tanto, si un sistema necesita mover una gran cantidad de datos a gran velocidad, Kafka puede ser una buena opción.

La arquitectura general de un sistema que utiliza Kafka para mover datos es la siguiente:

Arquitectura de alto nivel de Kafka
  • Productores (producers): Las aplicaciones productoras envían mensajes a un topic específico. En la jerga de Kafka, un topic es una colección de mensajes. Este concepto será ampliado más adelante.
  • Consumidores (consumers): Las aplicaciones consumidoras se suscriben a un topic, a fin de recibir los mensajes publicados al mismo. Puede decirse que Kafka implementa semánticas de publicador-suscriptor (publisher-susbcriber). Nótese que las flechas van desde los consumidores hacia el cluster: esto se debe a que Kafka usa un pull model. Esto significa que los consumidores revisan (poll) activamente el cluster buscando nuevos mensajes.
  • Cluster Kafka: Un cluster Kafka es una conexión de brokers Kafka conectados en red. A su vez, dichos brokers son nodos responsables de persistir los mensajes en sus topics correspondientes, y hacerlos llegar a los consumidores cuando éstos los piden. Uno de los brokers asume el rol de controlador, distribuyendo y coordinando trabajo entre los demás, que toman el rol de seguidores (followers). Para lograr tolerancia a fallas, los brokers pueden replicar topics con un factor de replicación configurable. De esta manera, si un broker se cae, el broker controlador puede redirigir su carga hacia una réplica hasta que vuelva a estar activo.
  • Ensemble de Zookeeper: Zookeeper es otro sistema distribuido, cuyo objetivo es administrar otros sistemas distribuidos, almacenando y monitoreando sus metadatos. En el caso de Kafka, los nodos de Zookeeper forman un ensemble, que no es otra cosa que una colección de nodos que forman un sistema Zookeeper particular. Dicho ensemble lleva cuenta de información como qué nodo es el controlador actual de un cluster Kafka, dónde está cada broker en la red, factores de replicación, configuración de arranque del cluster, monitorear la salud de los nodos, y mucho más.

Esta arquitectura logra escalabilidad horizontal permitiendo a los clusters crecer en tamaño, y asimismo teniendo clusters múltiples. Zookeeper es esencial para este fin, dado que maneja la complejidad de configurar y manejar los clusters.

En el próximo post de esta serie, se verá más en detalle cómo los mensajes son organizados en topics y particiones.

Ir a Parte II: Topics y particiones

Comments

Post a Comment

Popular posts from this blog

VB.NET: Raise base class events from a derived class

Spanish version / Versión en Español Say we: Have a class we want to divide into subclasses The future base class has events The refactoring leads us to the need of raising an event declared in the base class, from a derived class. When we try to do point 3, we will get a compile error saying that a derived class cannot raise events from a base class. To get around this, we add a protected method in the base class which encapsulates the RaiseEvent call, and call that method from the derived class using MyBase. This way: In the base class (parameters as needed): Protected Overridable Sub OnMessageGenerated(ByVal NewSender As Object, ByVal NewMessage As String) RaiseEvent MessageGenerated(NewSender, New MessageEventArgs(NewMessage)) End Sub And in the derived class: 'Do stuff 'Raise base class event MyBase.OnMessageGenerated( Me, "Message" ) 'Do more stuff... References: Mark Gilbert post
Keep reading

Apache Kafka - I - High level architecture and concepts

Image
Spanish version / Versión en Español First of all, what is Apache Kafka ? An initial definition for it is "a high-throughput distributed messaging system". Breaking this down a bit: High throughput: One of the main goals of Kafka is to process as much messages per unit of time as possible, in a scalable and fault-tolerant way. For example, LinkedIn , which is where Kafka originated, needs to achieve throughputs in the order of 20 million messages per second and 3 GB of data per second. Distributed messaging system: In a generic distributed system , networked computers work together for a common goal. In Kafka's case, that goal is to send data from points A 1 , A 2 , ... A N , to B 1 , B 2 , ... B M . A common benefit of this kind of system, which is crucial to Kafka's success, is horizontal scalability : the ability to handle higher and higher volumes of data by adding nodes to the system (not to be confused with  vertical scalability , whic
Keep reading

Upgrading Lodash from 3.x to 4.x

Spanish version / Versión en Español There are many breaking changes from version 3.x to 4.x; all changes are detailed in the Lodash changelog . There is also a list of deprecated functions , with a regex you can use to detect usages in your code. However, since it is not an exhaustive list, I will list the changes I encountered when performing my own migration, to help anyone undergoing the same process. Direct renames This section includes functions in which only the name changed, i.e. the arguments and return value are the same. 3.x 4.x contains includes first head rest tail invoke invokeMap padLeft padStart padRight padEnd Direct renames if not using thisArg This section includes functions in which the only change is dropping "thisArg". If you are not using it, you can just rename. If you are using thisArg in 3.x, it can be dropped if you are using iteratee to acce
Keep reading