Implementando un Enterprise Service Bus con Amazon API Gateway y AWS Fargate

Como ahorrar hasta el 85% en los costos de licenciamiento e infraestructura de un ambiente on-premises utilizando las mejores prácticas de DevOps

por el Dev Team de Escala 24×7

En diciembre 2018 un cliente del sector financiero se acercó a Escala 24×7 a través de AWS, buscando alternativas que le permitieran reducir sus costos de licenciamiento y operación del Enterprise Service Bus que tenían implementado on-premises. Este cliente es una compañía operadora de servicios transaccionales, orientada al procesamiento y administración de servicios tecnológicos en el mercado de medios de pago.

En este post, vamos a ilustrar brevemente la solución que el equipo de Escala 24×7 implementó con los servicios de AWS para ayudar a nuestro cliente no solo a ahorrar aproximadamente 85% de sus costos en el uso de licencias y reduciendo su infraestructura on-premises, sino también a transformar su solución actual en una novedosa arquitectura de microservicios completamente libre de servidores usando Amazon API Gateway y AWS Fargate.

Escala 24×7 es un Socio de Consultoría APN Advanced, que cuenta con la competencia de Seguridad y que tiene más de seis años de experiencia implementando una gran cantidad de soluciones en la nube de AWS.

Visión general

A simple vista, un Enterprise Service Bus (ESB) no es más que una herramienta que facilita la integración de diferentes aplicaciones a través de un canal (bus) y que permite desacoplar los sistemas unos de otros.

Hace ya varios años, cuando surgió este tipo de arquitectura, se vendió como la solución a muchos desafíos. Sin embargo, en la actualidad, hablar de ESB conlleva a hablar de una cantidad significativa de recursos de hardware y de licenciamiento, además implica contratar especialistas con experiencia que son cada vez más difíciles de encontrar, haciendo que el costo de mantener un ESB sea sumamente alto y que no cualquier compañía pueda asumirlo.

Basado en lo anterior, las compañías que cuentan con un ESB en su infraestructura, tarde o temprano se enfrentarán a la necesidad de reducir sus costos de mantenimiento, ya sea simplemente para generar ahorros o para direccionar esos gastos e invertirlos en otros proyectos. Justamente este fue el reto que nos propuso nuestro cliente.

Primeros pasos

Inicialmente, todos los servicios de nuestro cliente estaban alojados en un centro de datos on-premises y sus clientes accedían a estos servicios a través de un firewall que se encargaba de redirigir las solicitudes a los servicios web SOAP. Previa autenticación y autorización, ESB validaba, procesaba, transformaba y orquestaba las operaciones necesarias para devolver una respuesta al cliente.

Figura 1: arquitectura previa del cliente

Dependiendo de la solicitud, el ESB se apoyaba en diferentes servicios locales para crear una respuesta y devolverla al cliente.

El reto en este escenario, consistió en mover todos los servicios SOAP a la nube de AWS con el mínimo impacto para sus clientes, tomando en cuenta que se debían mantener las siguientes características:

• La solución debería estar en conformidad con PCI DSS.
• Confidencialidad.
• Alta disponibilidad.
• Escalabilidad.
• Trazabilidad.
• Flexibilidad.
• Ser eficiente.

Una arquitectura completamente serverless

Figura 2: arquitectura implementada por Escala 24×7

En nuestro diseño, una decisión fundamental es que toda la arquitectura fuese lo más serverless posible, no solo porque con una arquitectura de este tipo podríamos reducir los costos de hardware y licenciamiento del cliente, sino también porque además de reducir esos costos directos, el cliente no tendría que preocuparse por provisionar y operar servidores.

Como se puede ver en la figura 2, el tráfico fluye desde el cliente a través de un túnel VPN que garantiza que la información viaja cifrada, una vez la solicitud llega a AWS el procesamiento de la petición se lleva a cabo de la siguiente manera:

1. Debido a que se requería que todos los recursos desplegados en AWS fueran totalmente privados, Amazon Route53 Resolver se convirtió en uno de los componentes principales de esta arquitectura ya que permite el acceso a los recursos desplegados en AWS de manera privada mediante la resolución de nombres.
2. Otro de los requerimientos del cliente era acceder los endpoints de API Gateway utilizando custom domains. Sin embargo, para no exponer los Endpoints de API Gateway públicamente, se definieron Endpoints de tipo privado. Un endpoint de tipo privado, para el momento de la implementación, no soportaba el uso de custom domains. Conseguir este objetivo requirió volver a analizar el diseño y apoyarnos con el equipo de soporte de AWS que finalmente nos orientó sobre cómo utilizar una solución alternativa que consiste en los siguiente:

• Crear un ALB para colocarlo frente a API Gateway;
• Crear un Target Group conteniendo las IP privadas de las ENI del VPC endpoint de API Gateway;
• Configurar el custom domain en API Gateway utilizando el dominio deseado;
• Crear el dominio en una zona privada de Route53;
• Apuntar el dominio recién creado al ALB mediante un registro de tipo Alias;
• Crear certificados en ACM para el dominio creado y utilizarlos en la configuración del ALB y API Gateway.

De esta forma, el Application Load Balancer (ALB) recibe el request y lo envía a Amazon API Gateway usando comunicación cifrada en todo el camino mediante certificados TLS.

3. Por su parte API Gateway se encarga de controlar la demanda de las peticiones sobre los servicios, registrar logs y resolver la integración con las tareas de Fargate. Para garantizar que esta integración fuera privada se tomaron en cuenta las siguientes consideraciones:

