Executando o Magento em um ambiente da AWS


54

Hospedar Magento, como todos sabem, não é como hospedar outros aplicativos PHP. Quão viável é executar o Magento em um ambiente Amazon Web Services em 2013?

Que combinação mágica de serviços da AWS faz sentido usar com o Magento? Quais níveis são os padrões inteligentes para uma loja "run of the mill"? (sim, eu sei, não há lojas nas fábricas)

Quais (EBS?) Devem ser evitados?

Alguma dica, truque, estratégia de implantação para evitar semanas de dor ao obter essa configuração?

Respostas:


44

Eu estava hospedando o Magento na AWS em 2011 até 2013. Muitas das coisas que você ganha com o uso da infraestrutura em nuvem, em vez da hospedagem tradicional dedicada ou compartilhada, são descritas de forma mais relevante no tópico DevOps, que não são exclusivas da AWS, mas são mais facilmente habilitadas por meio da seu uso.

  • Controle completo e flexível do seu planejamento de capacidade - expanda antes dos eventos de marketing, habilite o provisionamento dinâmico via Elastic Beanstalk, reduza durante períodos de baixo volume, gere um site em algumas semanas, reduza-o e jogue-o fora.
  • Configure facilmente ambientes de desenvolvimento / teste / armazenamento temporário e replique as alterações entre eles.
  • Hospede suas páginas de administrador em um host separado.
  • Use o DynamoDB para gerenciamento de sessões e o ElastiCache para cache sem sobrecarga de operações adicionais; cuidado: o ElastiCache atualmente não funciona no VPC.
  • use ELBs para balanceamento de carga, mas cuidado, se as solicitações demorarem mais de 60 segundos, elas serão encerradas sem graça
  • Use o AmazonSES para enviar e-mails (agora ainda mais fácil via SMTP comum), embora ainda existam lacunas nas ferramentas para rastrear devoluções / reclamações
  • Use o AmazonS3 para hospedagem de mídia e o Cloudfront para CDN.
  • Custo de operações reduzido para a atividade do banco de dados via RDS, que apresenta restauração pontual, failover automatizado, backups automatizados e atualizações automáticas.
  • O gerenciamento de DNS é super fácil no Route53, mas geralmente é recomendado para facilitar o mapeamento de subdomínios para balanceadores de carga.
  • VPC para colocar todas as suas máquinas em sua própria rede privada para ter um controle mais granular e expor o acesso como achar melhor através de seus próprios túneis VPN.
  • Métricas e alertas de desempenho fáceis (além do uso da memória e do disco) via CloudWatch e SNS

O espaço mínimo será de 1 servidor ELB, 2 servidores EC2 em AZs separados, 1 zona hospedada RDS com vários azs e Route53 para o domínio. Inicialmente, você pode usar sessões persistentes no ELB para simplificar o gerenciamento de sessões, mas, à medida que o tráfego aumenta, você deseja mover a mídia para uma CDN (S3 e CloudFront) e sessões fora das máquinas individuais.

Áreas que eu não procurei, mas que ainda são promissoras: scripts CloudFormation para implantação mais fácil de uma pilha Magento, transferência de criação de pedidos via DynamoDB e filas de trabalhadores para maior taxa de saída de caixas (alguém já iniciou um projeto para fazer isso via MongoDB em um dos hackathons recentemente) e configurar uma presença de várias regiões por meio de roteamento baseado em latência com o Route53.

Eu acho que sou meio evangelista em nuvem. Específico para a AWS, o c3.large é um tamanho de instância decente para servidores da web de produção, mas eu começaria com o menor de cada classe de instância e media o desempenho e escalava ou otimizava o código como preferir, e é por isso que indico todo mundo xhgui constantemente.


Na verdade, eu sugeriria não usar o RDS para o banco de dados. Você não tem controle sobre a otimização do servidor, algo que precisa ter um bom desempenho, o Magento precisa. Há um white paper que o Magento publicou sobre o ajuste de uma pilha que mostra os detalhes sobre o ajuste do MySql. Basicamente, se você planeja escalar ou esperar a velocidade máxima, deve executar seu próprio servidor de banco de dados.
Davidalger #

3
@davidalger Desculpe, mas esse é um conselho terrível. Você precisa ler sobre os grupos de parâmetros do banco de dados e seu uso. aws.amazon.com/rds/faqs/#34 Além disso, há muito mais ganho de desempenho em cache ou otimização de código do que qualquer coisa que você possa fazer no banco de dados, a menos que esteja concentrado inteiramente nos processos de checkout, nesse caso, você deve observar github.com/magento-hackathon/MongoDB-OrderTransactions
Ralph Tice

3
Eu certamente usaria o RDS. No máximo, você perde a capacidade de criar funções do sistema, é isso. É altamente otimizado, altamente disponível e você pode gerar replicantes com apenas alguns cliques. Os benefícios superam de longe quaisquer possíveis inconvenientes.
22413 philwinkle

E o EBS (Block Storage)? Por que você não incluiu isso também na sua configuração? Além disso, qual é a maneira recomendada de sincronizar o diretório de mídia entre os vários EC2s?
Dayson 22/06/2013

11
@Dayson Boa pergunta. O Magento é bastante pesado de E / S, mesmo ao delegar o gerenciamento de sessões e cache aos sistemas de cache de memória. É por isso que você pode querer considerar o EBS. Atualmente, não estamos na AWS, mas executamos nosso ambiente Magento em uma pilha com balanceamento de carga de alta disponibilidade, na qual você teria o mesmo problema com o armazenamento CMS, como o diretório / media. Há 2 meses, montamos um NFS em nossos servidores da web e vinculamos nossos diretórios / home / user (onde todos os dados da web estão armazenados) nesse ponto de montagem. Do ponto de vista de usabilidade, é brilhante. Em termos de desempenho, ele ainda pode usar alguns ajustes.
Jaap Haagmans

30

É assim que fazemos na loja virtual do Angrybirds:

Apresentação em inglês no Magento Imagine 2012.

Apresentação em alemão no Meet Magento # 6.12

O alemão atual "PHP Magazin" também possui um artigo de 6 páginas (em alemão) com alguns detalhes

Depois de ler todas as apresentações de Fabrizio vinculadas acima várias vezes, acho que essa resposta é realmente a melhor, embora eu concorde que poderia usar mais explicações e uma extração das idéias principais das apresentações (especialmente porque o primeiro link original já havia foi 404 quando eu publiquei esta atualização).

A única coisa que gostaria de acrescentar aos conceitos-chave nas apresentações é que os avanços modernos nas tecnologias da AWS / concorrentes sugerem alguns ajustes ... como o fato de o Cloudfront oferecer suporte ao gzip para melhorias de desempenho da CDN agora, embora não seja tão rápido nem isso fornece rescisão SSL gratuita, como a CloudFlare oferece. O DNS da Route 53 também não é tão rápido ou rico em recursos como o CloudFlares, nem a AWS possui uma proteção comparável ao Web Application Firewall ou DDOS, todos incluídos nas ofertas do CloudFlare ...

Existem algumas outras maneiras possíveis de melhorar a apresentação original de Fabrizio, mas eu não seria um bom consultor se desse tudo TUDO que sabia em todas as postagens do StackExchange que respondi, agora? Além disso, algumas das ofertas mais recentes alterariam substancialmente as sugestões nas apresentações originais, as quais AINDA oferecem ótimo desempenho, mesmo que mais possam ser extraídas da AWS com diferentes opções usadas.

