Rejoignez-Nous sur

Incident post mortem: 29 avril et 9 mai 2020

0*qdSnVFGalSElDHjz

News

Incident post mortem: 29 avril et 9 mai 2020

Coinbase

Par Jesse Pollak, Responsable Ingénierie, Consommateur

Au cours des deux dernières semaines, Coinbase a connu deux pannes qui ont affecté notre capacité à servir nos clients. Pour ces deux incidents, nous avons rapidement découvert les causes profondes et restauré le service. Cependant, nous voulons donner un aperçu plus approfondi de ce qui n'a pas fonctionné et de ce que nous faisons pour y remédier à l'avenir. Nous nous engageons à faire de Coinbase l'endroit le plus simple et le plus fiable pour acheter, vendre et gérer votre crypto-monnaie.

De 10:28 PDT à 10:40 PDT le 29 avril 2020, l'API qui alimente coinbase.com et nos applications mobiles est devenue indisponible pour nos clients dans le monde entier. Cela a été suivi de 30 minutes de stabilité, puis d'une période d'instabilité de 11:12 PDT à 12:11 PDT, pendant laquelle nous avons subi 20 minutes d'indisponibilité totale et 40 minutes de performances dégradées avec des taux d'erreur élevés. À 12:11 PDT, le service complet a été restauré et tous les systèmes ont commencé à fonctionner normalement.

Ce problème a affecté la capacité des clients à accéder aux interfaces utilisateur Coinbase et Coinbase Pro, et n'a pas eu d'incidence sur le trading via nos API d'échange ni sur la santé des marchés sous-jacents. Elle a été causée et perpétuée par deux causes profondes distinctes mais liées.

Taux d'erreur API (%) pendant la période 4/29 (toutes les heures en PDT)

L'incident initial a été déclenché à 17 h 28 HAP par une augmentation du taux de connexions à l'une de nos bases de données principales. Cette augmentation du taux de connexion est le résultat d'un déploiement créant de nouvelles connexions alors que nos systèmes ont été mis à l'échelle pour répondre à un trafic élevé à l'époque. Lorsque ce pic de connexions s'est produit, le système d'exploitation hôte de la base de données a commencé à rejeter les nouvelles connexions TCP à l'hôte, ce qui a déclenché des opérations dégradées et redémarre dans la couche de routage de la base de données. Lorsque cela s'est produit, notre surveillance a commencé à signaler un taux d'erreur élevé dans toutes les demandes d'API qui ont touché la base de données impactée.

En réponse aux défaillances de la couche de routage et aux défaillances opérationnelles correspondantes, nos systèmes ont tenté de se reconnecter afin de réessayer ces opérations. Malheureusement, en raison de la mauvaise gestion des connexions fermées et du manque de prise en charge de la gigue de synchronisation dans la création de nouvelles connexions, nos systèmes ont «pris d'assaut» la base de données. Cette tempête de connexions a déclenché le même échec que nous avons vu sur d'autres membres de la couche de routage, empêchant l'établissement de nouvelles connexions. Alors que la base de données initiale a pu récupérer à 10 h 40 HAP, ce même mode de défaillance s'est produit avec trois autres instances de base de données distinctes, créant la deuxième période d'indisponibilité de 11 h 12 HAP à 12 h 11 HAP.

En réponse à cet échec, nous déployons un certain nombre de changements. Premièrement, nous modifions notre topologie de déploiement de base de données pour réduire notre nombre de connexions global, limiter les pics de connexion et séparer les processus de routage et de démon de la base de données pour limiter la concurrence pour les ressources hôtes. Deuxièmement, nous résolvons le problème avec la logique de connexion fermée du pilote et implémentons une meilleure gigue pour éviter les interruptions de connexion lorsque ce mode de défaillance se produit. Enfin, nous déployons des protections qui nous permettront de limiter l’impact des futures défaillances de la base de données à un sous-ensemble de demandes aussi réduit que possible.

De 17:17 PDT à 18:00 PDT le 9 mai 2020, l'API qui alimente coinbase.com et nos applications mobiles a connu un taux d'erreur élevé. Le taux d'erreur a culminé à 17:24 PDT et s'est progressivement dégradé jusqu'à ce que le problème soit complètement résolu à 18:00 PDT. Ce problème a affecté la capacité des clients à accéder aux interfaces utilisateur Coinbase et Coinbase Pro, et n'a pas eu d'incidence sur le trading via nos API d'échange ni sur la santé des marchés sous-jacents.

Taux d'erreur API (%) au cours de la période 5/9 (toutes les heures en PDT)

À 17:18 PDT, parallèlement à une augmentation du trafic due à la volatilité du marché, notre surveillance a détecté une latence élevée et des taux d'erreur dans notre API et a alerté notre équipe d'ingénieurs du problème. En réponse à ces alertes, notre équipe d'ingénieurs a observé une latence élevée dans tous les sortant Requêtes HTTP sur les instances d'application qui servent notre trafic API. Cela s'est manifesté dans notre surveillance par une augmentation spectaculaire du pourcentage de temps passé par demande d'API dans les demandes HTTP sortantes.

% de temps passé par demande pendant la période 5/9 (toutes les heures en PDT)

En raison de cette augmentation de la latence, nous avons constaté un taux d'erreur élevé en raison de délais d'attente lors de la tentative de ces requêtes HTTP sortantes. Le taux d'erreur élevé a été amplifié par notre équilibreur de charge tuant des instances d'application par ailleurs saines qui ont échoué aux vérifications de l'état. Les vérifications de l'état de santé ont échoué en raison de la saturation de leur file d'attente de demandes en raison de ce changement de forme de la demande.

Après une enquête plus approfondie, nous avons identifié que l'augmentation de la latence était due à la limitation du débit au niveau de l'instance des requêtes DNS utilisées pour traiter ces requêtes HTTP. À mesure que le trafic diminuait en raison du taux d'erreur, nous sommes descendus en dessous de la limite de taux, ce qui a entraîné une dégradation progressive du taux d'erreur. En parallèle, nous avons déployé une modification précédemment en cours pour ajouter une mise en cache DNS par instance, nous ramenant dans la plage non limitée de débit pour les requêtes DNS globales et garantissant que le mode de défaillance n'apparaîtra plus.

Au-delà de la résolution de la cause première spécifique de cet incident, nous apportons un certain nombre d'améliorations pour augmenter la disponibilité en cas de futures pannes similaires. Premièrement, nous ajustons notre logique de vérification de l'intégrité pour garantir que les instances d'application saturées, mais par ailleurs saines, ne sont pas automatiquement supprimées de l'équilibreur de charge. Deuxièmement, bien que cet incident ait affecté toutes les demandes HTTP, nous déployons des outils améliorés pour nous assurer que nous pouvons identifier et arrêter rapidement les services externes errants qui augmentent la latence. Enfin, comme pour l'incident du 4/29, nous déployons des protections qui nous permettront de limiter l'impact des futures défaillances HTTP à un sous-ensemble de demandes aussi réduit que possible.

Ces deux incidents ont eu un impact sur notre capacité à servir les clients Coinbase à des moments critiques. L'une des valeurs de notre entreprise est l'apprentissage continu et nous nous engageons à tirer les enseignements de ces épisodes pour améliorer Coinbase. Si vous souhaitez travailler sur des problèmes de disponibilité difficiles et construire l'avenir de la cryptoéconomie, Venez nous rejoindre!





Traduction de l’article de Coinbase : Article Original

BlockBlog

Le Meilleur de l'Actualité Blockchain Francophone & Internationale | News, Guides, Avis & Tutoriels pour s'informer et démarrer facilement avec Bitcoin, les Crypto-Monnaies et le Blockchain. En Savoir Plus sur L'Équipe BlockBlog

Commenter cet Article

Commenter cet Article

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Plus dans News

Les Plus Populaires

Acheter des Bitcoin

Acheter des Alt-Coins

Sécuriser vos Cryptos

Vêtements et Produits Dérivés

Top