En este artículo se resume el proceso y los componentes que el equipo de ingeniería de software comercial (CSE) de Microsoft usó para compilar una solución para un cliente de banca. Para mantener el anonimato, el artículo se refiere al cliente como Contoso Bank. Es una importante organización de la industria internacional de servicios financieros (FSI) que deseaba modernizar uno de sus sistemas de transacciones financieras.
Architecture
Descargue un archivo Visio de esta arquitectura.
La solución consta de tres bloques principales: servicios back-end, prueba de carga y supervisión con Event Autoscaler.
Los contenedores reales de microservicios de Contoso se insertaron manualmente con Docker en el clúster de Kubernetes. Este clúster fue:
Red Hat OpenShift en Azure (ARO) en el escalador automático de pods horizontal (HPA) de Kubernetes/OpenShift horizontal Pod (HPA) para:
Channel Holder.
El rendimiento y la escalabilidad de los resultados de la simulación de las transacciones.
Azure Kubernetes Services (AKS) para el escalador automático del nodo para Channel Holder.
El equipo de CSE creó los otros microservicios como código auxiliar para aislar específicamente los microservicios reales de Contoso de otros servicios del sistema central externos que la solución ha insertado mediante canalizaciones de Azure Pipelines.
Flujo de trabajo
En el núcleo, los servicios back-end proporcionan la lógica necesaria para que se produzca una transferencia electrónica de fondos:
Las transferencias electrónicas de fondos comienzan por una solicitud HTTP que recibe el servicio Channel Holder.
El servicio proporciona respuestas sincrónicas a los solicitantes con un patrón publish-subscribe mediante Azure Cache for Redis y espera una respuesta de back-end.
La solución valida esta solicitud inicial mediante el servicio de contraseña piloto del sistema de transferencia electrónica de fondos.
Además de llevar a cabo las validaciones, el servicio también enriquece los datos. El enriquecimiento de datos ayuda al back-end a decidir si la solución debe utilizar un sistema de microservicios heredado o uno nuevo para procesar la transferencia electrónica de fondos.
A continuación, Channel Holder inicia el flujo asincrónico.
El servicio llama a EFT Controller, que es un orquestador reactivo que coordina flujos de transacción. Lo hace generando comandos y consumiendo eventos de otros microservicios mediante Azure Event Hubs/Kafka.
Uno de estos servicios es EFT Processor, donde es la solución la que efectúa la transacción mediante operaciones de crédito y débito.
El equipo de CSE usó el escalado automático controlado por eventos (KEDA) de Kubernetes. Es un marco que escala automáticamente las aplicaciones en función de la carga de mensajes que procesa la solución. En la solución se usó para escalar EFT Processor a medida que la solución procesaba nuevas EFT.
KEDA es compatible con AKS y Azure Container Apps
Lo siguiente son las pruebas de carga. Azure Load Testing es un servicio de prueba de carga totalmente administrado que permite generar una carga a gran escala. El servicio simula el tráfico de las aplicaciones sin necesidad de implementar recursos adicionales. Azure Load Testing también incluye la capacidad de tomar un script de Apache JMeter existente y usarlo para ejecutar una prueba de carga.
Por último, durante la supervisión se integraron los resultados de las pruebas de carga, la infraestructura y las métricas de aplicación.
El equipo puso en correlación una ejecución de prueba de carga con los efectos secundarios de los microservicios en la capa de orquestación de contenedores y almacenamiento. Permitió un ciclo de comentarios rápido para la optimización de la aplicación. Prometheus, Grafana y Application Insights en Azure Monitor fueron los componentes principales que permitían esta funcionalidad de supervisión y observación. El escalador automático de eventos admitió la validación de un escenario en el que las aplicaciones se escalaban en función de la carga de mensajes recibida. Para implementar este comportamiento, el equipo de CSE adaptó KEDA para admitir el escalado de aplicaciones Java.
Funcionalidades de la solución
La solución cuenta con tres funcionalidades principales:
Escalador automático de pods horizontal para Channel Holder
Escalado automático de nodos para Channel Holder
Rendimiento y escalabilidad de los resultados de la simulación de las transacciones
Escalador automático de pods horizontal para Channel Holder
En esta solución el equipo usó un escalador automático de pods horizontal de Kubernetes/OpenShift como mecanismo. El escalador automático de pods horizontal escala automáticamente el número de pods según una métrica elegida. Al hacerlo, se proporciona un mecanismo eficaz de escalado y reducción horizontales para los contenedores. Dada la naturaleza de vinculación a la CPU de Channel Holder REST API, el equipo optó por usar el escalador automático de pods horizontal con la CPU para que las réplicas del servicio pudieran multiplicarse a medida que se producían nuevas transacciones electrónicas de fondos.
Este componente ejecuta un servicio denominado Channel Holder en Azure Red Hat OpenShift que lleva a cabo pruebas de escalado automático de pods en este servicio. El componente tenía que conseguir las siguientes funcionalidades:
La provisión de una canalización de DevOps desde el entorno local a Azure para el servicio Channel Holder.
La provisión de supervisión del clúster de OpenShift mediante un panel de Grafana.
La ejecución de pruebas de escalado horizontal automático de pods para el servicio Channel Holder.
La provisión de observabilidad en Channel Holder al activar la captura de métricas (por ejemplo, el uso) con Prometheus y Grafana.
La provisión de un informe detallado sobre las pruebas ejecutadas, el comportamiento de las aplicaciones y las estrategias de creación de particiones de Kafka, si procede.
Escalado automático de nodos para Channel Holder
Primero, el escalador automático de pods horizontal escala las réplicas hasta un punto en el que satura la infraestructura del clúster. Después, un mecanismo de escalado y reducción horizontales para los nodos mantiene las aplicaciones recibiendo y procesando las nuevas solicitudes. Para ese mecanismo, el equipo usó el escalado automático de nodos de Kubernetes, que permitía que el clúster creciera incluso cuando todos los nodos estaban cerca de su capacidad máxima.
Este componente se centra en ejecutar el servicio Channel Holder en AKS para permitir las pruebas de escalado automático de nodos. Tenía que conseguir las siguientes funcionalidades:
La provisión de supervisión del clúster de AKS mediante un panel de Grafana.
La ejecución de pruebas de escalado automático de nodos para el servicio Channel Holder.
La provisión de observabilidad en Channel Holder al activar la captura de métricas con Prometheus y Grafana.
La provisión de un informe detallado sobre las pruebas ejecutadas, el comportamiento de las aplicaciones y las estrategias de creación de particiones de Kafka, si procede.
Rendimiento y escalabilidad de los resultados de la simulación de las transacciones
Con el marco de pruebas de carga, el equipo de CSE generó una carga suficiente para desencadenar los mecanismos tanto del escalador automático de pods horizontal como del escalado automático de nodos. Cuando la solución desencadenó los componentes, generó métricas de infraestructura y aplicación para que el equipo validara los tiempos de respuesta de escalado de Channel Holder y el comportamiento de la aplicación con carga elevada.
Este componente se centra en ejecutar los servicios Channel Holder, EFT Controller y EFT Processor en ARO y AKS. Además, lleva a cabo pruebas de rendimiento y escalado automático de pods y nodos en todos los servicios. Tenía que conseguir las siguientes funcionalidades:
La ejecución de pruebas de rendimiento en los microservicios hasta que se alcanzaran o superaran las 2000 transacciones por segundo.
La ejecución de pruebas de escalado automático de pods/nodos horizontal en los microservicios.
La provisión de observabilidad en Channel Holder al activar la captura de métricas con Prometheus y Grafana.
La provisión de un informe detallado sobre las pruebas ejecutadas, el comportamiento de las aplicaciones y las estrategias de creación de particiones de Kafka adoptadas.
Componentes
En la siguiente lista se resumen las tecnologías que el equipo de CSE usó para crear esta solución:
Azure
Aplicaciones de terceros
Servicios back-end de Contoso Bank
De código abierto
Detalles del escenario
Contoso Bank es una de las principales organizaciones de la industria internacional de servicios financieros (FSI) que deseaba modernizar uno de sus sistemas de transacciones financieras.
Contoso Bank quería usar aplicaciones simuladas y reales, así como las cargas de trabajo existentes, para supervisar la reacción de la infraestructura de la solución en cuanto a la escalabilidad y el rendimiento. La solución tenía que ser compatible con los requisitos del sistema de pago existente.
Posibles casos de uso
Contoso Bank deseaba usar un conjunto de simulaciones para:
Determinar el impacto de la escalabilidad de la infraestructura.
Determinar la reacción ante errores en el diseño existente de la arquitectura del software del sistema central específico.
La solución propuesta usaría una aplicación virtual para simular escenarios funcionales. Su finalidad sería supervisar el rendimiento y la escalabilidad de la infraestructura. El objetivo era determinar mediante este conjunto de simulaciones el impacto de los errores en las cargas de trabajo del sistema de transferencia electrónica de fondos (EFT) del sistema central.
También se exigía una transición de DevOps fluida del entorno local a la nube. Esta debía incluir los procesos y la metodología del banco, y tenía que usar las herramientas existentes de Contoso Bank. El uso de las tecnologías existentes reduciría la necesidad de actualizar los conocimientos para los desarrolladores. Con la transición, Contoso Bank aprovecharía para revisar las decisiones de diseño actuales y futuras. La transición también proporcionaría la confianza en que Azure es un entorno lo suficientemente sólido para hospedar los nuevos sistemas distribuidos.
Consideraciones
Criterios de éxito
El equipo de Contoso y el equipo de CSE definieron los siguientes criterios de éxito para esta contratación:
Criterios generales
Contoso Bank consideró los siguientes puntos generales como criterios de éxito en todos los componentes:
La provisión de las habilidades necesarias para aplicar la transformación digital y la adopción de la nube al equipo técnico de Contoso. El equipo de CSE:
Proporcionó las herramientas y los procesos necesarios en Azure.
Demostró cómo el equipo técnico de Contoso podría seguir usando sus herramientas existentes.
Cada componente incluía un documento que abarcaba:
Los resultados de las pruebas de rendimiento y escalabilidad.
Los parámetros y las métricas que se consideraron en cada prueba.
Cualquier cambio de código o infraestructura, si hubiera sido necesario, durante cada prueba.
Las lecciones aprendidas sobre los ajustes y la optimización del rendimiento, y los parámetros que se tuvieron en cuenta para cada prueba.
Las lecciones aprendidas y las instrucciones sobre las estrategias de creación de particiones de Kafka.
Las recomendaciones o instrucciones generales de arquitectura en función de lo aprendido con las entregas.
Criterios de entrega
| Métrica | Valor (rango) |
|---|---|
| Capacidad de ejecutar pruebas de escalado automático de pods en Channel Holder | Destino: El sistema crea automáticamente una nueva réplica de pod de Channel Holder al alcanzar el 50 % del uso de la CPU. |
| Capacidad para ejecutar el escalado automático de nodos en función de Channel Holder | Destino: El sistema crea nuevos nodos de Kubernetes debido a las restricciones de los recursos en los pods (por ejemplo, uso de la CPU). Kubernetes restringe el número de nodos que el sistema puede crear. El máximo de nodos es tres. |
| Capacidad de ejecutar pruebas de rendimiento y escalado automático de pods/nodos en la simulación de transacción electrónica de fondos | Destino: El sistema crea automáticamente nuevas réplicas del pod para todos los servicios. La replicación se produce después de alcanzar el 50 % del uso de la CPU y la creación de un nuevo nodo de Kubernetes por las restricciones de los recursos de CPU. La solución debe admitir 2000 transacciones por segundo. |
Solución técnica
La solución que proporciona el equipo incluía cuestiones transversales e implementaciones específicas para lograr la entrega objetivo. También tenía que cumplir algunas restricciones de diseño basadas en las directivas de Contoso Bank.
Cabe tener en cuenta que, debido a una restricción de las características de Red Hat OpenShift 3.11 en Azure, Contoso solicitó el uso de Azure Kubernetes Service para probar escenarios de escalado automático de nodos.
Había una serie de restricciones de diseño que el equipo de CSE debía considerar:
Debido a requisitos internos, Contoso Bank solicitó el uso de las siguientes tecnologías:
OpenShift 3.11 como plataforma de orquestación de contenedores.
Java y Spring Boot para el desarrollo de microservicios.
Kafka como plataforma de transmisión de eventos con la característica Confluent Schema Registry.
La solución tenía que ser independiente de la nube.
Las herramientas de DevOps y de supervisión debían ser las mismas que Contoso usaba en su entorno de desarrollo local.
La solución no podía compartir el código fuente que Contoso hospedaba en el entorno local con entornos externos. La directiva de Contoso solo permite mover imágenes de contenedor de entornos locales a Azure.
La directiva de Contoso restringe la capacidad de las canalizaciones de integración constante (CI) para que funcionen entre los entornos locales y cualquier nube. Contoso implementó manualmente todo el código fuente hospedado en el entorno local, como las imágenes de contenedor, en Azure Container Registry. La implementación en el lado local era responsabilidad de Contoso.
El escenario simulado para las pruebas tenía que usar un subconjunto de cargas de trabajo de transacciones electrónicas de fondos en el sistema central como referencia de flujo.
Contoso Bank tenía que realizar todas las pruebas del escalador automático de pods horizontal y de rendimiento en ARO.
Cuestiones transversales de la solución
Transmisión de mensajes
El equipo de CSE decidió usar Apache Kafka como plataforma de transmisión de mensajes distribuidos para los microservicios. Para mejorar la escalabilidad, el equipo pensó en usar un grupo de consumidores por microservicio. En esa configuración, cada instancia del microservicio es una unidad de escalado para dividir y paralelizar el procesamiento de los eventos.
Usaban una fórmula para calcular el número de particiones ideal por tema para admitir el rendimiento estimado. Para más información sobre la fórmula, consulte Elección del número de temas o particiones en un clúster de Kafka.
Velocidad de CI/CD
Respecto a DevOps, Contoso Bank ya utilizaba una instancia local de GitLab para el repositorio de código. Crearon canalizaciones de integración continua y entrega continua (CI/CD) para los entornos de desarrollo mediante una solución personalizada basada en Jenkins que desarrollaron internamente. No proporcionó una experiencia de DevOps óptima.
Para ofrecer una experiencia de DevOps mejorada para Contoso, el equipo de CSE usó Azure Pipelines en Azure DevOps para administrar el ciclo de vida de la aplicación. La canalización de CI se ejecuta en cada solicitud de incorporación de cambios, mientras que la canalización de CD se ejecuta en cada combinación correcta en la rama principal. Todos los miembros del equipo de desarrollo eran responsables de administrar los repositorios y las canalizaciones para cada servicio. También tenían que aplicar las revisiones de código, las pruebas unitarias y los linting (análisis de código fuente estático).
El equipo de CSE implementó los servicios simultáneamente sin interdependencias y usó agentes de Jenkins según lo solicitó Contoso Bank.
Incorporaron Prometheus como parte de la solución para supervisar los servicios y el clúster. Además de generar datos significativos para la solución, Contoso Bank puede usar Prometheus en el futuro para mejorar los productos según el uso diario. Estas métricas se muestras en un panel de Grafana.
Estrategia de lanzamiento
El equipo lanzó la solución en el entorno de desarrollo mediante Azure Pipelines. Cada servicio tenía su propia canalización de compilación e implementación. Usaban una canalización de implementación que se desencadena manualmente. Debe forzar una implementación completa del entorno y de los contenedores en una versión específica de la rama.
El equipo de CSE creó bifurcaciones de lanzamiento que generaban versiones estables para la implementación. La combinación de ramas en la rama principal solo se produce cuando el equipo está seguro de que están listas para implementar la solución. Una estrategia de reversión, más allá de la implementación de la versión estable anterior, quedaba fuera del ámbito de este contrato. Existen puertas de aprobación para cada fase. Cada puerta solicita la aprobación de la implementación.
Recuperación ante desastres
La solución usa scripts de Terraform y Azure Pipelines para todos los servicios. Si se produce un desastre, Contoso Bank puede volver a crear todo el entorno mediante scripts de Terraform o la ejecución de la canalización de versiones de nuevo. Terraform entiende que el entorno ha cambiado y lo vuelve a crear. La solución aprovisiona y destruye de forma dinámica la infraestructura en Azure según sea necesario. Las cuentas de almacenamiento son de almacenamiento con redundancia de zona (ZRS). Las estrategias de copia de seguridad quedaban fuera del ámbito de este contrato.
Seguridad y privacidad
Todas las imágenes de contenedor se almacenaban en un registro privado (Azure Container Registry).
La solución utiliza los secretos de ARO y AKS para insertar datos confidenciales en pods, como las cadenas de conexión y las claves.
El acceso al servidor API de Kubernetes requiere autenticación a través de Microsoft Entra ID para ARO y AKS.
El acceso a Jenkins requiere autenticación a través de Microsoft Entra ID.
Conclusiones
Al final del proyecto, el equipo de CSE compartió la información siguiente:
Resultado de la solución y del contrato
El equipo observó un alto nivel de compatibilidad entre AKS y ARO para la implementación de los servicios.
Application Insights sin código facilita la creación de observabilidad, al colaborar para la adopción de la nube en las migraciones mediante lift-and-shift.
La prueba de carga es una parte importante de las soluciones de gran escala y requiere análisis previos y planeamiento para tener en cuenta las características específicas del microservicio.
Los clientes suelen subestimar la capacidad de la prueba de carga para encontrar los efectos secundarios de los microservicios.
La creación de un entorno de prueba puede requerir una estrategia de eliminación de la infraestructura para evitar costos innecesarios.
Aprendizajes clave
Hay una migración de aplicaciones fluida de ARO a AKS.
La característica de escalado automático de nodos no estaba disponible en la versión 3.11 de Red Hat OpenShift, que era la que se usó durante el contrato. Por lo tanto, el equipo de CSE llevó a cabo los escenarios de prueba de escalado automático de nodos con AKS.
Al final de su ciclo de vida, los productos pueden necesitar personalización creativa. Para entregar una solución correcta, la fase de preparación juega un papel importante para el equipo.
Al crear este artículo, el equipo de CSE creó una solución de prueba de carga que integra Container Instances y JMeter en una canalización de Azure DevOps. Azure Load Testing ya está disponible como un servicio de pruebas de carga totalmente administrado sin necesidad de implementar recursos de proceso adicionales.
El equipo recomendó el uso de la Azure Event Hubs para Kafka, pero, para Contoso Bank, el registro de esquemas era una característica importante. Para ayudar a Contoso Bank en el plazo de tiempo solicitado, el equipo tuvo que considerar el uso del registro de esquemas en otra instancia de AKS.
El protocolo de Kafka con registro de esquemas no era compatible con el escalador de Event Hubs de KEDA.
Pasos siguientes
Escalado automático de aplicaciones Java con KEDA mediante Azure Event Hubs: KEDA para ejemplo de Java
Patrón: Saga: información sobre el patrón Saga en Microservices.io
Recursos relacionados
Para más información sobre los procesos y las tecnologías que se usaron para crear esta solución, consulte los siguientes artículos: