Monitoreo en la ejecución de flujos de trabajo (workflows) en arquitecturas de microservicios

Puede separar los pasos de flujo de trabajo de alto nivel de los pasos de flujos de trabajo de bajo nivel para facilitar la supervisión y detección del origen de errores en cuestión de segundos.

El siguiente ejemplo muestra una llamada desde el flujo de servicio de flujo de trabajo principal (izquierda). El primer paso de este proceso es la ejecución del microservicio 1 (utilizado solo como ejemplo). Después de este paso, se realiza una llamada síncrona desde el flujo de trabajo secundario (a la derecha)

 

Figura 3 – Llamada sincrónica entre dos flujos de trabajo en AWS Step Functions

Esta ejecución se considera sincrónica porque el flujo primario espera a que la ejecución del flujo secundario continúe su lógica de negocio. Con esto, el microservicio 2 solo se ejecutará cuando finalice la ejecución de los microservicios 4 y 5. De esta forma, es posible asignar cualquier proceso de negocio que dependa de la ejecución de un subproceso que se considere terminado, exitosamente o fallado.

Para ejecutar flujos asincrónicos, es necesario usar tokens de control de ejecución, así como mecanismos de validación de estado ( opción ) para garantizar que la secuencia primaria solo finalice cuando todas las secuencias secundarias se completan también.

En el siguiente ejemplo se presenta una secuencia principal que, después de ejecutar el primer microservicio, crea tres ramas de ejecución. La rama de la derecha realiza la llamada de un nuevo flujo de trabajo que, al final, actualiza a través de un token u otra forma de notificación (como SNS, SQS, etc.) que su trabajo ha sido completado.

En este modelo, se lleva a cabo un proceso de validación en el flujo de trabajo principal para verificar que la ejecución del flujo secundario ha finalizado y si aún no se ha completado, espera un intervalo de tiempo y vuelve a realizar la validación. Si se ha terminado el flujo de trabajo secundario, el flujo principal sigue su ejecución o finaliza.

 

Parte IV: Ejemplo completo de un flujo de trabajo anidado

En el siguiente ejemplo se muestra una solicitud de compra de un paquete de viaje que incluye validar los datos del solicitante (a través de un microservicio en AWS Lambda), realiza un flujo de trabajo para reservar y efectuar el pago del hotel, un segundo flujo de trabajo para emitir y pagar pasajes aéreos y un último flujo de trabajo creado para gestionar las reservas de automóviles.

 

Figura 4 – Diagrama de alto nivel de solución de reservas de viajes

 

Es posible observar en este ejemplo el uso de un flujo de trabajo principal (flujo de negocio) marcado con el número 1, que durante su ejecución tiene la llamada de un micro servicio validando los datos de viaje. Poco después de este paso, el flujo principal realiza llamadas desde otras secuencias para cada uno de los pasos requeridos (2, 3 y 4).

Para cada uno de los flujos de trabajo anidados (2, 3 y 4), existe una lógica particular para atender el servicio del negocio. Para los flujos 3 y 4, es necesario hacer un llamado nuevamente a un flujo de negocios de pago (5), ya que estos servicios requieren pago en el momento de su contratación, pero el flujo 4, la lógica de negocio solo realiza la reserva sin la necesidad de pago inmediato.

El último flujo de este ejemplo define la lógica (micro servicio) de realizar el pago de una manera genérica (5), de modo que pueda ser reutilizado por varios procesos de negocio. Para que su lógica este completa es necesario realizar la invocación de otros microservicios como la validación de datos personales para que el pago no sea rechazado.

Puede crear y ejecutar AWS Step Functions mediante AWS Management Console, AWS CLI, AWS o AWS CloudFormation. En los siguientes pasos se explica cómo crear un flujo de trabajo exprés desde la CLI de AWS, y AWS Management Console también se utilizará para ver los pasos dados a través de la CLI.

1.Configuración de acceso básico

Paso 1.1: Crear una cuenta gratuita de AWS o utilizar su propia cuenta

Si aún no tiene una cuenta de AWS con acceso de administrador, visite el siguiente enlace y vea cómo crear su cuenta gratuita: https://aws.amazon.com/pt/getting-started/

Paso 1.2: Creación de usuarios para acceso a través de la CLI de AWS

Una vez que tenga una cuenta de AWS, cree un usuario “sfdemo” (nombre sugerido — no utilice comillas) mediante el servicio IAM con acceso de administrador a la cuenta de AWS y establezca el tipo de acceso programático (primera casilla de verificación)

https://console.aws.amazon.com/iam/home?#/users$new?step=details

 

 

Una vez creado el usuario, asigne la política de administrador (AdministratorAccess) a este usuario.

 

 

Información Importante: No se recomienda el acceso de administrador para entornos de desarrollo, pruebas o producción, ya que permite a este usuario ejecute todo tipo de servicios dentro de AWS. La creación de este usuario con este permiso es sólo para demostración y debe evitarse siempre que sea posible.

 

Validar la información y confirmar la información del usuario.

 

 

El usuario se creó correctamente.

 

 

Descargue el archivo the.csv o anote el Access Key ID y el Secret Acess Key

Paso 1.3: Instalación de la CLI de AWS

La instalación de la CLI de AWS depende del sistema operativo (Windows, Linux, macOS, etc.) que utilice en su equipo. Los enlaces a la instalación de CLI están disponibles en la siguiente dirección:

https://docs.aws.amazon.com/pt_br/cli/latest/userguide/install-cliv2.html

Paso 1.4: Configuración de las Credenciales del Usuario Creado

Después de realizar los pasos para crear el usuario, descargar (o anotar) credenciales e instalar la CLI de AWS, debe configurar las credenciales. Para ello, simplemente ejecute el comando “aws configure” y pase la información de credenciales del usuario creado.

AWS Step está disponible en la mayoría de las regiones de AWS, y para la estandarización en este blog, se recomienda utilizar us-east-1 en el campo “Default Region name”. El campo “Default output format” puede dejarse en blanco o en formato json.

 

2. Inicio de la creación del proceso de negocio Book Travel

Ahora que el usuario ya está creado y se ha configurado el acceso a la CLI de AWS, comencemos a crear los microservicios y flujos empresariales que coinciden con el diagrama presentado anteriormente.

 

Figura 5 – Diagrama de alto nivel de solución de reservas de viajes

 

Paso 2.1: Creación de roles de ejecución de microservicios en AWS Lambda

Para este escenario, utilizaremos 7 microservicios que pueden estar disponibles para su empresa para otros procesos de negocio o que se pueden crear en cualquier momento mediante AWS Lambda o alguna solución de AWS Container. Ellos son:

• Obtener datos de viaje
• Validar la disponibilidad de habitaciones (del hotel)
• Reservar hotel
• Comprar tarifa aérea
• Reservar vehículo
• Validar CPF/ CNPJ
• Ejecutar pago

Para que estos microservicios se ejecuten, no es obligatorio, pero se recomienda crear un rol que permita a AWS Lambda escribir registros en AWS CloudWatch y podamos investigar y analizar los registros de la solución.

A continuación, crearemos el rol llamado SFDemoLambdaExecutionRole relacionado con el servicio Principal Lambda. Principal es la entidad (relación de confianza o servicio) a la que se le permite realizar la acción AssumeRole con la siguiente política:

 

Para generar un archivo llamado LambdaTrust.json que contenga esta política (que se utilizará pronto en AWS CLI), escriba la línea de comandos:

aws iam create-role --role-name SFDemoLambdaExecutionRole --assume-role-policy-document "$(cat /tmp/lambdaTrust.json)" --output text --query "Role.Arn" > /tmp/lambdaExecutionRoleArn

 

El comando CLI de AWS que realiza la creación de este rol es el siguiente:

 

 

Tenga en cuenta que la salida del comando está en formato “text” (usando el parámetro —output) y para el resultado del comando solo necesitamos el ARN (filtramos por el parámetro —query). Este valor se almacenará en el archivo lambdaExecutionRoleArn.

Como resultado final, el rol que se crea tendrá la siguiente relación de confianza:

Todavía no hay permisos adjuntos a este rol.

Después de este paso, se creará una directiva de acceso a CloudWatch con el siguiente contenido:

 

 

La generación del archivo lambdaExecutionRole.json que contiene este json se realiza ejecutando el siguiente comando:

 

