Uber's Failover Architecture: Reconciling Reliability and Efficiency in Hyperscale Microservice Infrastructure

L'article présente l'architecture de basculement d'Uber (UFA), qui optimise la fiabilité et l'efficacité de son infrastructure microservices à grande échelle en remplaçant le modèle de capacité uniforme par une approche différenciée selon la criticité des services, permettant ainsi de réduire la provisionnement de 2x à 1,3x tout en maintenant une disponibilité de 99,97 %.

Mayank Bansal, Milind Chabbi, Kenneth Bogh, Srikanth Prodduturi, Kevin Xu, Amit Kumar, David Bell, Ranjib Dey, Yufei Ren, Sachin Sharma, Juan Marcano, Shriniket Kale, Subhav Pradhan, Ivan Beschastnikh, Miguel Covarrubias, Chien-Chih Liao, Sandeep Koushik Sheshadri, Wen Luo, Kai Song, Ashish Samant, Sahil Rihan, Nimish Sheth, Uday Kiran Medisetty

Publié Tue, 10 Ma
📖 5 min de lecture🧠 Analyse approfondie

Each language version is independently generated for its own context, not a direct translation.

Imaginez qu'Uber est une immense ville virtuelle où des millions de chauffeurs et de livreurs travaillent chaque jour. Pour que cette ville ne s'effondre jamais, même si un quartier entier (une région de serveurs) prend feu ou subit une panne, Uber avait une règle très simple mais très coûteuse : avoir deux villes identiques en permanence.

C'est comme si vous possédiez deux restaurants identiques, l'un à Paris et l'autre à Lyon, et que vous gardiez tous les deux ouverts à 100%, même si vous n'avez que 50 clients. Le restaurant de Lyon reste vide la moitié du temps, attendant patiemment que Paris tombe en panne. C'est sûr, mais c'est un gaspillage énorme d'argent et d'énergie.

Voici comment Uber a changé la donne avec son nouveau système, l'UFA (Uber Failover Architecture), en utilisant des analogies simples.

1. Le Problème : La "Méthode du Double Gâteau"

Avant, Uber traitait tous ses services de la même manière, qu'il s'agisse de la fonctionnalité la plus critique (trouver un chauffeur pour vous) ou de quelque chose de moins urgent (comme une fonctionnalité de test pour les développeurs).

  • L'ancien modèle : Ils avaient un "filet de sécurité" énorme et vide pour tout le monde. Résultat : leurs serveurs étaient utilisés à seulement 20% de leur capacité. C'est comme avoir un bus de 50 places qui ne transporte que 10 passagers, mais payer le chauffeur et le carburant pour 50.

2. L'Idée Géniale : Le "Bus de Transfert Intelligent"

Les ingénieurs d'Uber ont réalisé une chose cruciale : les pannes catastrophiques qui nécessitent de basculer tout le trafic d'une région à l'autre sont extrêmement rares. En moyenne, cela n'arrive que 20 heures par an !

Alors, pourquoi garder un filet de sécurité vide 99,7% du temps ?

Ils ont créé un système en deux temps, comme un stade de football :

  • Les places VIP (Services Critiques) : Ce sont les services vitaux (trouver un chauffeur, payer). Ils ont toujours une place réservée et garantie, prête à l'emploi.
  • Les places "Spectateurs" (Services Non-Critiques) : Ce sont les services moins urgents. En temps normal, ces services s'assoient sur les places réservées aux VIP qui sont vides ! Ils utilisent l'espace gratuit.
  • Le match commence (La Panne) : Si la région principale tombe en panne, les VIPs doivent absolument avoir leur place. Les "Spectateurs" (services non-critiques) sont donc gentiment mais fermement priés de se lever (évacués) pour laisser la place aux VIPs.

3. Comment ça marche en pratique ?

Voici les étapes de ce ballet numérique :

  1. Le "Triage" (La Sécurité) : Avant de pouvoir faire ça, il fallait s'assurer que les VIPs ne dépendent pas des Spectateurs. Si un service critique s'effondrait parce qu'un service non-critique a disparu, le système ne pouvait pas fonctionner. Uber a créé des outils (comme des détecteurs de fumée) pour trouver et corriger ces liens dangereux. C'est comme s'assurer que le moteur de la voiture ne dépend pas du système de climatisation pour démarrer.
  2. L'Évacuation Rapide : Quand la panne arrive, les services non-critiques sont arrêtés instantanément. Ils libèrent l'espace (les CPU) pour que les services critiques puissent grandir et absorber tout le trafic mondial.
  3. Le "Rebond" (Cloud et Batch) : Où vont les services non-critiques évacués ? Ils ne disparaissent pas ! Ils sont envoyés dans des "zones tampons" (des serveurs de traitement de données ou le Cloud public) pour être rétablis rapidement, mais avec un peu de retard (par exemple, dans une heure). C'est comme envoyer les spectateurs dans un parking voisin pendant que le stade est évacué pour les équipes de secours.

4. Les Résultats : Moins de Gaspillage, Plus de Sécurité

Grâce à cette architecture intelligente :

  • Efficacité : Au lieu d'utiliser 20% de leurs serveurs, Uber les utilise maintenant à 30%. C'est comme remplir un bus à moitié plein au lieu d'un quart.
  • Économies : Ils ont supprimé 1 million de cœurs de processeurs (l'équivalent de 1 million d'ordinateurs de bureau) de leur infrastructure. C'est une économie massive d'argent et d'énergie.
  • Fiabilité : Malgré ces changements, la disponibilité des services critiques reste à 99,97%. Les utilisateurs ne remarquent rien, même lors des pannes.

En Résumé

Uber a remplacé l'approche "gâchis par sécurité" (garder tout le monde en double) par une approche "intelligente et flexible".

  • Avant : Deux restaurants ouverts, l'un vide.
  • Maintenant : Un restaurant principal, et un second qui sert de salle de sport pour les employés quand il n'y a pas de clients. Si le restaurant principal brûle, les employés évacuent la salle de sport pour sauver les clients, et la salle de sport est réouverte quelques heures plus tard.

C'est un exemple parfait de comment la technologie peut être à la fois plus sûre et moins chère en utilisant les données pour prendre de meilleures décisions, plutôt que de simplement acheter plus de matériel.