J'hébergeais Magento sur AWS de 2011 à 2013. L'utilisation de l'infrastructure cloud plutôt que l'hébergement traditionnel dédié ou partagé présente de nombreux avantages, qui sont décrits de manière plus pertinente dans la rubrique DevOps, qui ne sont pas exclusives à AWS mais sont plus facilement activées via Son usage.
- Contrôle complet et flexible de votre planification de la capacité: accélérez les événements marketing, activez le provisioning dynamique via Elastic Beanstalk, réduisez les périodes de faible volume, développez un site en quelques semaines, supprimez-le et jetez-le.
- Configurez facilement les environnements dev / test / staging et répliquez les modifications entre eux.
- Hébergez vos pages d'administrateur sur un hôte distinct.
- Utilisez DynamoDB pour la gestion de session et ElastiCache pour le cache sans générer d’opérations supplémentaires, mais attention, ElastiCache ne fonctionne pas actuellement dans VPC.
- utilisez les ELB pour équilibrer la charge, mais méfiez-vous si les demandes prennent plus de 60 secondes, elles seront résiliées sans grâce.
- Utilisez AmazonSES pour envoyer des courriels (maintenant encore plus facile via SMTP classique), bien que des lacunes subsistent dans l'outillage permettant de suivre les retours / plaintes
- Utilisez AmazonS3 pour héberger des médias et Cloudfront pour CDN.
- Coût d'exploitation réduit pour l'activité de la base de données via RDS, qui comprend une restauration à un moment précis, un basculement automatique, des sauvegardes automatisées et des mises à niveau automatisées.
- La gestion DNS est très facile dans Route53, mais elle est généralement recommandée pour faciliter le mappage des sous-domaines aux équilibreurs de charge.
- VPC pour mettre toutes vos machines sur leur propre réseau privé afin d’avoir un contrôle plus granulaire et d’exposer les accès à votre guise via vos propres tunnels VPN.
- Métriques de performance et alertes simples (en dehors de l'utilisation de la mémoire et du disque) via CloudWatch et SNS
L'empreinte minimale sera de 1 ELB, 2 serveurs Web EC2 dans des AZ distinctes, 1 RDS multi-az, zone hébergée Route53 pour le domaine. Au départ, vous pouvez utiliser des sessions collantes sur l'ELB pour simplifier la gestion de session. Toutefois, à mesure que votre trafic augmente, vous souhaiterez déplacer le contenu multimédia vers un CDN (S3 & CloudFront) et des sessions hors de chaque ordinateur.
Zones que je n'ai pas regardées mais qui sont toujours prometteuses: scripts CloudFormation pour un déploiement plus facile d'une pile Magento, création d'une commande déchargée via DynamoDB et files d'attente de travail pour un débit de traitement supérieur (quelqu'un a déjà démarré un projet dans MongoDB via l'un des hackathons) récemment) et la mise en place d’une présence multirégionale via un routage basé sur le temps de latence avec Route53.
Je suppose que je suis un peu un évangéliste pour le cloud. C3.large est une taille d’instance décente pour les serveurs Web de production, mais je commencerais par la plus petite classe d’instances, puis mesurerais les performances et adapterais ou optimiserais le code à votre convenance. C’est pourquoi je demande à tout le monde de le faire. xhgui constamment.
Voici comment nous procédons pour la boutique en ligne Angrybirds:
Présentation en anglais à Magento Imagine 2012.
Présentation allemande à Meet Magento # 6.12
L'actuel "PHP Magazin" en allemand contient également un article de 6 pages (en allemand) avec quelques détails
Après avoir lu à plusieurs reprises toutes les présentations de Fabrizio mentionnées ci-dessus, je pense que cette réponse est vraiment la meilleure, même si je conviens qu'elle pourrait utiliser davantage d'explications et une extraction des idées clés des présentations (d'autant plus que le premier lien 404'd au moment où j'ai posté cette mise à jour).
La seule chose que j’aimerais ajouter aux concepts clés de ces présentations est que les avancées modernes dans les technologies AWS / concurrentes suggèrent quelques ajustements ... comme le fait que Cloudfront prend en charge l’amélioration des performances de gzip pour CDN, même si elle n’est pas aussi rapide. cela vous donne-t-il une terminaison SSL gratuite comme les offres CloudFlare . Leur DNS Route 53 n’est pas aussi rapide ni riche en fonctionnalités que CloudFlares, et AWS n’a pas non plus de protection pare-feu pour applications Web ou DDOS comparable, qui sont toutes incluses dans les offres CloudFlare ...
Il y a quelques autres moyens possibles d'améliorer la présentation originale de Fabrizio, mais je ne serais pas un bon consultant si je cédais TOUT ce que je savais sur chaque message StackExchange auquel j'ai répondu, maintenant, je le ferais? De plus, certaines des offres les plus récentes modifieraient de manière substantielle les suggestions des présentations originales. Toutes offrent encore d'excellentes performances, même si davantage pourraient être supprimées d'AWS avec différentes options utilisées.
Résumé des concepts clés :
Connaissez vos goulots d'étranglement intimement : et optimisez de manière appropriée. Chaque niveau de la pile comporte des goulots d'étranglement spécifiques (bande passante, unité centrale de traitement, base de données) et la résolution des problèmes à chaque niveau nécessite une solution différente optimisée pour chaque défi spécifique, même si la mise en cache est l'élément commun à tous les niveaux, ce qui conduit ...
Cachez tous les éléments : exploitez autant que possible les systèmes AWS (mise en cache des données de type Elasticache pour Redis / Memcache, actifs image, js et css de Cloudfront pour le cache les plus proches des utilisateurs finaux via CDN) et Varnish pour accélérer les réponses d'instance de serveur au niveau initial de l'actif mettre en cache les demandes de CDN. Assurez-vous également de compresser et de minimiser vos systèmes de déploiement AVANT de déployer sur un CDN.
La mise à l'échelle automatique est essentielle : Exigez des changements fréquemment et plus rapidement que vous ne pouvez les surveiller et réagir manuellement. L'adaptation à ces modifications en temps réel nécessite l'utilisation d'outils d'automatisation disponibles dans AWS, tels que les groupes Auto-Scaling, pour activer les éléments du système les mieux adaptés à cette tâche. AWS gère cela de manière transparente pour CloudFront CDN, Route 53 DNS, Elastic Load Balancers et S3 Buckets. Vous devez le gérer en dimensionnant et en mettant à l'échelle automatiquement les instances EC2, et en ajustant / dimensionnant uniquement les couches RDS et Elasticache.
L'automatisation est le seul moyen de lier efficacement tout cela : avec autant de composants interdépendants, dont certains doivent être initialisés au moment du déploiement, d'autres juste après le déploiement, la gestion d'un système optimisé pour des performances optimales nécessite une automatisation. Tirer parti du déploiement et de l’automatisation des systèmes pour l’effacement du cache, le réchauffement du cache, le traitement des images, etc., est le seul moyen raisonnable de gérer autant de sous-systèmes et de les maintenir en bon état et sans problèmes.
Mais en réalité, même sans l'automatisation des tests, ce n'est pas possible : avec autant de pièces mobiles, il y a quelque chose qui va rompre avec presque tous les changements. Et vous devrez changer pour suivre l'évolution de Magento et d'AWS. Et ceux-ci arriveront souvent . Afin de minimiser les coûts liés aux changements, toutes les formes de test doivent être mises en œuvre et automatisées - des tests unitaires aux tests d'intégration, en passant par les tests fonctionnels basés sur Sélénium du site réel lancé dans des configurations de test réelles imitant l'environnement de production. Maintenant, vous êtes vraiment heureux d'avoir automatisé tous vos processus de déploiement, n'est-ce pas?
la source
Une solution légèrement plus simple (!) Consiste simplement à installer comme vous le feriez sur n'importe quel autre VPS. Je propose une image gratuite depuis quelques années maintenant ... récemment, je me suis concentrée sur le nouveau centre de Sydney, en raison de son caractère local - pour plus de détails, visitez le site http://www.greengecko.co.nz/magento_on_amazon_ec2 si vous le souhaitez. êtes intéressé par ça. Pratiquement aucune douleur pour commencer - un clic et vous y êtes. Pointez votre navigateur sur l'instance pour plus de détails. Cela constituera un bon point de départ - mais examinez et modifiez /etc/rc.local si vous souhaitez en tirer parti.
Les choses importantes à réaliser est que les instances sont assez basses. Manifestement, le fait de dépenser beaucoup d’argent sur l’application améliore cela, mais pour un magasin en ligne de taille modérée, une instance moyenne est un minimum absolu, il suffit simplement d’obtenir plusieurs cœurs, et une taille vraiment importante est la plus petite nécessaire.
En outre, le stockage Amazon est lent. Pour cette raison, il est encore plus important que d'habitude de fournir tout ce que vous pouvez de la mémoire: il est impératif d'optimiser les bases de données, les caches sauvegardés, etc.
Une fois que vous avez trié cela, ça fonctionne bien. l'exigence d'exécuter dans un VPC si vous voulez> 1 adresse IP est vraiment ennuyeuse (surtout si vous ne le réalisez pas quand vous commencez!), et vraiment le seul piège que vous rencontrerez.
Il est simple d'étendre la plateforme «à la volée» - le seul goulot d'étranglement devient finalement la quantité de puissance de traitement disponible pour PHP (à part le code inefficace!), Et faire fonctionner plusieurs «moteurs» en parallèle est probablement l'option la plus simple: mettre les extras en ligne lorsque nécessaire.
Prendre plaisir!
Steve
la source
Nous utilisons RDS Multi AZ, deux serveurs optimisés NGINX, deux serveurs Varnish + ELB et les mêmes serveurs Varnish (port différent de Varnish) SSL Nginx. Nous utilisons Elasticache et avons très bientôt intégré DynamoDB à la gestion de session de Magento. Nous utilisons aussi S3 et Cloudfront.
J'ai eu une conversation intéressante avec une société d'hébergement basée au Royaume-Uni avec laquelle nous avons un serveur de 700 £ par mois. Tout ce qu'ils font, c'est ardoise Amazon AWS. Avec la configuration et l'optimisation correctes dans tous les domaines, y compris la réinsertion de Magento, la désactivation des modules, la fonction de comptage des catégories, etc., etc.
Nous pouvons actuellement obtenir 2 400 à plus de 3 000 visites par seconde sur les pages d'accueil, de catégorie, de produit et CMS (pages de vernis). Pages non vernies, nous pouvons traiter 400 à 500 demandes par seconde en fonction du magasin. Nous utilisons maintenant RDS Multi avec Reads.
Nous avons également mis Magento Admin sur son propre nœud pour exécuter le trafic et le trafic admin. http://administraton.mymagestore.com/admin
Nous n'avons jamais regardé en arrière. Nous utilisions l'un des meilleurs établissements britanniques, que ce soit des hôtes extrêmement coûteux.
la source
Vous pouvez utiliser presque tous les services AWS de base pour faire fonctionner votre magento. La solution la plus simple consisterait à utiliser EC2 avec Elastic IP et AWS VPC pour la configuration de la sécurité.
Une solution intelligente consiste à déployer deux serveurs: Web Server + Database. Le serveur Web inclut Magento + Nginx + PHP + Caching backend (Redis ou APC est une bonne option) et un serveur MySQL distinct dans le même sous-réseau. Ces serveurs peuvent être visibles entre eux via une adresse IP privée dans le réseau privé (configuré via VPC). Nginx est le serveur Web de choix dès lors qu'il peut livrer des fichiers statiques très rapidement.
Le serveur de base de données doit être caché de tout accès. Le serveur Web sera visible sur les ports 80 et 443. Il est possible d’attribuer Elastic IP au serveur Web. Plus tard, il sera utile de configurer DNS (par exemple via AWS Route 53) ou l'équilibrage de charge AWS.
Comme vous l'avez dit, une telle configuration peut être pénible. Ainsi, vous pouvez accélérer la configuration via Deploy4Me. Il configurera tous les systèmes de sécurité, les ordinateurs virtuels et les réseaux mentionnés en quelques minutes.
la source