Una introducción completa a los sistemas distribuidos

¿Qué es un sistema distribuido y por qué es tan complicado?

Con la expansión tecnológica en constante crecimiento del mundo, los sistemas distribuidos se están generalizando cada vez más. Son un campo de estudio vasto y complejo en informática.

Este artículo tiene como objetivo presentarle los sistemas distribuidos de una manera básica, mostrándole un vistazo de las diferentes categorías de dichos sistemas sin profundizar en los detalles.

¿Qué es un sistema distribuido?

Un sistema distribuido en su definición más simple es un grupo de computadoras que trabajan juntas para aparecer como una sola computadora para el usuario final.

Estas máquinas tienen un estado compartido, funcionan de forma simultánea y pueden fallar de forma independiente sin afectar el tiempo de actividad de todo el sistema.

Propongo que trabajemos gradualmente a través de un ejemplo de distribución de un sistema para que pueda tener una mejor idea de todo:

¡Vamos con una base de datos! Las bases de datos tradicionales se almacenan en el sistema de archivos de una sola máquina, siempre que desee obtener / insertar información en ella, hable directamente con esa máquina.

Para que podamos distribuir este sistema de base de datos, necesitamos que esta base de datos se ejecute en varias máquinas al mismo tiempo. El usuario debe poder hablar con la máquina que elija y no debe poder decir que no está hablando con una sola máquina; si inserta un registro en el nodo n. ° 1, el nodo n. ° 3 debe poder devolver ese registro.

¿Por qué distribuir un sistema?

Los sistemas siempre se distribuyen por necesidad. La verdad del asunto es que la gestión de sistemas distribuidos es un tema complejo repleto de trampas y minas terrestres. Es un dolor de cabeza implementar, mantener y depurar sistemas distribuidos, entonces, ¿por qué ir allí?

Lo que le permite hacer un sistema distribuido es escalar horizontalmente . Volviendo a nuestro ejemplo anterior del servidor de base de datos único, la única forma de manejar más tráfico sería actualizar el hardware en el que se ejecuta la base de datos. A esto se le llama escalar verticalmente .

Escalar verticalmente está muy bien mientras pueda, pero después de cierto punto verá que incluso el mejor hardware no es suficiente para suficiente tráfico, sin mencionar que no es práctico para alojar.

Escalar horizontalmente simplemente significa agregar más computadoras en lugar de actualizar el hardware de una sola.

Es significativamente más barato que el escalado vertical después de un cierto umbral, pero ese no es su caso principal de preferencia.

El escalado vertical solo puede aumentar su rendimiento hasta las capacidades del hardware más reciente. Estas capacidades resultan insuficientes para las empresas tecnológicas con cargas de trabajo de moderadas a grandes.

Lo mejor del escalado horizontal es que no tiene límite sobre cuánto puede escalar: siempre que el rendimiento se degrada, simplemente agrega otra máquina, hasta el infinito potencialmente.

El escalado sencillo no es el único beneficio que obtiene de los sistemas distribuidos. La tolerancia a fallos y la baja latencia también son igualmente importantes.

Tolerancia a fallas : un grupo de diez máquinas en dos centros de datos es intrínsecamente más tolerante a fallas que una sola máquina. Incluso si un centro de datos se incendia, su aplicación seguirá funcionando.

Baja latencia : el tiempo que tarda un paquete de red en viajar por el mundo está limitado físicamente por la velocidad de la luz. Por ejemplo, el tiempo más corto posible para el tiempo de ida y vuelta de una solicitud(es decir, ir y venir) en un cable de fibra óptica entre Nueva York y Sydney es de 160 ms. Los sistemas distribuidos le permiten tener un nodo en ambas ciudades, lo que permite que el tráfico llegue al nodo más cercano.

Sin embargo, para que un sistema distribuido funcione, necesita que el software que se ejecuta en esas máquinas esté diseñado específicamente para ejecutarse en varias computadoras al mismo tiempo y manejar los problemas que lo acompañan. Esto resulta no ser una tarea fácil.

Escalando nuestra base de datos

Imagina que nuestra aplicación web se hizo increíblemente popular. Imagine también que nuestra base de datos comenzó a recibir el doble de consultas por segundo de las que puede manejar. Su aplicación comenzaría a disminuir inmediatamente en rendimiento y esto sería notado por sus usuarios.

Trabajemos juntos y hagamos que nuestra base de datos se amplíe para satisfacer nuestras altas demandas.

En una aplicación web típica, normalmente lee información con mucha más frecuencia de lo que inserta información nueva o modifica una antigua.

Hay una forma de aumentar el rendimiento de lectura y es mediante la estrategia de replicación de réplica primaria . Aquí, crea dos nuevos servidores de base de datos que se sincronizan con el principal. El problema es que solo puede leer de estas nuevas instancias.

Siempre que inserta o modifica información, habla con la base de datos principal. Éste, a su vez, informa de forma asincrónica a las réplicas del cambio y también lo guardan.

