Migrando para o AWS Cloud com escalonamento automático - onde colocar o Redis e o ElasticSearch?

Question

Estou tentando pesquisar este tópico, mas não encontrei nenhum lugar que recomende onde instalar serviços como Redis e ElasticSearch ao migrar para uma estrutura em nuvem.

Atualmente, estou executando um aplicativo Symfony2 em dois servidores estáticos - um deles está executando o MySQL e o outro é o servidor da Web voltado para o público, que também tem o Redis e o ElasticSearch em execução. Esses dois servidores são virtualizados, mas são estáticos em termos de não serem capazes de replicar no momento (vários aspectos ainda dependem do sistema de arquivos local).

O objetivo é migrar para a AWS e usar o escalonamento automático para ativar e desativar servidores da Web conforme necessário, mas não estou claro sobre o que devo colocar em cada instância do EC2. Deveriam ser apenas de responsabilidade única? Ou seja, configurar instâncias individuais para o (s) servidor (es) da web, Redis e ElasticSearch e, muito provavelmente, uma instância do RDS para o MySQL e apenas configurar o escalonamento automático no (s) servidor (es) da web?

Eu não prevejo precisar escalar o servidor ElasticSearch tão cedo, pois isso só está impulsionando a funcionalidade de pesquisa, mas é possível que o Redis precise ser replicado em algum momento - mas isso deve ser feito manualmente? Não tenho certeza de como isso pode ser feito automaticamente, já que cada instância precisa ser configurada para saber sobre seu mestre / escravo (s), tanto quanto eu sei. Eu apreciaria conselhos sobre isso.

Mais uma pergunta rápida enquanto eu estou aqui - como eu seria capaz de implantar alterações de código quando há servidores X atualmente ativos? Estou usando um script de implantação do Capifony (versão Symfony2 do Capistrano), que acho que pode manipular vários servidores com bastante facilidade especificando uma matriz de :domain endereços ... mas como isso deve ser tratado quando o número de servidores da Web puder variar?

    

Answer 1

A maneira como lidamos com isso é criando vários grupos de servidores em uma pilha em camadas (mesmo que atualmente um grupo precise apenas de uma instância). A primeira camada é o Elastic Load Balancer , claramente.

A segunda camada é um Grupo Auto Scaling de servidores da Web (zona de multi-disponibilidade). Estes inicializam um AMI personalizado projetado em um estado pronto para essa tarefa na inicialização. (Agora que nossos processos estão mais maduros, na verdade inicializamos uma AMI genérica que pode ser configurada automaticamente na inicialização usando o Chef.) Mas também fazemos um git pull do repositório de código de produção mais recente na inicialização, portanto não precisamos crie uma nova AMI com cada implantação de código. Isso também nos permite alterar configurações, como hosts de banco de dados, hosts Redis, etc. mais facilmente.

A terceira camada é para banco de dados e outros serviços, como ElasticSearch e Redis. Você pode hospedar todos os três serviços em uma caixa, então lidar com o gerenciamento de seus próprios escravos mysql, ou você pode hospedar Redis e ElasticSearch em sua própria caixa e usar o RDS da Amazon para seus serviços MySQL. Sua escolha, com base em se você deseja ou não gerenciar sua própria replicação / tolerância a falhas no MySQL.

Geralmente, a maneira mais simples é usar o Amazon RDS em uma configuração de zona de disponibilidade múltipla. Nós sempre tentamos implantar multi-AZ com tudo , então ainda estamos em funcionamento se um único AZ falhar. Em seguida, você executa uma instância menor para hospedar somente o Redis e o ElasticSearch.

Com o ElasticSearch , aqui vai uma dica que usamos para instalar o Rails: Instale e mantenha uma instância completa do seu aplicativo junto com o ElasticSearch na caixa. Em seguida, crie uma AMI para essa função (ou uma função de Chef). O motivo é que você pode executar as tarefas do utilitário na inicialização para criar seus índices ElasticSearch a partir do zero, se estiver inicializando uma AMI nova. Em seguida, coloque essa instância em um ASG multi-AZ também, com um mínimo e máximo de um servidor. Se essa caixa ou AZ morrer, o ASG inicializará um substituto e reconstruirá seus índices na inicialização e estará pronto para atender aos clientes.

Para Redis , há boas notícias no horizonte. O redis-cluster está chegando em breve, o que promete facilitar o gerenciamento do escalonamento de lojas de redis. Enquanto isso, você pode lidar com sua própria replicação ou experimente o Garantia, uma solução de servidor redis escalável hospedada , que está usando uma versão do cluster de redis em beta agora (atualmente limitado a us-east-1 region). Isso tem a vantagem de manter os mesmos endereços IP para suas configurações, independentemente do que acontecer com seus pools de instâncias.

Por fim, para proteger seus dados indo e voltando de seus bancos de dados, eu recomendaria criar isso dentro da parte da rede privada de uma nuvem privada virtual pública / privada . Isso configura sua própria rede privada que é isolada dos sniffers de pacotes. Você também pode empregar criptografia SSL para suas conexões de banco de dados MySQL.