echo "{\"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Action\": [\"logs:CreateLogGroup\", \"logs:CreateLogStream\", \"logs:PutLogEvents\", \"xray:PutTraceSegments\", \"xray:PutTelemetryRecords\" ], \"Resource\": \"*\" } ] }" > /tmp/lambdaExecutionRole.json

Para validar este paso, es posible ver el rol SFDemoLambdaExecutionRole en AWS Management Console, en el servicio IAM:

 

A partir de ahora, los microservicios de Lambda que se crearán para este blog podrán ejecutar y generar el registro en CloudWatch.

Paso 2.2: Creación de microservicios

Para la creación de los 7 microservicios, podemos utilizar AWS Management Console, crear 7 funciones Lambda, copiar y pegar todo el código en NodeJS. Para facilitar el trabajo y evitar problemas de copiar y pegar, el siguiente archivo contiene la definición de todos los microservicios y su publicación (implementación) mediante la CLI de AWS. Descargue el archivo, realice el cambio de permisos (chmod) para que pueda ser ejecutado el script y, a continuación, realice la llamada al script:

 

Download doe Script de Creación de Fluxos de Serviço

 

chmod ugo+x ./CriarMicroServicos.sh
./CriarMicroServicos.sh

 

En AWS Management Console, en el servicio Lambda, podrá ver la existencia de los 7 microservicios creados, como se muestra en la siguiente imagen.

 

Para comprobar el código Lambda para cualquiera de los microservicios creados, simplemente haga clic en el nombre y aparecerá la pantalla de edición de las funciones de Lambda. Por ejemplo, el microservicio SFDemoComprarPassagemAerea tendrá la siguiente pantalla:

 

Paso 2.4: Creación del rol e inclusión de policies para ejecutar flujos de trabajo

Para poder crear y ejecutar flujos de trabajo, debe crear un rol asociado con el servicio AWS Step Functions e incluir policies con permisos para escribir en CloudWatch, similares a los pasos que se han realizado para los microservicios. También es necesaria la política de ejecución para las funciones Lambda que componen el proceso del negocio, es decir, AWS Step Functions necesita una política que autorice la ejecución de Lambda.

Paso 2.4.1: Creación del rol para ejecutar flujos de trabajo

 

 

El comando para generar un archivo stateTrust.json que contenga esta política es:

 

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Principal\": { \"Service\": \"states.amazonaws.com\"}, \"Action\": \"sts:AssumeRole\"} ] }" > /tmp/statesTrust.json

 

Para crear el rol denominado SFDemoStatesExecutionRole mediante este documento .json generado anteriormente, el comando CLI de AWS es:

 

aws iam create-role --role-name SFDemoStatesExecutionRole --assume-role-policy-document "$(cat /tmp/statesTrust.json)" --output text --query "Role.Arn" > /tmp/statesExecutionoRoleArn

 

Tenga en cuenta que la salida del comando está en formato “text” (usando el parámetro —output) y la salida del comando solo necesitamos el ARN (filtramos con  el parámetro —query). Este valor se almacenará en el archivo StatesExecutionRoleArn.

Paso 2.4.2: Creación de los permisos necesarios para ejecutar el flujo de negocio

AWS Step Functions, en nuestro caso, requiere 2 permisos en otros servicios de AWS. El primero es el acceso a CloudWatch para la creación de registros (logs). Para ello, se generará la siguiente política :

 

 

El comando requerido para crear un archivo de formato.json que contiene esta política es el siguiente:

 

 

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": [ \"logs:CreateLogGroup\", \"logs:CreateLogStream\", \"logs:PutLogEvents\", \"logs:GetLogDelivery\", \"logs:ListLogDeliveries\", \"logs:UpdateLogDelivery\" ], \"Resource\": [ \"*\"]}]}" > /tmp/statesCloudWhatchLogs.json

 

Para incluir esta política en el rol SFDemoStatesExecutionRole, tenemos que ejecutar el siguiente comando de la CLI de AWS:

 

aws iam put-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoCloudWatchLogsPolicy --policy-document file:///tmp/statesCloudWhatchLogs.json

 

AWS Step Functions también realizará llamadas de servicio Lambda, que en nuestro escenario simulan los microservicios de la empresa. Para hacer esto, es necesario permitir que las funciones Lambda sean ejecutadas con la siguiente policy:

 

 

