Meu primeiro ano na AWS: Lições de uma falha de 15 horas

Quando comecei a estudar sobre cloud computing e os benefícios que a AWS poderia trazer para os seus usuários, muito se falava sobre os pilares essenciais do serviço e a promessa de 99,99% de disponibilidade da nuvem.

Veja bem, a promessa de sistemas automaticamente escaláveis e sempre disponíveis, mesmo em casos de grandes catástrofes, saltava aos olhos dos desenvolvedores e administradores de sistemas

Antes de tudo, permita-me apresentar: sou o Vinicius, tenho 27 anos e sou desenvolvedor fullstack. No início do ano passado, iniciei o programa de Scholarship da CompassUOL, o que me permitiu adquirir conhecimentos teóricos e práticos durante os 6 meses de estágio e, por consequência, conquistar a certificação Cloud Practitioner. Dito isso, voltamos ao assunto principal desse artigo.

Mas e quando a promessa falha? Recentemente, a AWS ficou aproximadamente 15 horas apresentando problemas e derrubando serviços globalmente. Mesmo assim, cloud computing continua sendo sinônimo de confiabilidade. Neste artigo, vamos entender o porquê.

O que aconteceu?

Por volta das 3 horas da manhã (horário do leste dos EUA) do dia 20 de outubro, uma falha no serviço de resolução de nomes (DNS) do DynamoDB, serviço de banco de dados da AWS, usado para guardar grandes volumes de informações com alta velocidade, começou a apresentar problemas na região US-EAST-1. O DynamoDB é um serviço fundamental da AWS do qual outras ferramentas da própria AWS dependem para o seu perfeito funcionamento. Essa indisponibilidade causou um efeito cascata, derrubando outras ferramentas da AWS como:

• Elastic Compute Cloud (EC2)
• Lambda
• Simple Queue Service (SQS)
• Amazon Connect

O incidente durou cerca de 15 horas e afetou serviços de grandes empresas como: Snapchat, Fortnite, McDonald's, Mercado Livre, iFood, Prime Video, entre outras.

Por que aconteceu? (E por que escalou tanto)

Uma condição de corrida, que é quando dois processos tentam fazer uma coisa ao mesmo tempo e acabam se atrapalhando, no sistema automatizado de gerenciamento do DNS do DynamoDB, iniciou os problemas na região do Norte da Virgínia.

A US-EAST-1 é a região mais importante da AWS: hospeda cerca de 30% a 40% de toda a carga global dos serviços da AWS; além disso, aproximadamente 70% do tráfego de internet mundial passa por essa região. Recursos e serviços globais, como atualizações do IAM e tabelas globais do DynamoDB, foram impactados devido à dependência da US-EAST-1, fazendo com que a falha escalasse rapidamente em todo o mundo.

O que eu, como desenvolvedor, posso fazer?

O que fazer nesse caso? Essa é uma dúvida que deve ser pensada já nas primeiras etapas do desenvolvimento de um sistema hospedado em nuvem.

Como foi dito, o problema ocorreu em uma região específica da AWS; usar uma arquitetura multi-região já ajudaria a minimizar os impactos. Nessa abordagem, por meio de um failover automático, que é um processo de transferência automática de operações de um sistema em falha para um sistema de backup, todo o tráfego é direcionado para a região disponível. Imagine o cenário a seguir:

• Sistema Multi-Região:

1. US-EAST-1 (70% de tráfego usual): offline

2. US-WEST-2 (30% de tráfego usual): online

Ao detectar que uma das regiões está indisponível, o failover entra em ação e direcionará todo o tráfego recebido para a região US-WEST-2.

Outra opção para evitar uma queda é usar uma abordagem multi-cloud; nesse cenário, o sistema usa mais de um provedor de cloud para a operação (como, por exemplo, AWS + Google Cloud). Essa forma traz benefícios como redundância crítica, além de evitar que a empresa fique refém de um único provedor. Porém, o alto custo de implementação, a necessidade de treinamento em ambos os provedores de nuvem e a complexidade operacional são fatores que tornam essa prática pouco comum.

Por que confiar em Cloud Computing?

Depois do incidente, é comum que alguns fiquem em dúvida quanto a usar a cloud computing em suas aplicações, e por isso venho aqui tranquilizar a todos: falhas acontecem em todos os tipos de sistemas, e em número bem maior quando se trata de ambientes on-premise. O fato de apenas uma região da AWS, das 38 disponíveis no serviço, cair e chamar tanta atenção mostra que tais eventos quase nunca acontecem. Merece destaque ainda o histórico de transparência e melhoria contínua da Amazon, que em apenas três dias após o incidente publicou um post-mortem (documento detalhado) informando o que tinha acontecido, como foi resolvido e o que seria feito para evitar que isso aconteça novamente.

Os benefícios de uso da cloud ainda superam os riscos:

• Escalabilidade automática
• Redundância global
• Custo-benefício, se comparado a ambientes on-premise
• E atualizações e melhorias constantes

Esses são apenas alguns dos benefícios que evidenciam a performance de serviços de cloud computing e chamam a atenção por tornar as aplicações escaláveis e altamente disponíveis de forma facilitada.

Reflexões de um ano de jornada

A falha de outubro mostra que nem mesmo grandes serviços como a AWS estão imunes a períodos de inatividade, mas a forma como o provedor trata incidentes desse tipo expõe o quão seguros e eficientes os serviços de cloud computing são. Meu primeiro ano lidando com a Amazon Web Services me mostrou na prática que cloud não é sobre nunca falhar, mas sim estar preparado para tudo o que pode acontecer.

Por fim, convido vocês que já trabalham com a AWS ou até mesmo quem está começando a dar os primeiros passos nesse mundo a visitar os recursos de aprendizado gratuitos fornecidos pela própria Amazon através do AWS Skill Builder, conferir a documentação dos serviços no site, participar dos fóruns e comunidades de ajuda da AWS e testar todas as ferramentas disponibilizadas usando o Free Tier (camada gratuita para testes).

O conteúdo está disponível! Quanto mais você aprender, mais resilientes serão os seus sistemas.