Resumo dos principais conceitos :

  1. Conheça seus gargalos intimamente : e otimize adequadamente. Cada camada da pilha possui gargalos específicos (largura de banda, CPU, banco de dados) e a solução dos gargalos em cada camada exige uma solução diferente otimizada para cada desafio específico, embora o cache realmente seja o elemento comum em todos os níveis, o que leva a ...

  2. Cache de todas as coisas : aproveite os sistemas da AWS sempre que possível (cache de dados do tipo Elasticache para Redis / Memcache, imagem de Cloudfront for Caching, js e ativos de css mais próximos dos usuários finais via CDN) e Varnish para acelerar as respostas da instância do servidor ao nível inicial de ativos solicitações de armazenamento em cache da CDN. Além disso, certifique-se de compactar e mininificar em seus sistemas de implantação ANTES de implantar nas CDNs

  3. O escalonamento automático é essencial : a demanda muda frequentemente e com mais rapidez do que você pode monitorar e reagir manualmente. A adaptação a essas alterações em tempo real requer o uso de ferramentas de automação disponíveis na AWS, como o Auto-Scaling Groups, para ativar as partes do sistema mais adequadas a esta tarefa. A AWS lida com isso de forma transparente para CloudFront CDN, Route 53 DNS, Elastic Load Balancers e S3 Buckets, você precisa lidar com isso dimensionando e dimensionando automaticamente as instâncias do EC2 e apenas dimensionando / ajustando as camadas RDS e Elasticache

  4. A automação é a única maneira de vincular tudo isso efetivamente : com tantos componentes inter-relacionados, alguns dos quais precisam ser inicializados no momento da implantação, alguns logo após a implantação, o gerenciamento de um sistema ajustado para obter o desempenho ideal requer automação. Alavancar a implantação e a automação de sistemas para limpeza de cache, aquecimento de cache, processamento de imagens, etc. é a única maneira razoável de gerenciar tantos subsistemas diferentes e mantê-los bem lubrificados e sem problemas.

  5. Mas, na verdade, isso não é possível sem a automação de testes : com tantas partes móveis, algo quebrará com quase qualquer alteração. E você precisará alterar para acompanhar os desenvolvimentos no Magento e na AWS. E isso vai acontecer muitas vezes . Portanto, para manter o custo da mudança minimizado, todas as formas de teste precisam ser implementadas e automatizadas totalmente - desde testes de unidade até testes de integração, até testes funcionais baseados em Selenium do site real, lançados em configurações de testes reais que imitam o ambiente de produção. Agora você está realmente feliz por ter automatizado todos os seus processos de implantação, certo?


2
downvoting por ser um monte de links
Ralph Tice

9
@RalphTice Eu posso estar em minoria aqui, mas muitos links são bons, especialmente quando são tão relevantes quanto os da fbmc. Nem todo mundo quer colocar seu conteúdo em domínio público / creative-commons, soltando-o em uma resposta do StackExchange.
Alan Storm

4
@ AlanStorm Eu não quero dizer que todo mundo deveria votar, porque é um monte de links, mas apenas deixando uma explicação para o motivo pelo qual eu escolhi votar. Prefiro obter conteúdo do que links para conteúdo quando chego a um site da SE e uso a SE para evitar especificamente conteúdo em vídeo e que não seja em inglês.
Ralph Tice

3
O link solitário é considerado uma resposta ruim (consulte as perguntas frequentes ), pois não faz sentido por si só e não é garantido que o recurso de destino esteja vivo no futuro . Seria preferível incluir aqui as partes essenciais da resposta e fornecer o link para referência.
j0k

2
O primeiro link parece não existir mais. Provavelmente isso pode substituí-lo: slideshare.net/aoemedia/angrybirds-magento-cloud-deployment
ermannob

4

Uma solução um pouco mais simples (!) É apenas para instalar como você faria em qualquer outro VPS. Há alguns anos que ofereço uma imagem gratuita ... ultimamente, tenho me concentrado no novo Sydney DC por ser local - mais detalhes em http://www.greengecko.co.nz/magento_on_amazon_ec2 se você está interessado nisso. Praticamente zero dor ao começar - um clique e você está lá. Aponte seu navegador para a instância para obter mais detalhes. Isso será um bom ponto de partida - mas olhe e modifique o /etc/rc.local se você quiser desenvolver isso.

O importante é perceber que as instâncias são de baixa potência. Obviamente, jogar muito dinheiro no aplicativo melhora isso, mas mesmo para uma loja virtual moderadamente pequena, uma instância média é um mínimo absoluto, apenas para obter vários núcleos, e realmente grande é o menor necessário.