El comando necesario para crear un archivo de formato.json que contiene esta política es el siguiente:

 

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": [ \"lambda:InvokeAsync\", \"lambda:InvokeFunction\"  ], \"Resource\": [\"*\"]}]}" > /tmp/statesRunLambdaBasicPolicy.json

 

Para incluir también esta política en el rol SFDemoStatesExecutionRole (tal como lo hicimos con la política de CloudWatch), tenemos que ejecutar el siguiente comando de CLI de AWS:

 

aws iam put-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoLambdaBasicExecutionPolicy --policy-document file:///tmp/statesRunLambdaBasicPolicy.json

 

La última política que se requiere es el permiso para ejecutar, describir y detener las ejecuciones de workflows (flujos de trabajo) de AWS Step Functions y también incluir eventos en EventBridge. Para ello, debe estar presente la siguiente política en esta función:

 

 

El comando necesario para crear un archivo de formato.json que contiene esta política es el siguiente:

 

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": [ \"states:StartExecution\", \"states:DescribeExecution\", \"states:StopExecution\" ], \"Resource\": [\"*\"]}, { \"Effect\": \"Allow\", \"Action\": [ \"events:PutTargets\", \"events:PutRule\", \"events:DescribeRule\" ], \"Resource\": [\"*\"]}]}" > /tmp/statesExecutionPolicy.json

 

Para incluir esta última política necesaria para este blog en el rol SFDemoStatesExecutionRole, tenemos que ejecutar el siguiente comando de CLI de AWS:

 

aws iam put-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoStatesExecutionPolicy --policy-document file:///tmp/statesExecutionPolicy.json

 

En este punto, la función SFDemoStatesExecutionRole tendrá tres policies:

 

 

Según el diagrama propuesto del proceso de negocio, ahora es necesario crear las 4 workflows (flujos de trabajo) de AWS Step Functions que contengan los flujos secundarios (Hacer pago – FazerPagamento, Reservar Hotel – ReservarHotel, Reservar pasaje – ReservarPassagem y Reservar Carro – ReservarCarro), así como el flujo de trabajo principal (Reservar Viaje – ReservarViagem) que llamará a estos flujos de trabajo anidados.

La creación de un flujo de trabajo se puede realizar a través de la consola de administración de AWS, utilizando el lenguaje Amazon States Language (ASL) a través de la CLI de AWS, AWS CloudFormation o SDK.

 

 

Esta es la vista de creació de un nuevo flujo de trabajo mediante la consola. Tenga en cuenta que a medida que se están creando estados dentro del cuadro Definitions (izquierda), puede tener una presentación gráfica del flujo en el siguiente diagrama (derecha).

Para facilitar el trabajo y evitar problemas de copia y pegado, el siguiente archivo contiene la definición de todos los flujos de trabajo (AWS Step Functions) y su publicación (deploy) mediante la CLI de AWS.  Descargue el archivo, realice el cambio de permisos (chmod) consintiendo que se ejecute el script y, a continuación, realizar la llamada al script:

 

Download de Script de Creación de Fluxos de Trabajo

 

chmod ugo+x ./CriarFluxoTrabalho.sh
./CriarFluxoTrabalho.sh

El script para crear los flujos está disponible en este archivo, y los pasos para su ejecución se presentan a continuación.

 

 

Para ver cada uno de los flujos de trabajo, simplemente haga clic en el nombre del flujo y luego edite y vea el json que define los estados de flujo y la representación gráfica de este proceso.

 

 

El flujo de trabajo principal (Reservar Viaje – ReservarViagem) tendrá los estados enumerados a continuación. Tenga en cuenta que el flujo consta de 4 pasos (estados) llamados “Validar Dados da Viagem” (Validar datos del viaje), “Reservar Hotel”, “Reservar Passagem” (Reservar Pasaje) y “Reservar Carro”.

 

 

De estos 4 pasos, el primero es la simple llamada de un microservicio Lambda y los otros 3 estados se llaman desde otros flujos de trabajo en AWS Step Function.

Con estos pasos ya tenemos todo el flujo de trabajo (primario y secundario), micro servicios y permisos para llevar a cabo el proceso de negocio.

 

