Federación Patronal evoluciona su core de seguros hacia la nube con Red Hat OpenShift Service on AWS (ROSA) en la Local Zone de Buenos Aires

Por Guillermo Raimundo, Subgerente de Sistemas, Federación Patronal,

Andrés Montenegro, Arquitecto Sr. ProServe de AWS,

Alexis Winer, Sr. Advisory Consultant de AWS,

Beto Ortega, Líder de Negocios, Vertical de Seguros de AWS,

Leandro Santi, Arquitecto de Soluciones de AWS

Nota: Este artículo es el primero de una serie de publicaciones en la que exploraremos la implementación del patrón de arquitectura híbrido que soporta la evolución del nuevo core de seguros de Federación Patronal.

Federación Patronal Seguros (FedPat) es una de las principales compañías de seguros de Argentina. Además de ser líder en el ramo de seguros para automóviles, ofrece una amplia gama de seguros tanto para individuos como para empresas, que la convierte en la numero uno en el ranking general de seguros del país. Federación Patronal ofrece también servicios de asistencia al viajero, de asistencia al hogar y de asistencia para vehículos. Fue fundada en el año 1923 y tiene su casa matriz en la Ciudad de La Plata, provincia de Buenos Aires.

En el año 2021 la compañía decidió encarar un proyecto de actualización de su plataforma core de negocio. La plataforma existente se encontraba implementada en tecnologías de base de datos de Oracle, Forms y Weblogic. Este tipo de sistemas legados, comunes en ámbitos de negocios, suelen caracterizarse por un alto grado de acoplamiento entre los componentes de la arquitectura debido a la existencia de múltiples aplicaciones integradas al mismo motor de base de datos.

Desafíos

A principios de 2022, nuestros equipos estaban inmersos en el desarrollo y migración de sistemas hacia un nuevo stack de tecnología basado en contenedores gestionados por la plataforma Red Hat OpenShift. Para apoyar la modernización del core de seguros fue esencial implementar estas aplicaciones de una manera tal que permitan co-existir con los sistemas legados del negocio.

Esto llevó a nuestros equipos a considerar los siguientes desafíos:

Baja latencia. Los ambientes deben estar a unos pocos milisegundos de distancia del motor de base de datos alojado en nuestro centro de datos de la provincia de Buenos Aires. El alto nivel de acoplamiento de los sistemas legados que dan soporte al negocio requería desplegar los ambientes de desarrollo del nuevo stack próximos a la base de datos para mantener acotada la latencia y facilitar una adecuada experiencia de usuario.

Gobierno, seguridad y auditoría. La arquitectura de desarrollo híbrida, basada en OpenShift, debía soportar un esquema de desarrollo ágil para reducir los tiempos de implementación. Necesitábamos capacidades de gobierno, seguridad y auditoría que permitan brindar agilidad a los equipos sin perder el control de la plataforma y asegurando la co-existencia de la arquitectura híbrida.

Facilidad operativa. Posibilidad de desplegar y escalar la plataforma de contenedores rápidamente (en minutos). Posibilidad de contar con una API familiar a la que teníamos en el OpenShift on-premises manteniendo las mismas herramientas operativas, evitando tener que aprender de cero una nueva plataforma. Posibilidad de contar con una experiencia administrada, que permita a nuestros equipos enfocarse en desarrollar nuevas capacidades de negocio en la plataforma y delegar tareas periféricas que no aportan valor.

Confiabilidad. Posibilidad de contar con acuerdos de niveles de servicios definidos y servicios de soporte provisto por la marca. Posibilidad de contar con un esquema de interconexión confiable y robusto, compatible con el requerimiento de baja latencia.

Red Hat OpenShift Service on AWS (ROSA)

Hacia principios de 2022, FedPat ya estaba desarrollando el nuevo core de seguros sobre el sistema OpenShift de nuestro centro de datos, y sus equipos dedicaban una cantidad considerable de tiempo y esfuerzo para soportar y mantener en funcionamiento el cluster de contenedores.

Así surgió la idea de desplegar ROSA, un servicio de computación basado en contenedores operado por Red Hat y soportado conjuntamente con AWS que permite combinar la experiencia y ventajas de OpenShift con las facilidades de una plataforma administrada en la nube de AWS.

