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

Por Daniel Abib, Sr. Customer Solutions Manager, DNB/ISV – LATAM y
Enrico Bergamo, Sr. Specialist Solutions Architect, Serverless – LATAM

La migración de arquitecturas monolíticas y de mainframe a Soluciones Modernas que utilizan conceptos de microservicio ya está muy extendida en el mercado y está siendo adoptada por empresas de todos los tamaños. Los microservicios proporcionan un desacoplamiento de la lógica empresarial en pequeñas piezas autónomas, que permiten escalar según la demanda de determinadas partes de la solución, una mayor resiliencia de la arquitectura y en consecuencia, proporcionan una mayor productividad para los equipos de desarrollo que aprovechan modelos de despliegue ágiles con CI/CD, con el objetivo de entregar valor más rápido y constante al negocio.

Con este nuevo paradigma de cómo definir los servicios que satisfacen las demandas empresariales, se encontró que la orquestación o gobernanza de los mismos tendría que hacerse de una manera estructurada que permitiera a varios microservicios formar parte de un proceso de negocio. Esta gestión de llamadas a microservicios podría llevarse a cabo dentro del código fuente o de una manera más estructurada a través de flujos de trabajo.

Esta publicación está relacionada con el servicio AWS Step Functions en la función de Serverless Role Orchestrator (Serverless), que facilita la ejecución en secuencia de funciones AWS Lambda, servicios ejecutandose en contenedores (Amazon ECS , Amazon EKS o Amazon Fargate) y varios otros servicios de AWS en aplicaciones empresariales. A través de una interfaz visual, líneas de comando (CLI) o por medio del SDK, puede crear, ejecutar y rastrear el estado de una serie de flujos de trabajo orientados a eventos que mantienen el estado de la aplicación, es decir, la ejecución de una máquina de estados de una forma parametrizada y controlada.

Como beneficios de AWS Step Functions, su organización puede crear flujos de trabajo visuales que le permitan traducir los requisitos empresariales en requisitos técnicos, contenidos en cada uno de los microservicios existentes de su organización. También proporcionan una mejor gestión de la resiliencia asociada a los estados del flujo, mediante controles de verificación de la ejecución y el reinicio de tareas fallidas para asegurar que la lógica de negocio se ejecuta en el orden y en forma esperada. Como ventaja final, el uso de AWS Step Functions administra la lógica de negocio por usted, al tiempo que le permite reaprovechar las funciones ya existentes en microservicios de su organización.

Con esto, podemos definir y utilizar los flujos de trabajo del negocio como una forma de estructurar y controlar la ejecución de los microservicios que poseen una división segmentada, clara y organizada en torno al negocio de su empresa, y como se mencionó anteriormente, proporciona al equipo una alineación constante en el conocimiento del negocio y sus reglas, ofreciendo una reducción en el time-to-market y entrengado valor al negocio de forma continua y más rápida.

En este blog post vamos a detallar algunos puntos cruciales de cómo identificar las mejores alternativas de arquitecturas de flujos de trabajo, comprender las posibilidades de gestión de errores con el objetivo de monitorear la ejecución de estos flujos de trabajo y, consecuentemente, la ejecución de llamadas desde los servicios.

Por lo tanto, presentaremos en detalle:

Parte I: ¿Qué son los flujos de trabajo que utilizan AWS Step Functions?
Parte II: Diferencias con los flujos de trabajo estándar y rápido.
Parte III: Creación de un flujo de trabajo anidado.
- Flujos de trabajo anidados sincrónos.
- Flujos de trabajo anidados asíncronos.
Parte IV: Ejemplo completo de un flujo de trabajo anidado.
Parte V: Mecanismos de monitoreo de flujos de trabajo.
Parte VI: Costos.
Parte VII: Eliminación de servicios creados.
Parte VII: Conclusión.

Parte I: ¿Qué son los flujos de trabajo que utilizan AWS Step Functions?

AWS Step Functions le permite crear un flujo de trabajo (workflows) basado en estados mediante objetos de formato JSON fáciles de leer, así como una interfaz visual para detallar y hacer seguimiento a la ejecución de los flujos. Estos objetos, que se especifican mediante Amazon States Language, definen una serie de estados y transiciones de estado, vinculando las salidas de cada estado con las entradas de los siguientes estados.

Esta característica ofrece una mayor flexibilidad y simplifica la creación de flujos de control en sus aplicaciones para que pueda crear sistemas complejos de procesamiento en lote sin tener que desplegar infraestructura escalable necesaria en un enfoque más tradicional, dado que se trata de un servicio Serverless de AWS .

AWS Step Functions también le permite crear varias funciones de soporte para cuando algún paso en el flujo no se ejecutó correctamente. Esto incluye el manejo y enrutamiento de errores dinámicos, reintento automático y el enrutamiento personalizado basado en las salidas de la función.

Cómo funciona AWS Step Functions:

Figura 1 – Cómo funciona AWS Step Functions

El primer paso es configurar la máquina de estado, es decir, los pasos que serán ejecutados dentro del flujo de servicios del negocio. Tiene un estado inicial, y un estado activo (cuando se ejecuta). Un estado activo recibe una entrada (input), realiza alguna acción y genera una salida (output). Las transiciones entre estados de flujo de trabajo se basan en las salidas y en las reglas definidas por el estado.

Un ejemplo sencillo de un flujo de trabajo que contiene un solo paso utilizando Amazon States Language es:

En este ejemplo anterior, sólo hay un estado llamado “Hola Mundo” definido por el parámetro “States”, y los flujos de trabajo comienzan en este único estado definido por el parámetro “StartAt”. Cuando se ejecuta, llama a una función Lambda definida en el parámetro “Resource” de el archivo JSON y termina su ejecución, indicada por el parámetro “End: true”.

El tipo de estado, definido por el parámetro “Type”, puede contener las siguientes opciones:

Tipo	Significado
Pass	Estado “Pass”, donde las entradas se pasan a la salida sin modificación.
Choice	Estado “Choice”, permite agregar reglas para toma de decisiones lógicas
Wait	Estado “Wait”, genera una espera durante el tiempo (relativo o en segundos) definido.
Succeed	Estado “Succeed”, que finaliza la ejecución del flujo exitoso.
Fail	Estado “Fail”, que finaliza la ejecución del flujo si no se ha cumplido alguna regla de validación (o lógica).
Parallel	Estado “Parallel”, que se puede usar para crear ejecuciones ramificadas (en paralelo) del flujo.
Map	Estado “map”, que se puede utilizar para realizar una serie de pasos para cada elemento de un conjunto de datos (array).
Task	Estado “task”, representa una unidad simple de trabajo para ser ejecutada por el flujo

Como se mencionó anteriormente, AWS Step Functions se puede integrar con algunas de las API de otros servicios de AWS. Más arriba se ha presentado cómo utilizar las funciones de AWS Lambda (a través de su ARN) en estados de tipo Task, pero también se puede realizar en otros servicios. Algunos servicios particularmente populares que vale la pena mencionar incluyen Amazon ECS, Amazon EKS o Amazon Fargate, lo que le permite desarrollar lógica empresarial a través de contenedores, integración con Amazon SageMaker, el cuál es excelente para administrar el estado de sus entrenamientos de modelos de Machine Learning, adicionalmente, permite llamar a otros flujos de trabajo de AWS Step Functions, lo que permite la llamada anidada de otros flujos, con el objetivo de reutilizar la lógica entre flujos de trabajo llamando a otras funciones si es necesario.

Estos son algunos de los posibles servicios de AWS que se pueden integrar fácilmente con AWS Step Functions:

Figura 2 – Parte de los posibles servicios de integración de funciones escalonadas de AWS

Parte II: Diferencias con los flujos de trabajo estándar y rápido

En el momento de crear su flujo de trabajo en AWS Step Functions, debe definir un tipo Standard (estándar) o Express(rápido) utilizando el lenguaje Amazon States Language para definir los estados. La ejecución de sus máquinas de estado tienen diferentes comportamientos dependiendo del tipo que seleccione.

AWS Step Functions padrão (standard)

Los flujos de trabajo estándar son ideales para procesos empresariales de larga duración, ya que son persistentes (duraderos)y auditable. Pueden ejecutarse hasta por un año y puede recuperar el historial completo de ejecuciones mediante las API de funciones de paso de AWS en un plazo de 90 días a partir de la finalización de la ejecución.

Los flujos de trabajo estándar utilizan mecanismos que garantizan como máximo una única ejecución, lo que significa que sus tareas y estados nunca se ejecutan más de una vez a menos que se haya especificado el comportamiento de reintento en caso de fallo.

Las ejecuciones de flujo de trabajo estándar se cargan de acuerdo con el número de transiciones de estado procesadas.

AWS Step Functions expressos (express)

Express Workflows es un nuevo tipo de flujo de trabajo de AWS Step Functions publicado en Re:Invent 2019 que organiza de forma más económica los servicios de computo en la nube con tasas de eventos superiores a 100.000 eventos por segundo.

Los flujos de trabajo Express son ideales para cargas de trabajo de procesamiento de eventos de gran volumen, como la ingesta de datos de IoT, el procesamiento y transformación de datos por streaming y los backends de aplicaciones móviles. Pueden tener una duración máxima (tiempo de ejecución) de hasta cinco minutos. Sin embargo, los flujos de trabajo express emplean un modelo de ejecución llamado “al menos una vez”, donde existe la posibilidad de que una ejecución se pueda realizar más de una vez.

Las ejecuciones de flujos de trabajo express se cobran por el número de ejecuciones, la duración de cada ejecución y la memoria consumida.

Las diferencias básicas de los flujos de trabajo Standard y Express son:

Parte III: Creación de un flujo de trabajo anidado

A partir de agosto de 2019, es posible orquestar varios flujos de trabajo dentro del mismo servicio AWS Step Functions, como se anunció en este blog.

Basado en reglas de negocio complejas o múltiples interacciones de microservicios, resulta cada vez más difícil crear un flujo de trabajo que se ajuste plenamente a la lógica de negocio. Para evitar repeticiones, se pueden crear pequeños flujos e invocarlos desde flujos de trabajo más globales, facilitando así la creación de servicios intermedios, para crear, probar y editar de manera centralizada. En otras palabras, mediante el proceso de anidamiento de flujos de trabajo de AWS Step Functions, puede crear flujos de trabajo más grandes y complejos basados en flujos de trabajo más pequeños y sencillos.

Cuando los flujos de trabajo tienen procesos recurrentes, como revisión y aprobación humana o aprovisionamiento de recursos en cuentas, puede crear una biblioteca de componentes básicos modulares y reutilizables para acelerar el desarrollo. AWS Step Functions le permite cambiar y reorganizar módulos de flujo de trabajo sin personalizar el código. Esto le permite crear nuevos flujos de trabajo basados en los flujos de trabajo actuales en unos minutos.

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\": [ \"*\"]}]}" &gt; /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.

Blog de Amazon Web Services (AWS)