¡Felicitaciones, ahora puede ejecutar 3 veces más consultas de lectura! ¿No es esto genial?

Trampa

¡Te tengo! Inmediatamente perdimos la C en las garantías ACID de nuestra base de datos relacional , que significa Consistencia.

Verá, ahora existe una posibilidad en la que insertamos un nuevo registro en la base de datos, inmediatamente después emitimos una consulta de lectura y no obtenemos nada a cambio, ¡como si no existiera!

La propagación de la nueva información del primario a la réplica no ocurre instantáneamente. De hecho, existe una ventana de tiempo en la que puede obtener información obsoleta. Si este no fuera el caso, su rendimiento de escritura se vería afectado, ya que tendría que esperar sincrónicamente a que se propaguen los datos.

Los sistemas distribuidos vienen con un puñado de compensaciones. Este problema en particular es uno con el que tendrá que vivir si desea escalar adecuadamente.

Continuar escalando

Utilizando el enfoque de la réplica de la base de datos, podemos escalar horizontalmente nuestro tráfico de lectura hasta cierto punto. Eso es genial, pero nos hemos topado con un muro con respecto a nuestro tráfico de escritura, ¡todavía está todo en un servidor!

No nos quedan muchas opciones aquí. Simplemente necesitamos dividir nuestro tráfico de escritura en varios servidores, ya que uno no puede manejarlo.

Una forma es optar por una estrategia de replicación de múltiples primarias. Allí, en lugar de réplicas de las que solo puede leer, tiene varios nodos primarios que admiten lecturas y escrituras. Desafortunadamente, esto se complica rápidamente ya que ahora tiene la capacidad de crear conflictos (por ejemplo, insertar dos registros con la misma ID).

Vayamos con otra técnica llamada fragmentación(también llamado particionamiento ).

Con la fragmentación, divide su servidor en varios servidores más pequeños, llamados fragmentos. Todos estos fragmentos contienen registros diferentes: usted crea una regla sobre qué tipo de registros van a cada fragmento. Es muy importante crear la regla de manera que los datos se distribuyan de manera uniforme .

Un posible enfoque para esto es definir rangos de acuerdo con cierta información sobre un registro (por ejemplo, usuarios con el nombre AD).

Esta clave de fragmentación debe elegirse con mucho cuidado, ya que la carga no siempre es igual en función de columnas arbitrarias. (por ejemplo, más personas tienen un nombre que comienza con C en lugar de Z ). Un solo fragmento que recibe más solicitudes que otros se denomina zona activa y debe evitarse. Una vez divididos, volver a fragmentar los datos se vuelve increíblemente costoso y puede causar un tiempo de inactividad significativo, como fue el caso de la infame interrupción de 11 horas de FourSquare.

Para mantener nuestro ejemplo simple, suponga que nuestro cliente (la aplicación Rails) sabe qué base de datos usar para cada registro. También vale la pena señalar que hay muchas estrategias para fragmentar y este es un ejemplo simple para ilustrar el concepto.

Hemos ganado bastante en este momento: podemos aumentar nuestro tráfico de escritura N veces donde N es el número de fragmentos. Esto prácticamente no nos da ningún límite; imagínese cuán finos podemos obtener con esta partición.

Trampa

Todo en Ingeniería de Software es más o menos una compensación y esta no es una excepción. La fragmentación no es una tarea sencilla y es mejor evitarla hasta que sea realmente necesaria.

Ahora hemos realizado consultas por claves.aparte de la clave particionada, increíblemente ineficaz (necesitan pasar por todos los fragmentos). Las JOINconsultas SQL son aún peores y las complejas se vuelven prácticamente inutilizables.

Descentralizado vs distribuido

Antes de continuar, me gustaría hacer una distinción entre los dos términos.

Aunque las palabras suenan similares y se puede concluir que significan lo mismo lógicamente, su diferencia tiene un impacto tecnológico y político significativo.

Descentralizado todavía se distribuye en el sentido técnico, pero todos los sistemas descentralizados no son propiedad de un solo actor. Ninguna empresa puede poseer un sistema descentralizado; de lo contrario, ya no estaría descentralizado.

Esto significa que la mayoría de los sistemas que analizaremos hoy pueden considerarse como sistemas centralizados distribuidos , y para eso están hechos.

Si lo piensa, es más difícil crear un sistema descentralizado porque entonces necesita manejar el caso en el que algunos de los participantes son maliciosos. Este no es el caso de los sistemas distribuidos normales, ya que sabe que es propietario de todos los nodos.

Nota: Esta definición se ha debatido mucho y puede confundirse con otras (peer-to-peer, federado). En la literatura antigua, también se definió de manera diferente. Independientemente, lo que les di como definición es lo que creo que es el más utilizado ahora que blockchain y las criptomonedas popularizaron el término.

Categorías de sistemas distribuidos

Ahora vamos a revisar un par de categorías de sistemas distribuidos y enumerar su uso de producción más grande conocido públicamente. Tenga en cuenta que la mayoría de los números que se muestran están desactualizados y probablemente sean significativamente mayores al momento de leer esto.

Almacenes de datos distribuidos

Los almacenes de datos distribuidos son los más utilizados y reconocidos como bases de datos distribuidas. La mayoría de las bases de datos distribuidas son bases de datos no relacionales NoSQL, limitadas a la semántica de clave-valor. Proporcionan un rendimiento y una escalabilidad increíbles a costa de la coherencia o la disponibilidad.

Escala conocida : se sabe que Apple usa 75,000 nodos Apache Cassandra que almacenan más de 10 petabytes de datos, en 2015

No podemos entrar en discusiones sobre almacenes de datos distribuidos sin antes presentar el teorema CAP.

Teorema de CAP

Probado en 2002, el teorema de CAP establece que un almacén de datos distribuido no puede ser al mismo tiempo consistente, disponible y tolerante a particiones.

Algunas definiciones rápidas:

  • Consistencia : lo que lee y escribe secuencialmente es lo que se espera (¿recuerda el problema con la replicación de la base de datos hace unos párrafos?)
  • Disponibilidad : todo el sistema no muere; cada nodo que no falla siempre devuelve una respuesta.
  • Tolerante a particiones : el sistema continúa funcionando y mantiene sus garantías de consistencia / disponibilidad a pesar de las particiones de red

En realidad, la tolerancia de partición debe ser un hecho para cualquier almacén de datos distribuidos. Como se mencionó en muchos lugares, uno de los cuales es este gran artículo, no puede tener consistencia y disponibilidad sin tolerancia de partición.

Piénselo: si tiene dos nodos que aceptan información y su conexión muere, ¿cómo van a estar disponibles y a la vez proporcionar consistencia? No tienen forma de saber qué está haciendo el otro nodo y, como tal, pueden desconectarse (no estar disponibles) o trabajar con información obsoleta (inconsistente) .

Al final, tiene que elegir si desea que su sistema sea muy consistente o altamente disponible en una partición de red .

La práctica demuestra que la mayoría de las aplicaciones valoran más la disponibilidad. No necesariamente siempre necesitas una gran consistencia. Incluso entonces, esa compensación no se hace necesariamente porque necesite la garantía de disponibilidad del 100%, sino más bien porque la latencia de la red puede ser un problema al tener que sincronizar máquinas para lograr una gran consistencia. Estos y más factores hacen que las aplicaciones opten normalmente por soluciones que ofrecen alta disponibilidad.

Estas bases de datos se conforman con el modelo de consistencia más débil: consistencia eventual (explicación de consistencia fuerte vs eventual) . Este modelo garantiza que si no se realizan nuevas actualizaciones a un elemento determinado, eventualmente todos los accesos a ese elemento devolverán el último valor actualizado.

Esos sistemas proporcionan propiedades BASE (a diferencia del ACID de las bases de datos tradicionales)

  • B asically Un vailable - El sistema siempre devuelve una respuesta
  • S oft state: el sistema podría cambiar con el tiempo, incluso en momentos sin entrada (debido a una eventual consistencia)
  • E consistencia ventual - En ausencia de entrada, los datos se extienda a todos los nodos, tarde o temprano - convirtiéndose así en consonancia

Ejemplos de bases de datos distribuidas disponibles: Cassandra, Riak, Voldemort

Por supuesto, hay otros almacenes de datos que prefieren una mayor consistencia: HBase, Couchbase, Redis, Zookeeper

El teorema de CAP es digno de varios artículos por sí solo, algunos sobre cómo se pueden modificar las propiedades de CAP de un sistema en función de cómo se comporta el cliente y otros sobre cómo no se entiende correctamente.

Casandra

Cassandra, como se mencionó anteriormente, es una base de datos distribuida No-SQL que prefiere las propiedades AP fuera del CAP, resolviéndose con una consistencia eventual. Debo admitir que esto puede ser un poco engañoso, ya que Cassandra es altamente configurable; puede hacer que proporcione una gran consistencia a expensas de la disponibilidad también, pero ese no es su caso de uso común.

Cassandra usa hash consistente para determinar qué nodos de su clúster deben administrar los datos que está pasando. Usted establece un factor de replicación , que básicamente indica cuántos nodos desea replicar sus datos.

Al leer, leerá solo de esos nodos.

Cassandra es enormemente escalable, proporcionando un rendimiento de escritura absurdamente alto.

Aunque este diagrama puede estar sesgado y parece que compara a Cassandra con las bases de datos configuradas para proporcionar una consistencia sólida (de lo contrario, no puedo ver por qué MongoDB disminuiría el rendimiento cuando se actualiza de 4 a 8 nodos), esto debería mostrar lo que se establece correctamente hasta Cassandra cluster es capaz de.

Independientemente, en el intercambio de sistemas distribuidos que permite el escalado horizontal y un rendimiento increíblemente alto, Cassandra no proporciona algunas características fundamentales de las bases de datos ACID, a saber, transacciones.

Consenso

