DEV Community: Javi Mora

Aumenta la disponibilidad de tus sistemas Legacy

Javi Mora — Tue, 09 Jul 2024 07:00:00 +0000

Muchos de nosotros trabajamos con servicios legacy o bien servicios que no son capaces de escalar correctamente, ya sea por problemas de diseño o por requerimientos técnicos. Estos sistemas que tienen esas dificultad para escalar son mas propensos a sufrir paradas de servicio, lo que supone un gran problema, sobre todo para los sistemas que reciben notificaciones asíncronas de otros sistemas.
Es en este último tipo de comunicaciones en el que nos vamos a centrar en este artículo.

Si tenemos un sistema, obsoleto, legacy, mal construido o bien que no hemos podido perfeccionarlo todo lo que hemos podido, y que recibe comunicaciones asíncronas, las cuales no podemos perder ya que cada mensaje no recibido supone una pérdida de información, no hace falta que invirtamos una gran cantidad de tiempo y/o dinero en actualizar nuestro sistema. Podemos aplicar una solución muy sencilla, muy barata y muy fácil de mantener que resolverá todos nuestros problemas ante posibles caídas. Esta solución también se puede aplicar a instancias de tipo Spot, que únicamente reciben comunicaciones asíncronas, y de esta manera poder tener este tipo de instancias incluso en entornos productivos, reduciendo los costes considerablemente.

Solución

Nuestra solución se basa en añadir una capa serverless sobre nuestra aplicación, que nos permita gestionar las comunicaciones asíncronas a hacia nuestra API.

Este diseño permitirá una comunicación en tiempo real con nuestra API y un backup en caso de caída del servicio que nos permitirá recuperar la comunicación con los mensajes perdidos durante la caída.

Arquitectura

Para implementar esta solución descrita anteriormente, solo necesitamos implementar 3 servicios muy comunes dentro del catálogo de servicios de AWS

Amazon API Gateway
AWS Lambda
Amazon SQS

Con estos tres servicios conseguiremos una comunicación asíncrona con disponibilidad total (99,9% de disponibilidad cada uno de ellos)

Existe la posibilidad incluso de ahorrarnos uno de los tres servicios descritos anteriormente y hacer uso únicamente de Amazon API Gateway y Amazon SQS.

Este caso no lo recomendamos ya que el mensaje que llega a nuestra API debe tener una estructura determinada para poder ser enviado directamente al servicio de SQS. Con el uso del servicio de Lambda conseguimos una mayor flexibilidad, pudiendo modificar el mensaje, añadir control de excepciones, etc.

Comunicación con nuestra API

Ahora toca comunicar la nueva arquitectura con nuestra API. Existen varias opciones para establecer esta comunicación, por un lado podemos enviar los mensajes recibidos directamente a nuestra API o podemos hacer que nuestra API vaya a buscar los mensajes a nuestra servicio de mensajería. Ambas opciones son igualmente válidas y dependería de nuestra solución el usar una u otra opción.

SQS to API

Esta sería la comunicación mas lógica en un inicio, donde cada mensaje que llega a nuestra nueva capa de servicios serverless es enviada directamente a nuestra API

Y aquí también tenemos dos opciones. En la primera imagen vemos como el mensaje que llega a nuestro servicio de colas puede ser enviado a nuestra API. Amazon SQS permite implementar Listeners dentro de nuestra API que permita recibir los mensajes que se encolan en nuestro servicio.

Pero en el caso que la tecnología usada en nuestra API no permita conectarnos a nuestro servicio de SQS a través del Listener, podemos optar por una segunda opción, la cual sería añadir una Lambda que nos permita establecer la comunicación entre nuestro servicio de colas y nuestra API.

API to SQS

La segunda opción se trata de delegar la responsabilidad a nuestra API de la lectura de mensajes, es una opción menos usada pero que es efectiva si queremos tener el control de cuanta información queremos procesar o si queremos procesarla a una hora determinada del dia.

Otra de las ventajas de esta última opción, es que en el caso de caída de nuestra API, los mensajes no serán leídos, y cuando nuestra API vuelva a estar operativa se volverán a procesar.

Pero entonces, ¿qué pasaría si decidimos implementar la primera de las opciones descritas?

SQS to API - DLQ

En el caso que nuestra API no esté disponible, hay mecanismos (o configuraciones) que nos permiten reprocesar nuestros mensajes en otro momento.

Es el caso de las colas DLQ (Amazon SQS Dead Letter Queues), son colas a la que podemos enviar los mensajes fallidos de una cola SQS. Podemos establecer un número de reintentos de lectura en nuestra cola SQS y una vez realizado ese número de reintentos el mensaje de la SQS pasaría automáticamente a la DLQ, cuyo comportamiento es el mismo que el de una SQS.

Los mensajes permanecerán en esta cola hasta que nuestra API vuelva a estar disponible, y cuando eso ocurra, podremos volver a leer esos mensajes, ya sea accediendo a la DLQ desde nuestra API

O bien, haciendo uso de una lambda que se encargue de comprobar la disponibilidad de nuestra API y una vez esté disponible sea la encargada de leer y enviar de nuevo los mensajes de la DLQ a nuestra API

Y con esta simple arquitectura podemos implementar una capa asíncrona y con una disponibilidad del 99,9% sin necesidad de hacer grandes cambios en nuestra API.

En el siguiente post crearemos esta infraestructura con CDK y Python paso a paso y lo tendréis disponible en GitHub para que podáis adaptar y desplegar esta solución en pocos minutos.

WebSockets con Api Gateway

Javi Mora — Fri, 19 Apr 2024 07:26:21 +0000

¿Alguna vez has querido que tu app hable con tus usuarios en tiempo real, como por arte de magia? Pues bien, ¡hoy es tu día de suerte! En este post vamos a meternos de lleno en cómo darle súper poderes a tus proyectos usando WebSockets con AWS. Vamos a usar dos herramientas muy conocidas dentro del Cloud de AWS: API Gateway y Lambda. Te voy a llevar paso a paso para que crees tu propio websocket en menos de 10 minutos.

Crear el proyecto con cdk

Vamos a crear el proyecto con cdk y vamos a implementarlo con python, para ello vamos a crear nuestro directorio del proyecto y crearemos el proyecto con cdk


 shell
mkdir websocket-poc
cd websocket-poc
cdk init app --language python

Ahora activamos el entorno virtual


 shell
source .venv/bin/activate

Y por último instalamos las dependencias necesarias:


 shell
pip install -r requirements.txt

Este sería el contenido de nuestro requirements.txt



aws-cdk-lib==2.114.1
constructs>=10.0.0,<11.0.0

Creación de lambda

Usaremos una lambda para enviar un mensaje a través de nuestro websocket, para ello en nuestro proyecto cdk, y dentro de nuestro stack creamos la lambda con el siguiente código:


 python
lambda_function = lambda_.Function(
            self, 'WebSocketHandler',
            runtime=lambda_.Runtime.PYTHON_3_8,
            handler='ws_function.handler',
            code=lambda_.Code.from_asset('./lambda'),
            timeout=core.Duration.seconds(10)
        )

lambda_function.add_to_role_policy(iam.PolicyStatement(
            actions=["execute-api:ManageConnections"],
            resources=["arn:aws:execute-api:REGION:ACCOUNT-ID:API-ID/STAGE-NAME/*"],
            effect=iam.Effect.ALLOW
        ))

execute-api:ManageConnections permite a funciones autorizadas gestionar conexiones de clientes en API Gateway WebSockets.

Y este sería el código de la lambda, bastante sencillo, simplemente recibimos los parámetros de conexión y la url del websocket, esto podría ser fijo, pero en caso que tengamos mas de un websocket podríamos re-utilzar el código de la lambda, y por último, enviamos el mensaje "Hello, WebSocket!"


 python
import boto3

def handler(event, context):
    connection_id = event['requestContext']['connectionId']
    gatewayapi = boto3.client("apigatewaymanagementapi",
                              endpoint_url = "https://" + event["requestContext"]["domainName"] + "/" + event["requestContext"]["stage"])

    post_data = "Hello, WebSocket!"

    gatewayapi.post_to_connection(ConnectionId=connection_id, Data=post_data.encode('utf-8'))

    return {
        'statusCode': 200,
        'body': 'Message sent'
    }

Creación de la API

Ahora vamos a crear nuestra API que permitirá el envío de mensajes por websocket.


 python
api = apigw.WebSocketApi(self, "WebsocketApi")

Luego creamos un stage dentro de nuestra api:


 python
stage = apigw.WebSocketStage(
            self, 'DevStage',
            web_socket_api=api,
            stage_name='dev',
            auto_deploy=True
        )

