Recentemente eu comentei sobre a migração que fizemos no Myfinance saindo do Heroku e indo para a Amazon Web Services e diversas pessoas me perguntaram as razões pela qual fizemos essa mudança. O objetivo desse post é apenas explicar a decisão que a nossa equipe tomou, como foi e as conseguências dessa migração.
Antes de começar eu gostaria de deixar claro que o objetivo desse texto não é comparar hospedagens e nem dizer que uma é melhor do que a outra. Trata-se apenas do relato de uma experiência.
Antes de explicar a motivação por trás da migração é interessante mostrar como era a nossa estrutura.
- Rails 3.0.X
- Postgres (Heroku shared)
- Heroku
- DelayedJob com alguns workers
- Memcached (Heroku add-on)
- Websolr (Heroku add-on)
- Cron
- Airbrake (Heroku add-on)
Em um dado momento começamos a receber um número significativo de SIGTERM sem nenhum explicação. Após abrir um ticket no suporte do Heroku descobrimos que a razão pela qual nossos processos estavam sendo terminados era um excesso de carga no Postgres compartilhado.
Embora nossa aplicação realmente tenha crescido em número de usuários nós não estavamos confortaveis com a solução de contratar um banco de dados dedicado por duas razões. A primeira delas era o custo extra de $200,00 (sim, o banco de dados do Heroku é excessivamente caro) e em segundo lugar porque a quantidade de usuários ainda não era algo que justificasse essa carga tão elevada no banco.
Após analisar detalhes específicos da nossa aplicação constatamos que essa carga excessiva no banco de dados tinha como origem nossa fila de processos em background. O DelayedJob utiliza o mesmo banco de dados da aplicação e nossa aplicação faz um uso muito grande de filas.
Não nos restava outra alternativa a não ser utilizar um armazenamento diferente para nossa fila e a opção mais lógica era a dupla Redis + Resque.
Realmente em um primeiro momento essa opção de mostrou acertada e imediatemente após um deploy com a nova estrutura de fila a carga no nosso banco caiu absurdamente e ao que tudo indicava o problema estava solucionado.
Como diz o ditado, "alegria de pobre dura pouco". A ilusão do problema resolvido e de um fim de semana tranquilo não durou nem 24 horas.
Existe um problema com o uso do Resque no Heroku. Não vou me preocupar em relatar esse problema pois exitem dois tickets bastante explicativos: Veja em Heroku sends SIGTERM to Resque e prune_dead_workers doesn't work on heroku cedar.
Não preciso nem dizer que esse novo problema se manifestou exatamente em uma sexta feira e levou eu e o Vanderson a passar um final de semana inteiro de "babá de software". Passamos o final de semana todo monitorando e reiniciando os nossos workers.
Sabendo que o problema não era simples e que a solução para ele não dependia apenas da nossa equipe eu acabei tendo que apelar para os meus amigos Pedro Belo e Chris Stolt(o Chris era o único cara na EngineYard que resolvia os meus problemas).
Após algumas conversas com eles eu cheguei em uma situção onde eu tinha uma solução que dependia de uma informação que a API deles não tinha como me fornecer naquele momento. Com o sistema em produção nós não podíamos esperar e tivemos que partir para o plano B.
Quero deixar aqui registrado um MUITO OBRIGADO ao Pedro Belo e Chris Stolt que foram sensacionais.
A resposta é simples, porque lá na Myfreecomm já estávamos usando a Amazon Web Services (em outros projetos) e porque tinhamos toda uma infraestrutura já pronta que já resolvia os nossos principais problemas(deploy, setup de maquina e etc.).
Migrar um projeto em produção nunca é simples e sabendo disso nós tentamos elaborar um checklist com tudo necessário para minimizar o impacto dessa migração.
O primeiro passo foi migrar todos os add ons que a gente tinha contratado no Heroku para contas diretamente com o prestador do serviço. Esse passo foi super tranquilo.
Nosso principal desafio era (sempre é) o banco de dados. Como nós não queríamos ter que nos preocupar em criar uma maquina de banco de dados e cuidar de todos os problemas que iriam surgir (backup, escalabilidade, redundância) decidimos por usar o RDS. Porém para usar RDS era necessário migrar nossa aplicação para utilizar o Mysql.
Nesse momento eu tenho que confessar que eu estava desejando estar no lugar do Rodrigo(enchendo a cara na Oktoberfest lá em Munich). Mas infelizmente eu não tinha essa opção então me juntei ao Vanderson e o DX7 para fazer nossa aplicação rodar com o Mysql.
Para a minha supresa nossa aplicação funcionou 100% com o Mysql! As únicas coisas que quebraram foram alguns testes porque nós fomos IDIOTAS de olhar o SQL gerado por alguns scopos.
Pode parecer estranho tudo ter funcionado na mudança de banco mas existe uma explicação para isso. Mesmo a nossa aplicação tendo algumas queries bastante complexas elas são geradas utilizando a o ActiveRecord e o Arel e isso se mostrou uma sábia decisão. Se eu puder deixar uma única dica para você que está lendo isso ela é: Não escreva em SQL, gere o SQL!
Resolvido o problema da aplicação o passo seguinte era a migração dos dados já existentes. Para essa tarefa contamos com o apoio do Vitor Mazzi que com meia dúzia de comandos e expressões regulares conseguiu migrar nossa base.
Foi nesse momento que eu e o Vitor Mazzi percebemos algo que estava na nossa cara desde o início. A migração poderia ser fatiada em partes e a primeira dela seria por no ar uma versão (ainda no Heroku) usando o Mysql do RDS. Após alguns testes em sandbox colocamos no ar essa versão e tivemos um downtime de apenas 15 minutos.
Nesse momento também migramos para usar o ElasticCache mas esse passo nem merece destaque já que foi apenas trocar uma URL.
O passo seguinte foi migrar os nossos workers para uma instância do EC2. Com o auxilio da equipe do Vitor Mazzi fizemos as modificações necessárias no nosso gerenciador de deploy. Após algumas idas e vindas conseguimos subir uma maquina para processar nossos jobs e desligamos os workers do Heroku.
Após esse passo nosso problema principal estava resolvido. Agora nossos workers funcionavam perfeitamente na Amazon e nossa parte WEB no Heroku. Agora com um peso muito menor nas costas trabalhamos para subir as maquinas WEB na Amazon e trocamos nosso DNS. A parte legal é que como era a mesma versão no Heroku e na Amazon (ambas usando o RDS) o downtime dessa etapa foi zero.
Como passo final tivemos que ajustar algumas tarefas de manutenção e alguns scripts mas nada que mereça destaque.
O processo de migração foi trabalhoso e cheio de desafios porém nada de outro mundo. O maior desafio foi manter a aplicação no ar o maior tempo possível e acho que dado ao tamanho deste desafio saimos vitoriosos com um downtime de apenas 15 minutos.
A maior surpresa que nós timemos é que nosso response time caiu pela metada após a migração. Não vou discutir esse ponto pois ele envolve diversos aspectos técnicos.
Da data da migração até hoje nossa estrutura mudou um pouco, se estabilizou e a decisão de migrar para a Amazon se mostrou acertada. Desde então não tivemos nenhum problema com os nossos servidores e estamos mantendo um excelente SLA.
Como tudo na vida essa migração deixou bem claro para a gente os lados posítivos e negativos de cada uma das duas arquiteturas e isso irá balisar nossas decisões futuras.
@gilsondev isto sem falar em duplicar o banco de produção para ter redundância, o que dobraria o valor. Esta escala no banco também aumenta com a necessidade de mais cache (https://postgres.heroku.com/pricing), por aí vai.
Com relação aos dynos, muito também depende de ter um tempo de resposta rápido, já que um timeout no Heroku é de até 30 segundos por padrão. Ou seja, a demora para responder impacta em travar o dyno e piorar a experiência com o usuário. Usamos o New Relic para investigar gargalos e otimizar, seja no banco, código, etc.
Existe um case bem legal no Heroku que é o Rapportive (http://success.heroku.com/rapportive), recentemente comprado pelo LinkedIn. Em fevereiro de 2012 eles serviam 65 milhões de requisições para a sua siderbar e processavam 5 bilhões de mensagens por mês com 50 dynos e 15 workers.
A quantidade de dynos vai depender de ter um bom tempo de resposta e a quantidade de usuários da tua app, por exemplo, neste caso se o próprio trial/cadastro tem algum controle ou se é aberto.