EC2 Architecture design pour site Web

Question

J'ai un site que je vais bientôt lancer. Vous n'êtes pas tout à fait sûr de l'intensité du trafic. J'utilise Django + Nginx + Gunicorn + Mysql. Il y aura un support pour SSL/HTTPS. En guise de point de départ, je pense à équilibrer deux micro-instances par l'équilibrage de charge élastique. La base de données MySQL sera sur l'une des instances. Si le trafic devient lourd, je pourrais déplacer des fichiers statiques vers un CDN. Les micro-instances servent de serveurs frontaux chargés de générer uniquement du HTML/JSON et de servir des fichiers statiques. Les fichiers statiques sont principalement CSS/js et plusieurs images (pas beaucoup). Je prévois que la base de données sera lue et lourde.

Questions:

• En supposant que le trafic augmente à 100k de pages vues par jour, seront les 2 cas micro suffisent? Dois-je déplacer la base de données vers une instance distincte? Et quel type d'instance serait bon?

• Que faire si le trafic est seulement 1k pages vues par jour?

• Combien de processus gunicorn fonctionnent sur une micro-instance?

• En général, quel type de métrique m'aidera à déterminer de quel type et de combien d'instances aurais-je besoin? Quelle est la méthodologie pour décider du type d'architecture dont j'aurais besoin?

Merci beaucoup!

Answer 1

1. Probablement pas. Les micro-instances ne sont pas conçues pour les charges de production lourdes. Ils utilisent un profil CPU burstable. Ils peuvent fonctionner à 2 ECU pendant quelques minutes, puis ils se verrouillent à 0,1-0,2 ECU. J'ai tendance à aimer c1.medium, mais petit peut être suffisant pour vous. Peut-être, tant qu'ils sont étalés pendant la journée et pas tous dans une courte fenêtre.

2. 1-2 par cœur. Micro a seulement 1 noyau.

3. Chaque application est différente. La meilleure chose à faire est de lancer vos propres repères en utilisant des outils tels que ab (Apache Bench)

Answer 2

Complètement dépendant de la façon dont dynamique le site prévoit d'être. Les utilisateurs génèrent-ils du contenu vers le service ou sont-ils principalement statiques? Si vous avez l'intention de mettre beaucoup de choses comme des avatars, des images, etc. dans S3, mettez-le sur Cloudfront. Pareil avec vos fichiers statiques ... garder vos serveurs sans état vous permettra d'évoluer facilement.

A 100k pages vues par jour vous aurez certainement du mal avec des micros ... vous ne devriez vraiment utiliser ceux dans un environnement de développement et ne sont pas destinés à gérer des choses comme le service aux utilisateurs. J'utiliserais au moins une seule petite instance en face d'un Load Balancer, cela peut sembler étrange mais vous serez capable de lancer une autre instance quand les choses seront occupées sans avoir à jouer avec Route 53 ou potentiellement faire échouer votre site. Le contenu sans état est très important maintenant, car les ressources générées par les utilisateurs ne peuvent être référencées qu'à partir d'une instance et pas de l'autre.

Dans les pages vues 1k, j'utiliserais encore un petit pour le service web et un autre petit pour MySQL.

Vous pouvez également lancer des répliques en lecture en un clic pour obtenir un pic. Regardez dans l'Amazon CLI ainsi pour automatiser ces tâches. Cronjobs en fera un jeu d'enfant si vous êtes stressé par le temps, sinon Opsworks, Cloudformation et Auto-Scaling vous aideront. Oh et à titre de comparaison, un serveur d'applications qui exécute Apache, PHP avec APC pour servir nos utilisateurs commence à se battre avec environ 80 utilisateurs simultanés. Fonctionne sur une petite instance EC2 avec un petit RDS (qui se trouve à environ 15% en même temps que le serveur d'applications descend)

Answer 3

Suivre le diagramme d'architecture des meilleures pratiques d'AWS est toujours un bon début.

http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_web_01.pdf

je vous conseille fortement de stocker tous vos fichiers sur Amazon S3, et utilisez une Route 53 DNS (ou tout autre DNS si vous voulez) devant elle pour distribuer les fichiers, parce que plus tard si vous décidez d'utiliser CloudFront CDN, il sera très facile de changer. Et, juste pour mentionner l'utilisation de CloudFront comme CDN augmentera votre coût seulement un peu, pas une énorme chose.

Peu importe le scénario, si nous parlons de la production, vous devriez certainement opter pour des instances distinctes, au moins 1 EC2 pour le web et 1 EC2/RDS pour la base de données.

Si vous êtes geek et aimez entrer dans les détails, créez votre propre infrastructure et n'hésitez pas à utiliser n'importe quel outil d'automatisation (marionnette, chef) ou non. Ou si vous voulez juste récolter le bénéfice, ou avez peu de ressources pour prendre soin de tout, vous devriez essayer Elastic Beanstalk (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_Python_django.html)

Quoi qu'il en soit, en créant votre propre infrastructure ou en choisissant elastic beanstalk, exécutez toujours des tests de stress sur avoir une meilleure vue d'ensemble de vos besoins de planification de capacité. Après avoir choisi votre environnement initial, insistez-le en utilisant un banc apache, un siège ou tout autre outil que vous aimeriez.

Espérons que cela aide.

Answer 4

Je suggérerais d'utiliser de petites instances au lieu de micro car les micro-instances cessent souvent de répondre en cas de forte charge, puis elles nécessitent un arrêt-démarrage. Utilisez s3 pour les fichiers statiques, ce qui permet un chargement plus rapide et un aperçu du cloud. La région par exemple aide également à traiter les requêtes et si vous ciblez une région spécifique, créez l'instance en sélectionnant cette région.

Créez la base de données dans une nouvelle instance et joignez le volume ebs à cette instance. Automatisez le script de sauvegarde pour copier les fichiers de base de données et les stocker dans ebs pour éviter tout problème. L'instance sélectionnée ici peut être optimisée pour un traitement plus rapide que la norme. Les services Aws offrent beaucoup de flexibilité, mais vous devez avoir des scripts en cours d'exécution pour monter et descendre les serveurs selon les horaires.

Une instance ponctuelle peut aider à l'avenir, car ils sont bon marché au cas où vous agrandissez.