ROSA facilita la creación y operación de clústers OpenShift en AWS. Este servicio provee una experiencia integrada para soportar la creación, escalado, operación y mantenimiento del sistema. Provee además un esquema unificado de facturación con soporte para pago por uso, por hora o anual.

Para aplicaciones basada en contenedores que ya se encuentran corriendo sobre OpenShift en el centro de datos, ROSA provee una API familiar para el operador y permite usar las mismas herramientas de administración – permitiendo reducir los tiempos de aprendizaje y enfocar mejor a los equipos en el modelo de datos, evitando tener que aprender un stack de aplicaciones completamente nuevo.

Asimismo, la posibilidad de contar con ROSA en la nube permitió una rápida adaptación de nuestros desarrollos del nuevo core, sin necesidad de rediseñar los aplicativos y permitiéndonos combinar la elasticidad de una arquitectura de nube con las ventajas operativas que ofrecen los servicios administrados de AWS.

Faltaba resolver el desafío de baja latencia, ya que la base de datos relacional de Oracle continuaba alojada en nuestro centro de datos. Necesitábamos desplegar los ambientes del nuevo core de negocio a unos pocos milisegundos (menos de 5) de distancia de nuestro centro de datos. Previamente, habíamos experimentado un primer laboratorio de ROSA en una región de Estados Unidos interactuando contra la base de datos Oracle on-prem, lo cual nos ayudó a comprender que algunas de las aplicaciones (que habían nacido con la base de datos a pocos metros del servidor de aplicaciones) no estaban diseñadas para soportar la latencia, y generaban una experiencia de usuario pobre.

Local Zones al rescate

Local Zones es una familia de servicios de AWS que permite contar con capacidades de cómputo, almacenamiento, bases de datos y otros servicios específicos de AWS cerca de grandes centros metropolitanos e industriales. Asimismo, permite que empresas, organizaciones y gobiernos satisfagan necesidades específicas de residencia de datos, permitiendo al usuario configurar sus datos de forma tal que permanezcan dentro de la zona local en el país.

En noviembre 2022, AWS anunció la disponibilidad general de la Local Zone de Buenos Aires. Aproximadamente al mismo tiempo, Red Hat anunció el soporte para AWS ROSA workers en Local Zones.

Figura 1: proximidad de la Local Zones Buenos Aires al centro de datos de Federación Patronal. Aquí podemos ver que la latencia media entre los extremos de terminación del túnel IPSec ronda los 1.55 ms.

En la figura 1 podemos ver información relevada por nuestros equipos a partir de más de 20 mil métricas recolectadas durante el mes de septiembre de 2023. Como podemos ver en el diagrama, al activar la Local Zone de Buenos Aires observamos latencias medias próximas a los 1.55 ms – compatibles con latencias de redes de área local.

Esta característica de baja latencia resultó clave para asegurar el desempeño de las nuevas aplicaciones que nuestros equipos desarrollan sobre ROSA en la Local Zone de Buenos Aires, dado que la base de datos Oracle continuaba alojada en nuestro centro de datos debido al alto acoplamiento existente con los sistemas legados que continuaban dando soporte a la operación de negocio.

Arquitectura de referencia

Ante estos desafíos, FedPat confió en AWS Professional Services (ProServe) para implementar en AWS este nuevo patrón de arquitectura, en línea con las mejores prácticas de arquitectura en la nube.

Figura 2: arquitectura de referencia híbrida de Federación Patronal

En la figura 2 podemos ver la arquitectura de referencia que implementamos hacia diciembre de 2022. Esta arquitectura fue concebida teniendo en cuenta las siguientes características:

Gobierno, seguridad y auditoría. Implementamos junto a ProServe Amazon Control Tower como principal herramienta para el gobierno de los recursos en nuestra arquitectura híbrida.

Control Tower permite segmentar ambientes o cargas de trabajo en múltiples cuentas de AWS, proveyendo además un alto grado de integración con las herramientas de auditoría y seguridad en la nube. La segregación de ambientes y cargas de trabajo en múltiples cuentas es una mejor práctica que provee el máximo nivel de aislación entre los ambientes, reduciendo la superficie de impacto.

Figura 3: esquema de gobierno multi-cuenta basado en Control Tower y Landing Zone de AWS.

Esta herramienta incorpora mejores prácticas de gobierno, seguridad y auditoría que resultan de trabajar con cientos de miles de clientes alrededor del mundo para crear un entorno seguro que facilite controlar nuestras cargas de trabajo con reglas de seguridad, operaciones y cumplimiento (ver figura 3).