Além disso, o armazenamento da Amazon é lento. Por isso, é ainda mais importante do que o habitual fornecer tudo o que você puder da memória: bancos de dados de ajuste, caches com suporte à memória etc. são imperativos.

Depois de resolver isso, ele funciona bem. o requisito para executar em uma VPC se você quiser> 1 endereço IP é realmente irritante (especialmente se você não perceber isso quando começar!), e realmente a única pegadinha que você encontrará.

É simples expandir a plataforma 'on the fly' - eventualmente o único gargalo se torna a quantidade de poder de processamento disponível para PHP (código ineficiente à parte!), E executar vários 'mecanismos' em paralelo é provavelmente a opção mais simples - colocar extras online quando necessário.

Desfrutar!

Steve


Agora, a VPC é padrão para novas contas da AWS. aws.typepad.com/aws/2013/03/…
Ralph Tice

4

Estamos executando o RDS Multi AZ, dois servidores NGINX otimizados, 2 servidores de verniz + ELB e os mesmos servidores de verniz (porta diferente para o verniz) SSL Nginx. Usamos o Elasticache e rapidamente integramos o DynamoDB para o gerenciamento de sessões do Magento. Também usamos o S3 e o Cloudfront.

Eu tive um bate-papo interessante com uma empresa de hospedagem sediada no Reino Unido com a qual temos um servidor de £ 700 por mês. Tudo o que eles fazem é escolher o Amazon AWS. Com a configuração e otimização corretas em todas as áreas, incluindo a remoção do Magento, módulos desativados, função de contagem de categorias, etc., etc (nós ajustamos os servidores NGINX e Varnish para ficar na frente do servidor de banco de dados que equilibra a carga).

Atualmente, podemos obter 2400 - 3000 + hits por segundo nas páginas inicial, categoria, produto e CMS (páginas de verniz). Páginas sem verniz, podemos processar de 400 a 500 solicitações por segundo, dependendo da loja. Agora estamos usando o RDS Multi com leituras.

Também colocamos o Magento Admin em seu próprio nó para executar crons e tráfego de administrador. http://administraton.mymagestore.com/admin

Nós nunca olhamos para trás. Estávamos usando um dos melhores do Reino Unido, sejam eles anfitriões extremamente caros.


11
Cuidado: as sessões de administrador não funcionarão com o DynamoDB devido ao seu tamanho. Eu testaria com cuidado - o DynamoDB aumentou o tamanho máximo do item de 64 KB para 256 KB, mas isso ainda pode não ser grande o suficiente. Eu trabalhei com isso usando sessões de arquivo, pois tinha apenas um nó de administrador e muitos nós de front-end e, portanto, implantei local.xml separado para front-end de administração versus web.
precisa

2

Você pode usar quase todos os serviços básicos da AWS para fazer seu magento funcionar. O cenário mais simples seria usar o EC2 com IP elástico e AWS VPC para configuração de segurança.

A maneira inteligente é ter a implantação de 2 servidores: servidor Web + banco de dados. O servidor Web inclui o cache de Magento + Nginx + PHP + back-end (Redis ou APC é uma boa opção) e um servidor MySQL separado na mesma sub-rede. Esses servidores podem estar visíveis entre si via IP privado na rede privada (configurada via VPC). O Nginx é o servidor da Web escolhido assim que ele pode fornecer arquivos estáticos super rápido.

O servidor de banco de dados deve estar oculto de qualquer acesso. O servidor da Web estará visível nas portas 80 e 443. É possível alocar o Elastic IP ao servidor da Web. Posteriormente, será útil configurar o DNS (por exemplo, pela AWS Route 53) ou pelo balanceamento de carga da AWS.

Como você mencionou, pode ser difícil fazer essa configuração. Portanto, você pode acelerar a configuração via Deploy4Me. Ele irá configurar toda a segurança mencionada, VMs e redes em minutos.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.