Las transacciones de bases de datos son difíciles de implementar en sistemas distribuidos, ya que requieren que cada nodo acuerde la acción correcta a tomar (abortar o confirmar). Esto se conoce como consenso y es un problema fundamental en los sistemas distribuidos.

Alcanzar el tipo de acuerdo necesario para el problema del "compromiso de transacción" es sencillo si los procesos participantes y la red son completamente confiables. Sin embargo, los sistemas reales están sujetos a una serie de posibles fallas, como fallas de procesos, particiones de red y mensajes perdidos, distorsionados o duplicados.

Esto plantea un problema: se ha demostrado que es imposible garantizar que se alcance un consenso correcto dentro de un marco de tiempo limitado en una red no confiable.

En la práctica, sin embargo, existen algoritmos que llegan a un consenso sobre una red no confiable con bastante rapidez. Cassandra en realidad proporciona transacciones ligeras mediante el uso del algoritmo Paxos para consenso distribuido.

Computación distribuída

La informática distribuida es la clave del influjo del procesamiento de Big Data que hemos visto en los últimos años. Es la técnica de dividir una tarea enorme (por ejemplo, agregar 100 mil millones de registros), de la cual ninguna computadora es capaz de ejecutar prácticamente por sí sola, en muchas tareas más pequeñas, cada una de las cuales puede caber en una sola máquina. Divide su enorme tarea en muchas más pequeñas, haga que se ejecuten en muchas máquinas en paralelo, agregue los datos de manera adecuada y habrá resuelto su problema inicial. Este enfoque nuevamente le permite escalar horizontalmente; cuando tenga una tarea más grande, simplemente incluya más nodos en el cálculo.

Escala conocida: Folding @ Home tenía 160.000 máquinas activas en 2012

Uno de los primeros innovadores en este espacio fue Google, que por necesidad de sus grandes cantidades de datos tuvo que inventar un nuevo paradigma para la computación distribuida: MapReduce. Publicaron un artículo al respecto en 2004 y la comunidad de código abierto creó más tarde Apache Hadoop basándose en él.

Mapa reducido

MapReduce se puede definir simplemente como dos pasos: mapear los datos y reducirlos a algo significativo.

Vayamos de nuevo con un ejemplo:

Digamos que somos Medium y almacenamos nuestra enorme información en una base de datos distribuida secundaria con fines de almacenamiento. Queremos obtener datos que representen la cantidad de aplausos emitidos cada día durante abril de 2017 (hace un año).

Este ejemplo se mantiene lo más breve, claro y simple posible, pero imagina que estamos trabajando con una gran cantidad de datos (por ejemplo, analizando miles de millones de aplausos). Obviamente, no almacenaremos toda esta información en una máquina y no analizaremos todo esto con una sola máquina. Tampoco consultaremos la base de datos de producción, sino una base de datos de "almacén" creada específicamente para trabajos fuera de línea de baja prioridad.

Cada trabajo de mapa es un nodo independiente que transforma la mayor cantidad de datos posible. Cada trabajo atraviesa todos los datos en el nodo de almacenamiento dado y los asigna a una tupla simple de la fecha y el número uno. Luego, se realizan tres pasos intermedios (de los que nadie habla) : Shuffle, Sort y Partition. Básicamente, organizan aún más los datos y los eliminan en el trabajo de reducción apropiado. Como estamos tratando con big data, tenemos cada trabajo de Reducir separado para trabajar en una sola fecha.

Este es un buen paradigma y sorprendentemente le permite hacer mucho con él; por ejemplo, puede encadenar múltiples trabajos de MapReduce.

Mejores técnicas

MapReduce es algo heredado hoy en día y trae algunos problemas. Debido a que funciona en lotes (trabajos) surge un problema en el que, si su trabajo falla, debe reiniciar todo. Un trabajo fallido de 2 horas realmente puede ralentizar todo el proceso de procesamiento de datos y no lo desea en lo más mínimo, especialmente en las horas pico.

Otro problema es el tiempo que espera hasta recibir los resultados. En los sistemas analíticos en tiempo real (que tienen big data y, por lo tanto, usan computación distribuida) es importante que sus últimos datos procesados ​​estén lo más actualizados posible y, ciertamente, no desde hace unas horas.

Como tal, han surgido otras arquitecturas que abordan estos problemas. A saber, Lambda Architecture (combinación de procesamiento por lotes y procesamiento de secuencias) y Arquitectura Kappa (solo procesamiento de secuencias). Estos avances en el campo han traído nuevas herramientas que les permiten: Kafka Streams, Apache Spark, Apache Storm, Apache Samza.

Sistemas de archivos distribuidos

Los sistemas de archivos distribuidos se pueden considerar como almacenes de datos distribuidos. Son lo mismo que un concepto: almacenar y acceder a una gran cantidad de datos en un grupo de máquinas que aparecen como una sola. Por lo general, van de la mano con la informática distribuida.

Escala conocida: Yahoo es conocido por ejecutar HDFS en más de 42.000 nodos para almacenar 600 Petabytes de datos, allá por 201

