Tabla de contenido
2. ¿Cómo implementa Redpanda Raft?
Los requisitos de Redpanda son:
La implementación de Raft proporciona una base sólida para estos tres requisitos:
4. Combinación de ingeniería de rendimiento y Raft
I. Introducción
El consenso es la base de un sistema distribuido consistente. Para garantizar la disponibilidad del sistema en caso de un bloqueo inevitable, el sistema necesita una forma de garantizar que cada nodo en el clúster permanezca consistente para que, en caso de falla, el trabajo pueda cambiar sin problemas entre los nodos. Los protocolos de consenso como Paxos, Raft y View Stamped Replication (VSR) ayudan a aumentar la resiliencia de los sistemas distribuidos al proporcionar lógica para procesos como la elección de líder, los cambios de configuración atómica y la sincronización.
Al igual que con todos los elementos de diseño, los diferentes métodos de consenso distribuido tienen diferentes ventajas y desventajas. Paxos es el protocolo de consenso más antiguo y se usa en muchos sistemas, como Google Cloud Spanner, Apache Cassandra, Amazon DynamoDB y Neo4j. Paxos logra el consenso a través de un protocolo trifásico, sin líderes y de mayoría ganadora. Si bien Paxos es efectivo en la lucha por la corrección, es difícil de entender, implementar y razonar. Esto se debe en parte al hecho de que enmascara muchos de los desafíos para lograr un consenso (como la elección y reconfiguración de líderes), lo que dificulta su descomposición en subproblemas.
Raft (para confiabilidad, replicación, redundancia y tolerancia a fallas) se puede considerar como una evolución de Paxos, con un enfoque en la comprensibilidad. Raft puede lograr la misma corrección que Paxos, pero es más fácil de entender e implementar en el mundo real y, por lo tanto, a menudo ofrece mejores garantías de confiabilidad. Por ejemplo, Raft utiliza un mecanismo de liderazgo estable que simplifica la gestión de registros de replicación y su proceso de elección de líder es más eficiente.
Y debido a que Raft descompone diferentes componentes lógicos del problema de consenso, como hacer que la elección del líder sea un paso distinto antes de la replicación, es un protocolo flexible que puede adaptarse a sistemas distribuidos modernos complejos que necesitan escalar hasta petabytes de rendimiento mientras se mantiene la corrección y rendimiento, pero más fácil de entender para los nuevos ingenieros que trabajan en el código base.
Por estas razones, Raft se ha adoptado rápidamente en los sistemas nativos de la nube distribuidos de la actualidad, como MongoDB, CockroachDB, TiDB y Redpanda, para lograr un mayor rendimiento y eficiencia transaccional.
2. ¿Cómo implementa Redpanda Raft?
Cuando el fundador de Redpanda, Alex Gallego, decidió que el mundo necesitaba una nueva plataforma de transmisión de datos para admitir las cargas de trabajo de GBps+ que colapsaron Apache Kafka, decidió reescribir Kafka desde cero.
Los requisitos de Redpanda son:
1) Debe ser simple y liviano para reducir la complejidad y la ineficiencia de ejecutar clústeres de Kafka de manera confiable a gran escala;
2) la necesidad de maximizar el rendimiento del hardware moderno para proporcionar baja latencia para grandes cargas de trabajo;
3) La seguridad de los datos debe garantizarse incluso para rendimientos muy grandes.
La implementación de Raft proporciona una base sólida para estos tres requisitos:
1. Simplicidad
Cada partición de Redpanda es un grupo de Raft, por lo que todo en la plataforma se basa en Raft, incluida la gestión de metadatos y la replicación de particiones. Esto contrasta con la complejidad de Kafka: en Kafka, las ISR (réplicas sincrónicas) manejan la replicación de datos, ZooKeeper (o Kraft) maneja la administración de metadatos y tiene dos sistemas que deben razonar el uno sobre el otro.
2. Rendimiento
La implementación de Redpanda Raft puede tolerar perturbaciones en una minoría de réplicas siempre que el líder y la mayoría de las réplicas sean estables. En el caso de respuestas retrasadas de algunas réplicas, el líder no tiene que esperar a que respondan antes de dar el siguiente paso, mitigando el impacto en la latencia. Por lo tanto, Redpanda es más tolerante a fallas y puede proporcionar un rendimiento predecible en entornos a gran escala.
3. Confiabilidad
Cuando Redpanda ingiere eventos, se escriben en particiones de temas y se agregan a los archivos de registro en el disco. Luego, cada partición de tema forma un grupo de consenso de Raft que consta de un líder y una cantidad de seguidores, especificados por el factor de replicación del tema. Con 2f+1 nodos, un grupo de Redpanda Raft puede tolerar f fallas; por ejemplo, en un clúster con cinco nodos y un tema con un factor de replicación de 5, dos nodos pueden fallar mientras el tema permanecerá activo. Redpanda aprovecha el protocolo de consenso federado de Raft para brindar consistencia incluso durante las reconfiguraciones.
Redpanda también amplía la funcionalidad principal de Raft de manera clave para lograr la escalabilidad, la confiabilidad y la velocidad que requieren las soluciones modernas nativas de la nube. Las innovaciones basadas en balsa incluyen cambios en el proceso de elección, generación de latidos y soporte significativo para Apache Kafka ACKS. Estas innovaciones garantizan el mejor rendimiento en todos los escenarios, lo que hace que Redpanda sea mucho más rápido que Kafka y, al mismo tiempo, mantiene la seguridad de los datos. De hecho, las pruebas de Jepsen han confirmado que Redpanda es un sistema seguro sin problemas de consistencia conocidos y una capa de consenso confiable basada en Raft.
3. Pero, ¿qué pasa con Kraft?
Si bien Redpanda ha adoptado un enfoque nativo de Raft, las plataformas tradicionales de transmisión de datos se han quedado atrás en la adopción de métodos de consenso modernos. Kafka en sí es un registro distribuido replicado, pero solía depender de otro registro distribuido replicado: Apache Zookeeper para la gestión de metadatos y la elección del controlador. Esto es problemático por las siguientes razones:
1. La gestión de múltiples sistemas crea una carga administrativa;
2. La escalabilidad es limitada debido al procesamiento de metadatos ineficiente y al doble almacenamiento en caché;
3. Los clústeres pueden volverse muy inflados y consumir muchos recursos; de hecho, los clústeres con el mismo número de nodos de ZooKeeper y Kafka no son raros.
Estas limitaciones no han pasado desapercibidas para los encargados de confirmar y mantener Apache Kafka, que están reemplazando a ZooKeeper con un quórum de metadatos de autogestión: Kafka Raft (KRaft). Este Raft basado en eventos reduce los desafíos administrativos de la gestión de metadatos de Kafka y, con suerte, indica que el ecosistema de Kafka se está moviendo hacia un enfoque moderno de consenso y confiabilidad.
Desafortunadamente, Kraft no resuelve el problema de tener dos sistemas de consenso diferentes en un clúster de Kafka. En el nuevo paradigma de KRaft, las particiones de KRaft manejan metadatos y administración de clústeres, pero la replicación la manejan los intermediarios, por lo que todavía tiene estas dos plataformas diferentes y las ineficiencias causadas por la complejidad inherente.
4. Combinación de ingeniería de rendimiento y Raft
Como lo demostraron los líderes de la industria de datos como CockroachDB, MongoDB, Neo4j y TiDB, los sistemas basados en Raft brindan un entorno de datos distribuidos más simple, rápido y confiable. Raft se está convirtiendo en el protocolo de consenso estándar para los sistemas de datos distribuidos en la actualidad porque se combina excepcionalmente bien con la ingeniería de rendimiento para aumentar aún más el rendimiento del procesamiento de datos.
Por ejemplo, Redpanda combina Raft con elementos arquitectónicos rápidos y es al menos 10 veces más rápido que Kafka en latencia de cola (p99.99) cuando procesa cargas de trabajo de 1 GBps, lo que requiere solo un tercio del hardware sin afectar la seguridad de los datos. Tradicionalmente, las cargas de trabajo de GBps+ han sido históricamente una carga para Apache Kafka, pero Redpanda puede admitirlas con latencias de milisegundos de dos dígitos al tiempo que conserva la confiabilidad de la validación de Jepsen.
¿Cómo es esto posible? Redpanda está escrito en C++ y utiliza una arquitectura de subprocesos por núcleo para maximizar el rendimiento de los chips y tarjetas de red modernos. Juntos, estos elementos mejoran el valor de Raft para las plataformas de transmisión de datos distribuidos.
Por ejemplo, debido a que Redpanda pasa por alto la memoria caché de la página de Kafka y las dependencias de la máquina virtual Java (JVM), puede incorporar conocimiento a nivel de hardware en la implementación de Raft. Cada vez que escribe datos en Raft, por lo general tiene que vaciarlos para garantizar la durabilidad de las escrituras en el disco. En el enfoque optimista de Raft de Redpanda, las actualizaciones intermitentes pequeñas se descartan en favor de actualizaciones más grandes al final de la llamada. Si bien esto introduce una latencia adicional en cada llamada, reduce la latencia general del sistema y aumenta el rendimiento general porque reduce la cantidad total de operaciones de vaciado.
Si bien existen muchas formas efectivas de garantizar la coherencia y la seguridad en los sistemas distribuidos (las cadenas de bloques hacen un buen trabajo con los protocolos de prueba de trabajo y prueba de participación), Raft es un método probado que es lo suficientemente flexible como para usarse como Mejoras, como Redpanda, para adaptarse a los nuevos retos. A medida que avanzamos hacia un nuevo mundo basado en datos, impulsado por casos de uso de inteligencia artificial y aprendizaje automático, el futuro está en manos de los desarrolladores que pueden aprovechar los flujos de datos en tiempo real.
Los sistemas basados en balsa, junto con elementos de ingeniería de rendimiento como C++ y arquitecturas de subprocesos por núcleo, están impulsando la transmisión de datos a futuras aplicaciones de misión crítica.