Parte VI: Mecanismos de monitoreo de los flujos de trabajo

Con AWS, puede mejorar la agilidad de sus negocios mientras mantiene el control de gobierno. AWS ofrece soluciones de monitoreo y observabilidad para que pueda comprender y mejorar el estado, el rendimiento y la disponibilidad de sus recursos en AWS y en on-premises.

Alternativa 1 : Uso de AWS Management Console desde Step Functions

Si es necesario utilizar flujos de trabajo anidados en su proceso de negocio, debe planificar mecanismos de control de ejecución e investigaciones de incidentes que estos diversos flujos pueden generar. Como ya no es un punto único de registros para todos los microservicios o flujos de trabajo, intento en vista de que cada microservicio tiene su propio LogGroup y también son gestionados por varios servicios de negocio, necesitamos tener alternativas para facilitar el análisis de ejecución y las correcciones cuando sea necesario.

La forma más sencilla de realizar un seguimiento de la ejecución de un flujo de trabajo es a través de la consola AWS Step Functions. En esta consola puede ver todas las ejecuciones que están en progreso o finalizadas, y si la ejecución fue correcta o errónea.

Puede iniciar una nueva ejecución mediante el botón “Start Execution” de AWS Management Console o mediante la CLI con el siguiente comando:

 

aws stepfunctions start-execution --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)" --input "{ \"Origem\": \"Sao Paulo\", \"Destino\": \"Nova Iorque\", \"Data\": \"15/04/2022\", \"NumeroPessoas\": 2, \"ReservarCarro\": true }"

 

 

Al hacer clic en cualquiera de las ejecuciones del servicio, puede validar qué procesos/pasos se ejecutaron, los parámetros de entrada y salida de cada estado y el resultado final del proceso de negocio. Por ejemplo, seleccionando una de las ejecuciones de nuestro proceso de negocio principal, puede ver los 4 pasos ejecutados (un microservicio y 3 procesos secundarios) en color verde, mostrando que para esta ejecución todo el proceso ocurrió sin falta.

 

 

Pero si necesita investigar los flujos de trabajo secundarios o tener una vista más completa de la ejecución, es posible que la consola de AWS Step Functions no proporcione esta vista detallada.

Alternativa 2 : Uso de AWS X-Ray

Para obtener visibilidad de todos los pasos realizados por un flujo de trabajo, puede habilitar el seguimiento mediante AWS X-Ray. AWS X-Ray ayuda a los desarrolladores a analizar y depurar aplicaciones de producción distribuidas, como las creadas con una arquitectura de microservicios. También le permite comprender el rendimiento de las aplicaciones y sus servicios subyacentes para identificar y solucionar problemas y errores o impactos en ejecuciones que consumen mucho tiempo. AWS X-Ray ofrece una vista completa de las solicitudes a medida que viajan por el proceso empresarial y muestra un mapa de los componentes anidados, el objetivo de este blog.

Para habilitar X-Ray en nuestro ejemplo, necesitamos otorgar permisos de llamada de servicio X-Ray a las funciones de Lambda a través de una política y también agregar otra política similar en el Rol que está asociada a nuestros flujos de trabajo.

Esta política para las funciones de Lambda tendrá la siguiente estructura:

 

 

La creación de este archivo en formato json se puede realizar ejecutando el siguiente comando:

 

echo "{ \"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Action\": [\"xray:PutTraceSegments\", \"xray:PutTelemetryRecords\" ], \"Resource\": \"*\" } ] }" > /tmp/lambdaExecutionRoleXRay.json

 

Para incluir esta política de permisos en el servicio X-Ray en la función SFDemoStatesExecutionRole, tenemos que ejecutar el siguiente comando de CLI de AWS:

 

aws iam put-role-policy --role-name SFDemoLambdaExecutionRole --policy-name SFDemoLambdaBasicExecution --policy-document file:///tmp/lambdaExecutionRoleXray.json

 

Del mismo modo, los flujos empresariales que se crearon con AWS Step Functions necesitan acceso al servicio X-Ray. La política para este permiso es:

 

 

La creación de este archivo en formato json se puede realizar ejecutando el siguiente comando:

 

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": [ \"xray:PutTraceSegments\", \"xray:PutTelemetryRecords\", \"xray:GetSamplingRules\", \"xray:GetSamplingTargets\" ], \"Resource\": [\"*\"]}]}" > /tmp/statesXrayPolicy.json

 

Para incluir esta política de permisos en el servicio X-Ray en SFDemoStatesExecutionRole, tenemos que ejecutar el siguiente comando de la CLI de AWS:

 

aws iam put-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoStatesXrayPolicy --policy-document file:///tmp/statesXrayPolicy.json

 

Para habilitar las funciones de X-Ray en Lambda que ya existen, puede hacerlo a través de AWS Management Console o a través de la CLI de AWS. El comando CLI de AWS para actualizar todos los microservicios de este blog es:

 

aws lambda update-function-configuration --function-name SFDemoValidaCPF                            --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoExecutarPagamento            --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoValidarDisponibilidadeQuarto --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoReservarHotel                --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoComprarPassagemAerea         --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoReservarCarro                --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoValidarDadosDaViagem         --tracing-config Mode=Active --output text --query "LastUpdateStatus"

Del mismo modo, para actualizar los flujos de negocio y generar información para el servicio X-Ray, podemos utilizar AWS Management Console o mediante la CLI de AWS. Los comandos para actualizar los 5 flujos de negocio del alcance de este blog nuestro son:

 

aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarPassagemArn)" --tracing-configuration enabled=true --output text --query "updateDate"
aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarHotelArn)"    --tracing-configuration enabled=true --output text --query "updateDate"
aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarCarroArn)"    --tracing-configuration enabled=true --output text --query "updateDate"
aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineFazerPagamentoArn)"   --tracing-configuration enabled=true --output text --query "updateDate"
aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)"   --tracing-configuration enabled=true --output text --query "updateDate"

