Diseño de soluciones de arquitectura: la infraestructura.

Este artículo forma parte de una serie de artículos sobre el diseño de soluciones de arquitectura. En artículos anteriores hemos hablado sobre qué es y para qué sirve la arquitectura funcional, el contexto, la anatomía de un modelo de solución y su arquitectura funcional. En el artículo anterior vimos cómo detallar el modelo técnico que proporcione la visión del proyecto en un lenguaje más cercano al equipo de desarrollo y equipos técnicos.

En este artículo terminamos definiendo el contenido de diseño con la infraestructura de la solución.

El objetivo es tratar de recopilar todas las acciones necesarias para gestionar de forma eficiente la preparación de los entornos desde el principio con los equipos de desarrollo y sistemas para evitar retrasos cuando el equipo los necesite para realizar pruebas.

Entornos

Esta vista describe la estructura física de los recursos hardware o software sobre los que desplegar todos los artefactos descritos anteriormente. Podemos modelar la infraestructura como una nueva visión a partir de la arquitectura técnica y de despliegue, eliminando la información que no nos interesa y añadiendo los elementos de red, hardware, software y elementos físicos.

Los proyectos suelen trabajar con entornos previos, además del entorno de producción, por lo que esta vista debe diseñar los recursos necesarios de infraestructura para todos los entornos con los que se vaya a trabajar y ajustar así los recursos necesarios en cada entorno según las pruebas a realizar y optimizar los costes.

Los datos necesarios para detallar los elementos de infraestructura a desplegar se detallan en los siguientes capítulos y podemos calcularlos aplicando los requisitos no funcionales y volumetrías de los casos de uso a los recursos impactados por cada uno.

Hay que considerar que no hay por qué detallar la infraestructura completamente desde el primer momento. Es mejor ir detallando los recursos que se vayan necesitando conforme se vayan cerrando las decisiones de la arquitectura técnica, o una vez que el modelo de solución esté más maduro. Pero también es recomendable no dejarlo para el final e incluir este diseño en determinados momentos del proyecto donde aporta valor. Por ejemplo, cuando necesitamos un business case podemos definir la infraestructura a alto nivel para estimar los costes aproximados de infraestructura del proyecto, o en la fase de análisis del proyecto de forma más detallada para gestionar con tiempo las solicitudes de los recursos.

Caso práctico

Retomemos el caso práctico de la serie de artículos.

En el caso de nuestro cliente, utilizan entornos previos de desarrollo e integración. No utilizan entorno de preproducción ya que tienen el entorno de integración configurado y dimensionado de forma similar al de producción.

Partimos de esta vista general de producción que, en nuestro caso, va a ser representativa también de los entornos previos de desarrollo e integración. En caso de tener diferencias entre entornos es recomendable realizar un diagrama por entorno.

Para desplegar la nueva web de Servicios de RRHH, usaremos Kubernetes como indicamos en el artículo anterior. Necesitaremos desplegar un nuevo cluster de servidores en el CPD del cliente para ello. El SO a utilizar será Ubuntu 24, que es la última versión utilizada por el cliente.

Se ha evaluado la posibilidad de utilizar un servicio gestionado en Azure de Kubernetes, pero se estimó conveniente tras analizarlo con el equipo de sistemas desplegarlo en el CPD por cercanía con las aplicaciones existentes, como base para nuevos desarrollos y formación del equipo del hospital (y por conveniencia de dar más variedad al caso práctico).

Se planteó la opción de desplegar los servidores de Kubernetes como máquinas virtuales en los servidores actuales, pero tras revisarlos se identifica la necesidad de adquirir y desplegar nuevas máquinas, con los plazos que eso conlleva. Al hacerlo en fase de diseño, lo hemos identificado con tiempo para adquirirlos e instalarlos.

Para las aplicaciones existentes, no necesitamos detallar la infraestructura si no va a tener cambios para no perder el foco de los que necesitamos hacer en el proyecto. Más adelante evaluaremos si es necesario hacer crecer esa infraestructura.

El resto de componentes son servicios PaaS/SaaS para los que no necesitamos diseñar infraestructura. Su dimensionamiento lo revisaremos en los capítulos siguientes.

Redes

En el caso de implementar una infraestructura desde el inicio, un punto de partida es el diseño de la topología de red y las subredes como marco para ordenar el despliegue de la infraestructura de la forma más eficiente, especialmente a nivel de comunicaciones con foco en el ancho de banda necesario y las latencias.

Normalmente, vamos a partir de unas redes ya desplegadas con unos criterios y reglas a seguir, y las tomaremos como punto de partida.

No es objeto de este artículo entrar en detalle sobre el diseño de la red, al igual que no detallo patrones de diseño de arquitectura o de software, pero sí es importante disponer de este diseño en este punto para incluirlo en el modelo de solución, ya que la configuración de red de los elementos de infraestructura dependerá del diseño de las redes.

Caso práctico

El cliente actualmente tiene sus sistemas en una red interna y una red externa DMZ en su CPD del propio hospital.

El cluster de servidores para Kubernetes se despliega en su CPD y se configura dentro de la red interna. Como web server, utilizaremos el que actualmente tienen en la DMZ para el resto de aplicaciones.

Cada entorno tiene su propia subred dentro de la red interna y los servidores se configurarán dentro de las subredes correspondientes ya existentes en los entornos.

En Azure y CloudHub como proveedores cloud, contamos con que disponen de sus propias redes internas para configurar de forma privada los servicios y habilitar el acceso solamente a ellos a través de conexiones VPN. Actualmente, disponemos de servicio VPN desplegado en el CPD, por lo que se configuran los clientes VPN correspondientes en los servicios cloud. Se configurarán los DNS para resolver las URLs de los servicios cloud a través de la red privada.

Recursos

En esta sección enumeramos los recursos de hardware, software y servicios que vamos a necesitar y la configuración relevante desde el punto de vista de arquitectura para cumplir con la arquitectura técnica y los requisitos no funcionales.

Máquinas

Continuidad de negocio

Bases de datos

Unidades de ficheros

SFTP / Envíos de ficheros

Máquinas

Se enumeran las máquinas a comprar para dar soporte a la instalación de Kubernetes. En este caso no necesitamos concretar un modelo, pero sí el dimensionamiento de los recursos. Estos recursos son tallas pequeñas, pero son suficientes para soportar 4 veces las necesidades del proyecto y se considera que no es necesario recortar más estos recursos.

Al tratarse de recursos físicos, hay que considerar el uso que se les pueda dar en los próximos años. Se ha tenido en cuenta que el cluster de Kubernetes servirá tanto para crear nuevos servicios como para migrar las aplicaciones de los servidores obsoletos actuales más adelante.

Servicios cloud

Para los servicios cloud, detallamos también el dimensionamiento de los servicios según los criterios que proporcionan los proveedores. En este caso, hemos optado por el dimensionamiento mínimo para la carga actual siguiendo los criterios que ya describimos en el diseño de arquitectura técnica. La ventaja de usar servicios cloud es que, más adelante, podremos ampliarlos sin efecto en los usos actuales.

Continuidad de negocio

Considerando los requisitos no funcionales descritos, podemos calcular la carga que van a soportar cada uno de los componentes de aplicación, agrupando las volumetrías de las integraciones soportadas por los servicios que implementan.

Podemos ver que los volúmenes de operaciones se reparten a lo largo de la segunda quincena de cada mes con operaciones mayormente manuales. Hay momentos de carga pico en el proceso de planificación pero, incluso con el uso de paginación de los servicios, el número de llamadas es bajo.

¿Cómo sabemos que es bajo o alto? Comparando el rendimiento requerido con la capacidad de rendimiento que tienen los servicios. La forma de saberlo es realizando pruebas de estrés con servicios similares sobre esa configuración o una parecida del servidor.

Observando los resultados de las pruebas de estrés de las aplicaciones de gestión de empleados y servicios de RRHH que se hicieron en su momento, vemos que pueden soportar hasta 20 peticiones/s de forma continua sin degradarse. Deberían soportar bien su carga actual (unas 2 peticiones/minuto) con el incremento planteado en el proyecto (picos de 0,5 peticiones/s y de 20 peticiones en 1 o 2 segundos). Sobre el cluster de Kubernetes no tenemos pruebas de estrés, pero esperamos una carga de menos de 2 peticiones/minuto.

Para soportar el diseño, podemos indicar al equipo de desarrollo que ponga foco en estas pruebas o solicitar realizar una POC del cluster con pruebas de estrés sobre una app dummy para confirmarlo.

¿Qué ocurriría si, en lugar de gestionar la planificación de un hospital, extendiéramos la aplicación a todos los hospitales de la Comunidad de Madrid o España? Podríamos estar multiplicando las volumetrías por 100 o 200. No necesitamos multiplicar los servidores en ese mismo orden de magnitud para soportar la carga promedio, lo que supondría un ahorro de coste global, pero necesitaríamos capacidad elástica para los momentos pico, lo que nos llevaría a pensar en un despliegue en cloud con recursos bajo demanda o un cambio de la arquitectura técnica.

En la descripción de los requisitos no funcionales vimos que se dispone de tiempo para recuperar manualmente los servicios y se decide no implementar redundancia de los servicios desplegados en CPD. Para los servicios cloud se configurará redundancia de zona en configuración Activo / Pasivo para casos de caída local.

