Esecuzione di Magento in un ambiente AWS

Ospitare Magento, come tutti sanno, non è come ospitare altre applicazioni PHP. Quanto è possibile eseguire Magento in un ambiente Amazon Web Services nel 2013?

Quale combinazione magica di servizi AWS ha senso usare con Magento? Quali sono i livelli predefiniti intelligenti per un negozio "run of the mill"? (sì, lo so, non ci sono negozi dei mulini)

Quali (EBS?) Dovrebbero essere evitati?

Eventuali suggerimenti, trucchi, strategie di distribuzione per evitare settimane di dolore ottenere questa configurazione?

Ho ospitato Magento su AWS nel 2011 fino al 2013. Molte delle cose che guadagni dall'utilizzo dell'infrastruttura cloud piuttosto che dall'hosting tradizionale dedicato o condiviso sono descritte in modo più pertinente nell'argomento DevOps, che non è esclusivo di AWS ma è più facilmente abilitato tramite il suo uso.

• Controllo completo e flessibile della pianificazione della capacità: scalare in anticipo rispetto agli eventi di marketing, abilitare il provisioning dinamico tramite Elastic Beanstalk, ridimensionare durante periodi di volume ridotto, girare un sito in un paio di settimane, demolirlo e buttarlo via.
• Imposta facilmente ambienti di sviluppo / test / staging e replica le modifiche tra di loro.
• Ospita le tue pagine di amministrazione su un host separato.
• Usa DynamoDB per la gestione delle sessioni ed ElastiCache per la cache senza incorrere in ulteriori operazioni generali, ma ElastiCache attualmente non funziona in VPC.
• utilizzare gli ELB per il bilanciamento del carico, ma attenzione se le richieste impiegano più di 60 secondi, verranno terminate in modo sfortunato
• Utilizza AmazonSES per l'invio di e-mail (ora ancora più semplice tramite il normale SMTP), sebbene esistano ancora lacune negli strumenti per il monitoraggio di rimbalzi / reclami
• Usa AmazonS3 per l'hosting di contenuti multimediali e Cloudfront per CDN.
• Riduzione dei costi operativi per l'attività del database tramite RDS, che offre ripristino temporizzato, failover automatico, backup automatici e aggiornamenti automatici.
• La gestione DNS è semplicissima in Route53, ma generalmente è consigliata per mappare facilmente i sottodomini ai bilanciatori di carico.
• VPC per mettere tutte le tue macchine sulla propria rete privata per avere un controllo più granulare ed esporre l'accesso come ritieni opportuno tramite i tuoi tunnel VPN.
• Metriche e avvisi di prestazioni semplici (oltre all'utilizzo della memoria e dell'utilizzo del disco) tramite CloudWatch e SNS

L'impronta minima sarà 1 ELB, 2 server web EC2 in AZ separate, 1 RDS multi-az, zona ospitata da Route53 per il dominio. Inizialmente puoi utilizzare le sessioni appiccicose sull'ELB per semplificare la gestione delle sessioni, ma all'aumentare del traffico ti consigliamo di spostare i contenuti multimediali in un CDN (S3 e CloudFront) e le sessioni fuori dalle singole macchine.

Aree che non ho guardato ma che sono ancora promettenti: script CloudFormation per una più facile distribuzione di uno stack Magento, offload della creazione di ordini tramite DynamoDB e code di lavoro per una maggiore velocità di checkout (qualcuno ha già avviato un progetto per farlo tramite MongoDB in uno degli hackathon di recente) e impostare una presenza multi-regione tramite routing basato sulla latenza con Route53.

Immagino di essere una specie di evangelista per il cloud. Specifico per AWS, c3.large ha una dimensione dell'istanza decente per i server web di produzione, ma inizierei con il più piccolo di ogni classe di istanza e misurerei le prestazioni e ridimensionerei o ottimizzerei il codice come ritieni opportuno, motivo per cui rimando tutti a xhgui costantemente.

Ecco come lo facciamo per il webshop di Angrybirds:

Presentazione inglese a Magento Imagine 2012.

Presentazione tedesca a Meet Magento # 6.12

L'attuale "PHP Magazin" tedesco ha anche un articolo di 6 pagine (in tedesco) con alcuni dettagli

