REL04-BP01 Identificar el tipo de sistemas distribuidos de los que depende
Los sistemas distribuidos pueden ser síncronos, asíncronos o por lotes. Los sistemas síncronos deben procesar las solicitudes lo más rápido posible y comunicarse entre sí mediante llamadas síncronas de solicitud y respuesta mediante protocolos HTTP/S, REST o de llamada a procedimiento remoto (RPC). Los sistemas asíncronos se comunican entre sí mediante el intercambio de datos de forma asíncrona a través de un servicio intermediario sin acoplar sistemas individuales. Los sistemas por lotes reciben un gran volumen de datos de entrada, ejecutan procesos de datos automatizados sin intervención humana y generan datos de salida.
Resultado deseado: diseña una carga de trabajo que interactúe eficazmente con las dependencias síncronas, asíncronas y por lotes.
Patrones comunes de uso no recomendados:
-
La carga de trabajo espera indefinidamente una respuesta de sus dependencias, lo que podría provocar que se agote el tiempo de espera de los clientes de la carga de trabajo sin saber si su solicitud se ha recibido.
-
La carga de trabajo utiliza una cadena de sistemas dependientes que se llaman entre sí de forma síncrona. Para ello, cada sistema debe estar disponible y procesar correctamente una solicitud para que toda la cadena pueda tener éxito, lo que se traduce en un comportamiento y una disponibilidad general potencialmente frágiles.
-
La carga de trabajo se comunica con sus dependencias de forma asíncrona y confía en que la entrega de mensajes exactamente una vez está garantizada, cuando muchas veces sigue siendo posible que se reciban mensajes duplicados.
-
La carga de trabajo no utiliza herramientas adecuadas de programación por lotes y permite la ejecución simultánea del mismo trabajo por lotes.
Beneficios de establecer esta práctica recomendada: es habitual que una determinada carga de trabajo implemente uno o más estilos de comunicación, ya sea síncrono, asíncrono o por lotes. Esta práctica recomendada le ayuda a identificar las diferentes ventajas y desventajas asociadas a cada estilo de comunicación para que su carga de trabajo pueda tolerar las interrupciones en cualquiera de sus dependencias.
Nivel de riesgo expuesto si no se establece esta práctica recomendada: alto
Guía para la implementación
Las siguientes secciones contienen una guía de implementación general y específica para cada tipo de dependencia.
Guía general
-
Asegúrese de que los objetivos de nivel de servicio (SLO) de rendimiento y fiabilidad que ofrecen sus dependencias cumplan los requisitos de rendimiento y fiabilidad de su carga de trabajo.
-
Use servicios de observabilidad de AWS
para supervisar los tiempos de respuesta y las tasas de error con el fin de asegurarse de que su dependencia atienda los niveles que necesita su carga de trabajo. -
Identifique los posibles desafíos a los que puede enfrentarse su carga de trabajo al comunicarse con sus dependencias. Los sistemas distribuidos presentan una amplia gama de desafíos
que pueden aumentar la complejidad de la arquitectura, la carga operativa y el coste. Entre los desafíos comunes, se incluyen la latencia, las interrupciones de la red, la pérdida de datos, el escalamiento y el retardo en la replicación de datos. -
Implemente una gestión de errores y un registro sólidos que le ayuden a solucionar problemas cuando su dependencia experimente problemas.
Dependencia síncrona
En las comunicaciones síncronas, la carga de trabajo envía una solicitud a su dependencia y bloquea la operación en espera de una respuesta. Cuando la dependencia recibe la solicitud, intenta gestionarla lo antes posible y envía una respuesta a su carga de trabajo. Un problema importante de la comunicación síncrona es que provoca un acoplamiento temporal, por lo que la carga de trabajo y las dependencias de esta deben estar disponibles al mismo tiempo. Cuando la carga de trabajo necesite comunicarse de forma síncrona con sus dependencias, tenga en cuenta lo siguiente:
-
La carga de trabajo no debe depender de varias dependencias síncronas para realizar una sola función. Esta cadena de dependencias aumenta la fragilidad general, porque todas las dependencias de la ruta deben estar disponibles para que la solicitud se complete correctamente.
-
Cuando una dependencia no esté en buen estado o no esté disponible, determine sus estrategias de gestión de errores y reintentos. Evite utilizar un comportamiento bimodal. El comportamiento bimodal se produce cuando la carga de trabajo presenta un comportamiento diferente en los modos normal y de error. Para obtener más información sobre el comportamiento bimodal, consulte REL11-BP05 Usar la estabilidad estática para evitar el comportamiento bimodal.
-
Tenga en cuenta que responder rápido a los errores es mejor que hacer esperar a la carga de trabajo. Por ejemplo, en la Guía para desarrolladores de AWS Lambda se describe cómo gestionar los reintentos y los fallos al invocar funciones de Lambda.
-
Establezca tiempos de espera cuando la carga de trabajo llame a su dependencia. Esta técnica evita esperar demasiado o indefinidamente una respuesta. Para obtener información útil sobre este tema, consulte «Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications»
. -
Minimice la cantidad de llamadas que se realizan desde la carga de trabajo a su dependencia para atender una sola solicitud. Si hay una conversación demasiado intensa entre ellos, aumenta el acoplamiento y la latencia.
Dependencia asíncrona
Para desvincular temporalmente la carga de trabajo de su dependencia, deben comunicarse de forma asíncrona. Con un enfoque asíncrono, la carga de trabajo puede continuar con cualquier otro procesamiento sin tener que esperar a que su dependencia o cadena de dependencias envíe una respuesta.
Cuando la carga de trabajo necesite comunicarse de forma asíncrona con su dependencia, tenga en cuenta lo siguiente:
-
Determine si va a utilizar la mensajería o la transmisión de eventos en función de su caso de uso y sus requisitos. La mensajería
permite que la carga de trabajo se comunique con su dependencia mediante el envío y la recepción de mensajes a través de un agente de mensajes. La transmisión de eventos permite que la carga de trabajo y su dependencia utilicen un servicio de transmisión para publicar y suscribirse a eventos, que se entregan como flujos continuos de datos que deben procesarse lo antes posible.
-
La mensajería y la transmisión de eventos gestionan los mensajes de manera diferente, por lo que debe decidir si compensan en función de:
-
Prioridad de mensajes: los agentes de mensajes pueden procesar los mensajes de alta prioridad antes que los mensajes normales. En la transmisión de eventos, todos los mensajes tienen la misma prioridad.
-
Consumo de mensajes: los agentes de mensajes se aseguran de que los consumidores reciban el mensaje. Los consumidores de la transmisión de eventos deben llevar un registro del último mensaje que han leído.
-
Orden de los mensajes: en el sistema de mensajería, no se garantiza la recepción de los mensajes en el orden exacto en que se envían, a menos que se utilice un enfoque FIFO (primero en entrar, primero en salir). La transmisión de eventos siempre mantiene el orden en que se produjeron los datos.
-
Eliminación de mensajes: en el sistema de mensajería, el consumidor debe eliminar el mensaje después de procesarlo. El servicio de transmisión de eventos añade el mensaje a una transmisión y permanece allí hasta que venza el período de retención. Esta política de eliminación hace que la transmisión de eventos sea adecuada para volver a reproducir mensajes.
-
-
Defina la forma en que la carga de trabajo sabe cuándo su dependencia ha terminado el trabajo. Por ejemplo, cuando la carga de trabajo invoca una función de Lambda de forma asíncrona, Lambda coloca el evento en una cola e indica que se ha realizado correctamente en la respuesta sin información adicional. Una vez finalizado el procesamiento, la función de Lambda puede enviar el resultado a un destino, que se puede configurar en función de si se ha realizado correctamente o no.
-
Aumente la carga de trabajo para gestionar los mensajes duplicados utilizando la idempotencia. La idempotencia significa que los resultados de la carga de trabajo no cambian aunque esta se genere más de una vez para el mismo mensaje. Es importante señalar que los servicios de mensajería
o transmisión volverán a entregar un mensaje si se produce un fallo de la red o si no se recibe la confirmación de la recepción. -
Si la carga de trabajo no recibe una respuesta de su dependencia, debe volver a enviar la solicitud. Considere la posibilidad de limitar el número de reintentos para conservar los recursos de CPU, memoria y red de la carga de trabajo para gestionar otras solicitudes. En la documentación de AWS Lambda se indica cómo gestionar los errores de la invocación asíncrona.
-
Utilice las herramientas de observabilidad, depuración y rastreo adecuadas para administrar y utilizar la comunicación asíncrona de la carga de trabajo con su dependencia. Puede utilizar Amazon CloudWatch
para supervisar los servicios de mensajería y transmisión de eventos. También puede instrumentar la carga de trabajo con AWS X-Ray para obtener rápidamente información para la solución de problemas.
Dependencia por lotes
Los sistemas por lotes toman los datos de entrada, inician una serie de trabajos para procesarlos y producen algunos datos de salida, sin intervención manual. Según el tamaño de los datos, los trabajos pueden durar desde unos minutos hasta, en algunos casos, varios días. Cuando la carga de trabajo se comunique con su dependencia por lotes, tenga en cuenta lo siguiente:
-
Defina el intervalo de tiempo en el que la carga de trabajo debe ejecutar el trabajo por lotes. La carga de trabajo puede configurar un patrón de recurrencia para invocar un sistema por lotes como, por ejemplo, cada hora o al final de cada mes.
-
Determine la ubicación de la entrada de datos y la salida de los datos procesados. Elija un servicio de almacenamiento, como Amazon Simple Storage Service (Amazon S3)
, Amazon Elastic File System (Amazon EFS) y Amazon FSx for Lustre, que permita que su carga de trabajo lea y escriba archivos a escala. -
Si su carga de trabajo necesita invocar varios trabajos por lotes, puede utilizar AWS Step Functions
para simplificar la orquestación de los trabajos por lotes que se ejecutan en AWS o de forma local. Este proyecto de ejemplo demuestra el uso de la orquestación de trabajos por lotes mediante Step Functions, AWS Batch y Lambda. -
Supervise los trabajos por lotes para detectar anomalías, como que un trabajo tarde más de lo debido en completarse. Puede utilizar herramientas como CloudWatch Container Insights para supervisar los entornos y los trabajos de AWS Batch. En este caso, su carga de trabajo impediría el inicio del siguiente trabajo e informaría al personal correspondiente de la excepción.