Con los permisos establecidos (políticas asociadas a los roles) y funciones/flujos empresariales de Lambda en AWS Step Functions actualizados, necesitamos ejecutar un nuevo flujo de trabajo principal una vez más para poder ver la información en X-Ray.

 

aws stepfunctions start-execution --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)" --input "{ \"Origem\": \"Sao Paulo\", \"Destino\": \"Nova Iorque\", \"Data\": \"15/04/2022\", \"NumeroPessoas\": 2, \"ReservarCarro\": true }"

 

A partir de este momento, los datos de la última ejecución del flujo empresarial ya se han cargado en AWS. Mediante AWS Management Console, en el servicio AWS X-Ray, en el menú de la izquierda donde se encuentra el elemento “Service Map”, puede analizar toda la ejecución de la reserva de viaje

 

 

En la consola de AWS X-Ray puede ver todos los servicios llamados, el tiempo de ejecución de cada servicio y los problemas si se producen. AWS X-Ray realiza un seguimiento de las solicitudes de los usuarios a medida que viajan por todo el flujo empresarial, independientemente de si solo hay una sola transmisión o secuencias anidadas, como en nuestro ejemplo de este blog. Agrega los datos generados por los servicios y recursos individuales que componen el flujo de negocio, proporcionando una visión completa de su rendimiento.

Para aclarar cómo se atraviesan el flujo principal y los flujos anidados, la siguiente imagen resalta el flujo de trabajo principal en morado, los flujos secundarios en rojo y también el flujo de ejecución de pagos terciario en azul.

 

 

Además de esta vista de encadenamiento de servicio, es posible tener un análisis en tiempo de ejecución de cada parte de la solución utilizando la función “Traces” del menú de la izquierda, justo debajo del menú “Service Map”.

 

 

En esta ejecución, el flujo principal duró 846 ms, que es la agregación del tiempo de su ejecución y también de los otros flujos de negocio. La ejecución de la función Lambda de validación de los datos de viaje duró 380 ms, la ejecución del flujo de negocios de reservar hotel duró 136 ms y así sucesivamente.

Con este análisis, es posible identificar cuellos de botella (caída en el rendimiento de la aplicación) y actuar de manera que resuelva el problema para que no afecte a la experiencia del usuario final ni retrasa los procesos de negocio.

Alternativa 3 : utilice los logs de CloudWatch para obtener una vista completa de los flujos empresariales en ejecución

Para complementar las soluciones de monitoreo y observabilidad de la solución, es posible incluir registros del flujo principal del proceso y todos sus pasos. CloudWatch Logs le permite centralizar los registros de todos los sistemas, aplicaciones y servicios de AWS que utiliza en un único servicio altamente escalable. A continuación, puede visualizarlos fácilmente, buscar patrones o códigos de error específicos, filtrarlos en función de campos específicos o archivarlos de forma segura para futuros análisis. CloudWatch Logs le permite ver todos los registros, independientemente del origen, como un flujo único y coherente de eventos ordenados por tiempo, y puede consultarlos y ordenarlos en función de otras dimensiones, agrujarlos por campos específicos, crear cálculos personalizados utilizando una consulta eficiente y ver los datos de registro en paneles.

El primer paso que vamos a hacer es crear un nuevo LogGroup para el flujo de trabajo principal. La creación de este LogStream se realiza mediante el siguiente comando de la CLI de AWS:

aws logs create-log-group --log-group-name SFDemoReservarViagemPRINCIPAL

 

Para poder acceder al ARN de LogGroup que creó, debe ejecutar el siguiente comando en la CLI de AWS:

aws logs describe-log-groups --log-group-name-prefix SFDemoReservarViagemPRINCIPAL --output text --query 'logGroups[*].arn' > /tmp/SFDemoReservarViagemPRINCIPALLogGroup

 

El último paso necesario es actualizar el flujo de trabajo principal definiendo el nivel de registro y qué LogGroup se debe utilizar. Para este blog, vamos a utilizar el nivel ALL (todos los datos de registro). El comando CLI de AWS para realizar esta actualización es:

aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)" --logging-configuration "{\"level\": \"ALL\", \"includeExecutionData\": true, \"destinations\": [ { \"cloudWatchLogsLogGroup\": { \"logGroupArn\": \"$(cat /tmp/SFDemoReservarViagemPRINCIPALLogGroup)\" } } ] } " --output text --query "updateDate"

 

Para generar información en CloudWatch Logs, ejecutemos de nuevo el flujo de trabajo principal.

aws stepfunctions start-execution --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)" --input "{ \"Origem\": \"Sao Paulo\", \"Destino\": \"Nova Iorque\", \"Data\": \"15/04/2022\", \"NumeroPessoas\": 2, \"ReservarCarro\": true }"

 

En AWS Management Console, en el servicio CloudWatch, en el menú de la izquierda dentro de la opción Registros y grupos de registro, podremos ver todos los LogGroup creados.

 

 

Al seleccionar LogGroup SFDemoReservarViagemPRINCIPAL, podemos ver todas las ejecuciones de la secuencia principal. En este momento, solo debería haber un log de ejecución, pero si el flujo de trabajo se ha ejecutado otras veces, habrá nuevas entradas presentes.

 

 

El registro contendrá llamadas de todos los estados, ejecuciones de todas las tareas y llamadas de todos los demás flujos de trabajo de la solución, dando visibilidad a los parámetros de entrada y salida de cada uno de los pasos.

 

Parte VI: Costos

En este blog utilizamos IAM para definiciones de roles y políticas, AWS Lambda para ejecutar microservicios, AWS Step Functions para definir flujos de trabajo (primarios y anidados), AWS X-Ray for y observabilidad y registros de CloudWatch. Hay una capa gratuita para cada uno de ellos, pero generalmente es interesante consultar la página de AWS para ver los costes de cada servicio, ya que dependiendo del uso puede haber variaciones.

A continuación se muestra una tabla con el enlace al modelo de precios y también una breve descripción del nivel gratuito para cada servicio.

 

Servicio	Enlace de precios	Nivel Gratuito
Función y políticas de IAM	Sin costo	Totalmente gratis
AWS Lambda	https://aws.amazon.com/pt/lambda/pricing/	1 millón de solicitudes gratuitas por mes y 400.000 GB/segundos de tiempo de cómputo por mes
Funciones de paso de AWS	https://aws.amazon.com/pt/step-functions/pricing/	4.000 transiciones de estado (flujos estándar)
Rayos X de AWS	https://aws.amazon.com/pt/xray/pricing/	Los primeros 100.000 escaneos registrados cada mes son gratuitos Los primeros 1.000.000 de escaneos recuperados o verificados cada mes son gratuitos
CloudWatch	https://aws.amazon.com/pt/cloudwatch/pricing/	5 GB de datos (consumo, almacenamiento de archivos y datos verificados por consultas de Logs Insights)

Parte VII: Eliminación de servicios creados

En este blog desarrollamos microservicios en AWS Lambda y flujos de trabajo mediante AWS Step Functions. Para proporcionar acceso, se crearon 2 roles y algunas políticas. También creamos automáticamente algunos LogGroups para los 7 microservicios en Lambda y creamos de forma explícita un LogGroup para el flujo de trabajo principal de la reserva de viajes. Para eliminar estos servicios, siga los comandos de la CLI de AWS.

 

Política y desplazarse a AWS Lambda:

aws iam delete-role-policy --role-name SFDemoLambdaExecutionRole --policy-name SFDemoLambdaBasicExecution

aws iam delete-role --role-name SFDemoLambdaExecutionRole

 

Servicios de AWS Lambda:

aws lambda delete-function --function-name SFDemoValidaCPF

aws lambda delete-function --function-name SFDemoExecutarPagamento

aws lambda delete-function --function-name SFDemoValidarDisponibilidadeQuarto

aws lambda delete-function --function-name SFDemoReservarHotel

aws lambda delete-function --function-name SFDemoComprarPassagemAerea

aws lambda delete-function --function-name SFDemoReservarCarro

aws lambda delete-function --function-name SFDemoValidarDadosDaViagem

 

Política y desplazamiento a AWS Step Functions:

aws iam delete-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoStatesXrayPolicy

aws iam delete-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoLambdaBasicExecutionPolicy

aws iam delete-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoStatesExecutionPolicy

aws iam delete-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoCloudWatchLogsPolicy


aws iam delete-role --role-name SFDemoStatesExecutionRole

 

Flujo de trabajo en funciones de paso de AWS:

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineFazerPagamentoArn)"

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarHotelArn)"

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarPassagemArn)"

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarCarroArn)"

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)"

 