Avendo letto tutte le presentazioni di Fabrizio collegate più volte sopra, penso che questa risposta sia davvero la migliore, anche se concordo sul fatto che potrebbe usare più spiegazioni e un'estrazione delle idee chiave dalle presentazioni (soprattutto perché il primo link originale aveva già stato 404 quando ho pubblicato questo aggiornamento).

L'unica cosa che aggiungerei ai concetti chiave nelle presentazioni è che i moderni progressi nelle tecnologie AWS / della concorrenza suggerirebbero alcune modifiche ... come il fatto che Cloudfront supporta gzip per i miglioramenti delle prestazioni della CDN ora, anche se non è veloce come né ti dà la terminazione SSL gratuita come le offerte CloudFlare ? Anche il DNS Route 53 non è così veloce o ricco di funzionalità come CloudFlares, né AWS ha un Web Application Firewall o una protezione DDOS comparabili, tutti inclusi nelle offerte CloudFlare ...

Ci sono alcuni altri modi possibili per migliorare la presentazione originale di Fabrizio, ma non sarei un buon consulente se cedessi TUTTO ciò che sapevo su ogni post di StackExchange a cui ho risposto, ora lo farei? Inoltre, alcune delle offerte più recenti cambieranno sostanzialmente i suggerimenti delle presentazioni originali, tutte ancora STILL offrono grandi prestazioni, anche se si potrebbe spremere di più da AWS con diverse opzioni utilizzate.

Riepilogo dei concetti chiave :

1. Conosci a fondo i tuoi colli di bottiglia : e ottimizza in modo appropriato. Ogni livello dello stack ha colli di bottiglia specifici (larghezza di banda, CPU, database) e la risoluzione dei colli di bottiglia a ciascun livello richiede una soluzione diversa ottimizzata per ogni sfida specifica, sebbene la cache davvero sia l'elemento comune a ogni livello, che porta a ...

2. Cache All The Things : sfrutta i sistemi AWS ove possibile (Elasticache per Redis / Memcache cache dei dati di tipo, Cloudfront per memorizzazione nella cache di immagini, js e css asset più vicini agli utenti finali tramite CDN) e Varnish per accelerare le risposte delle istanze del server a livello di asset iniziale richieste di memorizzazione nella cache da CDN. Inoltre, assicurati di comprimere e minimizzare nei tuoi sistemi di distribuzione PRIMA di eseguire la distribuzione su CDN

3. Il ridimensionamento automatico è essenziale : la domanda cambia di frequente e più rapidamente di quanto sia possibile monitorare e reagire manualmente. L'adattamento a questi cambiamenti in tempo reale richiede l'utilizzo di strumenti di automazione disponibili in AWS come Auto-Scaling Group per far girare i pezzi del sistema più adatti a questo compito. AWS gestisce questo in modo trasparente per CloudFront CDN, Route 53 DNS, bilanciatori di carico elastici e secchi S3, devi gestirlo dimensionando e ridimensionando automaticamente le istanze EC2 e semplicemente dimensionando / ottimizzando i livelli RDS ed Elasticache

4. L'automazione è l'unico modo per legare efficacemente tutto questo : con così tanti componenti correlati, alcuni dei quali devono essere inizializzati al momento dell'implementazione, alcuni subito dopo l'implementazione, la gestione di un sistema ottimizzato per prestazioni ottimali richiede automazione. Sfruttare la distribuzione e l'automazione dei sistemi per la pulizia della cache, il riscaldamento della cache, l'elaborazione delle immagini, ecc. È l'unico modo ragionevole per gestire questi sottosistemi diversi e mantenerli ben oliati e senza problemi.

5. Ma in realtà ciò non è possibile senza l'automazione del test : con queste molte parti mobili, qualcosa si romperà con quasi ogni cambiamento. E dovrai cambiare per stare al passo con gli sviluppi di Magento e AWS. E quelli accadranno spesso . Pertanto, per ridurre al minimo i costi delle modifiche, è necessario implementare e automatizzare completamente tutte le forme di test: dai test unitari ai test di integrazione ai test funzionali basati sul selenio del sito effettivo, lanciati in configurazioni di test reali che imitano l'ambiente di produzione. Ora sei DAVVERO contento di aver automatizzato tutti i tuoi processi di implementazione, giusto?

