BT

Como o Heroku gerencia a alta disponibilidade: resumo de palestra do QCon Londres

por Fabian Lange , traduzido por Leonardo Campos em 16 Abr 2012 |

Para uma solução PaaS (Plataforma como Serviço), a alta disponibilidade é um desafio e tanto, pois não é só a infraestrutura de hardware, mas também a de software que deve estar disponível o tempo inteiro. Em sua apresentação no QCon Londres (PDF), Mark McGranaghan explicou os padrões utilizados no Heroku para oferecer um sistema PaaS de alta disponibilidade que, segundo ele, se encaixam em duas categorias

  • Arquitetural, com alguns conceitos de projeto;
  • Técnico-social, descrevendo como as pessoas interagem com o software.

De acordo com Mark, o fator humano é frequentemente desprezado quando se trata da forma que aplicações de alta disponibilidade são postas em produção e operadas. Do lado arquitetural, uma quantidade considerável de conceitos foi tomada do Erlang, como ficará claro com alguns exemplos.

Aspectos de arquitetura

Quando aplicações são postas no Heroku, elas ganham vários serviços do próprio Heroku e deixam de ter a necessidade de cuidar destes aspectos. Roteamento de requisições HTTP, por exemplo, é um serviço oferecido pelo Heroku. Na verdade, a aplicação não seria capaz de roteamento por conta própria, pois aplicações rodando sobre o Heroku estão em diversas instâncias e monitoradas por supervisores que podem reiniciá-las.

Assim, a aplicação não sabe onde está rodando, mas o sistema de roteamento do Heroku está ciente da localização de cada instância da aplicação e pode direcionar o tráfego HTTP de acordo. O sistema de roteamento em si consiste de muitas instâncias na núvem que são supervisionadas e escaladas ou reiniciadas, caso necessário.

Isto segue o conceito de núcleo de erros do Erlang. Todos os serviços são supervisionados e os próprios supervisores também são supervisionados. Qualquer coisa pode falhar e ser reiniciada. Este conceito facilita o tratamento de erros tanto para o próprio Heroku quanto para as aplicações hospedadas nele.

Como falhas podem acontecer em qualquer componente, as aplicações deveriam ser desenhadas para degradar de forma graciosa. Mark deu alguns exemplos de como isto parece na prática:

Mensageria confiável

Em uma arquitetura tradicional de broker de mensageria, existe um ponto único de falha: o destino para onde as mensagens são enviadas tem que estar disponível. O Heroku usa um padrão de projeto chamado "publique um / assine vários" no qual cada publicador conhece múltiplos brokers de mensageria possíveis. Os assinantes precisam assinar todos eles. Desta forma, o sistema de mensageria torna-se confiável em relação a falhas de brokers individuais.

As mensagens são simples coleções de pares chave/valor, que podem ser facilmente extendidas, permitindo atualizações do sistema sem interrupções. Mudanças incompatíveis podem ser realizadas com o uso de novos atributos que são utilizados apenas pelas instâncias da nova versão, de modo que as instâncias antigas consigam trabalhar com as novas mensagens que passem por elas.

Serviço indisponível

Sempre que há dependência entre uma aplicação e um serviço para leitura de dados, deveria ser possível degradar graciosamente caso o serviço esteja indisponível.

Caso seja necessária a escrita de dados em um serviço, a informação pode ser armazenada enquanto o serviço estiver indisponível. O armazenamento começará automaticamente a retransmitir a requisição de escrita no momento em que o serviço voltar a estar disponível. Por razões de simplicidade, o Heroku está movendo a maioria dos serviços para sempre armazenar antes de tentar enviar a informação. Este padrão é chamado de dessincronização de escrita.

Algo interessante é que o Heroku ainda usa PostgreSQL para realizar o armazenamento intermediário, em vez do seu próprio sistema distribuído de armazenagem chamado Doozer. De acordo com Mark, a razão é que as limitações do PostgreSQL são bem conhecidas e existe boa experiência com as ferramentas operacionais, ausentes do Doozer. Como coberto pelo InfoQ em novembro de 2011, o Heroku oferece o PostgreSQL como um serviço até para aplicações fora do Heroku. Isto nos leva à segunda parte do assunto, o aspecto "técnico social".

Aspectos técnico-sociais

Devido à interação de pessoas com o sistema, é importante torná-lo tão fácil quanto possível. Uma das razões mais comuns para problemas em sistemas são as interações humanas. Em um sistema preparado para mudanças, estas interações humanas certamente envolvem muitas mudanças.

Implantações

Com o uso de ferramentas customizadas, o Heroku consegue fazer implantações de forma incremental. Cada implantação passa por vários estágios que, diferentemente dos estágios tradicionais - em ambientes separados, no Heroku são subconjuntos da mesma infraestrutura de produção. Estes subconjuntos são algo como "interno", "beta" e "todos". O mesmo conceito é seguido para a implantação de novas funcionalidades. O Heroku utiliza marcadores para habilitar ou desabilitar funcionalidades em produção (técnica conhecida como feature toggle). Isto permite o desacoplamento entre instalaçao de pacotes e a implantação de funcionalidades: O primeiro passo é a instalação, que entrega a mesma funcionalidade que já estava estava presente, com as novas desabilitadas pelos marcadores. Caso a instalação seja bem sucedida, as funcionalidades podem ser ligadas gradualmente, permitindo a localização de problemas de forma mais fácil.

Visibilidade

Especialmente em um sistema com muitas partes móveis, a monitoração é essencial. O Heroku continua a investir pesado na monitoração e alertas porque a visibilidade que eles fornecem são essenciais para os sistemas em produção. Os problemas são detectados usando asserts. Exemplos de asserts são:

  • Percentual de Latência 99 < 50
  • Conexões ativas > 10

Mark deu dois exemplos que mostram como estes asserts poderiam ter avisado sobre uma interrupção para que eles pudessem estar postos para intervir.

Cascateamento de feedback

Um problema bastante típico em sistemas distribuídos é que falhas em um componente podem afetar vários componentes que estão encadeados na invocação do serviço. A despeito da arquitetura já ter resolvido a questão disponibilidade de componentes individuais por meio da degradação graciosa ou da de-sincronização de escrita, existe ainda um conceito necessário para evitar a sobrecarga de subsistemas. O Heroku usa o chamado "Controle de Fluxo" para isto. Alguns caminhos de código podem ser limitados a um número máximo de invocações. Estas taxas são configuráveis em tempo de execução para ajustar a mudanças em código ou hardware.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT