De 13 % d'erreurs dans les demandes pendant le Black Friday à zéro pannes : nous avons économisé 60 % des coûts d'hébergement grâce à la déployement en conteneurs.

L'année dernière, pendant la période de Black Friday, notre interface de résolution d'adresses a complètement échoué : 13 % des demandes ont reçu le code d'erreur 429, et notre service client a reçu plus de 300 plaintes de la part des commerçants. Trois serveurs backend ont dû fonctionner sans arrêt pendant 24 heures pour surmonter le pic de trafic. À cette époque, notre service était exécuté sur deux serveurs cloud à configuration fixe, et tout ajustement de la capacité se faisait manuellement. Il fallait attendre que de nouveaux instances soient lancées pour que le pic de trafic soit passé.

Pour commencer, expliquons ce qu'est le déploiement containerisé.

En d'autres termes, il s'agit de regrouper tout votre code, vos bibliothèques dépendantes et vos fichiers de configuration dans un « conteneur » standardisé, dont la taille varie de quelques mégaoctets à plusieurs centaines de mégaoctets. Peu importe sur quel serveur cela est exécuté, l'environnement de fonctionnement est 100 % identique. La taille de l'image du service de résolution d'adresses que nous avons initialement packagée était...187MBLa récupération et le lancement complet ne durent pas plus de 10 secondes.

Les 3 principaux bénéfices que nous avons réellement obtenus

• L'auto-échellement a vraiment sauvé la situation : pendant le Black Friday de cette année, le trafic a augmenté de trois fois, le système a automatiquement lancé 27 instances de conteneurs, puis les a réduits à 3 après le pic de demande, tout cela sans aucune intervention manuelle, et le taux d'erreurs est tombé directement en dessous de 0,1 %.
• Le bug lié aux incohérences environnementales a complètement disparu : les problèmes mystérieux qui ne posaient aucun problème lors des tests locaux mais qui provoquaient des erreurs dès la mise en ligne représentaient 40 % de notre total de bogues. Depuis le passage à l'utilisation de conteneurs, aucun de ces problèmes n’a plus surgi.
• Les coûts des serveurs ont été réduits de moitié : auparavant, pour faire face aux pics de charge, nous louions 8 serveurs haut de gamme toute l'année, avec un taux d'utilisation moyen de seulement 15 %. Maintenant, nous payons en fonction de l'utilisation réelle, ce qui nous permet d'économiser 60 % des dépenses liées aux serveurs sur toute l'année.

Ne regardons pas que les avantages, nous avons bien trébuché dans ces quelques pièges.

Lorsque nous avons commencé à utiliser le conteneur, par facilité, nous avons stocké tous les journaux et les fichiers temporaires à l'intérieur du conteneur. Malheureusement, lorsqu'une instance a été automatiquement détruite, les journaux de requêtes sur les 3 derniers jours ont disparu, et il a fallu deux jours entiers pour les récupérer. Une autre fois, l'image contenait trop de dépendances inutiles, ce qui a fait augmenter le temps de démarrage de 10 secondes à 2 minutes. Lorsqu'un afflux soudain de trafic est survenu, nous n'avons pas eu le temps de l'élargir, et nous avons failli rencontrer un autre problème.

Ce qui est le plus facile à négliger, ce sont les problèmes de droits d'accès : au début, nous avons accordé aux conteneurs des droits d'accès en tant que root, ce qui a permis aux programmes de minage de profiter de cette faille et de consommer 30 % des ressources CPU. Ce n'est que après une semaine que nous avons découvert cela grâce aux systèmes de surveillance.

Réfléchis bien avant de décider si tu dois vraiment l'utiliser ou non.

Si vous êtes un petit groupe de personnes travaillant sur des outils internes dont le trafic est très stable, avec seulement 1 ou 2 services, il n’est vraiment pas nécessaire de vous compliquer la vie. Il est plus simple de louer un serveur.

Mais si votre trafic de service est très instable, que vous avez besoin de mettre en ligne des mises à jour fréquentes, que les environnements développés par différents membres de l'équipe sont souvent en conflit, ou que vous dépensez de l'argent pour des ressources de serveur inutilisées, alors le déploiement en conteneurs vaut vraiment la peine d'être essayé, même si cela vous prend une semaine.

Trois conseils concrètes pour ceux qui commencent pour la première fois

• Ne commencez pas par travailler sur des clusters K8S ; commencez plutôt avec Docker Compose pour mettre en place des déploiements individuels. Comprenez bien les mécanismes de packaging, d’exécution et de montage des journaux. C’est exactement ce que nous avons fait pendant les premiers trois mois, et cela a été plus que suffisant.
• La première fois que l'on compile une image, on suit le « principe de minimalité » : on n'installe que les dépendances nécessaires au fonctionnement de l'application. En utilisant une image de base Alpine, on peut réduire la taille de l'image de plus de la moitié.
• Tous les données et journaux générés doivent être montés sur un volume de stockage externe au conteneur ; ils ne doivent en aucun cas être stockés à l'intérieur du conteneur lui-même. Cet point est inscrit en tête des directives opérationnelles de votre équipe.

Réponses aux petites questions courantes

Question : Personne dans notre équipe ne comprend les conteneurs, le coût d'apprentissage sera-t-il très élevé ?
Pour une utilisation de base, il suffit de passer deux jours à lire les documents d'introduction officiels pour mettre en marche le premier service. Vous pourrez apprendre les configurations plus avancées pour les clusters lorsque vous en aurez besoin, il n'y a pas de problème.

Question : Serait-il très compliqué de migrer les services existants vers des conteneurs ?
Réponse : Nous avons migré nos 3 services backend en une semaine, et la majeure partie de ce temps a été consacrée à la clarification des dépendances. Le temps réel passé à écrire les fichiers Dockerfile n'a pas dépassé une journée.