NGINX, un complément ou une alternative à AWS Elastic Load Balancing

Que ce soit pour suspendre des connexions SSL sur des centaines de sites Web ou encore pour manoeuvrer dans le monde si délicat des bases de données Oracle, certains départements IT se tournent désormais vers une alternative Open Source à AWS Elactic Load Balancing : NGINX.

NGINX supporte en effet SNI (Server Name Indication), un mécanisme avec lequel un client spécifie le nom du serveur qu’il cherche à contacter, lors d’une tentative de liaison. Cela permet à un serveur de présenter plusieurs certificats SSL sur la même adresse IP, ce qui est plus efficace que d’avoir un serveur spécifique pour chaque certificat SSL. De son côté, AWS Elastic Load Balancing (ELB) ne supporte pas SNI et certains clients de la marque en font la demande depuis l’année dernière.

Cela a par exemple conduit Brandcast, une société américaine de conception de site Web, de sélectionner NGINX, et de le considérer comme une alternative à la solution d’AWS, il y a 6 mois. S’il existe bien une version gratuite Open Source de NGINX, Brandcast utilise NGINX Plus, une version premium du serveur, dont la tarification démarre à 1 500 $ par an.

« Nous hébergeons tous nos sites Web, et donc tous les domaines pointent chez nous », explique Justin Keller, ingénieur DevOps chez Brandcast. « Le problème avec ELB est que vous ne pouvez avoir qu’un certificat SSL par ELB, et cela ne convient pas car des milliers de domaines sont dirigés chez nous ».

Il existe certes des contournements pour que ELB puisse supporter plusieurs serveurs avec une unique adresse IP, comme les « subject-alternate names » qui hébergent jusqu’à 100 noms différents sur un certificat. Certains clients AWS utilisent aussi ELB en tant que load balancer TCP. Mais aucune de ces alternatives n’étaient suffisantes pour Brandcast, qui doit prendre en compte des milliers de domaines.

Toutefois, il ne s’agit de considérer NGINX comme une solution de remplacement de d’AWS Elastic Load Balancing.

FedBird, qui gère une marketplace, a mis en place un cluster de serveurs d’application et utilise ELB entre ces serveurs. ELB est également le premier point d’entrée de certaines applications de FedBid. NGINX Plus est principalement utilisé pour gérer les sessions des clients Web, ainsi que certains clients B2B (comme ceux qui requièrent des adresses IP fixes pour s’interfacer avec FedBid).

ELB supporte des sticky sessions, qui utilisent un indicateur dans l’URL pour déterminer la requète. Celle-ci est envoyée à une instance spécifique en backend. Mais ELB s’appuie sur des cookies, ce qui ne colle pas à la réalité de la couche middleware WebLogic, présente dans l’application Oracle de la société.

« Nous ne nous reposons pas beaucoup sur les cookies, mais sur JSESSIONID dans WebLogic », explique Rukevbe Esi, vice-président en charge de la technologie chez FedBid. « Avec ELB, nous ne pouvions pas avoir ce type de session, à cause de notre architecture. »

ELB ne dispose pas d’IP statiques, ce dont FedBid a aussi besoin. En contactant le support, un client peut toutefois voir son ELB exploiter un pool d’adresses IP. Mais dans le cas de FedBid, il s’agissait d’une unique IP statique.

Ce sont certes des usages spécifiques, mais comme l’indiquent certains consultants Cloud, NGINX est souvent utilisé chez les utilisateurs AWS, au côté d’ELB. « Je l’utilise en permanence », soutient Patrick McClory, directeur chez Datapipe, un spécialiste des services d’hébergement AWS.

NGINX est la plupart du temps utilisé chez les pure-players du Web, ceux qui ont à gérer des applications massivement distribuées, dépendants de mécanismes de routage hautement performants et économiques, commente Carl Brooks, analyste du cabinet de conseil 451 Research. « Il s’agit d’un bout de logiciel terriblement efficace. En faisant bien le calcul, il peut battre Amazon sur son propre terrain. »

Traduit et adapté par la rédaction