Chaque jour, nous gérons un traffic entrant et sortant grandissant. Nous sommes passés à l'échelle supérieure la semaine dernière, et ce plus tôt que ce à quoi nous nous attendions, mais les résultats sont là.
Nous voulons donc partager les chiffres, les graphiques accompagnés d'explications sur la façon dont nous gérons ce traffic et cette quantité de données de plus en plus importants.
Frontaux
Nous délivrons un traffic sortant important notamment grâce aux plusieurs centaines de milliers de téléchargements quotidiens. Nous étions habitués à avoir un peu moins de 100Mbps de traffic sortant, mais il semble que c'est de l'histoire passée : nous gérons maintenant plus du double, et plus de 300Mbps au pic.
C'est pourquoi nous avons désormais une capacité de 2x1Gbps de capacité en traffic sortant.
Le traffic sortant d'un de nos frontaux depuis jeudi 31/03.
Ce graphique ne montre qu'un seul frontal (nous en avons deux actifs au moment de cet article, mais le nombre est flexible en fonction de la fréquentation) durant une période de plutôt faible fréquentation.
Le traffic entrant apporte d'autres problématiques délicates à gérer : la platforme entière est accessible via HTTPS (vous pouvez vérifier le cadenas vert dans la barre d'adresse de votre navigateur !) pour sécuriser votre navigation. Ce mode de navigation n'est pas forcé, vous pouvez toujours naviguer en clair (mais nous vous décourageons de le faire). Cependant, délivrer du contenu via HTTPS a un coût plutôt important. On ne le perçoit pas forcément à petite échelle, mais une forte latence et charge importante est vite arrivée à plus grande échelle si la configuration n'est pas optimale (nous avons saturé l'un de nos frontaux lors de la première migration à cause de ce point).
Nous avons effectué quelques mesures et on a pu observer un ratio d'un visiteur en HTTP pour 4 visiteurs en HTTPS, et entre quelques dizaines à plus de 1200 requêtes HTTPS par seconde.
Ainsi, nous avons choisi avec soin les ciphers à disposition, en fonction de plusieurs critères :
- sécurité,
- compatibilité avec la majorité des navigateurs,
- vitesse.
Ainsi, nous supportons les ciphers suivants :
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DES-CBC3-SHA
Nous préférons donc les échanges basés sur les courbes elliptiques (ECDHE_ECDSA) puisqu'ils fournissent un niveau de sécurité équivalent par rapport à du Diffie-Hellman classique, mais avec des clés plus courtes ce qui permet de réduire la quantité de données échangées, de réduire le coup de calcul (nous avons observé autour de 2.5 fois de coup supplémentaire pour du Diffie-Hellman classique par rapport à la version utilisant les courbes elliptiques).
Le dernier cipher, "DES-CBC3-SHA" est présent uniquement pour la rétro-compatibilité avec Windows XP. Il ne fournit pas de confidentialité persistente et doit être évité autant que possible. Malheureusement, c'est le seul moyen de fournir une navigation HTTPS aux utilisateurs sous Windows XP (représentant encore 6% de nos visiteurs en 2015). Nous les encourageons d'ailleurs à migrer vers un système plus récent..
Nous supportons également le cache et le "résumé" des sessions TLS ce qui permet de réduire le nombre d'aller retour pour les handshakes. Ces différents réglages, avec d'autres optimisations nous permettent de gérer le traffic entrant, même lors de pics soudains de fréquentation.
Backend
Au delà des frontaux, notre nouveau backend est pensé de façon à supporter une telle quantité de traffic transmis : l'ensemble des liens sont équipés en 1 Gbps et redondants. Ils sont également configurés pour utiliser des Jumbo Frames (et une MTU de 9000 octets) afin d'améliorer les performances, notamment pour les montages NFS.
Le traffic sortant depuis jeudi 31/03 sur l'un des backends web.
D'autre part, nous n'utilisons désormais plus aucun disque dur dans nos machines (excepté pour la partie sauvegarde). Les serveurs de productions sont tous équipés de SSD pour réduire la latence.
Enfin, la partie base de données est également impactée par l'augmentation de traffic et de la quantité de données traitées. Les serveurs de base de données stockent actuellement autour de 60 Go de données, et ce chiffre augmente de 5 Go chaque mois.
Ces serveurs ont un traffic permanent d'au moins 20 Mbps en période calme.
Le traffic sortant depuis jeudi midi sur l'un de nos serveurs MariaDB.
Le rendu du site a été amélioré notamment grâce à cette refonte : le temps de chargement des pages a été diminué de 10 à 20 ms par rapport à l'infrastructure précédente. Il sera encore meilleur dans un futur proche lorsque nous pourrons supporter HTTP/2. La vitesse de téélchargement a également été améliorée avec l'augmentation de la capacité.
Cependant, nous bénéficions de ce temps de latence faible grâce à un réseau performant et plutôt centralisé géographiquement. C'est pourquoi l'infrastructure est aussi présente dans d'autres emplacement distants de plus de 200 Km, prêts à prendre le relai en cas de problème sur l'infrastructure principale.
Nous reviendrons prochainement avec d'autres articles sur nos métriques (et par exemple du ratio d'1/5 entre les utilisateurs en IPv6 et IPv4). En attendant, vous pouvez suivre notre page de statut pour suivre nos maintenances et évolutions côté infrastructure !