Este artigo resume o processo e os componentes que a equipe de CSE (Engenharia de Software Comercial) da Microsoft usou para criar uma solução para um cliente de serviços bancários. Para fins de anonimato, o artigo se refere ao cliente como o Contoso Bank. Ele é uma importante organização internacional de FSI (Setor de Serviços Financeiros) que desejava modernizar um dos seus sistemas de transações financeiras.
Arquitetura
Baixe um Arquivo Visio dessa arquitetura.
Três blocos principais compõem a solução: serviços de back-end, teste de carga e monitoramento com o Dimensionador Automático de Eventos.
Os contêineres reais de microsserviços da Contoso foram manualmente enviados por push por meio do Docker para o cluster de Kubernetes. Esse cluster era:
ARO (Red Hat OpenShift no Azure) no Kubernetes/HPA (Dimensionador Automático de Pod Horizontal) do OpenShift para:
Titular do Canal.
Escalabilidade e desempenho para entregas de simulação de transação.
Serviço de Kubernetes do Azure (AKS) do agendador automático de nó para o Titular do Canal.
A equipe de CSE criou os outros microsserviços como stubs para isolar especificamente os microsserviços reais da Contoso de outros serviços externos de mainframe que a solução enviou por meio dos Azure Pipelines.
Workflow
No núcleo, os serviços de back-end fornecem a lógica necessária para que uma TED ocorra:
Uma nova TEF começa com uma solicitação HTTP recebida pelo serviço Titular do Canal.
O serviço fornece respostas síncronas para os solicitantes usando um padrão de publicação-assinatura por meio de um Cache do Azure para Redis e aguarda uma resposta de back-end.
A solução valida essa solicitação inicial usando o serviço Senha do Piloto de TEF.
Além de realizar validações, o serviço enriquece os dados. O enriquecimento de dados ajuda o back-end a decidir se a solução deve usar um sistema de microsserviço herdado ou um novo para processar a TEF.
Em seguida, o serviço Titular do Canal inicia o fluxo assíncrono.
O serviço chama o Controlador de TEF, que é um orquestrador reativo que coordena um fluxo de transações. Ele faz isso produzindo comandos e consumindo eventos de outros microsserviços por meio dos Hubs de Eventos do Azure/do Kafka.
Um desses serviços é o Processador de TEF, em que a solução efetua a transação real, realizando operações de crédito e débito.
A equipe do CSE usou o Kubernetes Event-driven Autoscaling (KEDA). Ele é uma estrutura que escala automaticamente os aplicativos com base na carga de mensagens processadas pela solução. Na solução, ele foi usado para escalar o Processador de TEF à medida que a solução processava novas TEFs.
O KEDA tem suporte no AKS e nos Aplicativos de Contêiner do Azure
A seguir, ocorre o teste de carga. O Teste de Carga do Azure é um serviço de teste de carga totalmente gerenciado que permite gerar cargas de alta escala. O serviço simula o tráfego para seus aplicativos sem a necessidade de implantar recursos adicionais. O Teste de Carga do Azure também vem com a capacidade de pegar um script Apache JMeter existente e usá-lo para executar um teste de carga.
Por fim, o monitoramento foi responsável por integrar os resultados do teste de carga, a infraestrutura e as métricas do aplicativo.
A equipe correlacionou um teste de carga executado com os efeitos colaterais causados pelos microsserviços na camada de orquestração do armazenamento e do contêiner. Isso permitiu um rápido ciclo de comentários para o ajuste do aplicativo. O Prometheus, o Grafana e o Application Insights no Azure Monitor foram os componentes principais que permitiram essa capacidade de monitoramento e observabilidade. O Dimensionador Automático de Evento deu suporte à validação de um cenário em que os aplicativos são escalados de acordo com a carga de mensagens recebida. Para implementar esse comportamento, a equipe de CSE adaptou o KEDA para dar suporte à escala de aplicativos Java.
Funcionalidades da solução
A solução envolve três funcionalidades principais:
Dimensionador Automático de Pod Horizontal para o Titular do Canal
Dimensionamento automático de nó para o Titular do Canal
Escalabilidade e desempenho para entregas de simulação de transação
Dimensionador Automático de Pod Horizontal para o Titular do Canal
Nesta solução, a equipe usou um mecanismo do Kubernetes/do HPA do OpenShift. O HPA escala automaticamente o número de pods de acordo com uma métrica selecionada. Isso fornece um mecanismo eficiente de redução horizontal e expansão para os contêineres. Devido à natureza associada à CPU da API REST do Titular do Canal, a equipe optou por usar o HPA com a CPU de modo que as réplicas de serviço possam crescer à medida que novas TEFs ocorram.
Esse componente executa um serviço chamado Titular do Canal no Red Hat OpenShift no Azure. Ele realiza testes de dimensionamento automático do pod nesse serviço. O componente precisava obter as seguintes funcionalidades:
Fornecer um pipeline de DevOps do local para o Azure para o serviço Titular do Canal.
Fornecer o monitoramento de cluster do OpenShift por meio de um painel do Grafana.
Executar testes de Dimensionamento Automático de Pod Horizontal para o serviço Titular do Canal.
Fornecer a observabilidade no Titular do Canal ativando a captura de métricas (por exemplo, uso) com o Prometheus e o Grafana.
Fornecer um relatório detalhado sobre os testes executados, o comportamento dos aplicativos e as estratégias de particionamento do Kafka, se houver.
Dimensionamento automático de nó para o Titular do Canal
Primeiro, o HPA escala as réplicas até um ponto em que ela satura a infraestrutura de cluster. Em seguida, um mecanismo de redução e expansão para os nós mantém os aplicativos recebendo e processando novas solicitações. Para esse mecanismo, a equipe usou o dimensionamento automático de nó do Kubernetes, que permitiu que o cluster crescesse mesmo quando todos os nós estivessem perto da capacidade total.
Esse componente se concentra na execução do serviço Titular do Canal no AKS para permitir testes de dimensionamento automático de nó. Ele precisava obter as seguintes funcionalidades:
Fornecer o monitoramento de cluster do AKS por meio de um painel do Grafana.
Executar testes de dimensionamento automático de nó para o serviço Titular do Canal.
Fornecer a observabilidade no Titular do Canal ativando a captura de métricas com o Prometheus e o Grafana.
Fornecer um relatório detalhado sobre os testes executados, o comportamento dos aplicativos e as estratégias de particionamento do Kafka, se houver.
Escalabilidade e desempenho para entregas de simulação de transação
Usando a estrutura de teste de carga, a equipe de CSE gerou uma carga suficiente para disparar os mecanismos de dimensionamento automático do HPA e de nó. Quando a solução disparou os componentes, ela gerou métricas de infraestrutura e de aplicativo para a equipe validar os tempos de resposta de escala do Titular do Canal e o comportamento do aplicativo sob alta carga.
Esse componente se concentra na execução dos serviços Titular do Canal, Controlador de TEF e Processador de TEF no ARO e no AKS. Além disso, ele realiza os testes de dimensionamento automático de pod e de nó e de desempenho em todos os serviços. Ele precisava obter as seguintes funcionalidades:
Executar testes de desempenho nos microsserviços até atingir ou ultrapassar 2 mil transações por segundo.
Executar testes de dimensionamento automático de nó/pod horizontal nos microsserviços.
Fornecer a observabilidade no Titular do Canal ativando a captura de métricas com o Prometheus e o Grafana.
Fornecer um relatório detalhado sobre os testes executados, o comportamento dos aplicativos e as estratégias de particionamento do Kafka adotadas.
Componentes
A lista abaixo resume as tecnologias usadas pela equipe de CSE para criar essa solução:
Azure
Terceiros
Serviços de back-end do Contoso Bank
Software livre
Detalhes do cenário
O Contoso Bank é uma importante organização internacional de FSI (Setor de Serviços Financeiros) que desejava modernizar um dos seus sistemas de transações financeiras.
O Contoso Bank queria usar aplicativos simulados e reais e cargas de trabalho existentes para monitorar a reação da infraestrutura da solução quanto à escalabilidade e ao desempenho. A solução precisava ser compatível com os requisitos existentes do sistema de pagamento.
Possíveis casos de uso
O Contoso Bank queria usar um conjunto de simulações para:
Determinar o impacto da escalabilidade da infraestrutura.
Determinar a reação a falhas no design de arquitetura existente de um software de mainframe específico.
A solução proposta usaria um aplicativo virtual para simular cenários funcionais. A finalidade dela seria monitorar o desempenho e a escalabilidade da infraestrutura. O objetivo era determinar o impacto das falhas nas cargas de trabalho do sistema de TEF (Transferência Eletrônica de Fundos) do mainframe por meio desse conjunto de simulações.
Também havia um requisito para propor uma transição estável de DevOps do local para a nuvem. A transição precisava incluir o processo e a metodologia do banco e usar as ferramentas existentes do Contoso Bank. O uso das tecnologias existentes reduziria o impacto de aquisição de novas habilidades para os desenvolvedores. A transição ajudaria o Contoso Bank a revisar as decisões atuais e futuras de design. A transição também forneceria confiança de que o Azure é um ambiente robusto o suficiente para hospedar os novos sistemas distribuídos.
Considerações
Critérios de êxito
A equipe da Contoso e a equipe de CSE definiram os seguintes critérios de sucesso para este compromisso:
Critérios gerais
O Contoso Bank considerou os seguintes pontos gerais como critérios bem-sucedidos em todos os componentes:
Fornecer à equipe técnica da Contoso a capacidade de aplicar a transformação digital e a adoção da nuvem. A equipe de CSE:
Forneceu as ferramentas e os processos necessários no Azure.
Demonstrou como a equipe técnica da Contoso pode continuar usando as ferramentas existentes.
Cada componente é fornecido com um documento que abrange:
Resultados do testes de desempenho e escalabilidade.
Parâmetros e métricas considerados em cada teste.
Qualquer alteração de código ou infraestrutura, se necessário, durante cada teste.
Lições aprendidas sobre ajustes de desempenho e parâmetros considerados para cada teste.
Lições aprendidas e diretrizes sobre estratégias de particionamento do Kafka.
Recomendações/diretrizes gerais de arquitetura com base nos aprendizados sobre as entregas.
Critérios de entrega
| Metric | Valor (intervalo) |
|---|---|
| Capacidade de executar testes de dimensionamento automático de pod no Titular do Canal | Meta: o sistema cria automaticamente uma réplica de pod do Titular do Canal depois de atingir 50% de uso da CPU. |
| Capacidade de executar o dimensionamento automático de nó com base no Titular do Canal | Meta: o sistema cria nós do Kubernetes devido a restrições de recursos em pods (por exemplo, uso da CPU). O Kubernetes restringe o número de nós que o sistema pode criar. O limite é de três nós. |
| Capacidade de executar testes de desempenho e de dimensionamento automático de pod/nó na simulação de TEF | Meta: o sistema cria automaticamente réplicas de pod para todos os serviços. A replicação ocorre depois de atingir 50% de uso da CPU e da criação de um nó do Kubernetes relacionado a restrições de recursos da CPU. A solução precisa dar suporte a 2 mil transações por segundo. |
Solução técnica
A solução fornecida pela equipe incluiu preocupações abrangentes e implementações específicas para atingir as metas de entrega. Ela também precisava respeitar algumas restrições de design de acordo com as políticas do Contoso Bank.
Vale a pena observar que, devido a uma restrição de recurso no Red Hat OpenShift no Azure 3.11, a Contoso solicitou o uso do Serviço de Kubernetes do Azure para testar cenários de dimensionamento automático de nó.
Havia várias restrições de design que a equipe de CSE precisava considerar:
Devido aos requisitos internos, o Contoso Bank solicitou o uso das seguintes tecnologias:
OpenShift 3.11 como a plataforma de orquestração de contêiner.
Java e Spring Boot para o desenvolvimento de microsserviço.
Kafka como a plataforma de streaming de eventos com o recurso Registro de Esquema do Confluent.
A solução precisava ser independente de nuvem.
As ferramentas de DevOps e de monitoramento precisavam ser as mesmas que a Contoso já havia usado no ambiente de desenvolvimento local.
A solução não podia compartilhar o código-fonte que a Contoso hospeda no ambiente local para ambientes externos. A política da Contoso só permite mover imagens de contêiner do local para o Azure.
Ela restringe a capacidade de um pipeline de CI (integração contínua) funcionar entre ambientes locais e qualquer nuvem. A Contoso implantou manualmente todo o código-fonte hospedado no ambiente local, como imagens de contêiner, no Registro de Contêiner do Azure. A implantação no lado local era responsabilidade da Contoso.
O cenário simulado para testes precisava usar um subconjunto de cargas de trabalho de TEF de mainframe como uma referência de fluxo.
O Contoso Bank precisava fazer todos os testes de HPA e de desempenho no ARO.
Preocupações abrangentes da solução
Streaming de mensagens
A equipe de CSE decidiu usar o Apache Kafka como a plataforma de streaming de mensagens distribuídas para microsserviços. Para aprimorar a escalabilidade, a equipe pensou em usar um grupo de consumidores por microsserviço. Nessa configuração, cada instância de microsserviço é uma unidade de escala para dividir e paralelizar o processamento de eventos.
Ela usou uma fórmula para calcular o número ideal estimado de partições por tópico para dar suporte à taxa de transferência estimada. Para obter mais informações sobre a fórmula, confira Como escolher o número de tópicos ou de partições em um cluster do Kafka.
Velocidade de CI/CD
Para o DevOps, o Contoso Bank já usou uma instância local do GitLab para o repositório de códigos. Ele criou pipelines de CI/CD (integração contínua/entrega contínua) para ambientes de desenvolvimento usando uma solução personalizada baseada no Jenkins desenvolvida internamente. Ele não estava fornecendo uma experiência de DevOps ideal.
Para fornecer uma experiência de DevOps aprimorada para a Contoso, a equipe de CSE usou o Azure Pipelines no Azure DevOps para gerenciar o ciclo de vida do aplicativo. O pipeline de CI é executado em cada solicitação de pull, enquanto o pipeline de CD é executado em cada mesclagem bem-sucedida com a ramificação principal. Cada membro da equipe de desenvolvimento era responsável por gerenciar os repositórios e os pipelines de cada serviço. Ele também precisava impor revisões de código, testes de unidade e lint (análise de código-fonte estático).
A equipe de CSE implantou serviços simultaneamente sem interdependência e usou agentes do Jenkins, conforme solicitado pelo Contoso Bank.
Ela incorporou o Prometheus como parte da solução para monitorar os serviços e o cluster. Além de gerar dados significativos para a solução, o Contoso Bank pode usar o Prometheus no futuro para aprimorar os produtos de acordo com o uso diário. Um painel do Grafana exibe essas métricas.
Estratégia de distribuição
A equipe distribuiu a solução para o ambiente de desenvolvimento por meio do Azure Pipelines. Cada serviço tinha um pipeline de build e implantação próprio. Ela usou um pipeline de implantação que pode ser disparado manualmente. Isso deve forçar uma implantação completa do ambiente e dos contêineres em uma versão de branch específica.
A equipe de CSE criou branches de lançamento que geraram versões estáveis para a implantação. A mesclagem de branches na ramificação principal ocorre apenas quando a equipe tem certeza de que está pronta para implantar a solução. Uma estratégia de reversão, além da implantação da versão estável anterior, estava fora do escopo nesse compromisso. Há portões de aprovação para cada fase. Cada portão solicita a aprovação da implantação.
Recuperação de desastre
A solução usa scripts do Terraform e o Azure Pipelines para todos os serviços. Se ocorrer um desastre, o Contoso Bank poderá recriar todo o ambiente usando scripts do Terraform ou executando o pipeline de lançamento novamente. O Terraform entende que o ambiente foi alterado e o recria. A solução provisiona e destrói dinamicamente a infraestrutura no Azure conforme necessário. As contas de armazenamento são ZRS (armazenamento com redundância de zona). Uma estratégia de backup estava fora do escopo nesse compromisso.
Segurança e privacidade
Um registro privado (Registro de Contêiner do Azure) armazenou todas as imagens de contêiner.
A solução usa segredos do ARO e do AKS para injetar dados confidenciais em pods, como cadeias de conexão e chaves.
O acesso ao servidor de API do Kubernetes requer autenticação por meio do Microsoft Entra ID para ARO e AKS.
O acesso ao Jenkins requer autenticação por meio do Microsoft Entra ID.
Conclusões
No final do projeto, a equipe de CSE compartilhou os seguintes insights:
Resultado da solução e do compromisso
A equipe observou um alto nível de compatibilidade entre o AKS e o ARO para a implantação de serviços.
O Application Insights sem código facilita a criação da observabilidade, colaborando com a adoção da nuvem em migrações de lift-and-shift.
O teste de carga é uma parte importante das soluções em larga escala pretendidas e exige análise e planejamento anteriores para considerar as especificidades do microsserviço.
O potencial do teste de carga para encontrar os efeitos colaterais dos microsserviços é frequentemente subestimado pelos clientes.
A criação de um ambiente de teste pode exigir uma estratégia de descarte de infraestrutura para evitar custos de infraestrutura desnecessários.
Principais aprendizados
Há uma migração estável do aplicativo do ARO para o AKS.
O recurso de dimensionamento automático de nó não estava disponível no Red Hat OpenShift versão 3.11, que era a versão usada durante o compromisso. Dessa forma, a equipe de CSE conduziu os cenários de teste de dimensionamento automático de nó por meio do AKS.
O fim da vida útil de um produto pode exigir personalizações criativas. Uma fase de preparação exerce um papel importante quando a equipe entrega uma solução bem-sucedida.
Na criação deste artigo, a equipe do CSE criou uma solução de teste de carga integrando Instâncias de Contêiner e JMeter em um Pipeline do Azure DevOps. Desde então, o Teste de Carga do Azure foi disponibilizado como um serviço de teste de carga totalmente gerenciado sem a necessidade de implantar recursos de computação adicionais.
A equipe recomendou o uso dos hubs de eventos do Azure para Kafka, mas para o Contoso Bank, o registro de esquema era um recurso importante. Para cumprir o prazo solicitado pelo Contoso Bank, a equipe precisou considerar o uso do registro de esquema em outra instância do AKS.
O protocolo do Kafka com o registro de esquema não era compatível com o Dimensionador dos Hubs de Eventos no KEDA.
Próximas etapas
Dimensionamento automático de aplicativos Java com o KEDA usando os Hubs de Eventos do Azure: exemplo do KEDA para Java
Padrão: Saga: informações sobre o padrão Saga em Microservices.io
Recursos relacionados
Para obter mais detalhes sobre os processos e as tecnologias usadas para criar essa solução, confira os seguintes artigos: