Les reverse proxies – Une vulgarisation décalée… (Chapitre 2 – Les performances)

Pour commencer, une question…

Tout raisonnement commence par un questionnement, mais c’est plutôt mon boulot …

Non, une vraie question : vous êtes qui toi d’abord ?

Peut-être une manifestation de la conscience post-moderne de l’artifice narratif du dialogue ?

Ah, OK. Bon on oublie et ..

Peut-être un élément d’identification du lecteur, créant l’illusion d’un antagonisme dialectique alors qu’en fait j’oriente le questionnement en faveur du narrateur ?

Bah non, là c’est le contraire, et ça réaffirme la première ..

Ou peut-être une voix dans ta tête ?

Stop ! Je prends la réponse 1, le truc moderne qui arrive par la Poste !

Et on change la question : tu entends quoi, par performance ?

Critères de performances

Attachons-nous à deux critères sans finesse pour évaluer les performances d’un système :

• La latence de réponse, c’est-à-dire le temps écoulé entre l’émission de la requête et l’obtention de sa réponse ;
• La processivité, c’est-à-dire le nombre de requêtes traitées par unité de temps.

Ces deux critères sont en partie antagonistes : une architecture logique rassemblée sur une seule machine physique optimise souvent la latence (les communications inter-processus via des sockets sont beaucoup plus rapides que des passages par le réseau physique) ; la même architecture répartie sur 8 serveurs physiques sera probablement plus à même de supporter de la charge.

Attention toutefois aux architectures trop compactes : la charge en fonctionnement accentue la  compétition pour les ressources lentes ; lorsque la base de données et le serveur Web se battent pour accéder au disque dur, la latence et la processivité deviennent simultanément mauvaises.

OK, donc maintenant, on parle de clusters et de load balancing.

Non.

Non ?

Bah non. C’est ce que le lecteur attend, le point d’orgue, le bouquet final, le lapin qui sort du chapeau. Après ça, il n’y a plus grand-chose à dire. En fait, si, mais il n’y aura plus grand monde pour lire. Alors je me réserve.

Mais parlons tout de même de répartition de charge, juste une autre manière de répartir.

Distribution des charges

Reprenons des configurations évoquées précédemment, toujours dans le schéma simpliste d’un mandataire inverse en frontal d’un seul serveur.

Nous avions proposé l’exemple d’un nginx+PHP en frontal d’un Tomcat traitant les JSP ; cette solution optimise la latence de la partie PHP, le moteur nginx se montrant plus réactif que celui de Tomcat. Les JSP souffriront d’une petite latence supplémentaire, liée à la traversée de nginx avant de parvenir à Tomcat ; cette latence peut être très faible, voire imperceptible si les deux services tournent sur le même serveur physique. Donc bilan positif pour la latence.

La partie nginx consomme par ailleurs moins de ressources par requête servie ; la combinaison nginx+Tomcat aura donc une capacité en charge supérieure à un Tomcat seul. De plus, la dégradation des performances en charge limite sera plausiblement moins marquée, amenant à une pente plus douce avant l’écroulement du serveur.

Le dernier avantage de cette solution devient alors apparent : en limite de charge, le serveur Tomcat seul oblige à acheter une nouvelle machine significativement plus puissante, et rend obsolète la machine précédente.

Une solution répartie permet d’acheter un nouveau serveur dans la même gamme de prix que le précédent, et d’y migrer le Tomcat : la partie nginx retrouve des ressources en étant seul sur l’ancienne machine, la partie Tomcat bénéficie seul d’un serveur neuf, potentiellement plus performant. La processivité augmente à moindre coût, au prix d’une dégradation de la latence sur les pages JSP, traitées par Tomcat, et donc requêtées sur le réseau entre les deux serveurs.

Nous verrons par la suite que cette architecture simpliste peut facilement évoluer, par exemple par adjonction d’un proxy cache frontal, ou multiplication des Tomcat.

Ça reste limité à un cas assez particulier tout de même …

Exact. Abordons un sujet à la mode : la terminaison SSL.

Jamais entendu …

C’est une mode qui commence, mais elle prendra progressivement, si on y réfléchit.

La gestion d’une connexion SSL a un coût, qui n’est pas négligeable ; dans les cas d’application abordés ici, cela signifie que le HTTPS présente un surcoût significatif face au HTTP.

Typiquement, la cryptographie asymétrique impliquée dans les protocoles sécurisés (pour faire simple, la partie RSA) est atrocement lourde pour le processeur ; à tel point d’ailleurs que l’essentiel du volume transféré utilise une cryptographie symétrique, moins couteuse (classiquement AES).

Le Web sécurisé a explosé, sous l’impulsion entre autres du commerce en ligne, mais aussi des messageries en ligne ou bureaux virtualisés. La puissance des processeurs ayant augmenté moins rapidement, le coût cryptographique fini par se faire sentir.

Un serveur standard (6-8 cœurs aux alentours de 2,5 GHz) va commencer à peiner à l’approche de 2000 nouvelles transactions par seconde en 2048 bits (recommandation réglementaire classique depuis 2009). Et ceci pour la partie SSL seule, sans pour autant traiter les requêtes reçues.

On parle de terminaison SSL lorsqu’un serveur placé en frontal de la ressource réelle ‘termine’ le ‘tunnel’ sécurisé avec le client ; il prend à sa charge le déchiffrement de la requête et le chiffrement de sa réponse, laquelle est sous-traitée au ‘vrai’ serveur Web. Il décharge donc le serveur Web de la bureaucratie pour qu’il se concentre sur le fond.

Dans la pratique, le terminateur SSL (qui est donc une forme de reverse proxy) peut être assez couteux, pour peu qu’il intègre une accélération matérielle.

Une accélération _matérielle_ pour la cryptographie ??

Oui, bien sûr. Il y a même de l’accélération matérielle juste pour la couche TCP dans les cartes réseau. Ça se vend même aux particuliers, dans des configurations ‘pour joueurs’.

Les débits ont explosé en quelques années, le Gigabit est la norme des cartes et des switchs, le 10GbE se démocratise rapidement, les normes pour 40 et 100 gigabits Ethernet sont déjà posées. Un tiers de l’humanité accède à Internet, plus d’un demi-milliard de particuliers ont l’ADSL à plus de 5 mégabits, les grosses entreprises n’ont plus de complexes à connecter leurs implantations en fibre 10 gigabit … Les volumes ont changé.

Il est important de se rappeler que le terminateur SSL est un _terminateur_ ; tout le trafic vers les serveurs de contenu se fait en clair, et il faut assurer sa sécurité. Elle peut être physique, en isolant le montage dans une DMZ et un LAN dédiés, avec VLAN voire switches dédiés. Elle peut aussi être logique, en montant un VPN entre le proxy frontal et ses cibles.

Bah oui, et puis c’est malin, de dédier une machine à déchiffrer du SSL / TLS, juste pour le chiffrer à nouveau en interne …

Ça n’est pas si stupide. La partie couteuse des opérations est la gestion d’une _nouvelle_ connexion. Un serveur Web passe le plus clair de son temps à en établir : pour peu qu’il soit en charge, il ne peut pas maintenir toutes les connexions ouvertes, il ferme et ouvre à nouveau. Dans le cas d’un VPN, la connexion est déjà négociée, il ‘suffit’ d’assurer le chiffrement symétrique. Et là, un cœur sur un vieux serveur suffit à saturer un lien gigabit. Avec les instructions spécifiques AES-NI (présentes dans à peu près tous les processeurs de moins de 3 ans), un seul cœur sature largement un lien 10 gigabit …

Donc, le terminateur peut aller du ‘simple’ serveur Web (Wikimedia utilise des grappes de nginx à cet effet), au boitier dispendieux. Il tend donc à être mutualisé pour plusieurs serveurs Web distincts, et à remplir d’autres rôles, typiquement celui de répartiteur de charge (load balancing).

Dispendieux comment, exactement ?

Les fabricants de ces produits fonctionnent un peu comme les horlogers suisses, on ne parle pas de prix, c’est vulgaire. D’ailleurs, les tarifs sont un peu les mêmes : on trouve des produits très bien à quelques milliers d’euros, mais on trouve aussi à quelques dizaines de milliers …

L’alternative étant de monter un serveur Web ?

Non, il existe des logiciels libres très efficaces, comme Pound, ou le couple Stunnel + HAProxy, par exemple.

OK. Par contre, j’ai bien vu la transition vers le load balancing cette fois.

Non, il y a encore un type que je veux décrire avant. Mais on se rapproche.

A suivre…