Wikipedia define la diferencia siendo que los sistemas de archivos distribuidos permiten acceder a los archivos utilizando las mismas interfaces y semántica que los archivos locales, no a través de una API personalizada como Cassandra Query Language (CQL).

HDFS

El sistema de archivos distribuido de Hadoop (HDFS) es el sistema de archivos distribuido que se utiliza para la computación distribuida a través del marco de Hadoop. Con una adopción generalizada, se utiliza para almacenar y replicar archivos grandes (GB o TB de tamaño) en muchas máquinas.

Su arquitectura se compone principalmente de NameNodes y DataNodes . Los NameNodes son responsables de mantener los metadatos sobre el clúster, como qué nodo contiene qué bloques de archivos. Actúan como coordinadores de la red al determinar dónde es mejor almacenar y replicar archivos, rastreando el estado del sistema. DataNodes simplemente almacena archivos y ejecuta comandos como replicar un archivo, escribir uno nuevo y otros.

Como era de esperar, HDFS se utiliza mejor con Hadoop para la computación, ya que proporciona conocimiento de los datos para los trabajos de computación. Luego, dichos trabajos se ejecutan en los nodos que almacenan los datos. Esto aprovecha la localidad de los datos: optimiza los cálculos y reduce la cantidad de tráfico en la red.

IPFS

El sistema de archivos interplanetario (IPFS) es un nuevo y emocionante protocolo / red de igual a igual para un sistema de archivos distribuido. Aprovechando la tecnología Blockchain, cuenta con una arquitectura completamente descentralizada sin un solo propietario ni punto de falla.

IPFS ofrece un sistema de nombres (similar al DNS) llamado IPNS y permite a los usuarios acceder fácilmente a la información. Almacena archivos a través de versiones históricas, similar a como lo hace Git. Esto permite acceder a todos los estados anteriores de un archivo.

Todavía está experimentando un gran desarrollo (v0.4 al momento de escribir este artículo) pero ya ha visto proyectos interesados ​​en construir sobre él (FileCoin).

Mensajería distribuida

Los sistemas de mensajería proporcionan un lugar central para el almacenamiento y la propagación de mensajes / eventos dentro de su sistema general. Le permiten desacoplar la lógica de su aplicación de hablar directamente con sus otros sistemas.

Escala conocida: el grupo de Kafka de LinkedIn procesó 1 billón de mensajes al día con picos de 4,5 millones de mensajes por segundo.

En pocas palabras, una plataforma de mensajería funciona de la siguiente manera:

Un mensaje se transmite desde la aplicación que potencialmente lo crea (llamado productor ), entra en la plataforma y es leído por varias aplicaciones potencialmente interesadas en él (llamadas consumidores ).

Si necesita guardar un evento determinado en algunos lugares (por ejemplo, creación de usuarios en la base de datos, almacén, servicio de envío de correo electrónico y cualquier otra cosa que se le ocurra), una plataforma de mensajería es la forma más limpia de difundir ese mensaje.

Los consumidores pueden extraer información de los intermediarios (modelo de extracción) o hacer que los intermediarios envíen información directamente a los consumidores (modelo de inserción).

Hay un par de plataformas de mensajería populares de primer nivel:

RabbitMQ: agente de mensajes que le permite un control más detallado de las trayectorias de los mensajes a través de reglas de enrutamiento y otras configuraciones fácilmente configurables. Puede ser llamado un corredor inteligente, ya que tiene mucha lógica y realiza un seguimiento estricto de los mensajes que pasan a través de él. Proporciona configuraciones para AP y CP desde CAP . Utiliza un modelo push para notificar a los consumidores.

Kafka - Agente de mensajes (y plataforma completa) que es un nivel un poco más bajo, ya que no realiza un seguimiento de los mensajes que se han leído y no permite una lógica de enrutamiento compleja. Esto le ayuda a lograr un rendimiento asombroso. En mi opinión, esta es la perspectiva más grande en este espacio con el desarrollo activo de la comunidad de código abierto y el apoyo del equipo de Confluent. Podría decirse que Kafka tiene el uso más extendido de las principales empresas de tecnología. Escribí una introducción completa a esto, donde entro en detalles sobre todas sus bondades.

Apache ActiveMQ: el más antiguo del grupo, que data de 2004. Utiliza la API JMS, lo que significa que está orientado a aplicaciones Java EE. Se reescribió como ActiveMQ Artemis, que proporciona un rendimiento sobresaliente a la par con Kafka.

Amazon SQS: un servicio de mensajería proporcionado por AWS. Le permite integrarlo rápidamente con las aplicaciones existentes y elimina la necesidad de manejar su propia infraestructura, lo que podría ser un gran beneficio, ya que los sistemas como Kafka son notoriamente difíciles de configurar. Amazon también ofrece dos servicios similares: SNS y MQ, el último de los cuales es básicamente ActiveMQ pero administrado por Amazon.

Aplicaciones distribuidas

