HeadlinesBriefing favicon HeadlinesBriefing.com

Protection d'Uber contre les tempêtes de réessais

Hacker News •
×

Les tempêtes de réessais ont historiquement un impact sur les opérations commerciales et la confiance dans la marque. Bien que le réglage de la configuration des réessais et les budgets de réessais offrent une atténuation significative au niveau du service, ils sont configurés manuellement et manquent de visibilité sur l'amplification interservices causée par les chaînes de dépendances profondes et les modèles de distribution. Par conséquent, il peut être difficile de protéger l'infrastructure contre l'effet domino déclenché par une seule panne de service plus profondément dans la pile.

Une raison clé est que le comportement de réessai actuel n'est pas conscient du contexte. Bien que nous puissions contrôler le nombre de réessais, nous ne pouvons pas contrôler précisément quand ils se produisent. Cela découle du défi de distinguer de manière fiable les erreurs générées par un service de celles simplement propagées à travers lui. Par conséquent, les réessais sont appliqués uniformément plutôt que conditionnellement. Cette approche fonctionne pour les défaillances transitoires ou à faible taux. Cependant, lors d'une dégradation modérée ou sévère, elle devient contre-productive.

Réessayer agressivement contre un service déjà en difficulté augmente la charge, accélère la défaillance et amplifie le trafic de réessai à travers les dépendances en amont. Ce qui commence comme une panne localisée peut rapidement dégénérer en un incident à l'échelle de la pile—dégradant finalement, ou dans le pire des cas, cassant complètement l'expérience de l'utilisateur final.

On pourrait soutenir que les codes d'erreur des services en aval pourraient être traduits en amont pour fournir un contexte aux réessais. Bien que théoriquement possible, cette approche ne passe pas à l'échelle chez Uber en raison d'un grand fan-in et fan-out, de flux d'appels en évolution et de la nécessité de changements adaptatifs fréquents. Par conséquent, nous avons développé un mécanisme contextuel dans l'infrastructure partagée pour gérer les erreurs plus efficacement. Ce blog explique le mécanisme.