Quelle est la configuration AWS (Amazon Web Service) la plus évolutive et la plus performante pour un service Web RESTful?

Je construis un service Web RESTful asynchrone et j’essaie de comprendre quelle est la solution la plus évolutive et la plus performante. À l’origine, je prévoyais d’utiliser la configuration FriendFeed, en utilisant une machine exécutant nginx pour héberger du contenu statique, agissant comme un équilibreur de charge et agissant en tant que proxy inverse pour quatre machines exécutant le serveur Web Tornado pour le contenu dynamic. Il est recommandé d’exécuter nginx sur une machine quad-core et chaque serveur Tornado sur une machine à cœur unique. Amazon Web Services (AWS) semble être le fournisseur d’hébergement le plus économique et le plus flexible, voici donc mes questions:

1a.) Sur AWS, je ne trouve que les types d’instance c1.medium (CPU dual core et 1,7 Go de mémoire). Donc, cela signifie-t-il que je devrais avoir une instance nginx exécutée sur c1.medium et deux serveurs Tornado sur des instances de m1.small (CPU simple cœur et 1,7 Go de mémoire)?

1b.) Si je devais évoluer, comment relier ces trois instances à trois autres instances dans la même configuration?

2a.) Il est plus judicieux d’héberger du contenu statique dans un compartiment S3. Nginx hébergerait-il toujours ces fichiers?

2b.) Sinon, la performance souffrirait-elle du fait que nginx ne les héberge pas?

2c.) Si nginx n’héberge pas le contenu statique, il n’agit que comme équilibreur de charge. Il y a un excellent article ici qui compare les performances des différentes configurations de cloud et dit ceci à propos des équilibreurs de charge: «HaProxy et Nginx acheminent le trafic sur la couche 7, ils sont donc moins évolutifs en raison de la terminaison SSL et de la renégociation SSL. trafic au niveau de la couche 4 sans surcharge de traitement SSL. ” Recommanderiez-vous de remplacer nginx en tant qu’équilibreur de charge par un autre fonctionnant sur la couche 4, ou Elastic Load Balancer d’Amazon est-il suffisamment performant?

1a) Nginx est un serveur asynchrone (basé sur des événements), avec un seul max_clients = worker_processes * worker_connections/4 ils peuvent gérer beaucoup de connexions simultanées ( max_clients = worker_processes * worker_connections/4 ref ) et continuent à bien fonctionner. J’ai moi-même testé autour de 20K de connexion simultanée sur c1.medium genre de boîte (pas dans aws). Ici vous définissez les travailleurs à deux (un pour chaque processeur) et exécutez 4 backend (vous pouvez même tester avec plus pour voir où cela casse). Seulement si cela vous pose plus de problèmes, optez pour une configuration similaire et enchaînez-les via un équilibreur de charge élastique.

1b) Comme indiqué en (1a), utiliser un équilibreur de charge élastique. Voir quelqu’un qui a testé ELB pour 20 000 requêtes / seconde et ce n’est pas la limite car il a abandonné car il a perdu tout intérêt.

2a) Hébergez du contenu statique dans cloudfront , son CDN et cela pour exactement cela (moins cher et plus rapide que S3, et il peut extraire du contenu du compartiment s3 ou de votre propre serveur). Son très évolutif.

2b) Evidemment, avec nginx servant des fichiers statiques, il devra maintenant servir plus de requêtes au même nombre d’utilisateurs. En supprimant cette charge, vous éviterez d’accepter les connexions et d’envoyer les fichiers (moins l’utilisation de la bande passante).

2c). Éviter complètement nginx semble être une bonne solution (un intermédiaire de moins). Elastic Load balancer gérera la terminaison SSL et réduira la charge SSL sur vos serveurs principaux (cela améliorera les performances des backends). D’après les expériences ci-dessus, il a montré environ 20K et comme son élastique il devrait s’étirer plus que le logiciel LB (Voir ce beau document sur son fonctionnement)