O serviço de armazenamento na nuvem da Amazon, o Amazon Web Services (AWS), teve problemas na terça-feira, 28 de fevereiro, e ficou parcialmente offline, afetando empresas nos Estados Unidos e no mundo.
A empresa informou em seu “Service Health Dashboard”, às 14h35 (horário da costa leste dos EUA), que seus engenheiros estavam trabalhando no “problema que afeta websites e aplicativos, que usam os servidores da AWS, incluindo Pinterest, Airbnb, Netflix, Spotify, Reddit e Adobe. A agência de notícias Associated Press relatou que suas fotos, webfeeds e outros serviços online também foram afetados.
Quase duas horas depois, às 16h12, o painel de controle da AWS informava que “nós continuamos a experimentar taxas de erro elevadas com o S3 da costa leste, que está impactando vários serviços”. E observou: “Estamos trabalhando para descobrir a causa raiz e reparar o sistema S3 para recuperar as operações normais”.
A falha afetou principalmente o sistema S3 (Simple Storage Service) da AWS, que fica na Virgínia do Norte, na costa leste. De acordo com a plataforma de monitoramento de internet Catchpoint, o sistema S3 teve uma interrupção de 3h39 minutos. “O S3 é como ar para a nuvem”, disse o analista da Forrester, Dave Bartoletti. “Quando ele cai muitos sites não conseguem respirar. Mas as interrupções, erros e falhas são um fato da vida na nuvem.” Bartoletti disse, porém, que não há nenhum motivo para pânico. “Isto não é uma tendência. O S3 tem sido muito confiável e seguro, e tem sido uma espécie de joia da coroa da nuvem da Amazon.”
Após ouvir vários especialistas, o Network World-EUA listou cinco dicas para que as empresas estejam preparadas para uma queda do serviço de nuvem:
- Não manter todos os seus ovos em uma única cesta
- Verificações de integridade
- Construir sistemas redundantes, desde o início
- Backup de dados
- Teste seu sistema
Este conselho pode significar coisas diferentes para diferentes usuários, mas a ideia básica é que se a empresa colocar um aplicativo ou de parte de seus dados na nuvem não poderá ser muito tolerante a falhas. Dependendo de quanto a empresa deseja que o aplicativo esteja disponível, determinará o número de cestas pelas quais as cargas de trabalho serão espalhadas.
Existem várias opções. AWS recomenda no mínimo a espalhar as cargas de trabalho por múltiplas Zonas de Disponibilidade (AZ) disponíveis em vários fusos horários. Cada uma das 16 regiões abrangidas pela AWS subdivide-se em pelo menos duas, às vezes até cinco, AZs. Cada AZ é isolada de outras AZs na mesma região. AWS fornece conexões de baixa latência entre suas Zonas de Disponibilidade na mesma região, criando uma forma mais básica para distribuir suas cargas de trabalho. Para maior proteção, os usuários podem espalhar suas aplicações através das várias regiões. Outra maneira seria colocar o aplicativo em vários provedores, por exemplo, usando o Microsoft Azure, a plataforma de nuvem do Google ou algum recurso de infraestrutura interna ou hospedada em um backup.
Bartoletti diz que clientes diferentes terão diferentes níveis de urgência para fazer isso. Se você confiar na nuvem para fazer dinheiro para o seu negócio ou para produtividade, certifique-se se ela é tolerante a falhas e altamente disponível. Se a empresa for usá-la para fazer backup de arquivos que não são acessados com frequência, então poderá conviver com a interrupção ocasional do serviço.
A questão chave para responder a uma falha de nuvem é saber quando ela pode acontecer. AWS tem uma série de maneiras de fazer isso. Uma das mais básicas é usar o que chama de verificações de integridade, que fornecem uma lista personalizada do status dos recursos usados por cada conta. O Amazon CloudWatch pode ser configurado para, automaticamente, controlar a disponibilidade do serviço, monitorar arquivos de log, criar alarmes e reagir a falhas. Um método importante para este trabalho é fazer uma análise exaustiva do comportamento “normal” para que as ferramentas de nuvem AWS possam detectar comportamento “anormal”.
Uma vez que um erro é identificado, há uma gama de reações de efeito dominó que precisam ser pré-configuradas para responder à situação. Balanceadores de carga podem ser usados para redirecionar o tráfego e sistemas de backup podem ser empregados, se definidos para isso.
Não será muito útil tentar responder a uma interrupção de energia em tempo real, mas a preparação antes que ocorra a paralisação vai gerar alguma economia quando se trata do inevitável. Existem duas maneiras básicas para construir redundância em sistemas de nuvem:
— Standby: Quando uma falha ocorre, o aplicativo automaticamente a detecta e aciona o sistema redundante, no caso o backup. Nesse cenário, o sistema de backup pode ser desligado, mas pronto para operar quando um erro é detectado. Outra alternativa é executar o backup em standby em segundo plano o tempo todo — custa mais, mas vai reduzir o tempo de interrupção. A desvantagem para essas abordagens é que pode haver uma defasagem entre quando um erro é detectado e quando o sistema de redundância entra em ação.
— Redundância ativa: Para evitar o tempo de inatividade (teoricamente) usuários podem programar sua aplicação para ter redundância ativa. Nesse cenário, o aplicativo é distribuído através de vários recursos redundantes: quando um falha, o restante dos recursos absorve uma parcela maior da carga de trabalho. Uma técnica de sharding pode ser usada em que serviços são divididos em componentes. Digamos, por exemplo, um aplicativo é executado através de oito instâncias de máquina virtual — oito instâncias podem ser divididas em quatro grupos de duas e o tráfego pode ter a carga balanceada entre elas. Se um pedaço cai, os outros três podem manter o tráfego.
Uma coisa é ter sistemas redundantes, outra é fazer backup de seus dados. Isto foi especialmente importante na interrupção da semana porque foi o primeiro que atingiu o sistema S3. A AWS tem várias maneiras de, nativamente, fazer o backup de dados:
— Replicação síncrona: é um processo no qual um aplicativo apenas confirma uma transação (por exemplo, carregar um arquivo na nuvem, ou inserir informações em um banco de dados) se a transação foi replicada em um local secundário. A desvantagem dessa abordagem é que ela pode introduzir latência para esperar a replicação secundária ocorrer e para o sistema principal obter a confirmação. Quando a latência não é uma prioridade, isso é bom.
— Replicação assíncrona: este processo dissocia o nó primário de réplicas, que é bom para sistemas que precisam de baixa latência. Os usuários devem estar dispostos a comprometer alguma perda de transações recentes durante falha nesse cenário.
— Quorum baseado em replicação: É uma combinação de replicação síncrona e assíncrona que define uma quantidade mínima de informações que precisam para fazer o backup e uma transação ser qualificada.
Para determinar a melhor forma de construir sistemas redundantes e backup de dados, as empresas devem considerar seu objetivo de ponto de recuperação desejado (RPO, na sigla em inglês) e objetivo de tempo de recuperação (RTO).
Por que esperar que uma paralisação ocorra para ver se seu sistema é resistente? Por isso é preciso testá-lo de antemão. Pode parecer loucura, mas os melhores arquitetos de nuvem estão dispostos a matar todos os nós, serviços, Zonas de Disponibilidade e regiões para ver se seu aplicativo pode suportá-la.
“Você deve constantemente ser capaz de espancar seu próprio site”, diz Bartoletti. O Netflix tem ferramentas de código aberto chamadas Chaos Monkey e Chaos Gorilla, que fazem parte do seu exército de símios que automaticamente pode matar certos sistemas internos para testar sua tolerância a erros. Eles funcionam? Esta semana, o Netflix não relatar quaisquer problemas de interrupção de seu serviço.
Fonte: Computer World