Enhancing OLAP Resilience at LinkedIn

Ce papier présente un cadre de résilience holistique pour Apache Pinot chez LinkedIn, intégrant l'isolation des charges de travail, le rééquilibrage sans impact, la conscience des zones de maintenance et la sélection adaptative de serveurs pour garantir une faible latence et une haute disponibilité à l'échelle.

L'essentiel

Imaginez que LinkedIn est une immense bibliothèque numérique où des milliards de livres (les données) sont stockés. Des millions de personnes viennent chaque seconde poser des questions à cette bibliothèque : « Qui a vu mon profil ? », « Quels sont les talents dans ce secteur ? ». Pour répondre instantanément, la bibliothèque utilise un système très rapide appelé Pinot.

Cependant, comme dans toute grande bibliothèque, il y a des problèmes :

1. Parfois, un visiteur très bruyant (une requête complexe) crie si fort qu'il empêche les autres de lire.
2. Parfois, un rayon entier de la bibliothèque doit être réorganisé (mise à jour), ce qui risque de bloquer l'accès aux livres.
3. Parfois, un bibliothécaire tombe malade ou son ordinateur plante, et cela ralentit tout le service.

Les auteurs de cet article, des ingénieurs de LinkedIn, ont créé quatre « super-pouvoirs » pour rendre ce système inébranlable. Voici comment ils fonctionnent, expliqués simplement :

1. Le « Portefeuille de Ressources » (QWI)

Le problème : Imaginez que tous les visiteurs partagent le même buffet. Si un visiteur gourmand prend tout le gâteau, les autres n'ont plus rien. C'est le problème du « voisin bruyant » : une seule requête compliquée peut épuiser la puissance de calcul et ralentir tout le monde.

La solution : Ils ont introduit un système de budgets individuels.

• Chaque groupe de visiteurs (par exemple, les publicitaires vs les utilisateurs normaux) reçoit un « portefeuille » de ressources (CPU et mémoire).
• Si un visiteur dépasse son budget, le système le stoppe immédiatement, comme un caissier qui refuse de laisser passer quelqu'un qui n'a plus d'argent.
• Résultat : Personne ne peut voler la nourriture des autres. Même si un groupe fait une grosse fête, les autres continuent de manger tranquillement, sans que le système ne ralentisse.

2. La « Réorganisation Invisible » (Rebalancing sans impact)

Le problème : Parfois, il faut déplacer des livres d'un rayon à un autre (par exemple, ajouter de nouveaux bibliothécaires ou en retirer). Normalement, pendant ce déménagement, les clients ne peuvent pas accéder aux livres, ce qui crée des files d'attente et de la frustration.

La solution : Ils ont inventé une méthode de déménagement sans jamais fermer les rayons.

