Arquitetura de referência do sistema SOLAR da Defensoria Pública na Nuvem AWS

Por Vanessa Fernandes, arquiteta de soluções da AWS

Visão Geral

O sistema SOLAR (Solução Avançada em Atendimento de Referência) é uma ferramenta para atendimento jurídico ao cidadão assistido pela Defensoria Pública. O sistema foi desenvolvido pela Defensoria Pública do estado do Tocantins e está em utilização em mais de quinze Defensorias estaduais. Além de oferecer módulos de agendamento, cadastro de assistidos, controle de atendimentos e suporte multidisciplinar, o SOLEAR está integrado com o SEEU (Sistema Eletrônico de Execução Unificado) e em breve estará integrado com o PROJUDI (Processo Judicial Digital).

Depois de consolidado, o sistema SOLAR foi migrado para a Nuvem AWS. Este artigo tem como objetivo apresentar as mudanças da arquitetura on-premises do sistema SOLAR para uma arquitetura Cloud, abrangendo as melhorias que essas mudanças trouxeram, bem como próximos passos.

Arquitetura On-Premises

Na arquitetura do sistema web SOLAR on-premises padrão, há três servidores: Um para o sistema SOLAR e o serviço Thoth assinador, o segundo para APIs (PROCAPI) junto com os sistema de relatórios, composto pelos serviços JASPER, CHRONUS, LIVRE. E a terceira para banco de dados contendo duas bases de dados, uma base para o sistema SOLAR e outra base para as APIs. Todos os sistemas operam em sistemas de contêineres Docker.

Em algumas defensorias é possível que haja uma quarta máquina, onde se separam os sistemas PROCAPI (máquina 1) dos sistemas Jasper, Chronus e Livre (máquina 2). Veja na figura 1 abaixo o desenho do sistema on-premises.

Figura 1: Arquitetura On-Premises

A utilização de serviços gerenciados em arquiteturas semelhantes à desse caso, é recomendada, uma vez que têm a possibilidade de aumentar a agilidade de equipes de TI, como por exemplo, das defensorias.

Um outro ponto importante é pensar no uso de múltiplas Zonas de Disponibilidade (Multi-AZ), que podem trazer vários benefícios como redundância, balanceamento de carga, alta disponibilidade.

Para entender o que são Multi-AZs, a AWS trabalha com os conceitos de região, zona de disponibilidade e pontos de presença. Onde cada região conta com 3 ou mais zonas de disponibilidade, que por sua vez possuem um ou mais datacenters físicos independentes entre si, com energia, rede e conectividade redundantes em uma região da AWS. Esses data centers ficam fisicamente distantes um do outro a fim de evitar que desastres naturais possam afetá-los simultaneamente, e perto o suficiente a fim de manter a latência baixa entre eles. Todas as AZs em uma região da AWS estão interconectadas por redes de alta largura de banda e baixa latência, usando fibras metropolitanas dedicadas e totalmente redundantes, sendo que todo o tráfego entre as AZs é criptografado. Já os pontos de presença são o nosso serviço Amazon CloudFront, uma rede de entrega de conteúdo (CDN) criado para alta performance, segurança e conveniência do desenvolvedor.

Para aproveitar as vantagens trazidas pelas Zonas de Disponibilidade, a arquitetura do SOLAR foi dividida em 2 AZs. Cada AZ possui uma rede pública e uma rede privada. Na rede pública estará o Application Load Balancer, que opera no nível da aplicação (camada 7 do modelo OSI), roteando o tráfego para os destinos (instâncias EC2, contêineres, endereços IP e funções Lambda) com base nas especificações da solicitação. Na rede privada de uma AZ se encontram os workloads em EC2 contendo os containers docker das aplicações e o banco de dados Aurora primário. Na segunda AZ encontra-se a réplica das bases de dados do Aurora. Devido ao RTO e RPO da primeira Defensoria migrada, não houve necessidade de implantação dos workloads em duas AZs, apenas o banco de dados.

Após a migração do mesmo temos a seguinte arquitetura:

Figura 2: Arquitetura atual na AWS

Para resolução de nomes é utilizado o Amazon Route53, um serviço da Web de Sistema de Nomes de Domínio (DNS) altamente disponível e escalável. O Route 53 conecta as requisições do usuário a aplicações da Internet executadas na AWS ou on-premises.

Para proteção de entrada na arquitetura on-premises havia um firewall. Na nuvem AWS temos os bloqueios via Grupos de Segurança permitindo a entrada e saída das portas estritamente necessárias. Também há o WAF/Shield que protege em uma camada antes da rede pública do sistema SOLAR. O AWS Shield é o serviço de proteção a ataque de DDoS (negação de serviço distribuído) e o AWS WAF, que protege o Application Load Balance (ALB) contra ataques WEB.  O ALB tem a função de receber e distribuir as requisições para o sistema SOLAR, que é executado em conteiner docker dentro das máquinas virtuais Amazon EC2. O Amazon Elastic Compute Cloud (Amazon EC2) oferece a plataforma de computação mais ampla e aprofundada, com mais de 600 configurações de máquinas (processador, armazenamento, rede, sistema operacional)

Há ainda o uso de um NAT gateway, que é um serviço de conversão de endereços de rede, usado para que as instâncias em uma sub-rede privada possam se conectar a serviços fora da VPC, para fazer updates de pacotes, por exemplo, mas os serviços externos não podem iniciar uma conexão com essas instâncias.

Evoluções Trazidas pela Nuvem ao sistema SOLAR das Defensorias Públicas

Em algumas defensorias, há um datacenter para hospedagem dos sistemas com redundância em nível de equipamentos de rede, servidores, acesso à Internet e armazenamento de dados, porém um datacenter único é um ponto de falha em caso de indisponibilidade. Além disso, há uma burocracia para compra de equipamentos para hospedar novos serviços ou aumentar a capacidade dos existentes.

Com a migração pra nuvem, o sistema SOLAR pode se beneficiar do uso de multi-AZ, não dependendo mais de um único datacenter ou localidade, permitindo também o balanceamento de carga entre as AZs. Além da melhoria física, há mais agilidade na forma de contratação da nuvem em comparação ao on-premises, podendo criar novas máquinas virtuais, banco de dados e outros serviços pertinentes em questão de minutos com o mínimo de esforço através de uma interface de web simples. No caso das máquinas virtuais Amazon EC2, é possível que você dimensione a capacidade rapidamente para mais e para menos, à medida que seus requisitos de computação mudarem. O Amazon EC2 muda os fatores econômicos da computação, permitindo que você pague somente pela capacidade que realmente usa, diferentemente de um datacenter on-premises, onde a compra é feita com capacidade provisionada, podendo muitas vezes tê-la ociosa ou necessitar de capacidade extra, deixando o sistema fora do ar.

A segurança também foi aumentada usando os serviços AWS Shield, AWS WAF conforme mencionado anteriormente.

Outra melhoria são os serviços gerenciados de banco de dados, o Amazon Aurora configurados como Multi-AZ, onde a base de dados réplica torna-se automaticamente a base primária em caso de falha da instância principal. Por ser um serviço gerenciado, as tarefas como administração do sistema operacional, failover automático, manutenção de rotina, passam a ser de responsabilidade da AWS, diminuindo bastante a complexidade de operação do serviço.

Próximas Melhorias

Com o sistema SOLAR consolidado na nuvem AWS, pela primeira defensoria, há alguns pontos de melhoria identificados. Podemos pensar em usar mais serviços como o Amazon Elastic Container Service (Amazon ECS) que é um serviço de orquestração de contêineres totalmente gerenciado que simplifica a implantação, o gerenciamento e a escalabilidade de aplicações conteinerizadas, já que esta aplicação roda toda em docker.

Também é interessante pensar em usar o AWS Auto Scaling, que ajuda a garantir que você tenha o número correto, por exemplo, de instâncias do Amazon EC2 ou containers do Amazon ECS disponíveis para processar a carga da sua aplicação.  O AWS Auto Scaling monitora os aplicativos e ajusta automaticamente a capacidade para manter um desempenho constante e previsível pelo menor custo possível.

Outra melhoria a se pensar é o uso do Amazon EFS, para armazenamento de arquivos sem servidor e totalmente elástico, permitindo o compartilhamento em MultiAZ pelas instâncias EC2 ou Containers do ECS com durabilidade de 99,999999999% (11 9s) e até 99,99% (4 9s) de disponibilidade. Pois atualmente eles utilizam apenas os discos Amazon EBS, um serviço de armazenamento em blocos projetados para uso das máquinas Amazon EC2. Apesar de os dados armazenados em um volume do Amazon EBS poderem persistir independentemente da duração da instância eles não podem ser compartilhados com várias instâncias EC2 nem usados em estratégias muiti-AZ como o Amazon EFS.

Aumentando a Segurança

Outras evoluções em relação à segurança é a integração do sistema SOLAR como o AWS Directory Service.

permitindo desta forma um login único através do serviço de integração Amazon Cognito, visto que o sistema SOLAR possui acesso apenas pelos colaboradores de cada Defensoria Pública. Exemplos de integração neste blog e neste blog.

Para proteger as credenciais do banco de dados em um cofre de senhas ao invés de deixá-la explícita em um arquivo de configuração de conexão, recomenda-se o uso do AWS Secrets Manager que ajuda você a gerenciar, recuperar e alternar credenciais de banco de dados, chaves de API e outros segredos ao longo de seus ciclos de vida.

Também podemos eliminar a necessidade de portas ssh ou rdp abertas para conexão via bastian host, utilizando o serviço AWS Systems Manager Session Manager em caso de EC2 ou AWS Systems Manager em caso de conteiners ECS, ou ainda autenticando com o Active Directory através de login único usando o IAM Identity Center (sucessor do AWS Single Sign-On), um serviço que ajuda a gerenciar de maneira centralizada o acesso dos funcionários à várias contas e aplicações da AWS. Passo a passo de como implementar essa última solução neste blog.

E para proteger a comunicação em trânsito a AWS fornece criptografia através do serviço AWS Certificate Manager (ACM), que lida com a complexidade de criar, armazenar e renovar chaves e certificados X.509 SSL/TLS públicos e privados, e chaves que protegem seus sites e aplicações da AWS. Você pode fornecer certificados para o seus serviços integrados da AWS emitindo-os diretamente com o ACM ou importando certificados de terceiros para o sistema de gerenciamento do ACM.

E por fim, devemos manter em dia os backups, podendo utilizar o serviço AWS Backup, que é  totalmente gerenciado, econômico e baseado em políticas que simplificam a proteção de dados em escala.

A nova arquitetura proposta ficaria assim:

Figura 3: Arquitetura com melhorias na AWS

Outras evoluções a se pensar é em criar um Pipeline de CI/CD, visto que o código das aplicações encontram-se no GitHub, isso aumentaria a velocidade das entregas, automatizando testes e tarefas operacionais, facilitando também o rollback em caso de deploy mal sucedido.

Migração

A estratégia de migração escolhida pela primeira defensoria para migrar o sistema SOLAR para a AWS foi a Re-host (Lift and shift) na qual se move a aplicação sem mudanças (conforme desenho da Figura 2: Arquitetura atual na AWS), e para isso podemos fazer o uso da ferramenta AWS Application Migration Service (AWS MGN) para automatizar a cópia e transferência das máquinas que hospedam os sistemas, acelerando o processo e evitando erros humanos. O passo a passo você pode assistir neste video.

Outra opção de migração que poderia ter sido feita seria a Re-platform (Lift, Tinker and Shift), conforme desenho da Figura 3: Arquitetura com melhorias na AWS, quando se pensa em modernizar ao migrar, sendo possível realizar algumas otimizações de Nuvem para obter os benefícios descritos na Arquitetura de Referência da Figura 3.