Una soluzione leggermente più semplice (!) È solo l'installazione come su qualsiasi altro VPS. Sto offrendo un'immagine gratuita da alcuni anni ... ultimamente mi sono concentrato sulla nuova Sydney DC perché è locale - maggiori dettagli su http://www.greengecko.co.nz/magento_on_amazon_ec2 se tu sei interessato a questo. Praticamente zero dolore per iniziare - un clic e sei lì. Punta il tuo browser sull'istanza per maggiori dettagli. Questo sarà un buon punto di partenza, ma cerca e modifica /etc/rc.local se vuoi costruirlo.

La cosa importante da capire è che le istanze sono piuttosto a bassa potenza. Ovviamente, lanciare un sacco di soldi nell'app migliora questo, ma anche per un negozio Web moderatamente piccolo un'istanza media è un minimo assoluto, solo per ottenere più core, e davvero grande è il più piccolo necessario.

Inoltre, lo spazio di archiviazione di Amazon è lento. Per questo motivo, è ancora più importante del solito fornire tutto ciò che è possibile dalla memoria: ottimizzare i database, le cache con memoria, ecc. Sono indispensabili.

Una volta che hai ordinato, funziona bene. il requisito di eseguire in un VPC se si desidera> 1 indirizzo IP è davvero fastidioso (soprattutto se non ti rendi conto di questo quando inizi!) e davvero l'unico gotcha che ti imbatterai.

È semplice espandere la piattaforma "al volo" - alla fine l'unico collo di bottiglia diventa la quantità di potenza di elaborazione disponibile per PHP (codice inefficiente a parte!), E l'esecuzione di più "motori" in parallelo è probabilmente l'opzione più semplice - portando extra online quando necessario.

Godere!

Steve

Stiamo eseguendo RDS Multi AZ, due server ottimizzati NGINX, 2 server Varnish + ELB e sugli stessi server Varnish (porta diversa da Varnish) SSL Nginx. Usiamo Elasticache e integriamo presto in modo accorto DynamoDB per la gestione delle sessioni di Magento. Utilizziamo anche S3 e Cloudfront.

Ho avuto un'interessante chat con una società di hosting con sede nel Regno Unito con un server da £ 700 al mese. Tutto ciò che fanno è ardesia Amazon AWS. Con la corretta configurazione e ottimizzazione in tutte le aree, tra cui lo striping di Magento, la disabilitazione dei moduli, la funzione di conteggio delle categorie, ecc. Ecc. (Abbiamo messo a punto i server NGINX e Varnish per sederci di fronte al server del database che bilancia il carico).

Al momento possiamo ottenere 2400 - 3000 + hit al secondo nelle pagine home, categoria, prodotto e CMS (pagine di vernice). Pagine non verniciate, possiamo elaborare 400 - 500 richieste al secondo a seconda del negozio. Ora stiamo utilizzando RDS Multi con letture.

Mettiamo anche Magento Admin sul suo stesso nodo per eseguire croni e amministrare il traffico. http://administraton.mymagestore.com/admin

Non abbiamo mai guardato indietro. Stavamo utilizzando uno dei migliori del Regno Unito, tutti host estremamente costosi.

Puoi utilizzare quasi tutti i servizi AWS di base per far funzionare magento. La scenografia più semplice sarebbe quella di utilizzare EC2 con Elastic IP e AWS VPC per la configurazione della sicurezza.

Il modo più intelligente è avere una distribuzione di 2 server: Web Server + Database. Il server Web include Magento + Nginx + PHP + backend Caching (Redis o APC è una buona opzione) e un server MySQL separato nella stessa sottorete. Questi server possono essere visibili tra loro tramite IP privato nella rete privata (configurato tramite VPC). Nginx è il server Web preferito non appena è in grado di fornire file statici in modo superveloce.

Il server di database dovrebbe essere nascosto da qualsiasi accesso. Il server Web sarà visibile sulle porte 80 e 443. È possibile allocare Elastic IP al server Web. In seguito sarà utile configurare DNS (ad esempio tramite AWS Route 53) o il bilanciamento del carico AWS.

Come hai detto, può essere una seccatura fare una tale configurazione. Quindi, puoi velocizzare la configurazione tramite Deploy4Me. Configurerà tutta la sicurezza, le macchine virtuali e le reti menzionate in pochi minuti.