Es hora de sincronizar la coherencia en los sistemas IIoT

Un tema importante (y muy debatido) en el diseño de sistemas distribuidos es qué modelo de coherencia utilizar. Los modelos de consistencia influyen en muchas partes del diseño del sistema, y ​​elegir uno sobre el otro impacta cosas como la disponibilidad del sistema y la solidez contra fallas de la red. Este blog está destinado a los arquitectos de sistemas que desean comprender mejor lo que significa ser o no ser coherente.

Primero, aclaremos que este blog no trata sobre la "C" en ACID (https://en.wikipedia.org/wiki/ACID). La coherencia de ACID garantiza que las actualizaciones de un almacén de datos sean válidas de acuerdo con un conjunto de restricciones. Este blog se centra en el tipo de coherencia que describe lo que sucede cuando los datos se replican entre tiendas distribuidas. Resulta que ACID lo hace decir algo sobre eso, pero es el "yo" (Aislamiento), no la "C" ¿Confuso? Un poco, pero tengan paciencia conmigo.

El aislamiento también se conoce como consistencia fuerte . Cuando un sistema es muy consistente, todas las escrituras y lecturas entre tiendas distribuidas se ejecutan en el mismo orden para cada aplicación en ese sistema. Esa es una forma elaborada de decir, cuando una aplicación escribe algo, todas las aplicaciones que leen después la escritura, están garantizados para ver los nuevos datos.

Esto resulta ser una propiedad increíblemente útil en muchos sistemas. Se asegura de que no dos personas puedan pedir el mismo refrigerador en un sitio web de compras, ni siquiera cuando compren exactamente al mismo tiempo. La coherencia sólida impone el mismo orden de operaciones globalmente , por lo que dos compras siempre son procesadas por todos en el mismo pedido. En la práctica, esto significa que el segundo intento de compra está garantizado para ver que el refrigerador está agotado.

Una consistencia sólida suena como algo muy bueno, entonces, ¿por qué no la usan todos los sistemas? Es por algo llamado teorema CAP (https://en.wikipedia.org/wiki/CAP_theorem). Primero, una nota rápida:CAP ha sido legítimamente criticado por muchos porque es demasiado simple para describir el comportamiento de sistemas distribuidos complejos, así que tenga cuidado al usarlo, pero proporciona un marco útil para discutir modelos de coherencia. No entraré en detalles de CAP porque Internet tiene muchos recursos que hacen un trabajo mucho mejor de lo que yo podría esperar hacer aquí.

En resumen, CAP nos dice qué sucede en los sistemas distribuidos cuando las aplicaciones pierden temporalmente la capacidad de "hablar", es decir, cuando la red se cae. Resulta que es imposible que un sistema sea muy consistente y Garantice siempre el tiempo de actividad, independientemente de la pérdida de conectividad. Qué lástima.

Suena complejo, pero en realidad es bastante intuitivo. ¿Recuerda que la consistencia fuerte requiere un orden global para todas las operaciones en un sistema? Eso significa que una lectura debe ver todos los escritos anteriores, de todos. Si no todas las aplicaciones están conectadas, esto se vuelve imposible de garantizar. Es posible que una solicitud haya realizado un pedido de un refrigerador, pero si no todas las solicitudes han recibido este pedido todavía, no podrán realizar nuevos pedidos. ¡Eso da como resultado un tiempo de inactividad para el sitio web de compras!

El tiempo de inactividad se puede mitigar dedicando más recursos al problema, como hacer la replicación de la base de datos (más almacenamiento) o implementar servidores web redundantes (más computación). Hoy en día, esto es casi trivial en las infraestructuras de la nube pública, aunque se vuelve bastante caro y complejo cuando un sistema tiene muchas partes móviles, como ocurre con las arquitecturas de microservicios. Cuando un sistema no se ejecuta en una nube, agregar más recursos está lejos de ser trivial, ya que el almacenamiento, la computación y el ancho de banda están mucho más restringidos en entornos que no son de nube.

Por lo tanto, si bien la coherencia sólida es conveniente para las aplicaciones, es una carga para la infraestructura (¡y su billetera!). Para sortear estos problemas, personas inteligentes han ideado soluciones que no son tan pedantes en lo que respecta a la coherencia, pero que siguen siendo viables desde la perspectiva de la aplicación. De lo que estamos hablando es de "consistencia eventual". Es hora de otra definición.

Un sistema es finalmente consistente cuando, si no ha habido actualizaciones para un elemento dado, todas las aplicaciones finalmente ven el mismo valor. O en términos simples:todos eventualmente ven los mismos datos si esperan lo suficiente. Esto significa que las aplicaciones pueden leer y escribir al mismo tiempo, y pueden hacerlo incluso cuando la red no funciona. Finalmente, la infraestructura del sistema entrega todas las actualizaciones a las aplicaciones.

Debido a que las aplicaciones no tienen que esperar unas a otras, el tiempo de actividad de un sistema eventualmente consistente es teóricamente infinito, siempre que sus aplicaciones no se bloqueen ni se produzca un corte de energía. Sin embargo, el infinito no es práctico; después de un tiempo, espera que sus aplicaciones se vuelvan a conectar. Por lo tanto, los sistemas eventualmente consistentes generalmente ponen un límite al tiempo que puede tomar para volverse consistente. Cuando ese límite expira y las aplicaciones no tuvieron la oportunidad de sincronizarse, se produce la recuperación de fallas.

La disponibilidad no es la única ventaja de los sistemas eventualmente consistentes. Debido a que las lecturas y escrituras no requieren sincronización, como es el caso de los sistemas fuertemente consistentes, son mucho más rápidas. La falta de sincronización también permite la comunicación directa de igual a igual, lo que mejora aún más el rendimiento y al mismo tiempo mejora la solidez, ya que elimina la necesidad de un intermediario de mensajes centralizado, que introduce puntos únicos de falla.

Si bien la coherencia eventual no funciona para los sitios web de compras, al considerar sus ventajas (disponibilidad, rendimiento, solidez, eficiencia de recursos) no debería sorprender que se use mucho en sistemas de misión crítica.

RTI Connext Product Suite es la implementación líder del estándar OMG DDS, que se implementa ampliamente como protocolo en sistemas de IoT industriales de misión crítica. Una gran diferencia entre OMG DDS y otros protocolos de conectividad es que DDS se comporta como una base de datos distribuida que se sincroniza continuamente entre aplicaciones, mientras que otros protocolos generalmente proporcionan una interfaz para enviar mensajes y dejar la administración del estado a la aplicación.

Si cree que una base de datos distribuida suena como algo que tiene que lidiar con la coherencia, tiene razón. RTI Connext DDS tiene que equilibrar constantemente la disponibilidad y el rendimiento con la coherencia para poder trabajar en los entornos de misión crítica más exigentes. De forma predeterminada, RTI Connext DDS utiliza una coherencia eventual que garantiza que las aplicaciones creadas con él no dejen de funcionar cuando falla la red, al tiempo que garantiza que todas las aplicaciones eventualmente compartan la misma visión del "mundo".

Ahora puede ver cómo algo que suena tan abstracto como la "coherencia" tiene consecuencias de gran alcance y debe tratarse como un tema importante en el diseño inicial del sistema. Desafortunadamente, nunca es tan simple como ser "fuertemente consistente" o "eventualmente consistente". Una arquitectura lambda (https://en.wikipedia.org/wiki/Lambda_architecture) es solo un ejemplo que usa consistencia fuerte y eventual para obtener lo mejor de ambos mundos. Con tantos matices de consistencia, los arquitectos de sistemas tienen que tomar decisiones complejas sobre cuánta consistencia puede permitirse su sistema.

En RTI, nuestro equipo de servicios profesionales lo ayuda a tomar esas decisiones, razonar las consecuencias y configurar nuestros productos para crear una solución coherente que funcione para usted.

Obtenga más información sobre los servicios de RTI aquí:https://www.rti.com/services