Heroku - Distribuindo o aplicativo Rails monolítico

Question

Temos um aplicativo Rails monolítico considerável que tem algumas funções (entre parênteses está a% estimada do total da base de código):

• Site de marketing quando os usuários não estão conectados: página inicial, páginas de destino adicionais, páginas de SEO, páginas de registro / login etc. (5%)
• Páginas de login do usuário: depois de fazer login, os usuários podem ver o aplicativo da web e interagir com nosso produto (20%)
• Logadas nas páginas de administração: após o login, os administradores podem usar o CMS integrado para gerenciar tudo o que os usuários podem ver (75%)

Com o passar do tempo, a parte administrativa do site cresceu e ficou muito maior do que todo o resto. Todos os itens acima ainda estão em um único aplicativo do Rails sendo hospedado em um dyno Heroku Performance-M.

O problema é que, na maior parte do tempo, ter um alto uso de "admin" leva à diminuição do servidor inteiro, o que afeta usuários não administradores.

Por causa disso, queremos dividir a carga em vários dynos da web Heroku, mas gostaríamos de manter um único aplicativo Rails, por simplicidade e velocidade de desenvolvimento.

Qual é a melhor maneira de fazer isso?

Obrigado!

PS - Eu não tinha certeza se o Serverfault é o melhor lugar para postar isso ... mas foi muito confuso escolher um. Se eu escolhi o lugar errado para postar, por favor me avise e eu vou postar lá.

    

Answer 1

A resposta simples aqui seria dividir em dois dynos, e colocar um roteador de camada 7 como HAProxy, Varnish, ou o que quer que o heroku forneça na frente dele. / admin / * vai para um dyno, todo o resto vai para o outro. É o mesmo aplicativo em ambos, apenas não chamando certas partes do site.

NO ENTANTO

Isso só ajuda você se esse for um problema de desempenho do aplicativo. Se as páginas de administração estão, por exemplo, matando o banco de dados - então isso NÃO aumentará o desempenho nem um pouco.

Além disso, isso pressupõe que seu aplicativo pode realmente manipular o estado e as sessões corretamente - ao escalar de um servidor para dois, muitas coisas provavelmente sairão da madeira para morder você. Certifique-se de testar muito e se comunicar com os clientes quando a mudança está acontecendo. Planeje uma reversão, pois a implantação pode levar algumas tentativas.