Dicas e melhores práticas para migrar uma arquitetura on-premises com HAProxy para AWS usando o Application Load Balancer

Por Allyson Oliveira, Arquiteto de Soluções na AWS;

Uanderson Sigler Gomes, Analista Judiciário do TRT da 17ª Região e;

Eduardo Arruda Pimentel Técnico Judiciário no TRT da 17ª Região. 

Visão Geral

A arquitetura PJe é uma arquitetura robusta, utilizada há alguns anos por todos os Tribunais pertencentes à Justiça do Trabalho. Tal arquitetura é embasada em tecnologias livres e está bem consolidada devido à intensa utilização do sistema em todo o território nacional.  Quer saber mais sobre o PJe? Leia o primeiro artigo clicando nesse link.

Neste artigo sobre o PJe da Justiça do Trabalho na Nuvem AWS, falaremos sobre uma mudança que viabilizou realizar a migração sem afetar o fluxo padrão de requisições HTTP recebidas pela aplicação.

Tal mudança permitiu manter a compatibilidade da aplicação do PJe com o ambiente on premise, sem que seja feita nenhuma mudança drástica na arquitetura e nos componentes.  Além disso, a mudança permite a portabilidade da aplicação para diversos ambientes, desde que mantida a utilização do Kubernetes com o proxy reverso Haproxy.

Metallb e Haproxy

Seguindo um padrão largamente utilizado no mercado para uma aplicação hospedada em Kubernetes, o PJe On Premise utiliza o Haproxy e o Metallb.  O Haproxy é um elemento importante na arquitetura, pois além de possuir funções de ingress controller, possui configurações das aplicações.  Apesar de outros elementos na AWS serem capazes de desempenhar suas funções, o Haproxy foi mantido para atenuar as mudanças na migração On Premise para a Nuvem.

O Metallb é o load balancer de código aberto comumente utilizado em implementações. de cluster Kubernetes em ambientes bare metals e também utilizado no PJe On Premise.  Para desempenhar suas funções, ele necessita de utilizar o protocolo ARP.  Nos principais provedores de nuvem, o ARP é emulado pela camada de rede virtual, o que significa que apenas os IPs atribuídos às VMs pela plataforma em nuvem podem ser resolvidos.  Isso quebra o modo L2 do MetalLB, que depende do comportamento do ARP em redes Ethernet normais. Diante disso, no próprio site do Metallb o seu uso é desencorajado na nuvem: https://metallb.universe.tf/installation/clouds/.

O diagrama , abaixo apresenta a arquitetura implementada utilizando  Haproxy e Metallb do PJe On Premise:

No Cluster Kubernetes On Premise, em cada node há um speaker do Metallb, o qual é responsável por publicar para as redes externas ao cluster os endereços IPs utilizados pelas aplicações.  A publicação é feita através do protocolo ARP, em layer 2.

O endereço IP publicado pertence a um service no cluster Kubernetes, o qual é o load balancer para os pods do Haproxy. Este IP é o IP externo para o service.  Também é importante mencionar o Ingress Controller do Haproxy.  Ele é o elemento responsável por direcionar as requisições HTTP para o service do Haproxy.

A figura a seguir representa com mais detalhes a configuração:

Por sua vez, os pods do Haproxy atuam como proxy reverso do sistema PJe.  Nele são realizadas algumas funções, como cache e roteamento de requisições HTTP para os pods do PJe, sem alterar o funcionamento padrão da aplicação. Como já mencionado, no ambiente on premise, o Load Balancer utilizado pelo PJe é o Metallb.

A imagem abaixo consiste em exemplo de um arquivo de configuração de um service do tipo Load Balancer:

apiVersion: v1
kind: Service
metadata:  
  name: load-balancer-service
  labels:
    app: haproxy
    tier: frontend
spec:
  selector:
    run: haproxy
  type: LoadBalancer
  ports:  
  - name: http
    port: 80
    targetPort: 80
    protocol: TCP

AWS Application Load Balancer e Haproxy

Para preservar o padrão de requisições do PJe e migrá-lo para a nuvem sem o uso do protocolo ARP através do Metallb, foi necessário repensar a interação da arquitetura com o ambiente externo ao cluster Kubernetes.  Observando que, o cluster Kubernetes é o AWS EKS, a arquitetura proposta foi a seguinte:

