Arquitectura basada en células en AWS

Introducción

Las aplicaciones monolíticas son muy comunes y no es ninguna vergüenza ejecutar una en sus cargas de trabajo. Estos sistemas a menudo evolucionan a partir de muchas iteraciones de mejoras y correcciones de funciones, y gradualmente crecen como una bola de nieve hasta convertirse en lo que ahora reconocemos como un monolito. Este crecimiento también es una señal indirecta de la capacidad de su empresa para expandirse y satisfacer demandas crecientes. Sin embargo, a medida que crece su base de usuarios, también aumentan los desafíos asociados con la refactorización y reingeniería de sus aplicaciones y flujos de trabajo, lo que en última instancia genera cuellos de botella y posibles puntos únicos de falla.

Este blog presenta arquitectura basada en células, un nombre que encontré cuando buscaba una solución viable para iniciar un viaje de desacoplamiento para varias aplicaciones monolíticas en AWS. Los patrones arquitectónicos no son un concepto nuevo; sin embargo, es una intención introducir el concepto de arquitectura de mamparo en su solución.

Si no está familiarizado con el marco de buena arquitectura de AWS, le sugiero que lea su documento técnico que explica el concepto de arquitectura de mamparo.

Introduciendo células

Imagine su aplicación dividida en unidades independientes y autónomas llamadas celdas. Cada celda es una instancia completa de la lógica de su aplicación, con su propia réplica de base de datos o recursos de almacenamiento. Debemos tener cuidado de no confundirnos con una solución de alta disponibilidad en múltiples zonas o regiones de disponibilidad, ya que esto nos brinda aislamiento físico en la capa de infraestructura. Nos preocupa el aislamiento de aplicaciones basado en las necesidades del negocio y CI/CD flujos de trabajo. Además, si simplificamos este concepto, es muy parecido a la arquitectura de contenedorización, pero en una escala diferente.

En este diagrama, podemos considerar que cada celda representa una aplicación aislada en su propia cuenta de AWS. Más adelante explicaré el enrutador celular representado como la "capa más delgada posible".

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Así es como se verá una arquitectura basada en celdas para una aplicación simple de dos niveles.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Para desglosar la arquitectura de la celda, cada celda es una cuenta de AWS. Si ampliamos una de las celdas, puede ver los recursos informáticos y de almacenamiento configurados en varias zonas de disponibilidad para lograr alta disponibilidad.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Beneficios de la arquitectura basada en células

Manejabilidad mejorada

• Radio de explosión reducido: Los problemas están contenidos dentro de celdas individuales, minimizando el impacto en la aplicación general. Esto le permite aislar problemas y solucionarlos rápidamente sin afectar a una gran base de usuarios. Este es el concepto de mamparo mencionado anteriormente.
• Implementaciones seguras: Se pueden implementar nuevas funciones o actualizaciones de versión en una sola celda para realizar pruebas antes de implementarlas en todas las celdas. Esto minimiza el riesgo y permite reversiones más fáciles si es necesario.

Tolerancia a fallos mejorada

• Tiempo medio alto entre fallas (MTBF): Al limitar el tamaño de cada celda, es decir, limitar el número de usuarios o la carga de trabajo por celda, es posible predecir y abordar las fallas más fácilmente. Esto genera un MTBF más alto, lo que significa que su aplicación experimenta fallas con menos frecuencia.
• Menor tiempo medio de recuperación (MTTR): El tamaño limitado de las celdas también simplifica la resolución de problemas. Con un grupo más pequeño de recursos para diagnosticar, puede resolver los problemas más rápido, lo que resulta en un MTTR más bajo.

Fácil escalabilidad:

• Escalado horizontal: A diferencia del escalamiento de una aplicación monolítica, la arquitectura basada en celdas le permite escalar agregando nuevas celdas para manejar el aumento del tráfico. Esto proporciona un enfoque más eficiente y manejable para manejar el crecimiento.
• Cuota de servicio predecible: Las cuotas de servicio de AWS definen los límites de uso de recursos para su cuenta. A veces, esto puede ser un obstáculo cuando se supervisa. Al utilizar una arquitectura basada en celdas, podemos garantizar que estas cuotas no obstaculicen la funcionalidad de la aplicación a medida que se escala.
• Capacidad de prueba mejorada: Las pruebas Canary, donde se implementa una nueva versión para un pequeño subconjunto de usuarios, se vuelven fáciles con la arquitectura basada en celdas. Puede probar nuevas funciones o actualizaciones en una sola celda sin afectar a toda la base de usuarios.

Construyendo su arquitectura basada en celdas en AWS

Aquí analizaré los componentes clave que proporciona AWS para configurar una arquitectura basada en células:

• Ruta 53: Este servicio distribuye el tráfico entre múltiples supercélulas (grupos de células dentro de una región) mediante enrutamiento ponderado o controles de estado avanzados para el control zonal.
• Capa de enrutamiento de celda: Un microservicio o aplicación en contenedores que recibe solicitudes, consulta una tabla de enrutamiento como DynamoDB para asignar usuarios a celdas específicas y los reenvía al balanceador de carga de la celda correspondiente. En el primer diagrama de arriba, se representa como la "capa más delgada posible" y eso es exactamente lo que debería ser. Esa debería ser la única tarea para esta capa.
• Supercélula (Región): Cada región de AWS representa una supercélula y puede contener varias celdas. Incluye un Elastic Load Balancer (ELB) para la distribución del tráfico, un grupo de Auto Scaling para el escalado automático, un agente de CloudWatch para el monitoreo y depósitos S3 opcionales para registros o datos específicos de cada celda.
• Celda: Esta es la unidad central, puede contener instancias EC2, funciones Lambda, ECS, EKS, etc. que ejecutan el código de su aplicación, su propia réplica o almacenamiento de base de datos y archivos de configuración específicos de la celda.

Gestión centralizada:

Al utilizar AWS Organizations y AWS Control Tower, la creación de AWS Landing Zones se automatizará y al mismo tiempo se cumplirán sus requisitos de gobernanza y se adoptarán las mejores prácticas de AWS en la nube.

Consideraciones clave para la arquitectura basada en celdas:

• Ubicación de las celdas: Decida cómo se asignan los clientes y las cargas de trabajo a las celdas. Esto implica dividir los datos y el tráfico según su aplicación específica (B2B vs. B2C) y contexto empresarial.
• Por ejemplo, ¿desea que las celdas estén más cerca de la ubicación geográfica de su usuario final o del cliente según su perfil de usuario?

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

• Enrutamiento: Implemente un mecanismo de enrutamiento sólido como Route 53 o API Gateway para distribuir el tráfico a las celdas correctas. Garantice una alta disponibilidad evitando puntos únicos de falla. Considere la posibilidad de utilizar varias VPC con emparejamiento de VPC para la comunicación celular. Podemos incorporar Route 53 Application Recovery Controller para escenarios de enrutamiento avanzado.
• Tamaño de celda: Determine el tamaño óptimo de sus celdas para garantizar un escalamiento eficiente basado en su plan de escalamiento predeterminado.

Como se mencionó anteriormente, la arquitectura basada en células no es un concepto nuevo. Es un patrón deliberado a considerar al elaborar una solución para usar al desacoplar una aplicación monolítica y al diseñar una nueva solución. Aprovechar algunos de los servicios globales de AWS, como Route 53 y CloudFront, en una arquitectura basada en células puede agregar nuevas dinámicas sobre cómo administrar su CI/CD canalización para adaptar las experiencias del usuario final según las necesidades de su negocio.

A medida que navegamos por las complejidades del desarrollo de software moderno, la transición de una arquitectura monolítica a una basada en células no es solo una actualización: es un paso estratégico hacia la agilidad, la resiliencia y la innovación sostenida. Si está listo para mejorar la capacidad de administración, la tolerancia a fallas y la escalabilidad de su sistema con AWS, demos el primer paso juntos.