Gracias a esto, los equipos distribuidos son capaces de proporcionar nuevas cuentas de AWS rápidamente, mientras que los equipos centralizados tienen la tranquilidad de saber que las nuevas cuentas están alineadas con las políticas de gobierno, seguridad y auditoría establecidas de forma central en toda la empresa. Así, podemos implementar un esquema de gobierno ágil que nos permite empoderar a nuestros equipos de desarrollo.

Esquema híbrido de networking. Sobre la estructura provista por Control Tower se creó una cuenta para soportar la gestión de networking: esto permitió desplegar allí los recursos de nube que dan soporte al esquema híbrido de interconexión: Transit Gateway, Site-to-Site VPN, herramientas de DNS y NAT gateways centralizados.

En la arquitectura de la figura 2 podemos ver que la conectividad entre el centro de datos con la Local Zone de Buenos Aires fue implementada una instancia EC2 corriendo StrongSwan para terminar el túnel IP Sec contra nuestro firewall Palo Alto existente en el centro de datos de Federación Patronal.

Por otro lado, para la conexión con la región ubicada en Estados Unidos usamos el servicio Site-to-Site VPN de AWS. Gracias a esto, contamos con túneles IP Sec redundantes, permitiéndonos acceder de forma segura a todos los componentes de la arquitectura. Asimismo, el servicio de Global Accelerator permite que la terminación de los túneles IP Sec, lado AWS, se realice usando un par de IPs publicadas mediante técnicas de anycast, de tal forma de que sean anunciadas a través del punto de presencia que AWS tienen en Buenos Aires. Así, el tráfico de la VPN puede ser enrutado en forma directa hacia el punto de presencia, reduciendo significativamente la cantidad de hops hasta llegar a las redes de AWS. Esto facilita una mejor confiabilidad de la conexión y mayor regularidad en la latencia de acceso.

Finalmente, del lado de on premises, se observa el firewall, el load balancer F5, las bases de datos que consumen los workers de Buenos Aires, y los usuarios que consumen los servicios que se ejecutan en dichos workers.

Cómputo. Se desplegó el clúster de contenedores usando el servicio ROSA de AWS en configuración multi-AZ para el ambiente de producción. En la figura 2 podemos ver que los nodos worker de ROSA fueron desplegados en una subnet alojada en la Local Zone de Buenos Aires, permitiendo así un esquema híbrido de co-existencia con nuestros sistemas y bases de datos legados.

Se observan también 2 load balancers que son usados por el cluster para proveer acceso a su consola/API, y para publicar aplicaciones vía OpenShift routes.

El componente ROSA fue implementado en modo privado con private link, lo cual implica que el acceso a la consola y APIs de OpenShift es privado. Asimismo, private link es usado por el propio Red Hat para soportar tareas de administración del cluster.

Para maximizar el grado de aislación entre ambientes, se definió que cada cluster esté en su propia cuenta de AWS e integrado con las herramientas de gobierno, seguridad y auditoría provistas por el esquema de Control Tower.

Conclusiones

La combinación de ROSA en la Local Zone de Buenos Aires nos permitió desplegar rápidamente una plataforma de contenedores de baja latencia, facilitando una experiencia integrada gracias a las herramientas de administración y APIs familiares a las provistas por OpenShift on-premises.

La combinación de las herramientas de gobierno, seguridad y auditoría de AWS con el servicio de contenedores administrados de ROSA permite a Federación Patronal adoptar un esquema ágil de desarrollo, facilitando desplegar el cluster de contenedores en minutos, sin perder el control de la plataforma y asegurando la co-existencia de la arquitectura híbrida. Como contrapartida, el despliegue original del cluster OpenShift que realizamos en nuestro centro de datos demoró varios meses.

Gracias a esto pudimos adoptar un nuevo patrón de arquitectura híbrida para soportar el desarrollo de nuestro nuevo stack de tecnología. La proximidad de la Local Zone de Buenos Aires con nuestros centros de datos combinada con los componentes presentados en este patrón de arquitectura facilita la co-existencia y evolución del nuevo core de seguros.

Próximos pasos

En los próximos artículos de la serie profundizaremos sobre aspectos de seguridad, operaciones, observabilidad, performance, networking y optimización de costos de los componentes de la arquitectura.