• Au lieu de déplacer les livres d'un coup, le système vide d'abord le rayon de ses clients (il arrête d'envoyer de nouvelles questions).
• Une fois le rayon vide, il déplace les livres rapidement.
• Ensuite, il rouvre le rayon.
• L'astuce : Cela se fait étape par étape, toujours en s'assurant qu'il reste toujours assez de bibliothécaires pour répondre aux questions. C'est comme changer les pneus d'une voiture de course pendant qu'elle roule à 200 km/h, mais en utilisant des roues de rechange invisibles.

3. La « Carte des Zones de Sécurité » (Maintenance Zone Aware)

Le problème : Imaginez que votre bibliothèque est répartie dans plusieurs bâtiments. Si un incendie éclate dans le bâtiment A, vous ne voulez pas que tous les livres importants soient stockés dans ce bâtiment, sinon tout est perdu.

La solution : Le système est intelligent sur la géographie des pannes.

• Il s'assure que les copies des mêmes livres sont toujours réparties dans des bâtiments différents (zones de maintenance).
• Si un bâtiment entier doit être vidé pour des travaux ou une panne, le système sait exactement où sont les copies de secours dans les autres bâtiments.
• Résultat : Même si un quartier entier de la ville (une zone de données) s'effondre, la bibliothèque reste ouverte et continue de fonctionner normalement.

4. Le « GPS Intelligent » (Adaptive Server Selection)

Le problème : Quand vous demandez un livre, le système envoie votre requête à un bibliothécaire au hasard. Si ce bibliothécaire est lent (parce qu'il a un mal de tête ou un ordinateur lent), vous attendez longtemps. Comme le système doit attendre tous les bibliothécaires pour vous répondre, le plus lent dicte la vitesse de tout le monde.

La solution : Ils ont remplacé le hasard par un GPS en temps réel.

• Au lieu de choisir un bibliothécaire au hasard, le système regarde en temps réel : « Qui est rapide ? Qui est lent ? ».
• Si un bibliothécaire commence à ralentir, le GPS redirige instantanément les nouveaux clients vers les bibliothécaires en forme.
• Résultat : Même si un bibliothécaire tombe malade, les clients ne s'en rendent presque pas compte car le trafic est redirigé vers les autres en quelques millisecondes.

En résumé

Ces ingénieurs ont transformé un système fragile en une forteresse résiliente. Grâce à ces quatre mécanismes :

1. Chacun a son budget (pas de vol de ressources).
2. On déménage sans fermer les portes (maintenance sans coupure).
3. On répartit les risques (pas de perte totale en cas de panne de zone).
4. On évite les embouteillages (redirection intelligente vers les serveurs sains).

C'est ce qui permet à LinkedIn de rester rapide et fiable, même avec des milliards d'utilisateurs et des milliers de pannes potentielles chaque jour.

Résumé technique

Titre : Amélioration de la résilience des systèmes OLAP chez LinkedIn

Auteurs : Praveen Chaganlal, Jia Guo, Vivek Vaidyanathan, et al. (LinkedIn)
Sujet : Architecture distribuée, OLAP temps réel, Apache Pinot, résilience, isolation des charges de travail.

---

1. Problématique

Les entrepôts de données OLAP (Online Analytical Processing) en temps réel, tels qu'Apache Pinot utilisé chez LinkedIn, sont devenus critiques pour les infrastructures modernes, permettant l'analyse interactive de jeux de données à l'échelle du pétaoctet avec une latence inférieure à la seconde.

Cependant, à mesure que ces systèmes deviennent intégraux aux architectures de services, le maintien de stricts accords de niveau de service (SLA) face aux pannes, aux pics de charge et aux changements de cluster est aussi crucial que la performance brute. Les défis principaux identifiés sont :

• Le problème du "voisin bruyant" (Noisy Neighbor) : Sur des clusters partagés, des requêtes complexes peuvent saturer les ressources CPU et mémoire, dégradant les performances des autres charges de travail co-localisées.
• Impact des opérations de maintenance : Le rééquilibrage des données (lors de mises à jour, de mise à l'échelle ou de récupération de pannes) peut perturber le traitement des requêtes et réduire la disponibilité des données si les réplicas ne sont pas placés intelligemment par rapport aux domaines de défaillance.
• Sélection de serveur inadaptée : Les stratégies de routage statiques (comme le round-robin) ne tiennent pas compte de l'état réel des nœuds (lenteur due au GC, problèmes I/O), ce qui entraîne une latence élevée lorsque le nœud le plus lent d'un groupe de réplicas bloque l'ensemble de la requête.

2. Méthodologie et Solutions Proposées

L'article présente quatre mécanismes clés développés pour Apache Pinot, formant un cadre de résilience holistique :

A. Isolation des Charges de Travail par Requête (Query Workload Isolation - QWI)

Ce système introduit une budgétisation des ressources (CPU et mémoire) au niveau de la charge de travail, et non plus seulement au niveau de la requête ou du cluster.

• Comptabilité fine : Utilisation d'un échantillonnage sans verrou (lock-free sampling) pour mesurer la consommation de ressources par requête avec une surcharge inférieure à 1 %.
• Budgétisation et Application : Chaque charge de travail dispose d'un budget défini (en nanosecondes de CPU et octets de mémoire). Ces budgets sont propagés des contrôleurs aux brokers et serveurs.
• Application stricte :
  • Niveau Requête : Terminaison proactive des requêtes dépassant des seuils critiques (ex: 85 % d'utilisation de la mémoire) pour éviter les crashes OOM.
  • Niveau Charge de Travail : Rejet des nouvelles requêtes d'une charge de travail ayant épuisé son budget sur un hôte spécifique, garantissant l'isolation même en cas de pic de charge d'un voisin.

B. Placement de Données et Rééquilibrage Conscients des Zones de Maintenance (Maintenance Zone Aware)

Pour garantir la disponibilité lors des opérations de maintenance (ex: mise à jour d'une zone de disponibilité), les réplicas doivent être répartis de manière à ce que la perte d'une zone entière n'affecte pas la disponibilité des données.

• Algorithme d'affectation (Greedy Swap) : Un algorithme glouton calcule une affectation cible qui maximise la diversité des réplicas à travers les zones de maintenance (MZ). Il utilise une procédure d'échange itérative pour corriger les états "mauvais" (où plusieurs réplicas d'un même segment sont dans la même zone) avec des garanties de convergence prouvées mathématiquement.
• Rééquilibrage sans impact (Impact-Free Rebalancing) : Une procédure en deux phases pour passer de l'affectation actuelle à l'affectation cible :
  1. Drainage : Le trafic de requêtes est retiré des hôtes avant tout mouvement de données significatif.
  2. Transfert : Les segments sont déplacés uniquement lorsque la sécurité des réplicas est maintenue.
     Cela permet des mises à l'échelle et des migrations sans violation de SLA ni perte de disponibilité.

C. Sélection Adaptative des Serveurs (Adaptive Server Selection - ADSS)

Remplacement du routage statique par un routage dynamique basé sur les signaux de charge en temps réel.

• Modèle de Score : Les brokers calculent un score pour chaque serveur au sein d'un ensemble de serveurs miroirs (Mirror Server Set - MSS) en utilisant des métriques de requêtes en cours (in-flight) et une moyenne mobile exponentielle (EMA) de la latence.
• Algorithme Hybride : Combine la profondeur de file d'attente estimée et la latence pour éviter les nœuds lents.
• Contrôle des oscillations : Utilisation d'une politique probabiliste (Softmax) pour éviter que tous les brokers ne redirigent simultanément le trafic vers le même "meilleur" serveur, ce qui pourrait créer de nouvelles oscillations de charge.

3. Résultats et Évaluation

Les mécanismes ont été déployés et évalués sur la production de LinkedIn, couvrant plus de 200 clusters, 10 000+ nœuds serveurs et 10 Pétaoctets de données.

• Performance de QWI :
  • Surcharge CPU < 1 % et augmentation de la mémoire de ~0,5 Go.
  • Latence P99 inchangée.
  • Résultat clé : En présence d'une charge de travail lourde, la latence d'une charge de travail sensible (co-locataire) reste stable (autour de 500 ms) grâce à l'isolation, alors qu'elle aurait dégrader de 10x (6 secondes) sans QWI.
• Résultats du Rééquilibrage :
  • Disponibilité : Maintien de > 99,9 % de disponibilité malgré un turnover quotidien de nœuds de 7 %.
  • Migration : Migration réussie de 10 PB de données vers une infrastructure cloud-native avec une mise à disposition zéro (zero-downtime) et aucune violation de SLA.
  • Avant ces mécanismes, le drainage d'une zone de maintenance pouvait laisser jusqu'à 33 % des données indisponibles ; désormais, l'impact est nul.
• Efficacité de l'ADSS :
  • Réduction de la latence globale P98 d'environ 9 %.
  • Prévention de la dégradation de la latence : < 10 % des requêtes sont affectées lors d'un ralentissement de serveur (contre ~33 % avec le routage par groupe de réplicas).
  • Réduction de 97 % des alertes de serveurs lents et de 89 % du temps d'ingénierie consacré aux investigations.

4. Contributions Clés

1. QWI (Isolation des charges) : Première implémentation de budgétisation CPU/mémoire fine et appliquée en continu au sein d'un moteur OLAP distribué, offrant une isolation prédictive avec une surcharge négligeable.
2. Algorithme de placement MZ-Aware : Une solution algorithmique prouvée pour garantir la tolérance aux pannes de zone lors de la mise à l'échelle et des réparations, sans nécessiter de contrôle total sur le placement des nœuds par la plateforme cloud.
3. Rééquilibrage sans impact : Une méthode de transition d'état qui garantit que le trafic est drainé avant le mouvement de données, éliminant les interruptions de service lors des opérations de maintenance.
4. Routage Adaptatif OLAP : Adaptation réussie des techniques de sélection de réplica (inspirées de C3/ELS) aux contraintes spécifiques de l'OLAP (modèle scatter-gather), avec des mécanismes de stabilisation contre les oscillations.

5. Signification et Impact

Ce travail démontre qu'il est possible de maintenir des SLA stricts (latence sub-secondaire) sur des systèmes OLAP massifs et hétérogènes, même dans des environnements cloud dynamiques sujets aux pannes et aux changements fréquents.

L'approche de LinkedIn transforme la résilience d'une propriété réactive (gestion des pannes) en une propriété proactive (isolation, placement intelligent, routage adaptatif). Ces mécanismes ne sont pas spécifiques à Pinot mais sont présentés comme génériques et applicables à la plupart des systèmes OLAP modernes, offrant une feuille de route pour la construction d'infrastructures d'analyse de données robustes à l'échelle du pétaoctet.