Datacenters : comment Wikipédia est passé du mono au multi
Depuis 2022, Wikipédia exploite des serveurs d’application répartis sur deux datacenters. La plate-forme sous-jacente a été remodelée à cet effet.
Un datacenter secondaire, c’est bien, mais pourrait-on envisager de l’exploiter en production ? En 2015, Wikimédia avait amorcé une démarche dans ce sens. Sept ans plus tard, elle la finalisait.
L’initiative a impliqué de multiples ajustements de la plate-forme sous-jacente (MediaWiki), conçue pour fonctionner avec un seul back-end.
Wikipédia repose aujourd’hui sur 6 datacenters. Dont deux hébergeant les serveurs d’application, à Ashburn (Virginie) et Carrollton (Texas). Les quatre autres (Amsterdam, Marseille, San Francisco, Singapour) hébergent des serveurs de cache.
Wikimédia utilisait initialement Squid comme proxy de cache – il l’a ensuite remplacé par Varnish et Apache Traffic Server. Les premières briques de son CDN furent déployées en 2005 à Amsterdam, Séoul et Paris.
Le back-end envoyant une requête par serveur pour purger le cache, la charge a augmenté à mesure que l’infrastructure s’est étendue. En 2013, la fondation avait fini par adopter une solution plus scalable, fondée sur du multicast UDP. Elle la remplaça ensuite, en 2020, par un système basé sur Kafka.
Les utilisateurs disposant d’un compte Wikipédia sont un cas particulier. Le fait qu’ils peuvent avoir des préférences d’interface et des permissions spécifiques complique la mise en cache de pages entières.
Les principales cibles de trafic sont tout de même conçues pour pouvoir être mises en cache, y compris pour les utilisateurs connectés. Cela englobe la livraison du JavaScript et du CSS, les icônes et le texte d’interface localisés, ainsi que les vignettes.
Wikimédia avait commencé à exploiter son deuxième datacenter (celui à Carrollton, chez CyrusOne) en 2014. L’idée de l’utiliser en parallèle du datacenter primaire plutôt qu’en simple solution de secours tenait à plusieurs éléments :
– Potentiel de réduction de la latence
– Meilleure utilisation du hardware
– Dispense de « préchauffage » des caches dans le datacenter secondaire
– Motivation à concevoir des services reproductibles
Wikipédia passe sur Swift, Kafka et Cassandra
L’un des leviers d’adaptation de MediaWiki à l’architecture multi-DC touche au routage des méthodes HTTP.
Par essence, MediaWiki opère une séparation stricte entre base de donnée primaire (accessible en écriture) et replicas (lecture seule). Pour s’assurer de ne pas surcharger la base principale, Wikimédia a fait en sorte que les requêtes n’impliquant pas de modification de contenu n’utilisent que les replicas. Cela s’aligne sur la RFC 9110.
De ce pattern est née l’idée de diriger les requêtes de type WRITE vers le datacenter principal… et les requêtes de type READ vers le datacenter secondaire le plus proche. La logique est implémentée en Lua dans un des proxys Apache Traffic Server.
Il y a également eu du changement sur le stockage des contenus. À l’origine, MediaWiki utilisait du NFS et du matériel NetApp assurait la mise en miroir.
L’option décentralisée Swift a pris le relais depuis 2012. Chaque datacenter a son cluster. La plate-forme tente d’écrire sur l’un et l’autre, un service en arrière-plan (swiftrepl) gérant la cohérence. Lorsque le CDN Wikipédia ne peut livrer une vignette, il transmet les requêtes au cluster Swift le plus proche.
La file d’attente de tâches a aussi évolué. MediaWiki en embarque une depuis 2009. Initialement fondée sur Redis, puis migrée vers Kafka en 2017, elle supprote la réplication bidirectionnelle asynchrone. Cela permet la mise en attente dans les datacenters secondaires, puis le relais pour exécution dans le datacenter primaire, près des bases de données principales.
Pour le cache objet en mémoire, MediaWiki utilise MemCached. Afin de gérer plusieurs datacenters, on a introduit une composante WANObjectCache basée sur mcrouter, un proxy made in Facebook. Elle remplit deux fonctions : getWithSet et delete.
MainStash, le cache objet sur disque pour les extensions MediaWiki, fonctionnait lui aussi à l’origine sur Redis. En 2022, on est passé à MySQL, avec réplication circulaire et modèle LWW (la dernière écriture gagne). Les sessions de connexion ont elles aussi migré depuis Redis, mais vers un socle Cassandra supportant nativement les clusters régionaux.
WikiMédia a choisi un indicateur pour rendre compte des apports de ce travail incrémental. En l’occurrence, un gain en latence de l’ordre de 15 ms pour les utilisateurs localisés à l’ouest du datacenter texan (par exemple dans l’Est asiatique).
Illustration principale © Frank – Adobe Stock
