REL 4: ¿Cómo diseña interacciones en un sistema distribuido para evitar errores?

Los sistemas distribuidos dependen de las redes de comunicación para interconectar los componentes, como servidores o servicios. A pesar de la pérdida de datos o la latencia en estas redes, su carga de trabajo debe operar de manera confiable. Los componentes del sistema distribuido deben funcionar de manera que no afecten negativamente a otros componentes o a la carga de trabajo. Las prácticas recomendadas evitan errores y mejoran el tiempo promedio entre los errores (MTBF).

Recursos

AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
Amazon EC2: Ensuring Idempotency
The Amazon Builders' Library: Challenges with distributed systems

Prácticas recomendadas:

• Identifique qué tipo de sistema distribuido se requiere: Los sistemas distribuidos de tiempo real críticos requieren que las respuestas se brinden de manera sincronizada y rápida, mientras que los sistemas de tiempo real flexibles disponen de una franja de tiempo en minutos mucho más amplia para proporcionar respuestas. Los sistemas sin conexión gestionan las respuestas a través del procesamiento asíncrono o por lotes. Los sistemas distribuidos de tiempo real estrictos presentan los requisitos de fiabilidad más rigurosos.

• Implemente dependencias con acoplamiento bajo: Las dependencias, como los sistemas de cola, los sistemas de streaming, los flujos de trabajo y los balanceadores de carga, están acopladas en un nivel bajo. El bajo acoplamiento ayuda a aislar el comportamiento de un componente de los demás componentes que dependen de él, lo que aumenta la resistencia y la agilidad

• Proporcione respuestas idempotentes: Un servicio idempotente garantiza que cada solicitud se complete exactamente una vez, de manera que hacer múltiples solicitudes idénticas tiene el mismo efecto que hacer una solicitud única. Un servicio idempotente facilita a los clientes la implementación de reintentos sin temor a que una solicitud se procese erróneamente varias veces. Para implementar los reintentos, los clientes pueden emitir solicitudes de la API con un token de idempotencia; el mismo token se utiliza cuando se repite la solicitud. Una API de servicio idempotente usa el token para generar una respuesta idéntica a la respuesta que se generó la primera vez que se completó la solicitud.

• Realice un trabajo constante: Los sistemas pueden producir errores cuando hay cambios grandes y rápidos en la carga. Por ejemplo, un sistema de comprobación de estado que monitorea el estado de miles de servidores debe enviar cada vez una carga del mismo tamaño (una instantánea completa del estado actual). Aunque ningún servidor fallara o todos lo hicieran, el sistema de comprobación de estado realiza un trabajo constante sin cambios grandes ni rápidos.

Plan de mejora

Identifique qué tipo de sistema distribuido se requiere

Identifique qué tipo de sistema distribuido se requiere: Los desafíos con los sistemas distribuidos incluían latencia, escalado, comprensión de las API de redes, serialización y deserialización de datos y la complejidad de algoritmos como Paxos. A medida que los sistemas se hacen más grandes y más distribuidos, lo que habían sido casos de borde teóricos se convierten en ocurrencias regulares.
The Amazon Builders' Library: Challenges with distributed systems

• Los sistemas distribuidos en tiempo real requieren que las respuestas se den de forma sincrónica y rápida.
• Los sistemas blandos en tiempo real tienen una ventana de tiempo más generosa de minutos o más para la respuesta
• Los sistemas sin conexión gestionan las respuestas a través del procesamiento asíncrono o por lotes.
• Los sistemas distribuidos de tiempo real estrictos presentan los requisitos de fiabilidad más rigurosos.

Implemente dependencias con acoplamiento bajo

Implemente dependencias con acoplamiento bajo: Las dependencias, como los sistemas de cola, los sistemas de streaming, los flujos de trabajo y los balanceadores de carga, están acopladas en un nivel bajo. El bajo acoplamiento ayuda a aislar el comportamiento de un componente de los demás componentes que dependen de él, lo que aumenta la resistencia y la agilidad
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?

• Amazon EventBridge le permite crear arquitecturas controladas por eventos, que se acoplan y distribuyen libremente
  AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)
• Si los cambios en un componente impulsan a los otros componentes que dependen de este a que cambien, entonces se trata de un acoplamiento ajustado. El bajo acoplamiento rompe esta dependencia, de modo que los componentes dependientes solo necesitan conocer la interfaz publicada y la de la versión.
• Haga que las interacciones de los componentes sean asíncronas siempre que sea posible. Este modelo es adecuado para cualquier interacción que no necesite una respuesta inmediata y en la que bastará una confirmación de que la solicitud se ha registrado.
  AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)

Proporcione respuestas idempotentes

Proporcione respuestas idempotentes: Un servicio idempotente garantiza que cada solicitud se complete exactamente una vez, de manera que hacer múltiples solicitudes idénticas tiene el mismo efecto que hacer una solicitud única.

• Los clientes pueden emitir solicitudes de la API con un token de idempotencia; el mismo token se utiliza cuando se repite la solicitud. Una API de servicio idempotente usa el token para generar una respuesta idéntica a la respuesta que se generó la primera vez que se completó la solicitud.
  Amazon EC2: Ensuring Idempotency

Realice un trabajo constante

Realice un trabajo constante: Los sistemas pueden producir errores cuando hay cambios grandes y rápidos en la carga
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)

• Diseñe las cargas de trabajo para que los tamaños de la carga útil permanezcan constantes, independientemente del número de éxitos o fracasos.
  • Por ejemplo, si el sistema de comprobación de estado monitorea 100 000 servidores, la carga sobre este es nominal según la tasa ligera de errores del servidor. Sin embargo, si un evento importante hace que la mitad de esos servidores sean incorrectos, entonces el sistema de comprobación de estado estaría abrumado intentando actualizar los sistemas de notificaciones y comunicar el estado a sus clientes. En su lugar, el sistema de comprobación de estado debe enviar cada vez la instantánea completa del estado actual. Los estados de 100 000 servidores, cada uno representado por un bit, implicarían una carga de 12,5 KB. Independientemente de que no haya servidores que produzcan errores, o que todos los produzcan, el sistema de comprobación de estado realiza un trabajo constante y los cambios grandes y rápidos no constituyen una amenaza a la estabilidad del sistema. Esta es realmente la forma en que está diseñado el plano de control para llevar a cabo las comprobaciones de estado de Amazon Route 53.