Y por último añadimos una ruta específica (sendMessage" al websocket de la api y lo vinculamos a la función lambda que hemos creado previamente.


 python
api.add_route("sendMessage",
  integration=WebSocketLambdaIntegration("SendMessageIntegration", lambda_function)
)

Outputs

Necesitamos conocer la url de nuestro websocket para poder establecer una comunicación con el, por lo que hacemos que nos la muestre en el terminal cuando complete el despliegue de la api



core.CfnOutput(self, "WebSocketURL", value=stage.url)

WebScocket client

Ahora vamos a usar una herramienta para simular nuestro cliente de websocket, podríamos crear una web o una app para probarlo, pero esta herramienta nos permite probar nuestro websocket mucho mas rápido y de una forma mas sencilla.

La herramienta es websocketking (https://websocketking.com/) y es muy fácil de usar.

Lo primero que debemos hacer es añadir la url de nuestro websocket que nos ha devuelto el deploy de nuestro proyecto cdk. En nuestro caso sería wss://kiyi70kcll.execute-api.eu-west-1.amazonaws.com/dev
y le damos a conectar

una vez conectados enviaremos un mensaje (puede estar vacio),simplemente es la forma mas sencilla de conocer nuestro connectionId que lo necesitaremos luego en el test de la lambda para poder enviar un mensaje a través del websocket.



{
  "message": "Forbidden",
  "connectionId": "WbqM9csoDoECF9w=",
  "requestId": "WbqUVE-OjoEFwjw="
}

ahora copiamos nuestro connectionId y creamos un test en la lambda

y ahora enviaremos un mensaje a nuestro websocket con este JSON



{
    "requestContext": {
        "connectionId": "WbqM9csoDoECF9w=",
        "domainName": "kiyi70kcll.execute-api.eu-west-1.amazonaws.com",
        "stage": "dev"
    }
}

donde tenemos:

connectionId: obtenido previamente
domainName: url de nuestro websocket
stage: stage de nuestra api

y realizamos nuestro test ....

comprobamos que nuestra lambda se ha ejecutado correctamente

y comprobamos nuestra aplicación cliente de websocket

Como se puede comprobar en la imagen, nuestra comunicación a través de websocket a funcionado perfectamente :)

Precios

Ahora viene el dato delicado, si, muy bonito, pero cuanto me va a costar. Ya sabemos que el coste en AWS (y en el resto de Clouds) es de pago por uso, por lo que antes de implementar te aconsejo que vayas a la web de AWS para consultar los precios:

AWS Api Gateway Pricing

O bien también puedes ir a la calculadora de AWS y calcularlo en función de tus métricas

AWS Princing Calculator

Te pongo un ejemplo de costes calculados con la calculadora:

800 Messages/minutes
80 (kb) Average message size
20 (seconds) Average connection duration)
300 Average connection rate / minute

Y esto hace un total de 121,11 UDS / Mes

Cabe destacar que existe una capa gratuita los 12 primeros meses:

En el caso de las API WebSocket, la capa gratuita de API Gateway incluye un millón de mensajes (enviados o recibidos) y 750 000 minutos de conexión durante un máximo de doce meses.

Dependiendo de cada proyecto puede compensar o no pagar este tipo de soluciones frente a otras que necesiten mas desarrollo.

Github

El proyecto lo podéis encontrar en mi repositorio de Github

https://github.com/fjaviermoradiaz/aws-blog-websocket

Ahorra con Amazon EKS

Javi Mora — Thu, 28 Mar 2024 08:21:38 +0000

Cuando nos planteamos el diseño de una nueva arquitectura para nuestra plataforma uno de los aspectos que suele influenciar en el diseño es el coste. Pero ya no solo es el coste, sino también el impacto medioambiental que supone el hecho de optimizar los recursos de los que disponemos. En muchas ocasiones tenemos distintos entornos que no tienen porque ser usados las 24 horas (desarrollo, qa, staging, ...). En este caso, os voy a mostrar cómo poder ahorrar costes haciendo un scale down de los nodos de vuestros clusters de kubernetes en AWS a través de una Lambda, de esta manera podréis optimizar costes con aquellos entornos que no necesitáis tener encendidos durante todo el día.

Para realizar este proyecto usaremos Serverless Framework para crear y desplegar nuestro pequeño sistema de apagado automático, el cual realizaremos en NodeJS con Typescript.

Instalar serverless framework

Lo primero de todo es instalar serverless framework con el siguiente comando desde un terminal

npm install -g serverless

Una vez instalado creamos nuestro proyecto en un nuevo directorio ejecutamos el siguiente comando:

sls create -t aws-nodejs-typescript

