Avant-propos
Mise à jour en 2016. Les choses évoluent, tous les serveurs s'améliorent, ils prennent tous en charge le protocole SSL et le Web est plus étonnant que jamais.
Sauf indication contraire, les éléments suivants sont destinés aux professionnels du secteur des entreprises et des start-ups, qui assistent des milliers, voire des millions d'utilisateurs.
Ces outils et architectures nécessitent beaucoup d'utilisateurs / matériel / argent. Vous pouvez essayer ceci dans un laboratoire à domicile ou pour tenir un blog, mais cela n’a pas beaucoup de sens.
En règle générale, rappelez-vous que vous voulez garder les choses simples . Chaque middleware ajouté est un autre composant essentiel à maintenir. La perfection n'est pas atteinte lorsqu'il n'y a rien à ajouter mais lorsqu'il ne reste plus rien à enlever.
Quelques déploiements communs et intéressants
HAProxy (équilibrage) + nginx (application php + mise en cache)
Le serveur web est nginx sous php. Quand nginx est déjà là, il pourrait tout aussi bien gérer la mise en cache et les redirections.
HAProxy ---> nginx-php
A ---> nginx-php
P ---> nginx-php
r ---> nginx-php
o ---> nginx-php
x ---> nginx-php
y ---> nginx-php
HAProxy (équilibrage) + Varnish (mise en cache) + Tomcat (application Java)
HAProxy peut rediriger vers Varnish en fonction de l'URI de la demande (* .jpg * .css * .js).
HAProxy ---> tomcat
A ---> tomcat
---> tomcat
P ---> tomcat <----+
r ---> tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
HAProxy (équilibrage) + nginx (SSL vers l'hôte et la mise en cache) + Webserver (application)
Les serveurs Web ne parlent pas SSL même si TOUT LE MONDE DOIT PARLER DE SSL (en particulier ce lien HAProxy-WebServer avec des informations d’utilisateur privé passant par EC2 ). L'ajout d'un nginx local permet de mettre SSL en place sur l'hôte. Une fois que nginx est là, il pourrait tout aussi bien faire de la mise en cache et de la réécriture des URL.
Remarque : La redirection de port 443: 8080 est en cours mais ne fait pas partie des fonctionnalités. Il est inutile de faire la redirection de port. L’équilibreur de charge peut s’adresser directement au serveur Web: 8080.
(nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A ---> nginx:443 -> webserver:8080
P ---> nginx:443 -> webserver:8080
r ---> nginx:443 -> webserver:8080
o ---> nginx:443 -> webserver:8080
x ---> nginx:443 -> webserver:8080
y ---> nginx:443 -> webserver:8080
Middleware
HAProxy: L'équilibreur de charge
Caractéristiques principales :
- Equilibrage de charge (TCP, HTTP, HTTPS)
- Algorithmes multiples (round robin, source ip, en-têtes)
- Persistance de session
- Résiliation SSL
Alternatives similaires : nginx (serveur Web polyvalent configurable comme équilibreur de charge)
Différentes alternatives : Cloud (Amazon ELB, équilibreur de charge Google), Matériel (F5, fortinet, citrix netscaler), Autre et dans le monde entier (DNS, anycast, CloudFlare)
Qu'est-ce que HAProxy fait et quand devez-vous l'utiliser?
Chaque fois que vous avez besoin d'équilibrer la charge. HAProxy est la solution idéale.
Sauf si vous voulez vraiment pas cher ou rapide et sale ou vous n'avez pas les compétences disponibles, alors vous pouvez utiliser un ELB: D
Sauf si vous êtes dans le secteur bancaire / gouvernement / similaire, vous devez utiliser votre propre centre de données avec des exigences strictes (infrastructure dédiée, basculement fiable, 2 couches de pare-feu, audits, SLA pour payer x% par minute d'indisponibilité, le tout en un). vous pouvez placer 2 F5 au-dessus du rack contenant vos 30 serveurs d'applications.
Sauf si vous voulez dépasser 100k HTTP (S) [et plusieurs sites], vous DEVEZ avoir plusieurs HAProxy avec une couche d'équilibrage de charge [global] devant eux (cloudflare, DNS, anycast). Théoriquement, l’équilibreur global pourrait parler directement aux serveurs Web, ce qui permettrait d’abandonner HAProxy. Cependant, généralement, vous DEVEZ garder HAProxy (s) en tant que point (s) d’entrée public vers votre centre de données et ajuster les options avancées pour équilibrer équitablement les hôtes et minimiser la variance.
Opinion personnelle : Un petit projet open source, confiné, entièrement dédié à UN VRAI OBJECTIF. Parmi la configuration la plus facile (fichier ONE), le logiciel open source le plus utile et le plus fiable que j'ai rencontré dans ma vie.
Nginx: Apache qui ne craint pas
Caractéristiques principales :
- Serveur Web HTTP ou HTTPS
- Exécuter des applications en CGI / PHP / autres
- Redirection / réécriture d'URL
- Contrôle d'accès
- Manipulation des en-têtes HTTP
- Caching
- Proxy inverse
Alternatives similaires : Apache, Lighttpd, Tomcat, Gunicorn ...
Apache était le serveur Web de facto, également connu sous le nom de cluster géant de dizaines de modules et de milliers de lignes httpd.confau-dessus d’une architecture de traitement de requêtes en panne. Nginx refait tout cela, avec moins de modules, une configuration (un peu) plus simple et une meilleure architecture de base.
Que fait nginx et quand devez-vous l’utiliser?
Un serveur Web est destiné à exécuter des applications. Lorsque votre application est développée pour fonctionner sur nginx, vous avez déjà nginx et vous pouvez également utiliser toutes ses fonctionnalités.
Sauf si votre application n'est pas destinée à s'exécuter sur nginx et que nginx ne figure nulle part dans votre pile (Java shop any?), Il ne sert à rien d'avoir nginx. Les fonctionnalités des serveurs Web sont susceptibles d'exister sur votre serveur Web actuel et les autres tâches sont mieux gérées par l'outil dédié approprié (HAProxy / Varnish / CDN).
Sauf si votre serveur Web / votre application manque de fonctionnalités, qu'il est difficile de le configurer et / ou que vous préférez ne pas l'examiner (n'importe qui?), Vous pouvez placer un nginx devant (localement sur chaque nœud) pour effectuer l'URL réécrire, envoyer des redirections 301, appliquer le contrôle d'accès, fournir un cryptage SSL et éditer les en-têtes HTTP à la volée. [Ce sont les fonctionnalités attendues d'un serveur Web]
Varnish: LE serveur de cache
Caractéristiques principales :
- Caching
- Mise en cache avancée
- Mise en cache grain fin
- Caching
Alternatives similaires : nginx (serveur Web polyvalent configurable en tant que serveur de mise en cache)
Alternatives alternatives : CDN (Akamai, Amazon CloudFront, CloudFlare), matériel (F5, Fortinet, Citrix Netscaler)
Que fait Varnish et quand dois-tu l'utiliser?
Il met en cache, uniquement en cache. Cela ne vaut généralement pas la peine et c'est une perte de temps. Essayez CDN à la place. Sachez que la mise en cache est la dernière chose à laquelle vous devez prêter attention lorsque vous exploitez un site Web.
Sauf si vous exploitez un site Web exclusivement consacré aux images ou aux vidéos, vous devez examiner le CDN de manière approfondie et envisager sérieusement la mise en cache.
Sauf si vous êtes obligé d'utiliser votre propre matériel dans votre propre centre de données (CDN n'est pas une option) et que vos serveurs Web ne sont pas en mesure de fournir des fichiers statiques (l'ajout de nouveaux serveurs Web n'est pas utile), alors Varnish est le dernier recours.
Sauf si vous avez un site avec un contenu principalement statique, mais complexe, généré dynamiquement (voir les paragraphes suivants), Varnish peut économiser beaucoup de puissance de traitement sur vos serveurs Web.
La mise en cache statique est surestimée en 2016
La mise en cache est presque sans configuration, sans argent et sans temps. Il vous suffit de vous abonner à CloudFlare, CloudFront, Akamai ou MaxCDN. Le temps qu'il me faut pour écrire cette ligne est plus long que le temps requis pour configurer la mise en cache ET la bière que je tiens dans ma main est plus chère que l'abonnement médian CloudFlare.
Tous ces services fonctionnent immédiatement pour les fichiers static * .css * .js * .png et plus. En fait, ils respectent la Cache-Controldirective dans l'en-tête HTTP. La première étape de la mise en cache consiste à configurer vos serveurs Web pour qu'ils envoient les directives de cache appropriées. Peu importe quel CDN, quel vernis, quel navigateur est au milieu.
Considérations de performance
Varnish a été créé à une époque où la plupart des serveurs Web étaient sur le point de servir une image de chat sur un blog. De nos jours, une seule instance du serveur Web moderne multithread basé sur des mots à la mode asynchrones peut livrer de manière fiable des chatons à tout un pays. Gracieuseté de sendfile().
J'ai effectué des tests de performance rapides pour le dernier projet sur lequel j'ai travaillé. Une seule instance de tomcat peut traiter 21 000 à 33 000 fichiers statiques par seconde via HTTP (test des fichiers de 20 à 12 Ko avec un nombre de connexions HTTP / client variable). Le trafic sortant maintenu dépasse 2,4 Gb / s. La production n'aura que des interfaces 1 Gb / s. Ne peut pas faire mieux que le matériel, inutile d'essayer Varnish.
Mise en cache complexe Modification du contenu dynamique
CDN et les serveurs de mise en cache ignorent généralement les URL avec des paramètres tels que ?article=1843, ils ignorent toutes les requêtes avec des cookies de session ou des utilisateurs authentifiés, et la plupart des types MIME, y compris application/jsonfrom /api/article/1843/info. Il y a des options de configuration disponibles mais généralement pas à grain fin, plutôt "tout ou rien".
Varnish peut avoir des règles complexes personnalisées (voir VCL) pour définir ce qui est cachable et ce qui ne l'est pas. Ces règles peuvent mettre en cache un contenu spécifique par URI, en-têtes et cookie de session de l'utilisateur actuel, ainsi que le type et le contenu MIME ALL TOGETHER. Cela peut économiser beaucoup de puissance de traitement sur les serveurs Web pour un modèle de charge très spécifique. C'est à ce moment que Varnish est pratique et génial.
Conclusion
Il m'a fallu un certain temps pour comprendre toutes ces pièces, quand les utiliser et comment elles s'emboîtent. J'espère que cela peut vous aider.
Cela s'avère être assez long (6 heures pour écrire. OMG!: O). Peut-être que je devrais commencer un blog ou un livre à ce sujet. Fait amusant: Il ne semble pas y avoir de limite à la longueur de la réponse.