Si acumula 5 servidores Rails detrás de un único equilibrador de carga, todos conectados a una base de datos, ¿podría llamar a eso una aplicación distribuida? Recuerda mi definición de arriba:

Un sistema distribuido es un grupo de computadoras que trabajan juntas para aparecer como una sola computadora para el usuario final. Estas máquinas tienen un estado compartido, funcionan de forma simultánea y pueden fallar de forma independiente sin afectar el tiempo de actividad de todo el sistema.

Si cuenta la base de datos como un estado compartido, podría argumentar que esto puede clasificarse como un sistema distribuido, pero estaría equivocado, ya que se perdió la parte de " trabajar juntos " de la definición.

Un sistema se distribuye solo si los nodos se comunican entre sí para coordinar sus acciones.

Por lo tanto, algo como una aplicación que ejecuta su código de back-end en una red de igual a igual se puede clasificar mejor como una aplicación distribuida. Independientemente, esta es una clasificación innecesaria que no tiene ningún propósito, pero ilustra lo quisquillosos que somos al agrupar las cosas.

Escala conocida: enjambre de BitTorrent de 193.000 nodos para un episodio de Game of Thrones, abril de 2014

Máquina virtual Erlang

Erlang es un lenguaje funcional que tiene una gran semántica para la concurrencia, distribución y tolerancia a fallas. La propia máquina virtual de Erlang maneja la distribución de una aplicación de Erlang.

Su modelo funciona al tener muchos procesos ligeros aislados , todos con la capacidad de comunicarse entre sí a través de un sistema integrado de transmisión de mensajes. Esto se llama el modelo de actory las bibliotecas de Erlang OTP se pueden considerar como un marco de actor distribuido (en la línea de Akka para la JVM).

El modelo es lo que le ayuda a lograr una gran simultaneidad de manera bastante simple: los procesos se distribuyen entre los núcleos disponibles del sistema que los ejecuta. Dado que esto es indistinguible de una configuración de red (aparte de la capacidad de eliminar mensajes), la VM de Erlang se puede conectar a otras VM de Erlang que se ejecutan en el mismo centro de datos o incluso en otro continente. Este enjambre de máquinas virtuales ejecuta una sola aplicación y maneja las fallas de la máquina a través de la adquisición (se programa la ejecución de otro nodo).

De hecho, se agregó la capa distribuida del lenguaje para brindar tolerancia a fallas. El software que se ejecuta en una sola máquina siempre corre el riesgo de que esa única máquina muera y desconecte la aplicación. El software que se ejecuta en muchos nodos permite un manejo más fácil de fallas de hardware, siempre que la aplicación se haya creado teniendo eso en cuenta.

BitTorrent

BitTorrent es uno de los protocolos más utilizados para transferir archivos grandes a través de la web a través de torrents. La idea principal es facilitar la transferencia de archivos entre diferentes pares en la red sin tener que pasar por un servidor principal.

Con un cliente BitTorrent, se conecta a varias computadoras en todo el mundo para descargar un archivo. Cuando abres un archivo .torrent, te conectas a un llamado rastreador , que es una máquina que actúa como coordinador. Ayuda con el descubrimiento de pares, mostrándole los nodos en la red que tienen el archivo que desea.

Tienes las nociones de dos tipos de usuario, un leecher y un seeder . Un leecher es el usuario que está descargando un archivo y un seeder es el usuario que está cargando dicho archivo.

Lo curioso de las redes peer-to-peer es que usted, como usuario común, tiene la capacidad de unirse y contribuir a la red.

BitTorrent y sus precursores (Gnutella, Napster) le permiten alojar archivos de forma voluntaria y subirlos a otros usuarios que los deseen. La razón por la que BitTorrent es tan popular es que fue el primero de su tipo en brindar incentivos por contribuir a la red. El freeride , donde un usuario solo descargaba archivos, era un problema con los protocolos de intercambio de archivos anteriores.

BitTorrent resolvió el freeride hasta cierto punto al hacer que los seeders subieran más a aquellos que brindan las mejores tasas de descarga. Funciona al incentivarlo a cargar mientras descarga un archivo. Desafortunadamente, una vez que haya terminado, nada lo mantendrá activo en la red. Esto provoca una falta de sembradoras en la red que tengan el archivo completo y como el protocolo depende en gran medida de dichos usuarios, las soluciones como los rastreadores privados se hicieron realidad. Los rastreadores privados requieren que seas miembro de una comunidad (a menudo solo por invitación) para poder participar en la red distribuida.

Después de los avances en el campo, se inventaron los torrents sin rastreadores. Esta fue una actualización del protocolo BitTorrent que no dependía de rastreadores centralizados para recopilar metadatos y encontrar pares, sino que usaba nuevos algoritmos. Una de esas instancias es Kademlia (Mainline DHT), una tabla hash distribuida (DHT) que le permite encontrar pares a través de otros pares. En efecto, cada usuario realiza las tareas de un rastreador.

Libros mayores distribuidos

Se puede pensar en un libro mayor distribuido como una base de datos inmutable de solo anexión que se replica, sincroniza y comparte en todos los nodos de la red distribuida.

Escala conocida: Ethereum Network tuvo un pico de 1.3 millones de transacciones al día el 4 de enero de 2018.

Aprovechan el patrón Event Sourcing, lo que le permite reconstruir el estado del libro mayor en cualquier momento de su historial.

Blockchain

Blockchain es la tecnología subyacente actual utilizada para los libros contables distribuidos y, de hecho, marcó su inicio. Esta última y mayor innovación en el espacio distribuido permitió la creación del primer protocolo de pago verdaderamente distribuido: Bitcoin.

Blockchain es un libro mayor distribuido que contiene una lista ordenada de todas las transacciones que ocurrieron en su red. Las transacciones se agrupan y almacenan en bloques. Toda la cadena de bloques es esencialmente una lista vinculada de bloques (de ahí el nombre) . Dichos bloques son computacionalmente costosos de crear y están estrechamente vinculados entre sí mediante criptografía.

En pocas palabras, cada bloque contiene un hash especial (que comienza con X cantidad de ceros) del contenido del bloque actual (en forma de árbol Merkle) más el hash del bloque anterior. Este hash requiere mucha potencia de CPU para producirse porque la única forma de obtenerlo es a través de la fuerza bruta.

Los mineros son los nodos que intentan calcular el hash (mediante la fuerza bruta). Todos los mineros compiten entre sí por quién puede crear una cadena aleatoria (llamada nonce ) que, cuando se combina con el contenido, produce el hash mencionado anteriormente. Una vez que alguien encuentra el nonce correcto, lo transmite a toda la red. Luego, dicha cadena es verificada por cada nodo por sí solo y aceptada en su cadena.

Esto se traduce en un sistema en el que es absurdamente costoso modificar la cadena de bloques y absurdamente fácil de verificar que no está alterado.

Es costoso cambiar el contenido de un bloque porque eso produciría un hash diferente. Recuerde que el hash de cada bloque subsiguiente depende de él. Si cambiara una transacción en el primer bloque de la imagen de arriba, cambiaría Merkle Root. Esto, a su vez, cambiaría el hash del bloque (probablemente sin los ceros iniciales necesarios), lo que cambiaría el hash del bloque n. ° 2, y así sucesivamente. Esto significa que necesitaría forzar un nuevo nonce para cada bloque después del que acaba de modificar.

La red siempre confía y replica la cadena válida más larga. Para engañar al sistema y eventualmente producir una cadena más larga, necesitaría más del 50% de la potencia total de la CPU utilizada por todos los nodos.

Se puede pensar en Blockchain como un mecanismo distribuido para un consenso emergente . El consenso no se logra explícitamente: no hay elecciones ni un momento fijo en el que se produce el consenso. En cambio, el consenso es un producto emergente de la interacción asincrónica de miles de nodos independientes, todos siguiendo las reglas del protocolo.

Esta innovación sin precedentes se ha convertido recientemente en un boom en el espacio tecnológico y las personas predicen que marcará la creación de la Web 3.0. Definitivamente es el espacio más emocionante en el mundo de la ingeniería de software en este momento, lleno de problemas extremadamente desafiantes e interesantes que esperan ser resueltos.

Bitcoin

Lo que carecían los protocolos de pago distribuidos anteriores era una forma de prevenir prácticamente el problema del doble gasto en tiempo real, de forma distribuida. La investigación ha producido propuestas interesantes [1] pero Bitcoin fue el primero en implementar una solución práctica con claras ventajas sobre otras.

El problema del doble gasto establece que un actor (por ejemplo, Bob) no puede gastar su único recurso en dos lugares. Si Bob tiene $ 1, no debería poder dárselo tanto a Alice como a Zack; es solo un activo, no se puede duplicar. Resulta que es realmente difícil lograr esta garantía en un sistema distribuido. Hay algunos enfoques de mitigación interesantes anteriores a la cadena de bloques, pero no resuelven el problema por completo de una manera práctica.

Bitcoin resuelve fácilmente el doble gasto, ya que solo se agrega un bloque a la cadena a la vez. El doble gasto es imposible dentro de un solo bloque, por lo tanto, incluso si se crean dos bloques al mismo tiempo, solo uno llegará a estar en la cadena más larga eventual.

Bitcoin se basa en la dificultad de acumular potencia de CPU.

Mientras que en un sistema de votación, un atacante solo necesita agregar nodos a la red (lo cual es fácil, ya que el acceso libre a la red es un objetivo de diseño), en un esquema basado en la potencia de la CPU, un atacante enfrenta una limitación física: obtener acceso a más y más potente hardware.

Esta es también la razón por la que los grupos de nodos maliciosos necesitan controlar más del 50% de la potencia computacional de la red para llevar a cabo un ataque exitoso. Menos que eso, y el resto de la red creará una cadena de bloques más larga más rápido.

Ethereum

Ethereum se puede considerar como una plataforma de software programable basada en blockchain. Tiene su propia criptomoneda (Ether) que impulsa el despliegue de contratos inteligentes en su blockchain.