Por las indicaciones de negocio que recogimos en el RPO, se necesita realizar backup al menos cada hora de las bases de datos de CPD. En los servicios cloud este requisito se cubre suficientemente con la configuración por defecto, que es cada 10 minutos.

Bases de datos

La base de datos actual de la aplicación de servicios de RRHH está en SQL Server y su carga se verá incrementada en unas 4.000 operaciones cada 15 días. Con este volumen de operaciones, no se considera necesario ampliar los recursos del servidor de BD.

Con el crecimiento mensual estimado en base a los tamaños de datos de las operaciones que vimos en el diseño de arquitectura técnica es de unos 30 MB mensuales, por lo que, con vistas a su uso durante los 2 años de retención de datos necesarios, necesitaremos ampliarla sobre 1 GB de espacio.

La tabla de planificación de turnos de cada sanitario se puede considerar información privada que se debe configurar para que se cifre.

En el caso de la BD del gestor de notificaciones, su contenido es fijo, ya que es información de parametrización del servicio. La dimensionamos con los recursos mínimos necesarios.

Comunicaciones

Es un clásico encontrarnos con bloqueos y problemas en las pruebas o al desplegar en producción porque no se han configurado todas las comunicaciones convenientemente.

Esta sección nos sirve para revisar todas las comunicaciones que se establecen en la solución de arquitectura. Una forma sencilla de obtenerlas es a través de las integraciones, pero agrupándolas por los componentes, servicios o subredes de origen y destino de las integraciones.

Al revisar las integraciones sobre el modelo de infraestructura podremos ver los saltos entre redes y configuraciones necesarias para habilitar las comunicaciones. Podremos revisar también si hay comunicaciones muy lejanas que pudieran dar problemas con las latencias.

Comunicaciones

Caso práctico

Comunicaciones

La mayoría de las comunicaciones son mediante servicios REST por HTTPS, por lo que necesitaremos permitir comunicaciones en los firewalls de cada red por el puerto correspondiente. En el caso de las comunicaciones de eventos con el broker, será el puerto específico del protocolo Kafka.

Los sistemas del CPD se encuentran todos en Madrid. Los servicios cloud los configuraremos en las geografías más cercanas disponibles.

Batch

Para configurar la planificación de los procesos batch identificados en el diseño técnico necesitamos proporcionar algunos detalles adicionales para que el equipo de sistemas pueda valorar cómo encajan en la malla batch.

Caso práctico

Aunque no tenemos procesos batch como tales, sí que tenemos procesos planificados en determinados momentos y podemos detallarlos en esta sección.

Operación

Finalmente, para conseguir una buena calidad de la arquitectura desplegada, necesitamos definir los recursos de monitorización y operación que se necesitan configurar.

Quizá sea discutible si este punto es relevante para la arquitectura o es una cuestión más de QA o DevOps, pero es importante definirlo, sobre todo cuando estamos desplegando nueva infraestructura o hay que analizar la necesidad de introducir nuevas herramientas de monitorización.

Para gestionarlo, se puede acordar con los equipos de desarrollo y sistemas si debe formar parte del diseño de arquitectura o de otra documentación de despliegue. Lo relevante es que quede definido y sea producto del trabajo en equipo.

Sondas de monitorización

Agentes de monitorización

Alertas de logs

Caso práctico

En nuestro proyecto, necesitamos desplegar agentes de monitorización en los nuevos servidores del cluster de Kubernetes con el sistema de monitorización ya existente.

Agentes de monitorización

Los patrones de alerta y gestión de alerta serán los acordados con el equipo de sistemas.

Alertas de logs

También veremos con el equipo de desarrollo cómo van a detallar los errores en los logs y datos relevantes para ser monitorizados y que deban generar alertas.

Conclusiones

En este artículo hemos visto cómo detallar los recursos de infraestructura necesarios para implantar la solución de arquitectura con una visión completa.

Para el modelo de arquitectura, utilizado principalmente en las fases de conceptualización y análisis de los proyectos, no necesitamos detallar mucho más, ya que no se trata de definir la configuración concreta de los componentes, sino de estimar las necesidades de infraestructura y validar la viabilidad y coste de la solución. En momentos más avanzados del proyecto, los equipos de desarrollo y sistemas podrán utilizar esta base para terminar de diseñar el despliegue de la infraestructura.

Los contenidos expuestos en las tablas son una propuesta perfectamente discutible y flexible que puede servir de base para que la puedas personalizar y adaptar a tus necesidades. Deja cualquier sugerencia de mejora que identifiques en los comentarios.

Llegados a este punto, tenemos el contenido técnico completo del modelo de solución. Pero esto no es todo. En el próximo capítulo veremos cómo rematarlo incluyendo las consideraciones importantes para interpretar y tener contexto sobre el proceso de diseño.