De nos jours, une panne d'électricité à la maison est extrêmement handicapante et nous bloque dans la plupart de nos activités. Il est presque impossible de continuer sa journée sans lumière ni appareils électriques. De même, des millions de services utilisés par les personnes à travers le monde dépendent d’infrastructures externes, c'est le cas des sites internet, des outils en ligne ou encore des applications mobiles.
Dans cet article, nous expliquons comment nous avons construit un système basé sur la stabilité et la flexibilité. Nous allons également vous montrer comment nous sommes capables de déplacer des ressources et des données entre des serveurs séparés par des milliers de kilomètres en un claquement de doigt.
Répartir la distribution géographiquement
Wix est avant tout centré sur l'utilisateur. Nous embauchons des centaines d’ingénieurs dont l'objectif ultime est de fournir une infrastructure stable et d’éviter tout dysfonctionnement. Chaque site créé sur Wix doit pouvoir être accessible à tout moment et pour ce faire, nous ne pouvons pas nous permettre de compter sur une seule infrastructure ou un seul serveur basé dans un seul et unique pays.
De ce fait, l'infrastructure qui exécute tous les services Wix est faite pour pouvoir atténuer les incidents occasionnels tout en s’assurant que nos utilisateurs ne soient pas affectés. Nous nous basons avant tout sur la haute disponibilité, en jargon informatique, il s’agit de la capacité d’un serveur à rester fonctionnel à tout moment. L'une des caractéristiques uniques de notre approche est d’examiner la haute disponibilité à travers une lentille multi-géographique plutôt que de nous concentrer sur des zones spécifiques basées dans les mêmes régions.
Nous commençons par exploiter tout ce que les zones à haute disponibilité ont à offrir, mais nous allons également au-delà. Nous ne pouvons tout simplement pas compter sur un seul et unique type d'infrastructure partagée qui pourrait détruire une zone entière. Nous misons donc une haute disponibilité distribuée géographiquement : nous utilisons toutes les zones hautement disponibles réparties autour de différents emplacements géographiques sur des milliers de kilomètres (des États-Unis à l’Asie, en passant par l’Europe), 15 emplacements au total disponibles à tout moment.
Tous ces emplacements sont sélectionnés en fonction de la quantité de trafic qu'ils reçoivent et desservent. Ainsi, au lieu d'avoir un très grand emplacement au service de tout le monde, nous avons 15 « petits » emplacements. Si nous divisons les emplacements de manière égale, cela représente environ 6,6 % de la taille d'origine.
Imaginez maintenant que l'un des serveurs tombe en panne pour une raison quelconque : le trafic sera immédiatement basculé vers les 2 ou 3 emplacements les plus proches. Nous avons créé plusieurs algorithmes afin de nous assurer que tout fonctionne correctement.
Pour pouvoir être rentable en toute circonstance, tous nos emplacements sont toujours au service du trafic et ne restent pas inutilisés, sauf en cas de panne.
Anticiper les crises
Le principe sous-jacent de l’anticipation est la surveillance continue. Nous surveillons activement tous nos emplacements, jusqu'au dernier service en cours d'exécution dans un emplacement donné. Une telle visibilité nous donne une compréhension très approfondie du statut de chaque emplacement. Nous n'attendons pas qu'une catastrophe se produise pour réagir. Dès que des signes de faiblesse apparaissent, nous prenons les devants pour garantir la stabilité de notre infrastructure. Cette technique nous permet d'être proactif dans notre travail.
Par exemple, lors de la panne d’Amazon Web Services (AWS) en décembre 2021, nous avons commencé à remarquer quelques problèmes avec de petits services, notamment ceux liés aux services DynamoDB. En termes simples, certains de nos services ont commencé à ressentir une situation d'instabilité et ont informé le système qu'ils s’affaiblissaient. À ce moment précis, Amazon n'avait encore rien publié, personne n'était au courant des problèmes. Malgré cela, nous avons décidé d’arrêter d’utiliser cet emplacement et d'acheminer le trafic des utilisateurs vers un autre emplacement. Au final, notre fournisseur a fini par avoir une panne et nos utilisateurs n'ont même pas remarqué que quelque chose n'allait pas.
Procéder méthodiquement
Comment pouvons-nous mettre en place un système qui nous permet de transférer des ressources ailleurs, puis d'enquêter calmement sur ce qui se passe sans affecter l'expérience de nos utilisateurs ? Voici ce que nous avons mis en place :
Surveiller l'ensemble des technologies et localiser où se situent exactement les dysfonctionnements.
Avoir la capacité de servir le trafic à partir de différents emplacements (en utilisant des fournisseurs DNS pour déplacer le trafic entre plusieurs centres de données).
Avoir la capacité de faire évoluer nos ressources automatiquement et très rapidement pour faire face à un changement immédiat de la demande.
Créer des connecteurs entre les données pour que les serveurs soient capables de recevoir une requête d'un côté du monde et comprendre qu'il s'agit d'une continuation d'une autre requête qui a été lancée précédemment.
Outre les mesures citées ci-dessus, l'ensemble de notre système doit comprendre chacune des requêtes, la manière dont elles arrivent et la manière dont elles doivent être traitées lorsqu'elles se déplacent entre différents emplacements géographiques.
Par exemple, lorsqu'un paiement est effectué sur le site de l'un de nos utilisateurs, nous devons pouvoir suivre le cheminement de cette transaction. Ceci, même si cette transaction commence à partir d’un serveur aux États-Unis et se termine avec un autre serveur en Chine.
Pour pouvoir être aussi flexible, tout notre système doit pouvoir s'adapter au changement automatiquement. De plus, il dispose toujours d'un tampon de ressources pour s'assurer que si un changement se produit pendant l'un des pics saisonniers habituels, nous sommes en mesure de supporter l’augmentation du trafic.
Ce modèle nous permet de :
Ne jamais être géographiquement que dans une seule région.
Garder une trace de chaque requête entre tous les emplacements de manière transparente.
Nous assurer que chaque emplacement peut évoluer automatiquement selon les besoins.
Déplacer une partie du trafic et non son intégralité.
Notre modèle nous permet de réagir très rapidement à tout événement et de pouvoir compter sur notre infrastructure.
Ce système que nous avons mis en place nous permet de pouvoir prendre des précautions et des initiatives avant même que de graves problèmes ne se manifestent. Par exemple, nous pouvons détecter les problèmes potentiels avec l'infrastructure d'un fournisseur de cloud et être sûrs que notre système agira plus rapidement qu'un humain et redistribuera automatiquement le trafic de manière efficace.
Nos ingénieurs testent constamment ce système depuis deux ans et demi afin d'être prêt quel que soit le dysfonctionnement. Lors de la dernière panne, nous avons agi rapidement, automatiquement, et avant même que notre fournisseur ne comprenne quels étaient les problèmes.
Nos ingénieurs croient fermement en la loi de Murphy selon laquelle « Tout ce qui est susceptible de mal tourner, tournera mal. » De ce fait, ils font également tout leur possible pour anticiper et éviter que les choses ne tournent mal. La totalité de l'infrastructure est ainsi conçue avec des objectifs de stabilité et de flexibilité afin que nos utilisateurs profitent pleinement de Wix sans se soucier d’une panne éventuelle.