A arquitetura, foi distribuída em 3 zonas de disponibilidade (AZs), com o objetivo de tornar a arquitetura mais resiliente a falhas.  O AWS Application Load Balancer passou a receber as requisições do PJe.  Na figura acima, o ALB EXT é um Application Load Balancer exposto para Internet (Scheme Internet Facing) e está representado nas 3 AZs no desenho acima apenas para facilitar o entendimento, mas é apenas um serviço rodando em todas as AZs e distribuindo a carga entre todas essas AZ’s.  Ele recebe as requisições que chegam da Internet.  O ALB INT é um Application Load Balancer com Schema Internal e recebe as requisições internas.  O ALB INT também está representado nas 3 AZs, mas também é apenas um serviço e lembrando que a carga é distribuída entre todas as Zonas de Disponibilidades disponíveis.

Nas regras de listeners dos ALBs estão configurados target groups que são compostos pelos nodes EKS, nos quais são executados os services do Haproxy.   Sem o Metallb como Load Balancer, o service do Haproxy foi configurado com o type NodePort.  Nessa configuração, cada node EKS que executa esse service apresenta a porta HTTPS configurada no NodePort.  É através dessa porta que o ALB envia as requisições para o service do Haproxy e este as encaminha para os respectivos pods.

A figura a seguir detalha um pouco mais essa comunicação:

Por sua vez, temos um exemplo de um arquivo de configuração de um service com type NodePort, utilizando a porta 40010 mencionada na figura acima:

apiVersion: v1
kind: Service
metadata:
  name: load-balancer-service
  labels:
    app: haproxy
spec:
  type: NodePort
  selector:
    run: haproxy
  ports:
    - port: 443
      name: https
      targetPort: 443
      nodePort: 40010

O uso do AWS Application Load Balancer trouxe duas grandes melhorias na segurança.  A primeira foi o uso do AWS Web Application Firewall(WAF) com o AWS Shield para proteger o ambiente de diversos ataques DDoS e HTTP.  A segunda grande melhoria é impedir que as conexões sejam fechadas diretamente com o Haproxy.  Nessa nova configuração, o ALB recebe as conexões e abre uma nova com o Haproxy.  Isso reduz o consumo dos recursos de infraestrutura, tendo em vista que somente as requisições “filtradas” são entregues ao ambiente do PJe.

Conclusão

Nesse artigo trouxemos um pouco de um grande desafio enfrentado na migração para a nuvem AWS do PJe da Justiça do Trabalho.  O desafio foi aceito e uma mudança “cirúrgica” permitiu que toda a robustez da arquitetura do PJe fosse mantida.  E mais, a nova arquitetura permitiu o uso de ferramentas de segurança Shield e WAF, além de aumentar a tolerância a falhas com o uso das 3 zonas de disponibilidade.

Fiquem de olho em novos artigos, vamos falar ainda mais sobre experiências de migração, arquitetura, funcionamento, serviços e lições aprendidas do PJe na AWS.

Sobre os autores

Allyson Oliveira é arquiteto de soluções da AWS no time de Setor Público. Já liderou diversos projetos de tecnologia tanto em ambientes on-premises quanto em nuvem, com foco em modernização de aplicação com containers e segurança da informação. Atualmente, trabalha ajudando os tribunais do Brasil a migrarem a sua infraestrutura para a nuvem, seguindo as melhores práticas e de maneira segura.

Uanderson Sigler Gomes é Analista Judiciário do TRT da 17ª Região e membro do Subcomitê Nacional de Infraestrutura da Justiça do Trabalho.  Engenheiro de Computação, com MBA em Gestão de TIC, possui as três certificações AWS Associate (Solutions Architect, SysOps e Developer).  Há 18 anos atua no serviço público com foco em infraestrutura.  Atualmente, trabalha com projetos de migração para a nuvem nos Tribunais do Trabalho.

Eduardo Arruda Pimentel é Técnico Judiciário no TRT da 17ª Região e graduado em Ciência da Computação pela Universidade Federal do Espírito Santo. Possui uma década de experiência no serviço público, concentrando-se na área de Infraestrutura de TI com especial ênfase em Kubernetes e SRE. Adquiriu especialização no ambiente AWS, obtendo três certificações e atualmente desempenha um papel significativo no apoio à migração da infraestrutura para a nuvem.