Journey to Cloud Native nº 7: Uso de contêineres e design baseado em células para maior resiliência e eficiência

Conteinerize aplicativos para padronização e escala

Padronize ferramentas de orquestração de contêineres

Selecionar o serviço certo para seu caso de uso requer considerar suas necessidades organizacionais e conjuntos de habilidades para gerenciar orquestradores de contêineres em grande escala. Nossa equipe escolheu o Amazon Elastic Kubernetes Service (EKS) porque temos as habilidades e a experiência de trabalho com Kubernetes. Além disso, nossa liderança estava comprometida com o código aberto e o recurso de reconhecimento de topologia estava alinhado com nossos requisitos de resiliência.

Para conteinerizar nossos aplicativos Java e .NET, usamos o AWS App2Container (A2C) para criar artefatos de implantação. O AWS A2C reduziu o tempo necessário para análise de dependência e criou artefatos que poderíamos conectar ao nosso pipeline de implantação. A2C oferece suporte a EKS Blueprints com GitOps, o que ajuda a reduzir o tempo de adoção do contêiner. Os blueprints também melhoraram a consistência e seguem as práticas recomendadas de segurança. Se não tiver certeza sobre as ferramentas certas para executar cargas de trabalho em contêineres, consulte Escolher um serviço de contêiner da AWS.

Identifique as ferramentas certas para registro e monitoramento

O registro em ambientes de contêiner adiciona a complexidade do número dinâmico de fontes de log, que pode durar pouco. Para o rastreamento adequado de eventos, precisávamos de uma forma de coletar logs de todos os componentes e aplicativos do sistema. Configuramos o plug-in Fluent Bit para coletar registros e enviá-los para o Amazon CloudWatch.

Usamos o CloudWatch Container Insights for Prometheus para coletar métricas do Prometheus de aplicativos em contêineres. Isso nos permitiu usar ferramentas existentes (Amazon CloudWatch e Prometheus) para construir painéis específicos para diferentes equipes e aplicativos. Criamos painéis no Amazon Managed Grafana usando a integração nativa com o Amazon CloudWatch. Essas ferramentas eliminaram o trabalho pesado de gerenciamento de registros e monitoramento de contêineres de nossas equipes.

Gerenciando a utilização de recursos

Em ambientes de hiperescala, um contêiner vizinho barulhento pode consumir todos os recursos de um cluster inteiro. O Amazon EKS oferece a capacidade de definir e aplicar solicitações e limites para pods e contêineres. Esses valores determinam a quantidade mínima e máxima de um recurso que um contêiner pode ter. Também usamos cotas de recursos para configurar a quantidade total de memória e CPU que pode ser usada por todos os pods em execução em um namespace.

Para entender melhor a utilização de recursos e o custo da execução de aplicativos e pods individuais, implementamos o Kubecost, usando as orientações do Monitoramento de custos de vários clusters para Amazon EKS usando Kubecost e Serviço gerenciado da Amazon para Prometheus.

Dimensionando cluster e aplicativos dinamicamente

Com o Amazon EKS, o servidor de métricas do Kubernetes coleta métricas de recursos do Kubelets e as expõe no servidor da API do Kubernetes. Isso é feito por meio da API de métricas para uso pelo Horizontal Pod Autoscaler (HPA) e Vertical Pod Autoscaler (VPA). O HPA consome essas métricas para fornecer escalabilidade horizontal, aumentando o número de réplicas para distribuir suas cargas de trabalho. O VPA usa essas métricas para ajustar dinamicamente os recursos do pod, como reservas de CPU/memória.

Com a integração do servidor de métricas, o Amazon EKS elimina a complexidade operacional do escalonamento de aplicativos e fornece controles mais granulares sobre o escalonamento dinâmico de aplicativos. Recomendamos que os clientes de hiperescala considerem o HPA como seu escalonador automático de aplicativos preferido porque ele fornece resiliência (maior número de réplicas), além de dimensionamento. No nível do cluster, Karpenter fornece provisionamento e desprovisionamento rápidos de um grande número de diversos recursos de computação, além de fornecer uso econômico. Ele ajuda os aplicativos a se expandirem para atender às necessidades de crescimento dos negócios.

Crie estratégias de reversão para gerenciamento de falhas

Em ambientes de hiperescala, as implementações de implantação normalmente têm uma margem baixa para erros e exigem tempo de inatividade próximo de zero. Implementamos lançamentos progressivos, implantações canário e reversões automatizadas para reduzir o risco de implantações de produção. Usamos indicadores-chave de desempenho (KPIs), como tempo de resposta do aplicativo e taxas de erro para determinar se continuaremos ou reverteremos nossa implantação. Aproveitamos a integração com o Prometheus para coletar métricas e medir KPIs.

Melhorando a resiliência e a escala usando design baseado em células

Ainda precisávamos lidar com eventos de cisne negro e minimizar o impacto de falhas inesperadas ou eventos de escalonamento para torná-los mais resilientes. Criamos um design que cria unidades de aplicativos implantáveis ​​de forma independente, com limites de isolamento de falhas contidos. O novo design usa uma abordagem baseada em células, juntamente com uma técnica de fragmentação aleatória para melhorar ainda mais a resiliência. A palestra re:Invent de Peter Vosshall detalha essa abordagem.

Primeiro, criamos uma arquitetura baseada em células, conforme descrito em Reduzindo o escopo do impacto com a arquitetura baseada em células. Em segundo lugar, aplicamos a fragmentação aleatória conforme descrito em E quanto à fragmentação aleatória?, para controlar ainda mais o impacto do sistema no caso de eventos de cisne negro.

Na Figura 1 vemos dois componentes:

• Uma camada de roteamento leve que gerencia o roteamento de tráfego de solicitações recebidas para as células.
• As próprias células, que são unidades independentes com limites isolados para evitar impacto em todo o sistema.

Usamos as práticas recomendadas do Guidance for Cell-based Architecture on AWS para implementação de nossas arquiteturas baseadas em células e camada de roteamento. Para minimizar o risco de falha na camada de roteamento, tornamos-na a camada mais fina e testamos a robustez para todos os cenários possíveis. Usamos uma função hash para mapear células para clientes e armazenamos o mapeamento em um armazenamento de dados altamente dimensionado e resiliente, o Amazon DynamoDB. Essa camada facilita a adição de novas células e fornece um ambiente de aplicativos em escala horizontal para lidar com o hipercrescimento de clientes ou pedidos.

Na Figura 2, revisitamos a arquitetura mencionada no Blog nº 3 da nossa série. Para gerenciar os limites de serviços da AWS e reduzir o raio de explosão, espalhamos nossos aplicativos em várias contas da AWS.

Esta é a aparência do novo design quando implementado na AWS:

A Figura 3a usa o Amazon EKS em vez do Amazon EC2 para implantar aplicativos e usa uma camada de roteamento leve para o tráfego de entrada. Uma configuração do Amazon Route 53 foi implantada em uma conta da AWS de serviços compartilhados de rede. Temos vários limites isolados em nosso design: uma zona de disponibilidade da AWS, uma região da AWS e uma conta da AWS. Isso torna a arquitetura mais resiliente e flexível no hipercrescimento.

Usamos nossas zonas de disponibilidade da AWS como limite de célula e implementamos a fragmentação aleatória para mapear clientes para várias células. Isso reduz o impacto caso uma das células caia. A fragmentação aleatória também permite que a arquitetura seja dimensionada caso tenhamos solicitações sem precedentes de um cliente.

Design baseado em células para lidar com eventos do Cisne Negro

Vamos discutir como nosso aplicativo baseado em células reagirá aos eventos do cisne negro. Primeiro, precisamos alinhar os pods em grupos de células no cluster do Amazon EKS. Agora podemos observar como cada implantação está isolada das outras implantações. Somente a camada de roteamento, que inclui Amazon Route 53, Amazon DynamoDB, roteador de célula ECS e balanceador de carga, é comum em todo o sistema.

Sem um design baseado em células, um evento cisne negro poderia derrubar nosso aplicativo no ataque inicial. Agora que nossa aplicação está espalhada por três células, o pior caso para um ataque inicial é 33% da capacidade da nossa aplicação. Agora temos limites de resiliência no nível do nó e zonas de disponibilidade.

Conclusão

Nesta postagem do blog, discutimos como a conteinerização de aplicativos pode melhorar a eficiência dos recursos e ajudar a padronizar ferramentas e processos. Isso reduz a sobrecarga de engenharia de aplicativos de escalonamento. Conversamos sobre como a adoção do design baseado em células e da fragmentação aleatória melhora ainda mais a postura de resiliência de nossos aplicativos, nossa capacidade de gerenciar falhas e lidar com eventos inesperados de grande escala.

Artigo originalmente publicado em Blog AWS

DNX Brasil – Soluções cloud-native