Projetar para sobreviver a falhas (criando aplicativos de nuvem Real-World com o Azure)

por Rick Anderson, Tom Dykstra

Baixar o Projeto de Correção ou Baixar E-book

O livro eletrônico Criando Aplicativos de Nuvem do Mundo Real com o Azure é baseado em uma apresentação desenvolvida por Scott Guthrie. Ele explica 13 padrões e práticas que podem ajudá-lo a desenvolver aplicativos Web para a nuvem com êxito. Para obter informações sobre o livro eletrônico, consulte o primeiro capítulo.

Uma das coisas que você precisa pensar ao criar qualquer tipo de aplicativo, mas especialmente um que será executado na nuvem em que muitas pessoas o usarão, é como projetar o aplicativo para que ele possa lidar normalmente com falhas e continuar a fornecer valor o máximo possível. Dado tempo suficiente, as coisas vão dar errado em qualquer ambiente ou em qualquer sistema de software. A forma como seu aplicativo lida com essas situações determina o quanto seus clientes ficarão chateados e quanto tempo você tem para gastar analisando e corrigindo problemas.

Tipos de falhas

Há duas categorias básicas de falhas que você desejará lidar de forma diferente:

• Falhas transitórias de autorrecuperação, como problemas intermitentes de conectividade de rede.
• Falhas duradouras que exigem intervenção.

Para falhas transitórias, você pode implementar uma política de repetição para garantir que, na maioria das vezes, o aplicativo se recupere de forma rápida e automática. Seus clientes podem notar um tempo de resposta um pouco mais longo, mas caso contrário, eles não serão afetados. Mostraremos algumas maneiras de lidar com esses erros no capítulo Tratamento transitório de falhas.

Para falhas duradouras, você pode implementar a funcionalidade de monitoramento e registro em log que notifica você imediatamente quando surgem problemas e que facilita a análise de causa raiz. Mostraremos algumas maneiras de ajudá-lo a ficar por dentro desses tipos de erros no capítulo Monitoramento e Telemetria.

Escopo da falha

Você também precisa pensar no escopo da falha – se um único computador é afetado, um serviço inteiro, como Banco de Dados SQL ou Armazenamento, ou uma região inteira.

Falhas no computador

No Azure, um servidor com falha é substituído automaticamente por um novo e um aplicativo de nuvem bem projetado se recupera desse tipo de falha automaticamente e rapidamente. Anteriormente, enfatizamos os benefícios de escalabilidade de uma camada da Web sem estado, e a facilidade de recuperação de um servidor com falha é outro benefício da falta de estado. A facilidade de recuperação também é um dos benefícios dos recursos de PaaS (plataforma como serviço), como Banco de Dados SQL e Serviço de Aplicativo do Azure Aplicativos Web. Falhas de hardware são raras, mas quando ocorrem, esses serviços as manipulam automaticamente; você nem precisa escrever código para lidar com falhas de computador ao usar um desses serviços.

Falhas de serviço

Normalmente, os aplicativos de nuvem usam vários serviços. Por exemplo, o aplicativo Fix It usa o serviço Banco de Dados SQL, o serviço de Armazenamento e o aplicativo Web é implantado para Serviço de Aplicativo do Azure. O que seu aplicativo fará se um dos serviços dos quais você depende falhar? Para algumas falhas de serviço, uma mensagem amigável "desculpe, tente novamente mais tarde" pode ser a melhor que você pode fazer. Mas em muitos cenários você pode fazer melhor. Por exemplo, quando o armazenamento de dados de back-end estiver inativo, você poderá aceitar a entrada do usuário, exibir "sua solicitação foi recebida" e armazenar a entrada em outro lugar temporariamente; em seguida, quando o serviço necessário estiver operacional novamente, você poderá recuperar a entrada e processá-lo.

O capítulo Padrão de Trabalho centrado em fila mostra uma maneira de lidar com esse cenário. O aplicativo Fix It armazena tarefas em Banco de Dados SQL, mas não precisa parar de funcionar quando Banco de Dados SQL está inativo. Nesse capítulo, veremos como armazenar a entrada do usuário para uma tarefa em uma fila e usar um processo de trabalho para ler a fila e atualizar a tarefa. Se o SQL estiver inativo, a capacidade de criar tarefas de Correção não será afetada; o processo de trabalho pode aguardar e processar novas tarefas quando Banco de Dados SQL estiver disponível.

Falhas de região

Regiões inteiras podem falhar. Um desastre natural pode destruir um data center, pode ser achatado por um meteoro, a linha do tronco no datacenter pode ser cortada por um fazendeiro enterrando uma vaca com uma retroescavadeira, etc. Se seu aplicativo estiver hospedado no datacenter afetado, o que você faz? É possível configurar seu aplicativo no Azure para ser executado em várias regiões simultaneamente para que, se houver um desastre em uma, você continue em execução em outra região. Essas falhas são ocorrências extremamente raras e a maioria dos aplicativos não passa pelos aros necessários para garantir o serviço ininterrupto por meio de falhas desse tipo. Consulte a seção Recursos no final do capítulo para obter informações sobre como manter seu aplicativo disponível mesmo por meio de uma falha na região.

Um objetivo do Azure é facilitar muito o tratamento de todos esses tipos de falhas e você verá alguns exemplos de como estamos fazendo isso nos capítulos a seguir.

SLAs

Pessoas geralmente ouve falar sobre SLAs (contratos de nível de serviço) no ambiente de nuvem. Basicamente, essas são promessas que as empresas fazem sobre o quão confiável é seu serviço. Um SLA de 99,9% significa que você deve esperar que o serviço funcione corretamente 99,9% do tempo. Esse é um valor bastante típico para um SLA e soa como um número muito alto, mas você pode não perceber quanto tempo de inatividade .1% realmente equivale a. Aqui está uma tabela que mostra quanto tempo de inatividade vários percentuais de SLA equivalem a mais de um ano, um mês e uma semana.

Portanto, um SLA de 99,9% significa que seu serviço pode cair 8,76 horas por ano ou 43,2 minutos por mês. Isso é mais tempo de inatividade do que a maioria das pessoas imagina. Portanto, como desenvolvedor, você deseja estar ciente de que uma determinada quantidade de tempo de inatividade é possível e lidar com isso de maneira normal. Em algum momento alguém vai usar seu aplicativo, e um serviço vai ficar inativo, e você quer minimizar o impacto negativo disso no cliente.

Uma coisa que você deve saber sobre um SLA é a que período ele se refere: o relógio é redefinido toda semana, todos os meses ou todos os anos? No Azure, redefinimos o relógio todos os meses, o que é melhor para você do que um SLA anual, já que um SLA anual pode ocultar meses ruins compensando-os com uma série de bons meses.

É claro que sempre aspiramos a fazer melhor do que o SLA; normalmente você vai estar para baixo muito menos do que isso. A promessa é que se alguma vez estivermos para baixo por mais tempo do que o tempo máximo de inatividade você pode pedir dinheiro de volta. A quantidade de dinheiro que você recebe de volta provavelmente não compensaria totalmente o impacto nos negócios do excesso de tempo de inatividade, mas esse aspecto do SLA atua como uma política de aplicação e informa que levamos isso muito a sério.

SLAs compostos

Uma coisa importante a se pensar quando você está olhando para SLAs é o impacto do uso de vários serviços em um aplicativo, com cada serviço tendo um SLA separado. Por exemplo, o aplicativo Fix It usa Serviço de Aplicativo do Azure Aplicativos Web, Armazenamento do Azure e Banco de Dados SQL. Aqui estão seus números SLA a partir da data em que este e-book está sendo escrito em dezembro de 2013:

Qual é o tempo de inatividade máximo esperado para o aplicativo com base nesses SLAs de serviço? Você pode pensar que seu tempo de inatividade seria igual ao pior percentual de SLA, ou 99,9% nesse caso. Isso seria verdade se todos os três serviços sempre falhassem ao mesmo tempo, mas isso não é necessariamente o que realmente acontece. Cada serviço pode falhar independentemente em momentos diferentes, portanto, você precisa calcular o SLA composto multiplicando os números individuais do SLA.

Portanto, seu aplicativo pode ficar inativo não apenas 43,2 minutos por mês, mas 3 vezes esse valor, 108 minutos por mês e ainda estar dentro dos limites do SLA do Azure.

Esse problema não é exclusivo do Azure. Na verdade, fornecemos os melhores SLAs de nuvem de qualquer serviço de nuvem disponível e você terá problemas semelhantes para lidar se usar os serviços de nuvem de qualquer fornecedor. O que isso destaca é a importância de pensar em como você pode projetar seu aplicativo para lidar com as falhas de serviço inevitáveis normalmente, pois elas podem acontecer com frequência suficiente para afetar seus clientes ou usuários.

SLAs de nuvem em comparação com a experiência de tempo de inatividade empresarial

Pessoas às vezes dizem: "No meu aplicativo empresarial, nunca tenho esses problemas." Se você perguntar quanto tempo de inatividade por mês eles realmente têm, eles geralmente dizem: "Bem, isso acontece ocasionalmente." E se você perguntar com que frequência, eles admitem que "Às vezes, precisamos fazer backup ou instalar um novo servidor ou atualizar software". Claro, isso conta como tempo de inatividade. A maioria dos aplicativos corporativos, a menos que eles sejam especialmente críticos, estão realmente inativos por mais do que o tempo permitido por nossos SLAs de serviço. Mas quando é seu servidor e sua infraestrutura e você é responsável por ele e no controle dele, você tende a sentir menos angústia sobre os tempos de inatividade. Em um ambiente de nuvem, você depende de outra pessoa e não sabe o que está acontecendo, então você pode ficar mais preocupado com isso.

Quando uma empresa obtém uma porcentagem de tempo de atividade maior do que você obtém de um SLA de nuvem, elas o fazem gastando muito mais dinheiro em hardware. Um serviço de nuvem poderia fazer isso, mas teria que cobrar muito mais por seus serviços. Em vez disso, você aproveita um serviço econômico e projeta seu software para que as falhas inevitáveis causem interrupções mínimas para seus clientes. Seu trabalho como designer de aplicativo de nuvem não é tanto para evitar falhas quanto para evitar catástrofes, e você faz isso focando em software, não em hardware. Enquanto os aplicativos empresariais se esforçam para maximizar o tempo médio entre falhas, os aplicativos de nuvem se esforçam para minimizar o tempo médio de recuperação.

Nem todos os serviços de nuvem têm SLAs

Lembre-se também de que nem todos os serviços de nuvem têm um SLA. Se seu aplicativo depende de um serviço sem garantia de tempo de inatividade, você pode ficar inativo por muito mais tempo do que você pode imaginar. Por exemplo, se você habilitar o logon em seu site usando um provedor social como Facebook ou Twitter, marcar com o provedor de serviços para descobrir se há um SLA e você pode descobrir que não há um. No entanto, se o serviço de autenticação ficar inativo ou não puder dar suporte ao volume de solicitações lançadas nele, seus clientes serão bloqueados para fora do aplicativo. Você pode ficar para baixo por dias ou mais. Os criadores de um novo aplicativo esperavam centenas de milhões de downloads e assumiram uma dependência da autenticação do Facebook , mas não falaram com o Facebook antes de entrar em vigor e descobriram tarde demais que não havia SLA para esse serviço.

Nem todas as contagens de tempo de inatividade para SLAs

Alguns serviços de nuvem poderão negar deliberadamente o serviço se o aplicativo os usar demais. Isso é chamado de limitação. Se um serviço tiver um SLA, ele deverá declarar as condições sob as quais você pode ser limitado, e o design do aplicativo deve evitar essas condições e reagir adequadamente à limitação se isso acontecer. Por exemplo, se as solicitações para um serviço começarem a falhar quando você exceder um determinado número por segundo, você deseja garantir que as repetições automáticas não ocorram tão rápido que causem a limitação. Teremos mais a dizer sobre a limitação no capítulo Tratamento de Falhas Transitórias.

Resumo

Este capítulo tentou ajudá-lo a perceber por que um aplicativo de nuvem do mundo real precisa ser projetado para sobreviver a falhas normalmente. A partir do próximo capítulo, os padrões restantes desta série entram em mais detalhes sobre algumas estratégias que você pode usar para fazer isso:

• Tenha um bom monitoramento e telemetria, para que você descubra rapidamente sobre falhas que exigem intervenção e tenha informações suficientes para resolve-las.
• Manipule falhas transitórias implementando a lógica de repetição inteligente, para que seu aplicativo se recupere automaticamente quando puder e volte para a lógica do disjuntor quando não puder.
• Use o cache distribuído para minimizar problemas de taxa de transferência, latência e conexão com o acesso ao banco de dados.
• Implemente o acoplamento flexível por meio do padrão de trabalho centrado em fila, para que o front-end do aplicativo possa continuar funcionando quando o back-end estiver inativo.

Recursos

Para obter mais informações, consulte capítulos posteriores neste livro eletrônico e os recursos a seguir.

Documentação:

• Failsafe: diretrizes para arquiteturas de nuvem resilientes. White paper de Marc Mercuri, Ulrich Homann e Andrew Townhill. Versão da página da Web da série de vídeos FailSafe.
• Práticas recomendadas para o design de serviços de Large-Scale no Azure Serviços de Nuvem. White paper de Mark Simms e Michael Thomassy.
• Diretrizes técnicas de continuidade dos negócios do Azure. White paper de Patrick Wickline e Jason Roth.
• Recuperação de desastre e alta disponibilidade para aplicativos do Azure. White paper de Michael McKeown, Hanu Kommalapati e Jason Roth.
• Padrões e práticas da Microsoft – Diretrizes do Azure. Consulte Diretrizes de implantação de vários datacenters, Padrão de disjuntor.
• Suporte do Azure – Contratos de Nível de Serviço.
• Continuidade dos negócios no banco de dados SQL do Azure. Documentação sobre Banco de Dados SQL recursos de alta disponibilidade e recuperação de desastre.
• Alta disponibilidade e recuperação de desastre para SQL Server no Azure Máquinas Virtuais.

Vídeos:

• FailSafe: criando Serviços de Nuvem escalonáveis e resilientes. Série de nove partes de Ulrich Homann, Marc Mercuri e Mark Simms. Apresenta conceitos de alto nível e princípios arquitetônicos de maneira muito acessível e interessante, com histórias extraídos da experiência da CAT (Equipe de Consultoria de Clientes) da Microsoft com clientes reais. Os episódios 1 e 8 se aprofundam nos motivos para criar aplicativos de nuvem para sobreviver a falhas. Veja também a discussão de acompanhamento da limitação no episódio 2 a partir das 49:57, a discussão sobre pontos de falha e modos de falha no episódio 2 a partir das 56:05, e a discussão de disjuntores no episódio 3 a partir das 40:55.
• Criando grandes: lições aprendidas com os clientes do Azure – Parte II. Mark Simms fala sobre como projetar para falhas e instrumentar tudo. Semelhante à série Failsafe, mas entra em mais detalhes de instruções.

AnteriorAvançar