Uso da AWS para executar cargas críticas no setor público: Consulta dos resultados das eleições nacionais ou estaduais.

Eduardo Patino, arquiteto de soluções para o setor público na AWS

A Amazon Web Services (AWS) tem milhões de clientes ativos por mês, muitos dos quais executam aplicativos essenciais aos negócios. Entre eles, na América Latina podemos encontrar ICFES, Tecnológico de Monterrey, Rappi, Cinépolis ,Televisa, Wizeline, Enviaflores e muitos outros, que se beneficiaram de poder atender a demanda de seus clientes.

Como essas empresas e entidades, nossos clientes governamentais e educacionais exigem um aumento de escala, por exemplo, para criar e manter um portal web que um país inteiro entra para consultar os resultados das eleições presidenciais. Esse foi o caso do Instituto Nacional Eleitoral (INE) no México, que encontrou nos serviços da AWS a segurança e a força para divulgar os resultados da última eleição presidencial em 2018.

Utilizando o poder de computação do Amazon Elastic Compute Cloud, do AWS Lambda e do armazenamento de dados com o Amazon Simple Storage Service, além da segurança do AWS WAF e o AWS Shield, o INE gerenciou com sucesso uma eleição nacional garantindo agilidade no acesso aos dados, sempre tendo em mente a segurança dos dados.

Como o INE, outros clientes estão se perguntando:

A minha arquitetura na AWS está pronta para escalar e oferecer suporte a milhares ou milhões de usuários por minuto?

Embora existam vários blogs relacionados à segurança, arquiteturas com servidor ou serverless e muitas outras boas práticas, a preparação para esses tipos de eventos é primordial.

Com uma boa preparação podemos arquitetar todos os componentes envolvidos de forma antecipada e com isso garantir que os usuários finais acessem um aplicativo confiável, resiliente e tolerante à falhas e prontos para suportar até mesmo ataques distribuídos de negação de serviço (DDoS).

Durante o planejamento deste tipo de eventos, o objetivo é contemplar todos os componentes e evitar ou mitigar degradações de serviço relacionadas ao número de usuários acessando, latências no nível da rede, revisões de espaço de endereço IP, políticas de escalabilidade, revisão de limites de componentes, ter monitoramento constante de todos os componentes e logs, entre outros.

Neste post, você encontrará recomendações e diretrizes da AWS com base em nossos princípios de boas arquiteturas (link) e orientação para eventos de infraestrutura planejados (link).

O ponto zero a contemplar é a segurança. Esta é a base de uma boa arquitetura e é fundamental para que nossas arquiteturas sejam resilientes e capazes de suportar a quantidade de tráfego que esperamos. É importante estabelecer um perímetro de segurança e permitir ou negar acesso baseado em regras, quer se trate de regras de nível de rede (grupos de segurança, geolocalização etc.) ou regras de nível de aplicativo, usando um WAF (Web Application Firewall). Antes de um DDoS existem 4 práticas gerais recomendadas a serem seguidas:

1. Minimize a área de superfície de ataque e proteja recursos expostos: Isso nos permite focar nossos esforços de mitigação. Desacoplar em camadas o máximo possível. Para entender como podemos proteger os serviços que expusemos, vejamos quais recursos a AWS nos oferece:
   1. O AWS Shield, em sua versão padrão, é um serviço de proteção DDoS para aplicativos executados na AWS. Protege a camada de rede e os serviços de transporte, como o AWS Route 53 e o AWS Cloudfront. Você pode usar o AWS Shield em sua versão avançada para proteger os mesmos serviços de versão padrão e, adicionalmente, serviços como Amazon Elastic Compute Cloud (EC2), Elastic Load Balancer (ELB) e AWS Global Accelerator; ele ainda fornece acesso ininterrupto à equipe de resposta à DDoS (DRT), se a mitigação for necessária.
   2. O Amazon Route 53 é um serviço de DNS (Domain Name System) escalável e altamente disponível na nuvem. Este serviço tem um SLA 100%, além disso, tem um mínimo de TTLs de 60 segundos, entre outros recursos do serviço, por conta disso ele permitirá que você tome uma ação rápida no caso de você precisar fazer alterações de DNS antes, durante e depois do evento.
   3. O Amazon Cloudfront (Content Distribution Networks (CDN)) te ajudará a aproximar o conteúdo de seus usuários, para que seu site seja carregado mais rápido. Além disso, você pode distribuir o tráfego de entrada de um ataque para mais de 210 pontos de presença do Amazon CloudFront atualmente. Na América Latina, temos locais de fronteira na Colômbia, Chile e Argentina. O Amazon CloudFront, o AWS Shield, o AWS WAF e o Amazon Route 53 trabalham juntos para criar um perímetro de segurança flexível e em camadas contra vários tipos de ataques. Entre os quais estão ataques de nível de infra-estrutura (como UDP floods), ataques de exaustão de estado (como TCP SYN floods) e ataques de aplicativos (como HTTP GET ou POST floods). Outro recurso de segurança que o Amazon Cloudfront tem e que você pode aproveitar em tais eventos é restringir o tráfego dependendo da geolocalização do usuário e permitir o tráfego de onde você precisa ser visto. Por exemplo, se nosso evento for exclusivamente em um país e não em todo o mundo, podemos usar esse recurso para bloquear tráfego indesejado de outros países. Também é recomendável que ao configurar suas distribuições de conteúdo, você pense em alta disponibilidade usando failover de origem para ter uma origem ativa e uma origem passiva. Se houver um problema com sua infraestrutura em uma região, o Cloudfront pode redirecioná-la para uma região saudável.
2. Prepare-se para escalar. Este é um princípio de boa arquitetura, mas, por sua vez, uma técnica eficaz de mitigação de DDoS. Em relação à segurança, é necessário considerar que os ataques volumétricos procuram duas coisas: saturar a largura de banda e saturar a capacidade do servidor. Por esse motivo, para cobrir a capacidade de largura de banda, usamos o Amazon Cloudfront (que discutimos no ponto anterior). Além disso, vamos lembrar que, dependendo do tipo de instância de EC2 que você usa, ela terá desempenho de rede específico (link). Para absorver um ataque volumétrico, é importante que nossa infraestrutura possa se adaptar à quantidade de tráfego, solicitações, entre outros; para isso, é costume usar balanceadores de carga e grupos de Auto Scaling. Isso permite criar nova capacidade de computação e direcionar a carga para essa nova capacidade, a fim de evitar sobrecarregar um nó específico.
3. Saiba o que é normal e tome medidas automáticas sobre o que não é: É fundamental que você identifique o tráfego corretamente. Para portais de revisão de resultados eleitorais em um país, sabemos que esses sites têm grande exposição pública, dos meios de comunicação às mídias sociais, o que pode fazer com que o portal da web seja sobrecarregado pelo tráfego. O monitoramento constante da infraestrutura pode ajudá-lo a identificar rapidamente um ataque legítimo e envolver a AWS. Para aumentar a visibilidade dos ataques em seus recursos do Amazon EC2, CloudFront e Elastic Load Balancing, recomendamos o uso do AWS Shield Advanced, oferecendo acesso exclusivo a métricas e relatórios avançados em tempo real.
4. Arquitete de Resiliência: Conversamos sobre como o Amazon Route 53, o Amazon Cloudfront e o AWS Shield fornecem proteção nos níveis da camada 3 e da camada 4, mas para ser resiliente, é importante proteger seu aplicativo na camada 7 ou camada de aplicativo, para isto você pode utilizar o AWS WAF. Como ponto de partida, você pode usar o AWS WAF Security Automations (link); no entanto, recomendamos adicionar regras personalizadas, aplicar análise de registros e aproveitar as regras gerenciadas pelo AWS WAF, dependendo das necessidades da sua empresa.

A imagem a seguir (Fig1) mostra uma arquitetura de referência de nível de camada de segurança para um aplicativo web sem estado que depende de HTTP/S, como um site, uma API ou um aplicativo móvel.

Figura 1

5. Use Serviços, NÃO Servidores. Usando serviços como o AWS Route 53, o Amazon Cloudfront, o AWS Lambda ou o AWS DynamoDB, você pode realmente se preocupar com seu aplicativo, e não por administrar, gerenciar ou escalar a infraestrutura necessária. Isso ajudará seu aplicativo a escalar dependendo do tráfego que está recebendo. Esses serviços já usam várias zonas de disponibilidade na mesma região, a fim de fornecer alta disponibilidade sem que você precise se preocupar com isso. O anterior não significa que, se o aplicativo passou de zero a dois milhões de conexões simultâneas, o serviço estará pronto para oferecer suporte a esse tráfego. Para isso, considere os seguintes aspectos:

1. 1. Projete antes de implementar: Parece um ponto bastante normal, mas quanto mais tempo você gasta pensando em como projetar seu sistema para alta disponibilidade e como seu sistema é tolerante a falhas, você gastará menos tempo tentando corrigir problemas que você não contemplou durante o projeto. Confie em um de nossos arquitetos de soluções e/ou parceiros em nossa extensa rede, eles podem ajudá-lo com as melhores práticas e recomendações durante todo o processo, dependendo da sua carga de trabalho.
   2. Realize testes de carga/estresse: Para realizar um teste de carga em seu aplicativo, você pode usar ferramentas que você já conhece ou pode implantá-las a partir no nosso catálogo de aplicativos. Com eles, você determinará qual infraestrutura ou serviços você precisa para oferecer suporte aos picos de carga do aplicativo e garantirá que o serviço possa lidar com a carga esperada.
   3. Arquiteturas de várias regiões: Para aplicações críticas, onde um país inteiro terá acesso em um curto período de tempo e terá muita visão nacional e/ou internacional, é fundamental pensar em arquiteturas multi-regionais. Para atender à necessidade de direcionar o tráfego entre regiões, use os diferentes tipos de roteamento do AWS Route 53 (Simples, failover, geolocalização, geoproximidade, latência e muito mais) conforme necessário.

6. Autenticação e autorização: Quando falamos de autenticação e autorização para componentes que escalam massivamente, encontramos problemas complexos, por exemplo, como podemos autenticar centenas de milhares de usuários em um período de tempo muito curto? Para fazer isso, o Amazon Cognito fornece serviços de identidade, federação e sincronização para aplicativos móveis e da web. Ele também simplifica a tarefa de autenticar usuários e armazenar, gerenciar e sincronizar seus dados em vários dispositivos, plataformas e aplicativos. O Amazon Cognito fornece credenciais temporárias com privilégios limitados a usuários autenticados e não autenticados sem a necessidade de gerenciar nenhuma infraestrutura interna. O Amazon Cognito, além de gerar um conjunto de credenciais próprias, também funciona no modo de federação, usando provedores de identidade populares como Google, Facebook e Amazon para autenticar seus usuários finais. Com o Amazon Cognito, você pode usar recursos de segurança adicionais, como solicitar um duplo fator de autenticação ou um código único no momento em que os usuários fazem login. Você pode usar o seguinte blog como um guia de implementação (link)

7. Pense de forma diferente, faça arquiteturas serverless (sem servidores), processe no lado do cliente e resolva problemas difíceis de uma maneira fácil: Muitas vezes, pensa-se que, para exibir informações aos usuários, é necessário fazer uma consulta online no banco de dados. Isso torna as arquiteturas complexas porque é necessário pensar sobre como dimensionar bancos de dados (quantidade de IOPS, Shardening, réplicas de leitura, multimaster, entre outros), mas a realidade é que muitos desses processos podem ser processados em back uma vez a cada certo tempo e exibir o resultado para cidadãos, espectadores ou usuários finais. Vamos pensar em mostrar resultados eleitorais ou resultados de nota de estudantes em nível de país e tentar resolver isso de uma maneira diferente:

8. Toda vez que um usuário entra no portal para exibir os resultados das eleições, o portal fornece informações atualizadas segundo a segundo? A pergunta que os desenvolvedores precisam fazer é se o processo está pronto para processar segundo a segundo conforme a contagem de votos prossegue. Na verdade, o processo de consolidação é executado a cada determinado número de minutos e, em seguida, atualiza o banco de dados ou repositório com os dados consolidados. Com isso em mente, em vez de ter centenas de servidores fazendo centenas ou milhares de consultas em um banco de dados central, é possível executar um único processo que extrai as informações a cada 30 segundos e as deposita no formato JSON em um armazenamento de objetos como o Amazon S3, para que ele seja acessado e exibido aos usuários via javascript a partir do seu navegador.

1. 1. Use Serverless para consolidar: Para resolver o ponto acima, você pode usar o AWS Lambda, que pode executar código para qualquer tipo de aplicativo ou serviço back-end sem ter que executar tarefas de gerenciamento. Basta carregar seu código e o AWS Lambda cuidará de tudo o que você precisa para executar e escalar seu código com alta disponibilidade. Nesse caso, você pode usar o AWS Lambda para executar automaticamente a cada “30 segundos” usando eventos do Amazon Cloudwatch para consolidar e gerar objetos JSON para posterior armazenamento no Amazon S3.
   2. Armazene e exiba informações atualizadas como um site estático processando do lado do cliente: Lembre-se de que o Amazon S3 tem a capacidade de hospedar sites estáticos sem que nossos clientes se preocupem sobre como ele será dimensionado. Com o padrão do Amazon S3, quando um objeto é depositado, ele é replicado em 3 zonas de disponibilidade dentro da mesma região da AWS, portanto, teremos alta disponibilidade e durabilidade das informações. No caso de consulta de resultados nacionais e estaduais, sendo um processo crítico, você pode obter tolerância a falhas adicional ativando a opção de replicação entre regiões. Uma vez que o usuário acessa a página hospedada no Amazon S3, ela será interpretada pelo navegador e usando JavaScript, fará referência aos objetos JSON.

A imagem a seguir (Fig 2) mostra uma arquitetura de referência na qual uma página da web estática é hospedada usando o Amazon S3 e uma distribuição de conteúdo com o Amazon CloudFront. O back-end é executado usando o Amazon API Gateway, o AWS Lambda e/ou o Amazon ECS.

Figura 2

9. Simplifique a criação de aplicativos escaláveis da web e móveis: Para fazer isso, você pode usar o serviço AWS Amplify que facilita a criação, a configuração e a implantação de aplicativos escaláveis da web e móveis. Amplify provisiona e administra de maneira continua seu backend móvel e fornece uma estrutura simples para integrar facilmente seu backend com seus frontends iOS, Android, Web e React Native. O AWS Amplify também automatiza o processo de desbloqueio do aplicativo frontend e backend, permitindo que ele forneça recursos mais rápidos. Este serviço simplificará a forma como utiliza os serviços, tais como: Amazon Cognito, Amazon S3 e Amazon Cloudfront, sobre os quais já falamos neste blog. Com o uso desses serviços você pode criar sites escaláveis onde você não precisa de servidores e, portanto, se preocupar com a quantidade de recursos necessários para suportar centenas de milhares de solicitações por minuto, já que, como mencionamos, estamos usando serviços, não servidores. Use o link a seguir caso você não tenha implantado anteriormente no S3 um site estático (HTML, Javascripts, Imagens, JSON etc) usando o Amazon Route 53 e o Amazon Cloudfront.

10. Armazene seus dados de maneira persistente no serviço certo: Os arquitetos de soluções da Amazon Web Services sempre mencionam a importância de usar a ferramenta certa para o trabalho certo. Os dias do banco de dados monolítico único e centralizado estão para trás e os desenvolvedores estão agora criando aplicativos altamente funcionais e de alto desempenho, usando diferentes bancos de dados especialmente projetados para cada tipo de necessidade. O vídeo a seguir (link) ajudará você a identificar qual tipo de banco de dados você deve escolher para sua carga de trabalho. Mas tome as seguintes considerações sobre a camada de dados necessária para processos como resultados de consulta para eleições nacionais ou estaduais, ou processos adjacentes, como consultar o local de votação:

1. 1. Bancos de dados NoSQL: O Amazon DynamoDB é um dos serviços de banco de dados do tipo NoSQL gerenciados pela AWS e também é catalogado dentro do mundo serverless. O Amazon DynamoDB ajusta dinamicamente e automaticamente a capacidade de desempenho em resposta aos padrões de tráfego reais. Você pode usar, dependendo do seu aplicativo, esse tipo de banco de dados NoSQL para consolidar a contagem de votos por candidato.
   2. Bancos de dados SQL: Em relação ao banco de dados relacional, é importante identificar com testes de carga a quantidade de IOPS (leituras e gravações de disco) que requer com a simultaneidade esperada. Para escalar o nível de IOPS no Amazon RDS, você pode usar volumes de armazenamento com IOPS provisionadas. Outra vantagem de usar o Amazon RDS é a facilidade de escalabilidade usando réplicas de leitura do banco de dados, que você pode implantar com alguns cliques. Para alta disponibilidade, você pode usar a opção RDS Multi-AZ, que replica de modo síncrono seu banco de dados para outra zona de disponibilidade. https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/ebs-io-characteristics.html.
   3. Cache de banco de dados: Use o serviço Amazon ElastiCache para armazenar em cache as consultas mais frequentes em bancos de dados. Isso permite que você acelere a resposta e ofereça aos seus clientes uma melhor experiência de usuário, bem como reduzir o número de solicitações para seu banco de dados central. Clique aqui para obter mais informações Link. Continuando com o exemplo de resultados de consulta em eleições nacionais, é notável que o aplicativo irá realizar consultas padrão, por exemplo, locais de votação ou número de votos por partido, portanto, armazenar essas consultas em cache diminuirá o número de solicitações para seus bancos de dados.

11. O monitoramento é fundamental neste tipo de evento. Existem serviços essenciais para poder dispor de um acompanhamento adequado em termos de visibilidade e, assim, tomar medidas mais cedo sobre o que está a acontecer, antes, durante e depois desses períodos críticos. Seguindo as práticas recomendadas da AWS, é recomendável que você tenha uma única conta de segurança, que servirá como um repositório de log para suas outras contas da AWS. Para esta conta central, os serviços da AWS: AWS CloudTrail, Amazon Cloudwatch, AWS Application Load Balancer, Amazon Cloudfront e VPC Flowlogs, serão capazes de enviar seus logs para que você tenha uma visão geral única de tudo que você está usando. Para estar em conformidade com isso, você pode usar o Amazon CloudWatch (link). O Amazon Athena é um bom aliado para realizar consultas interativas tipo SQL para grandes quantidades de dados (por exemplo, logs). Nesse caso, você pode usá-lo para identificar os padrões de acesso dos usuários aos seus aplicativos consultando seus logs para que você possa agir de forma proativa. Aqui está um exemplo de como você pode usar o Amazon Athena para analisar logs do Application Load Balancer (link).

12. Enterprise Support + IEM (gerenciamento de eventos de infraestrutura): Ao contratar serviços de suporte, você terá mãos especializadas que apoiarão durante o período crítico do seu evento, que irão orientá-lo e ajudar seu aplicativo a funcionar perfeitamente. Para que este serviço seja executado da melhor maneira, recomenda-se contratá-lo com pelo menos 1 mês de antecedência, isto para que a equipe de suporte possa conhecer sua infraestrutura, conteúdo, dar recomendações, fazer ajustes e identificar pontos únicos de falha, entre outros. https://aws.amazon.com/es/premiumsupport/programs/iem/.

Conclusão: Os tipos de arquiteturas e recomendações descritos aqui ajudarão você a ter melhor desempenho, escalabilidade e alta disponibilidade para fornecer uma melhor resposta aos seus usuários. Além disso, você pode reduzir o custo da solução usando arquiteturas baseadas em serviço. Se você precisar de mais informações sobre os processos eleitorais e como podemos ajudá-lo, criamos um portal dedicado com este caso de uso do qual você pode consultar, se necessário https://aws.amazon.com/stateandlocal/elections/.

Sobre o autor

Eduardo Patino Balaguera é arquiteto de soluções na Amazon Web Services para o setor público. Eduardo tem ajudado várias empresas do setor público e privado na adoção da tecnologia de nuvem nos últimos 8 anos e tem realizado com sucesso projetos que marcam impacto social ao nível de cidadãos e estudantes em toda a América Latina.