Los contratos inteligentes son un fragmento de código almacenado como una sola transacción en la cadena de bloques Ethereum. Para ejecutar el código, todo lo que tiene que hacer es emitir una transacción con un contrato inteligente como destino. Esto, a su vez, hace que los nodos mineros ejecuten el código y cualquier cambio en el que incurra. El código se ejecuta dentro de la máquina virtual Ethereum.

Solidity , el lenguaje de programación nativo de Ethereum, es lo que se usa para escribir contratos inteligentes. Es un lenguaje de programación completo de turing que interactúa directamente con la cadena de bloques Ethereum, lo que le permite consultar estados como saldos u otros resultados de contratos inteligentes. Para evitar bucles infinitos, ejecutar el código requiere cierta cantidad de Ether.

Dado que la cadena de bloques se puede interpretar como una serie de cambios de estado , se han construido muchas aplicaciones distribuidas (DApps) sobre Ethereum y plataformas similares.

Otros usos de los libros de contabilidad distribuidos

Prueba de existencia : un servicio para almacenar de forma anónima y segura pruebas de que un determinado documento digital existió en algún momento. Útil para garantizar la integridad, la propiedad y el sello de tiempo de los documentos.

Organizaciones autónomas descentralizadas (DAO) : organizaciones que utilizan blockchain como un medio para llegar a un consenso sobre las propuestas de mejora de la organización. Algunos ejemplos son el sistema de gobierno de Dash, el proyecto SmartCash

Autenticación descentralizada : almacene su identidad en la cadena de bloques, lo que le permite utilizar el inicio de sesión único (SSO) en todas partes. Sovrin, cívico

Y muchos muchos mas. La tecnología de contabilidad distribuida realmente abrió infinitas posibilidades. ¡Algunos probablemente se están inventando mientras hablamos!

Resumen

En el breve lapso de este artículo, logramos definir qué es un sistema distribuido, por qué usaría uno y repasar un poco cada categoría. Algunas cosas importantes para recordar son:

  • Los sistemas distribuidos son complejos
  • Se eligen por necesidad de escala y precio.
  • Son más difíciles de trabajar
  • Teorema de CAP: compensación de consistencia / disponibilidad
  • Tienen 6 categorías: almacenes de datos, informática, sistemas de archivos, sistemas de mensajería, libros de contabilidad, aplicaciones

Para ser sincero, apenas hemos tocado la superficie en los sistemas distribuidos. No tuve la oportunidad de abordar y explicar a fondo los problemas centrales como el consenso, las estrategias de replicación, el orden y el tiempo de eventos, la tolerancia a fallas, la transmisión de un mensaje a través de la red y otros.

Precaución

Déjame dejarte con una advertencia de despedida:

Debe alejarse de los sistemas distribuidos tanto como pueda. No vale la pena el esfuerzo por la complejidad en la que incurren ellos mismos si puede evitar el problema resolviéndolo de una manera diferente o con alguna otra solución lista para usar.

[1]

Lucha contra el doble gasto mediante sistemas cooperativos P2P, del 25 al 27 de junio de 2007: una solución propuesta en la que cada 'moneda' puede caducar y se le asigna un testigo (validador) de su gasto.

Bitgold , diciembre de 2005 - Una descripción general de alto nivel de un protocolo extremadamente similar al de Bitcoin. Se dice que este es el precursor de Bitcoin.

Lectura adicional sobre sistemas distribuidos:

Designing Data-Intensive Applications, Martin Kleppmann : un gran libro que repasa todo en sistemas distribuidos y más.

Especialización en computación en la nube, Universidad de Illinois, Coursera : una larga serie de cursos (6) que repasa conceptos y aplicaciones

Jepsen - Blog que explica muchas tecnologías distribuidas (ElasticSearch, Redis, MongoDB, etc.)

¡Gracias por tomarse el tiempo de leer este artículo largo (~ 5600 palabras)!

Si, por casualidad, encontró esta información o pensó que le proporcionó valor, asegúrese de darle tantas palmadas como crea que se merece y considere compartir con un amigo al que le vendría bien una introducción a este maravilloso campo de estudio.

~ Stanislav Kozlovski

Actualizar

Actualmente trabajo en Confluent. ¡Confluent es una empresa de Big Data fundada por los propios creadores de Apache Kafka! Estoy inmensamente agradecido por la oportunidad que me han brindado; actualmente trabajo en Kafka, ¡que es más que increíble! En Confluent ayudamos a dar forma a todo el ecosistema de Kafka de código abierto, incluida una nueva oferta de nube administrada de Kafka-as-a-service.

Estamos contratando para muchos puestos (especialmente SRE / Ingenieros de software) en Europa y EE. UU. Si está interesado en trabajar en Kafka en sí, en busca de nuevas oportunidades o simplemente por curiosidad, asegúrese de enviarme un mensaje en Twitter y compartiré todos los grandes beneficios que se obtienen al trabajar en una empresa del área de la bahía.