Para isso você deve subir sua imagem docker que está rodando em seu ambiente on-premises para o repositório privado Amazon Elastic Container Registry (Amazon ECR), um serviço de registro de contêiner totalmente gerenciado que oferece hospedagem de alta performance para que você possa implantar imagens e artefatos de aplicações de forma confiável em qualquer lugar, ou outro repositório de imagens de conteiners de sua preferência. Passo a passo neste vídeo.

Em seguida você deverá criar seu cluster no Amazon ECS e baixar a imagem recém carregada, passo a passo neste video (43:42)

Em relação a migração de dados, na AWS  há algumas opções de serviços para simplificar e otimizar essas tarefas quando falamos de Servidor de Arquivos (NFS) ou Banco de Dados:

1. AWS DataSyncé um serviço online seguro que automatiza e acelera a movimentação de dados entre serviços de armazenamento on-premises e da AWS. O DataSync pode copiar dados entre compartilhamentos do Network File System (NFS), Server Message Block (SMB), buckets do Amazon Simple Storage Service (Amazon S3), sistemas de arquivos do Amazon Elastic File System (Amazon EFS), entre outros. Com o AWS DataSync  é possível realizar a comparação entre um sistema de arquivos on-premises com outro na AWS e replicar apenas as diferenças desde a última sincronização.
2. AWS Database Migration Service (AWS DMS)é um serviço de replicação e migração gerenciado que ajuda a mover workloads analíticos e bancos de dados para a AWS rapidamente, de forma segura e com o mínimo possível de inatividade e zero perda de dados. . O AWS DMS pode migrar dados de/para a maioria dos bancos de dados comerciais e de código aberto mais usados. O AWS DMS viabiliza migrações homogêneas, como de Oracle para Oracle, além de migrações heterogêneas entre plataformas de banco de dados diferentes, como de Oracle ou de Microsoft SQL Server para Amazon Aurora. Com o AWS DMS também é possível usar o mecanismo de CDC (Change Data Capture), utilizado para capturar mudanças no log de transações das bases de dados e aplicá-las em uma base de dados destino.

Ou seja, ao utilizarmos estes dois serviços é possível realizar tanto uma carga inicial dos dados quanto uma a replicação contínua/diferencial, permitindo assim que a virada para a Nuvem AWS tenha o mínimo de indisponibilidade.

Conclusão

Neste blog falamos sobre a Arquitetura do sistema SOLAR na Nuvem AWS, a partir da migração da primeira Defensoria. Também abordamos possíveis melhorias no sistema baseado nas melhores práticas do AWS Well-Architected Framework, apresentando evoluções em relação a Segurança, Excelência Operacional, Resiliência, Confiabilidade e Eficiência de Custos, na qual são chamados de pilares e fazem parte deste framework.

Abordamos ainda formas de migrar do on-premises para AWS adotando uma estratégia Re-Host ou Re-platform e sugerimos o uso de um Pipeline CI/CD para agilizar o deploy da aplicação.

Outras evoluções poderão ser desenvolvidas e aplicadas, como o uso de Machine Learning, automações, observabilidade, respostas à incidentes, entre muitos outros, trazendo ainda mais benefícios para as Defensorias, seus times técnicos e os cidadãos que necessitam do serviço.

Sobre a autora

Vanessa Rodrigues Fernandes é Arquiteta de soluções do setor público na AWS. Com formação técnica em Redes de Computadores pela Universidade Federal do Rio Grande do Sul, graduação em Segurança da Informação pela Universidade do Vale do Rio dos Sinos (RS) e Pós Graduação em Gestão Estratégica em TI pela PUCRS. Com mais de 20 anos de experiência na área de infraestrutura, redes, segurança da informação, trabalhou em diferentes nichos de mercado, ajudando empresas a suportar e construir soluções tecnológicas e estratégicas para seus negócios. É apaixonada por tecnologia e segurança da informação.