Arquitetura baseada em células na AWS

Introdução

Aplicativos monolíticos são muito comuns e não há vergonha em executá-los em suas cargas de trabalho. Esses sistemas geralmente evoluem a partir de muitas iterações de melhorias e correções de recursos, gradualmente se transformando no que hoje reconhecemos como um monólito. Esse crescimento também é um sinal indireto da capacidade do seu negócio de se expandir e atender às demandas crescentes. No entanto, à medida que sua base de usuários cresce, também aumentam os desafios associados à refatoração e à reengenharia de seus aplicativos e fluxos de trabalho, levando a gargalos e possíveis pontos únicos de falha.

Este blog apresenta arquitetura baseada em células, um nome que encontrei ao procurar uma solução viável para iniciar uma jornada de desacoplamento para vários aplicativos monolíticos na AWS. Os padrões arquitetônicos não são um conceito novo, no entanto, é uma intenção introduzir o conceito de arquitetura bulk-head em sua solução.

Se você não está familiarizado com o Well-Architected Framework da AWS, sugiro que leia o whitepaper que explica o conceito de arquitetura bulkhead.

Apresentando células

Imagine seu aplicativo dividido em unidades independentes e independentes chamadas células. Cada célula é uma instância completa da lógica do seu aplicativo, com sua própria réplica de banco de dados ou recursos de armazenamento. Precisamos ter cuidado para não nos confundirmos com uma solução de alta disponibilidade em diversas zonas ou regiões de disponibilidade, pois isso nos proporciona isolamento físico na camada de infraestrutura. Estamos preocupados com o isolamento de aplicativos com base nas necessidades do negócio e CI/CD fluxos de trabalho. Além disso, se você eliminar esse conceito, ele se parecerá muito com a arquitetura de conteinerização, mas em uma escala diferente.

Neste diagrama, podemos considerar que cada célula representa um aplicativo isolado em sua própria conta AWS. Mais tarde explicarei o roteador celular descrito como a 'camada mais fina possível'.

< entidade 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>

Esta é a aparência de uma arquitetura baseada em células para um aplicativo simples de duas camadas.

< entidade 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 detalhar a arquitetura da célula, cada célula é uma conta AWS. Se ampliarmos uma das células, você poderá ver os recursos de computação e armazenamento configurados em várias AZs para alta disponibilidade.

< entidade 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>

Benefícios da arquitetura baseada em células

Capacidade de gerenciamento aprimorada

• Raio de explosão reduzido: Os problemas estão contidos em células individuais, minimizando o impacto na aplicação geral. Isso permite isolar problemas e corrigi-los rapidamente, sem afetar uma grande base de usuários. Este é o conceito de anteparo mencionado acima.
• Implantações seguras: Novos recursos ou atualizações de versão podem ser implantados em uma única célula para teste antes de serem implementados em todas as células. Isso minimiza o risco e permite reversões mais fáceis, se necessário.

Tolerância a falhas aprimorada

• Alto tempo médio entre falhas (MTBF): Limitando o tamanho de cada célula, ou seja, limitando o número de usuários ou carga de trabalho por célula, você pode prever e resolver falhas com mais facilidade. Isso leva a um MTBF mais alto, o que significa que seu aplicativo apresenta falhas com menos frequência.
• Menor tempo médio de recuperação (MTTR): O tamanho limitado das células também simplifica a solução de problemas. Com um conjunto menor de recursos para diagnosticar, você pode resolver problemas mais rapidamente, resultando em um MTTR mais baixo.

Escalabilidade fácil:

• Escalabilidade horizontal: Ao contrário da expansão de um aplicativo monolítico, a arquitetura baseada em células permite a expansão adicionando novas células para lidar com o aumento do tráfego. Isso fornece uma abordagem mais eficiente e gerenciável para lidar com o crescimento.
• Cota de serviço previsível: As cotas de serviço da AWS definem limites de uso de recursos para sua conta. Às vezes, isso pode ser um bloqueador quando supervisionado. Ao usar uma arquitetura baseada em células, podemos garantir que essas cotas não prejudiquem a funcionalidade do aplicativo à medida que você aumenta a escala.
• Testabilidade aprimorada: O teste canário, onde você implanta uma nova versão para um pequeno subconjunto de usuários, torna-se fácil com a arquitetura baseada em células. Você pode testar novos recursos ou atualizações em uma única célula sem impactar toda a base de usuários.

Construindo sua arquitetura baseada em células na AWS

Aqui discutirei os principais componentes que a AWS fornece para configurar uma arquitetura baseada em células:

• Rota 53: Este serviço distribui o tráfego entre várias supercélulas (grupos de células dentro de uma região) usando roteamento ponderado ou verificações de saúde avançadas para controle zonal.
• Camada de roteamento de células: Um microsserviço ou aplicativo em contêiner que recebe solicitações, consulta uma tabela de roteamento como o DynamoDB para mapear usuários para células específicas e os encaminha para o balanceador de carga da célula apropriada. No primeiro diagrama acima, ela é representada como a “camada mais fina possível” e é exatamente isso que deveria ser. Essa deve ser a única tarefa desta camada.
• Supercélula (Região): Cada região da AWS representa uma supercélula e pode conter várias células. Inclui um Elastic Load Balancer (ELB) para distribuição de tráfego, um grupo de Auto Scaling para escalonamento automático, um agente CloudWatch para monitoramento e buckets S3 opcionais para dados ou logs específicos de células.
• Célula: Esta é a unidade principal, pode conter instâncias EC2, funções Lambda, ECS, EKS, etc. executando o código do seu aplicativo, sua própria réplica ou armazenamento de banco de dados e arquivos de configuração específicos da célula.

Gestão centralizada:

Utilizando o AWS Organizations e o AWS Control Tower, as zonas de destino da AWS serão automatizadas, ao mesmo tempo em que atendem aos seus requisitos de governança, bem como adotam as melhores práticas da AWS na nuvem.

Principais considerações para arquitetura baseada em células:

• Posicionamento de células: Decida como os clientes e as cargas de trabalho são mapeados para as células. Isso envolve particionar dados e tráfego com base em sua aplicação específica (B2B vs. B2C) e contexto empresarial.
• Por exemplo, você deseja que as células estejam mais próximas da localização geográfica do usuário final ou do cliente com base em seu perfil de usuário.

< entidade 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>

• Roteamento: Implemente um mecanismo de roteamento robusto como Route 53 ou API Gateway para distribuir o tráfego para as células certas. Garanta alta disponibilidade evitando pontos únicos de falha. Considere usar várias VPCs com peering de VPC para comunicação celular. Podemos incorporar o Route 53 Application Recovery Controller para cenários de roteamento avançados.
• Dimensionamento de células: Determine o tamanho ideal para suas células para garantir um dimensionamento eficiente com base em seu plano de expansão predeterminado.

Conforme mencionado anteriormente, a arquitetura baseada em células não é um conceito novo. É um padrão deliberado a ser considerado ao elaborar uma solução a ser usada ao desacoplar um aplicativo monolítico e ao projetar uma nova solução. Aproveitar alguns dos serviços globais da AWS, como Route 53 e CloudFront, em uma arquitetura baseada em células, pode adicionar novas dinâmicas sobre como você pode gerenciar seus CI/CD pipeline com a personalização das experiências do usuário final com base nas necessidades do seu negócio.

À medida que navegamos pelas complexidades do desenvolvimento de software moderno, a transição da arquitetura monolítica para a arquitetura baseada em células não é apenas uma atualização – é um movimento estratégico em direção à agilidade, resiliência e inovação sustentada. Se você estiver pronto para aprimorar a capacidade de gerenciamento, a tolerância a falhas e a escalabilidade do seu sistema com a AWS, vamos dar o primeiro passo juntos.