Inicia sesión en CloudWatch:

aws logs delete-log-group --log-group-name SFDemoReservarViagemPRINCIPAL

for lg in $(aws logs describe-log-groups --query "logGroups[?logGroupName | contains(@, 'aws/lambda/sumologic')].logGroupName" --output text); do

aws logs delete-log-group --log-group-name "$lg";

done;

 

Parte VIII: Conclusión

Muchos clientes ya están usando AWS Step Functions para orquestar cargas de trabajo auditables a largo o corto plazo (estándar o expreso). Agregar flujos de trabajo anidados implica una mayor necesidad de control de procesos y ejecución, pero con AWS Management Console dentro de AWS Step Functions, X-Ray y CloudWatch puede realizar un seguimiento integral del proceso empresarial y también proporcionar herramientas a los desarrolladores para analizar el rendimiento y solucionar problemas que puedan aparecer durante la construcción de la solución.

 

Este artículo fue traducido del Blog de AWS en Portugués

 

---

Sobre los autores

Daniel Abib es Customer Solutions Manager  de AWS, con más de 20 años trabajando en gestión de proyectos, arquitecturas de aplicaciones, desarrollo de sistemas, microservicios, serverless y seguridad.  Trabaja para apoyar a los clientes de Enterprise, ayudándoles en su transición a la nube.

 

 

 

 

Enrico es un Arquitecto de Soluciones especialista en Serverless en AWS para América Latina y trabaja para ayudar a clientes de varios segmentos en su proceso de modernización de aplicaciones en la nube.  Con más de 10 años de experiencia en Arquitectura y Desarrollo de Sistemas, y DevOps, Enrico ha trabajado directamente con varias empresas en la definición, implementación e implementación de diversas soluciones empresariales.

 

 

 

Revisor

Javier Cristancho es Arquitecto de Soluciones Senior  en AWS Colombia. Ha trabajado en AWS para clientes en Sudamérica y Centroamérica. En su puesto actual, trabajó apoyando a las principales organizaciones de servicios financieros en su adopción de la nube. Es uno de los pioneros de la comunidad interna de LATAM AWS Serverless Advocate.