Esto nos creará un proyecto serverless con typescript. Al abrirlo veréis como ha creado el serverless.ts y una función de ejemplo “hello”. En el fichero de serverless.ts debéis poner los datos referentes a vuestra cuenta de aws.

Ahora ya podéis probar que el proyecto se ha creado correctamente invocando la función hello desde local:

sls invoke local -f start

Lambda

Una vez que comprobamos que el ejemplo funciona, ya podemos empezar a modificar nuestra lambda, o bien podemos crear una nueva. Lo primero que necesitamos es la sdk de aws:

npm i aws-sdk

y luego añadimos este código a nuestra lambda:

import type { ValidatedEventAPIGatewayProxyEvent } from '@libs/api-gateway';
import { formatJSONResponse } from '@libs/api-gateway';
import { middyfy } from '@libs/lambda';
import { NodegroupScalingConfig, UpdateNodegroupConfigRequest, UpdateNodegroupConfigResponse } from 'aws-sdk/clients/eks';
import { AWSError, EKS } from 'aws-sdk';

import schema from './schema';
import { PromiseResult } from 'aws-sdk/lib/request';

const stop: ValidatedEventAPIGatewayProxyEvent<typeof schema> = async (event) => {

  const CLUSTER_NAME:string = '[CLUSTER_NAME]';
  const NODE_GROUP_NAME:string = '[NODE_GROUP_NAME]';

  let nodeGroupConfig:NodegroupScalingConfig = {
    desiredSize: 0,
    maxSize: 1,
    minSize: 0

  };

  let nodeGroupRequest:UpdateNodegroupConfigRequest = {
    clusterName: CLUSTER_NAME,
    nodegroupName: NODE_GROUP_NAME,
    scalingConfig: nodeGroupConfig
  };


  let response:PromiseResult<UpdateNodegroupConfigResponse, AWSError> = await new EKS().updateNodegroupConfig(nodeGroupRequest).promise();
  console.log(response);


  return formatJSONResponse({
    message: 'NodeGroupScaling updated to 0',
    event,
  });
};

export const main = middyfy(stop);

En el código podemos ver cómo modificamos la configuración de escalado de los nodos, poniéndola a 0. Antes debemos modificar los datos para indicar cual es nuestro cluster y nuestro node group name.

Lambda scheduler

La lambda podemos ejecutarla manualmente, a través de una llamada a un endpoint de API Gateway o a través de una tarea periódica con CloudWatch Rules.

Para ello vamos al archivo index.ts y vemos que está configurado para llamar a la lambda a través de un endpoint de API Gateway, sustituimos ese código por el siguiente:

import { handlerPath } from '@libs/handler-resolver';
export default {
  handler: `${handlerPath(__dirname)}/handler.main`,
  events: [
    {
      schedule: 'cron(0 19 ? * MON-FRI *)',
    }
  ],
};

De esta manera nuestra lambda hará un scale down cada día, de lunes a viernes a las 7 de la tarde.

Lambda role (I)

Para que la lambda tenga acceso a nuestro cluster de eks debemos hacer que su rol tenga acceso a la policy que permite modificar la configuración de escalado de los nodos:

provider: {
    name: 'aws',
    iamRoleStatements: [
      {
        'Effect': 'Allow',
        'Action': ['eks:UpdateNodegroupConfig'],
        'Resource': '*'
      }
    ],

Deploy

Ahora tenemos todo nuestro código preparado para ralizar la función que queremos, solo queda desplegarlo, y es tan simple como hacer lo siguiente:

sls deploy

Lambda role (II)

Una vez desplegados podemos ver que la lambda tiene asignado un rol

Debemos copiar el arn de ese rol, ya que debemos configurar nuestro cluster para permitir a ese rol realizar cambios, tal y como se explica en la documentación oficial https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html

eksctl create iamidentitymapping \
    --cluster cluster-name \
    --region=xx-xxxx-x \
    --arn arn:aws:iam::0000000000000:role/eks-management-dev-xx-xxxx-x-lambdaRole \
    --group group:example

Esto creará un registro nuevo en el mapa de identidades de nuestro cluster

eksctl get iamidentitymapping --cluster cluster-name --region=xx-xxxx-x

y con esa acción podremos comprobar que realmente se ha añadido. Con esto ya hemos conseguido dar acceso a nuestra lambda.

Os dejo la documentación oficial donde se detalla como funciona la API de la SDK de AWS: https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html

Os dejo también el repositorio GitHub donde está subido este ejemplo: https://github.com/fjaviermoradiaz/aws-eks-manager