Une présence sur 17 marchés, 26 millions de clients actifs, 5,4 milliards d'euros de revenus, 250 millions de visites par mois, 15 000 employés en Europe... Les principaux chiffres caractérisant le géant du e-commerce allemand Zalando, spécialisé dans la distribution de chaussures en ligne, ont de quoi donner le tournis. Une performance commerciale qui ne pourrait pas être atteinte sans une infrastructure informatique solide. Rien d'étonnant donc de savoir que cette dernière repose en particulier sur la puissante technologie de base de données NoSQL Elasticsearch connue pour ses hautes capacités volumétriques et de mise à l'échelle.

Opéré jusqu'en octobre 2016 dans le cloud AWS EC2, l'ensemble des clusters Elasticsearch (ES) a été depuis basculé vers Kubernetes à des fins d'optimisation des coûts et d'automatisation de la gestion des mises à jour. Aujourd'hui, 125 clusters ES - pour un total de 1 400 noeuds - tournent sur Kubernetes. « Basculer les clusters Elasticsearch sur Kubernetes a permis d'économiser des mises à jour et aussi des opérations d'auto-scaling », a expliqué Mikkel Larsen, ingénieur infrastructure cloud chez Zalando, à l'occasion d'une session technique du Kubecon 2019 qui se tient en ce moment à Barcelone.

Répondre à des contraintes d'exploitation

Pour parvenir à cette migration, Zalando est passé par deux étapes : preStop hook (bash scripts) avec la nécessité d'exclure les noeuds dans ES, patienter pour le drainage de noeuds qui a pu prendre jusqu'à une heure, et basculer les données sur des noeuds existants. Et puis une deuxième étape postStart hook (bash script) qui a nécessité d'enlever toutes les exclusions, et de reallouer les bases ES depuis des noeuds existants. Objectif pour Zalando : devenir un opérateur de patterns pour simplifier la gestion des noeuds, effectuer des mises à jour sans changement de replicas, et stocker chaque état dans des annotations.

Zalando

En devenant opérateur de clusters Elasticsearch avec Kubernetes, Zalando a gagné en souplesse, réactivité et optimisation de gestion opérationnelle et d'administration, d'après Mikkel Larsen, ingénieur infrastructure cloud chez Zalando. (crédit : D.F.)

La bascule d'ES en tant qu'opérateur a en outre permis à Zalando une gestion dynamique des noeuds pour répondre à des contraintes d'exploitation (charge CPU élevée, durée de sollicitation...), soit en augmentant les replicas de pod - ou les index - lorsque la situation nécessite de réallouer des ressources et de les exploiter pour améliorer la performance (scaling up). Soit au contraire de les diminuer (scaling down). A noter que les premiers problèmes de scalabilité rencontrés dans la phase de PoC, induite par une taille du réseau réduite par le nombre d'IP des machines virtuelles, ont pu être réglés avant la mise en production, a précisé Mikkel Larsen en réponse à une question posée par un participant.

24h pour un scale-up de dataset pour Zalando en Allemagne

« Il faut faire attention à ne pas opérer lorsqu'un cluster n'est pas prêt, sinon cela peut conduire à une perte de noeud et à se retrouver dans une situation difficile », prévient Mikkel Larsen. « En cas de scaling up d'ES, il faut penser à accroitre les index des replicas pour scaler sur plusieurs jours, en fonction des besoins, le nombre de replicas. Sur l'Allemagne, le scale-up d'un dataset a pu se faire sur 24h. » Et l'ingénieur infrastructure cloud de Zalando de prévenir : « en transformant les bash scripts en opérateurs, il faut garder en tête que ces derniers peuvent mourir à tout moment et qu'il faut donc penser à ajouter des abstractions ».