• Para no exponer públicamente los Endpoins de API Gateway, fue necesario utilizar API Gateway Private Endpoints. De esta forma nos aseguramos que los endpoins solamente pudieran ser accedidos desde nuestros servicios;
• Adicionalmente, para que API Gateway pudiera acceder recursos de la VPC en forma privada, se configuró un VpcLink que se conecta a un NLB encapsulando la comunicación con la VPC.

4. Nuevamente Amazon Route53 permite la resolución de nombres hacia el Network Load Balancer (NLB).

5. El NLB, envía la solicitud a un target group en donde finalmente es recibida por una tarea de Fargate en ECS. Esta tarea incluye funcionalidades de trazabilidad utilizando AWS X-Ray.
6. La tarea de AWS Fargate procesa la información y si necesita comunicarse con un servicio de backend, le envía el request apropiado, recibe la respuesta del backend, la procesa, crea la respuesta y la envía al cliente de vuelta por el mismo camino de la petición original.

Infraestructura como código

En AWS, la automatización, la escalabilidad y la reusabilidad están directamente ligadas al uso de infraestructura como código. Desde el principio, para nuestro equipo de ingenieros estaba claro que ese era el camino a seguir.

Para el aprovisionamiento de la arquitectura, y para las tareas de CI/CD, fue necesario hacer uso de AWS CloudFormation y funciones AWS Lambda. Uno de los retos más grandes fue diseñar una estrategia de aprovisionamiento de infraestructura que permitiera estandarizar y automatizar despliegues de recursos en AWS, según el ámbito de acción de los diferentes equipos de IT.

Figura 3: Estrategia de aprovisionamiento de Infraestructura como código

CI/CD

Desde el comienzo, el equipo de Escala 24×7 diseñó y desarrolló los servicios y aplicaciones siguiendo una estrategia que se acoplara a la integración y actualización continua (CI/CD).

Para el desarrollo usamos como IDE AWS Cloud9 y tomamos ventaja de las herramientas CI/CD provistas por AWS, usando AWS CodeCommit para manejar nuestros repositorios de código, AWS CodeBuild para construir nuestros contenedores y almacenarlos en ECR, y finalmente AWS CodeDeploy para automatizar el despliegue de las aplicaciones. Todo esto orquestado a través de CodePipeline.

Para reducir el tiempo fuera de línea durante los despliegues, se hizo uso de las técnicas suministradas por AWS, en este caso particular decidimos que nuestros despliegues usarían técnicas Blue/Green y el resultado ha sido excelente. Desde que el proyecto se encuentra en producción el cliente ha podido liberar nuevas versiones de los servicios teniendo transiciones transparentes y si durante las pruebas se detectan fallas cuentan con la opción de hacer rollback y regresar a la versión previa sin ningún inconveniente.

Independencia de servicios usando AWS Fargate

Para poder proveer una independencia de servicios, decidimos desplegar cada servicio como una tarea de ECS sobre AWS Fargate. De esta forma un cluster ECS es el encargado de proveer la escalabilidad y la alta disponibilidad de tal manera que, si un servicio en particular requiere más recursos, el cluster se encargará de adicionarlos.

En esta tarea, un NLB trabaja en conjunto con el cluster ECS y ambos son los responsables de orquestar la escalabilidad sobre las diferentes zonas de disponibilidad habilitadas

Figura 4: arquitectura con AWS Fargate

Seguridad

Para el equipo de Escala 24×7 la seguridad es primordial en cada proyecto y este no fue la excepción. Para cumplir los requerimientos del cliente, nuestro equipo trabajó para seleccionar las herramientas y el diseño apropiado que nos ayudaría a cumplir con el reto de desarrollar un ambiente totalmente privado, donde solo el cliente tuviese acceso a los recursos de AWS y donde toda la comunicación entre el cliente y los recursos de AWS estuviera cifrada.

Como resultado, se construyó una arquitectura de conformidad con PCI DSS, usando certificados TLS para garantizar una comunicación cifrada todo el camino desde el request hasta el response. Decidimos utilizar AWS Cognito para administrar y manejar los controles de acceso a los servicios; nos apoyamos en AWS Parameter Store para almacenar en forma segura los parámetros de las aplicaciones y nos aseguramos de evitar almacenar secretos en los contenedores.

Adicionalmente en un entorno multi-cuenta, otro reto importante fue garantizar que solo las personas apropiadas tuviesen acceso a información sensitiva. Para esto fue necesario crear AWS Identities con accesos reducidos de tal forma que por ejemplo usuarios que tienen acceso total a la cuenta de desarrollo no tengan acceso a la cuenta de producción.

Resumen

En este post, hemos descrito brevemente la implementación de Escala 24×7 usando infraestructura como código, Amazon API Gateway, AWS Fargate y una serie de estrategias claves que se usaron para evolucionar los servicios web del cliente, llevándolo desde una arquitectura monolítica a una arquitectura de microservicios completamente libre de servidores y sobre todo de conformidad con PCI DSS.

Con la solución implementada, el cliente paso de tener un ambiente on-premises de cuatro servidores físicos sobredimensionados (para soportar demandas esporádicas) a una arquitectura serverless sin necesidad de aprovisionar VMs y pagar por licenciamiento. Esta optimización en componentes de hardware y software fue la que permitió llegar a un ahorro de aproximadamente 85% en costos.