.jpg "Quero me preparar")
.jpg "Quero me preparar")
Confira 5 dicas para evitar que falhas comprometam o serviço aos clientes.
Em fevereiro uma falha no serviço de armazenamento na nuvem da Amazon causou momentos de apreensão entre seus usuários. O serviço ficou parcialmente indisponível e afetou diversas empresas nos Estados Unidos e no mundo. De acordo com a empresa o problema afetou “websites e aplicativos que usam os servidores da AWS, incluindo Pinterest, Airbnb, Netflix, Spotify, Reddit e Adobe”.
A falha que atingiu a AWS (Amazon Web Services, que oferece serviços de computação em nuvem) afetou principalmente o sistema S3 (Simple Storage Service), que fica na Virgínia do Norte, na costa leste americana. O sistema teve ao todo uma interrupção de 3h39 minutos.
O S3 é vital para a nuvem, assim como o ar. Quando ele cai, muitos sites não conseguem “respirar”. Neste caso específico o problema foi gerado por um erro operacional, parte de uma linha de comando foi digitada incorretamente e um conjunto de servidores foi removido de um dos subsistemas do S3.
Para que tudo voltasse ao normal foi preciso que a equipe de suporte reiniciasse todas as máquinas, o que levou mais tempo que o esperado e aumentou a duração da interrupção do S3.
No caso da Amazon a ferramenta que originou a queda foi alterada para desativar os servidores mais lentamente e também para bloquear operações que pudessem derrubar a capacidade abaixo dos graus adequados de segurança. Mas o caso deixa um alerta para quem faz uso de serviços de nuvem: é necessário ter mecanismos de segurança que protejam a empresa.
Veja a seguir cinco dicas para preparar seus clientes caso ocorra uma instabilidade ou queda no serviço de nuvem.
1 – Não manter todos os seus ovos em uma única cesta
A ideia básica é que se a empresa colocar um aplicativo ou parte de seus dados na nuvem, não poderá ser muito tolerante a falhas. Dependendo do quanto a empresa deseja que o aplicativo esteja disponível, determinará o número de “cestas” pelas quais as cargas de trabalho serão distribuídas.
Existem várias opções, uma delas, recomendada pela AWS, é espalhar as cargas de trabalho por múltiplas Zonas de Disponibilidade (AZ). Estas zonas estão distribuídas em vários fusos horários. Cada uma das 16 regiões abrangidas pela AWS subdivide-se em pelo menos duas, às vezes chegando até cinco, AZs.
Cada AZ é isolada das demais na mesma região. Assim, a AWS fornece conexões de baixa latência entre suas Zonas de Disponibilidade na mesma região. Isso cria uma forma mais básica para distribuir suas cargas de trabalho. Para garantir maior segurança os usuários podem distribuir suas aplicações através das várias regiões disponíveis.
É preciso garantir que se for confiar na nuvem para fazer dinheiro para o negócio ou para gerar produtividade, ela deve ser tolerante a falhas e estar altamente disponível. Entretanto, se a empresa for utilizar a tecnologia para fazer backup de arquivos que são acessados esporadicamente, é possível conviver com interrupções ocasionais do serviço.
2 – Fazer verificações de integridade
A questão chave para responder a uma falha de nuvem é saber quando ela pode acontecer. A AWS tem uma série de maneiras de fazer isso, uma das mais básicas é usar o que chama de verificações de integridade.
Um método importante é realizar uma análise exaustiva do comportamento “normal” para que as ferramentas de nuvem AWS possam detectar comportamento “anormal” quando estes acontecerem.
Assim que o erro é identificado, há diversas reações de “efeito dominó” que precisam ser pré-configuradas para resolver a situação. O balanceamento de carga pode ser usado para redirecionar o tráfego e sistemas de backup podem ser empregados, por exemplo.
3 – Construir sistemas redundantes, desde o início
Há duas formas básicas para construir redundância em sistemas de nuvem: Standby e Redundância Ativa. No primeiro caso, quando uma falha ocorre, o aplicativo automaticamente 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.
Ainda no Standby é possível executar o backup em standby em segundo plano o tempo todo, o que tenho um custo maior, porém reduz o tempo de interrupção. A desvantagem do Standby é que pode haver uma defasagem quando um erro é detectado e quando o sistema de redundância entra em ação.
O segundo caso, de redundância ativa, também pode ser aplicado. 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.
Um processo de sharding pode ser empregado para dividir os serviços em componentes. 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 serviço em funcionamento.
4 – Ter backup dos dados
Ter sistemas redundantes é uma coisa, fazer backup dos dados da empresa é outra. Isso foi especialmente importante na interrupção do sistema S3, que foi afetado pelo primeiro cenário. A AWS tem diversas maneiras de, naturalmente, fazer o backup dos dados:
Replicação síncrona: processo no qual um aplicativo apenas confirma uma transação (carregamento de arquivo na nuvem ou inserção de informações em banco de dados) se a ação foi replicada em um local secundário. A desvantagem nesse caso é que ela pode introduzir latência para esperar a replicação secundária acontecer para o sistema principal obter a confirmação. Quando a latência não é prioridade isso é ruim.
Replicação assíncrona: este processo dissocia o nó primário de réplicas, o que é positivo para sistemas que precisam de baixa latência. Os usuários devem estar dispostos a comprometer alguma perda de transações recentes se ocorrer uma falha nesse modelo.
Quórum baseado em replicação: consiste em 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 definir a melhor forma de construir sistemas redundantes e backup de dados as empresas devem considerar seu objetivo de ponte de recuperação desejado (RPO, na sigla em inglês) e objetivo de tempo de recuperação (RTO).
5 – Testar regularmente o sistema
Esperar que uma paralisação aconteça para “testar” se o sistema da empresa é resistente não é uma opção muito inteligente. Por isso, testar o sistema regularmente e previamente é uma das dicas mais importantes. Os melhores arquitetos de nuvem estão dispostos a “estressar” todas as áreas, serviços, Zonas de Disponibilidade e regiões para ver se o aplicativo é capaz de suportá-la.
Escreva seu comentário