{"id":92073,"date":"2020-08-22T19:41:56","date_gmt":"2020-08-22T17:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io"},"modified":"2020-08-22T19:41:56","modified_gmt":"2020-08-22T17:41:56","slug":"post-mortem-po-nedostupnosti-quay-io","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem sur l'indisponibilit\u00e9 de Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Note de traduction.<\/b>: au d\u00e9but du mois d'ao\u00fbt, Red Hat a publiquement annonc\u00e9 des solutions aux probl\u00e8mes d'accessibilit\u00e9 rencontr\u00e9s par les utilisateurs de son service au cours des mois pr\u00e9c\u00e9dents Quay.io<\/a><\/noindex> (\u00e0 la base \u2014 un registre pour les images de conteneurs, acquis par la soci\u00e9t\u00e9 avec l'achat de CoreOS). Peu importe votre int\u00e9r\u00eat pour ce service en lui-m\u00eame, le parcours des ing\u00e9nieurs SRE de l'entreprise pour diagnostiquer et r\u00e9soudre les causes de l'incident est instructif.<\/i><\/p>\n

\"Post
\n
\nLe 19 mai, t\u00f4t le matin (heure d'\u00e9t\u00e9 de l'Est nord-am\u00e9ricain, EDT), le service quay.io est tomb\u00e9. L'incident a affect\u00e9 \u00e0 la fois les utilisateurs de quay.io et les projets Open Source utilisant quay.io comme plateforme pour construire et distribuer des logiciels. Red Hat tient \u00e0 la confiance des deux groupes.<\/p>\n

L'\u00e9quipe des ing\u00e9nieurs SRE s'est imm\u00e9diatement mise au travail pour stabiliser le fonctionnement du service Quay. Cependant, pendant qu'ils s'occupaient de cela, les clients ont perdu la capacit\u00e9 de pousser de nouvelles images, ne r\u00e9ussissant qu'\u00e0 r\u00e9cup\u00e9rer sporadiquement celles existantes. Pour une raison inconnue, la base de donn\u00e9es de quay.io se bloquait apr\u00e8s l'extension du service \u00e0 pleine capacit\u00e9.<\/a><\/noindex><\/p>\n

\u00abQu'est-ce qui a chang\u00e9 ?<\/b>\u00bb \u2014 c'est la premi\u00e8re question que l'on pose g\u00e9n\u00e9ralement dans de tels cas. Nous avons remarqu\u00e9 qu'un peu avant le probl\u00e8me, le cluster OpenShift Dedicated (sur lequel repose quay.io) avait commenc\u00e9 \u00e0 se mettre \u00e0 jour vers la version 4.3.19. \u00c9tant donn\u00e9 que quay.io fonctionne sur Red Hat OpenShift Dedicated (OSD), les mises \u00e0 jour r\u00e9guli\u00e8res \u00e9taient une op\u00e9ration routine et n'avaient jamais entra\u00een\u00e9 de probl\u00e8mes. De plus, au cours des six derniers mois, nous avons mis \u00e0 jour plusieurs fois les clusters Quay sans aucune interruption du service.<\/p>\n

Alors que nous tentions de restaurer le service, d'autres ing\u00e9nieurs ont commenc\u00e9 \u00e0 pr\u00e9parer un nouveau cluster OSD avec la version pr\u00e9c\u00e9dente du logiciel, afin de pouvoir tout d\u00e9ployer dessus en cas de besoin.<\/p>\n

Analyse des causes profondes<\/h2>\n

\nLe principal sympt\u00f4me de la panne \u00e9tait une avalanche de dizaines de milliers de connexions \u00e0 la base de donn\u00e9es, rendant l'instance MySQL quasiment inutilisable. Cela compliquait le diagnostic du probl\u00e8me. Nous avons impos\u00e9 une limite au nombre maximal de connexions des clients pour aider l'\u00e9quipe SRE \u00e0 \u00e9valuer le probl\u00e8me. Aucun trafic anormal vers la base de donn\u00e9es n'a \u00e9t\u00e9 observ\u00e9 : en r\u00e9alit\u00e9, la plupart des requ\u00eates \u00e9taient des lectures, et seules quelques-unes \u00e9taient des \u00e9critures.<\/p>\n

Nous avons \u00e9galement essay\u00e9 d'identifier un mod\u00e8le dans le trafic de la base de donn\u00e9es qui aurait pu provoquer cette avalanche. Cependant, aucune r\u00e9gularit\u00e9 n'a pu \u00eatre trouv\u00e9e dans les logs. En attendant la disponibilit\u00e9 du nouveau cluster avec OSD 4.3.18, nous avons continu\u00e9 \u00e0 tenter de lancer les pods quay.io. Chaque fois que le cluster atteignait sa pleine capacit\u00e9, la base de donn\u00e9es se gelait. Cela signifiait qu'il \u00e9tait n\u00e9cessaire de red\u00e9marrer l'instance RDS en plus de tous les pods quay.io.<\/p>\n

Dans la soir\u00e9e, nous avons stabilis\u00e9 le service en mode lecture seule et d\u00e9sactiv\u00e9 le maximum de fonctionnalit\u00e9s non essentielles (comme la collecte des d\u00e9chets dans l'espace de noms) pour r\u00e9duire la charge sur la base de donn\u00e9es. Les blocages ont cess\u00e9, mais la cause n'a pas \u00e9t\u00e9 trouv\u00e9e<\/b>. Le nouveau cluster OSD \u00e9tait pr\u00eat, nous avons d\u00e9plac\u00e9 le service, connect\u00e9 le trafic et continu\u00e9 \u00e0 surveiller.<\/p>\n

Quay.io fonctionnait de mani\u00e8re stable sur le nouveau cluster OSD, nous sommes donc retourn\u00e9s aux journaux de la base de donn\u00e9es, mais nous n'avons pas pu trouver de corr\u00e9lation expliquant les blocages. Les ing\u00e9nieurs OpenShift ont travaill\u00e9 avec nous pour essayer de comprendre si des changements dans Red Hat OpenShift 4.3.19 avaient pu causer des probl\u00e8mes avec Quay. Cependant, rien n'a \u00e9t\u00e9 d\u00e9couvert, et nous n'avons pas pu reproduire le probl\u00e8me en conditions de laboratoire.<\/b>.<\/p>\n

Le deuxi\u00e8me incident<\/h2>\n

\nle 28 mai, peu avant midi EDT, quay.io est tomb\u00e9 \u00e0 nouveau avec les m\u00eames sympt\u00f4mes : le fonctionnement de la base de donn\u00e9es \u00e9tait bloqu\u00e9. Et encore une fois, nous avons concentr\u00e9 tous nos efforts sur l'enqu\u00eate. Tout d'abord, il fallait r\u00e9tablir le fonctionnement du service. Cependant, Cette fois-ci, le red\u00e9marrage de RDS et le red\u00e9marrage des pods quay.io n'ont rien donn\u00e9.<\/b>Quay est \u00e9crit en Python, et chaque pod fonctionne comme un conteneur monolithique unique. Un grand nombre de t\u00e2ches parall\u00e8les sont ex\u00e9cut\u00e9es simultan\u00e9ment dans l'environnement d'ex\u00e9cution du conteneur. Nous utilisons la biblioth\u00e8que<\/p>\n

gevent pour traiter les requ\u00eates web. Lorsque Quay re\u00e7oit une requ\u00eate (via notre propre API ou via l'API de Docker), un travailleur gevent lui est assign\u00e9. Ce travailleur doit g\u00e9n\u00e9ralement se connecter \u00e0 la base de donn\u00e9es. Apr\u00e8s la premi\u00e8re panne, nous avons d\u00e9couvert que les travailleurs gevent se connectaient \u00e0 la base de donn\u00e9es en utilisant les param\u00e8tres par d\u00e9faut.<\/code> d'\u00eatre gunicorn<\/code> pour le traitement des requ\u00eates Web. Lorsqu'une requ\u00eate arrive dans Quay (via notre propre API ou via l'API de Docker), elle se voit assigner un worker gevent. Ce worker doit g\u00e9n\u00e9ralement se connecter \u00e0 la base de donn\u00e9es. Apr\u00e8s le premier incident, nous avons d\u00e9couvert que les workers gevent se connectaient \u00e0 la base de donn\u00e9es en utilisant les param\u00e8tres par d\u00e9faut.<\/p>\n

\u00c9tant donn\u00e9 le nombre significatif de pods Quay et des milliers de requ\u00eates entrantes par seconde, un grand nombre de connexions \u00e0 la base de donn\u00e9es aurait th\u00e9oriquement pu surcharger l'instance MySQL. Gr\u00e2ce \u00e0 la surveillance, nous savons que Quay traite en moyenne 5 000 requ\u00eates par seconde. Le nombre de connexions \u00e0 la base de donn\u00e9es \u00e9tait plus ou moins le m\u00eame. 5 000 connexions \u00e9taient confortablement dans les capacit\u00e9s de notre instance RDS (ce qui n\u2019\u00e9tait pas le cas pour des dizaines de milliers). Pour une raison quelconque, il y a eu des pics inattendus dans le nombre de connexions.<\/b>, cependant nous n'avons remarqu\u00e9 aucune corr\u00e9lation avec les requ\u00eates entrantes.<\/p>\n

Cette fois, nous avons d\u00e9cid\u00e9 de trouver et de r\u00e9soudre la source du probl\u00e8me, au lieu de nous contenter d'un red\u00e9marrage. Des modifications ont \u00e9t\u00e9 apport\u00e9es \u00e0 la base de code de Quay Des modifications ont \u00e9t\u00e9 apport\u00e9es pour limiter le nombre de connexions \u00e0 la base de donn\u00e9es pour chaque worker.<\/b> gevent. Ce nombre est devenu un param\u00e8tre de configuration : il est devenu possible de le modifier \u00ab \u00e0 la vol\u00e9e \u00bb, sans avoir \u00e0 reconstruire une nouvelle image de conteneur. Pour d\u00e9couvrir combien de connexions pouvaient r\u00e9ellement \u00eatre g\u00e9r\u00e9es, plusieurs tests ont \u00e9t\u00e9 effectu\u00e9s dans un environnement de staging, o\u00f9 diff\u00e9rentes valeurs \u00e9taient sp\u00e9cifi\u00e9es pour voir comment cela affectait les sc\u00e9narios de tests de charge. Au final, il a \u00e9t\u00e9 constat\u00e9 que Quay commence \u00e0 renvoyer des erreurs 502 lorsque le nombre de connexions d\u00e9passe 10 000.<\/b><\/p>\n

Nous avons imm\u00e9diatement d\u00e9ploy\u00e9 cette nouvelle version en production et avons commenc\u00e9 \u00e0 surveiller le graphique des connexions \u00e0 la base de donn\u00e9es. Dans le pass\u00e9, la base \u00e9tait bloqu\u00e9e environ 20 minutes. Apr\u00e8s 30 minutes sans probl\u00e8me, nous avons commenc\u00e9 \u00e0 avoir de l'espoir, et apr\u00e8s une heure, nous avons eu la certitude. Nous avons restaur\u00e9 le trafic d'\u00e9criture sur le site et avons commenc\u00e9 l'analyse post-mortem.<\/p>\n

Avoir r\u00e9ussi \u00e0 contourner le probl\u00e8me causant le blocage, nous n'avons pas d\u00e9termin\u00e9 ses v\u00e9ritables causes.<\/b>Il a \u00e9t\u00e9 confirm\u00e9 qu'il n'\u00e9tait pas li\u00e9 \u00e0 des modifications dans OpenShift 4.3.19, puisque le m\u00eame ph\u00e9nom\u00e8ne avait eu lieu sur la version 4.3.18, qui avait auparavant fonctionn\u00e9 avec Quay sans aucun probl\u00e8me.<\/p>\n

Il y avait clairement quelque chose de plus dans le cluster.<\/p>\n

Une \u00e9tude d\u00e9taill\u00e9e<\/h2>\n

\nQuay.io a utilis\u00e9 les param\u00e8tres par d\u00e9faut pour se connecter \u00e0 la base de donn\u00e9es sans aucun probl\u00e8me pendant six ans. Qu'est-ce qui a chang\u00e9 ? Il est clair que le trafic sur quay.io a augment\u00e9 de mani\u00e8re constante durant tout ce temps. Dans notre cas, il semblait que nous avions atteint un certain seuil qui a d\u00e9clench\u00e9 une avalanche de connexions. Nous avons continu\u00e9 \u00e0 examiner les journaux de la base de donn\u00e9es apr\u00e8s la deuxi\u00e8me panne, mais nous n'avons trouv\u00e9 aucune r\u00e9gularit\u00e9 ni relation \u00e9vidente.<\/p>\n

Pendant ce temps, l'\u00e9quipe SRE travaillait sur des am\u00e9liorations concernant l'observabilit\u00e9 des requ\u00eates dans Quay et la sant\u00e9 globale du service. De nouvelles m\u00e9triques et tableaux de bord<\/b>, montrant quelles parties de Quay sont les plus sollicit\u00e9es par les clients.<\/p>\n

Quay.io a fonctionn\u00e9 normalement jusqu'au 9 juin. Le matin (heure de l'Est), nous avons de nouveau constat\u00e9 une augmentation significative du nombre de connexions \u00e0 la base de donn\u00e9es. Cette fois-ci, il n'y a pas eu d'interruption<\/b>, car un nouveau param\u00e8tre limitait leur nombre et emp\u00eachait de d\u00e9passer la capacit\u00e9 de MySQL. Cependant, pendant environ une demi-heure, de nombreux utilisateurs ont signal\u00e9 un ralentissement de quay.io. Nous avons rapidement rassembl\u00e9 toutes les donn\u00e9es possibles, en utilisant les outils de surveillance ajout\u00e9s. Une r\u00e9gularit\u00e9 s'est soudainement manifest\u00e9e.<\/p>\n

Juste avant la mont\u00e9e en charge des connexions, un grand nombre de requ\u00eates sont arriv\u00e9es sur l'API App Registry<\/b>. App Registry est une fonctionnalit\u00e9 peu connue de quay.io. Elle permet de stocker des \u00e9l\u00e9ments tels que des charts Helm et des conteneurs avec des m\u00e9tadonn\u00e9es riches. La plupart des utilisateurs de quay.io n'utilisent pas cette fonction, mais elle est activement exploit\u00e9e par Red Hat OpenShift. L'OperatorHub inclus dans OpenShift stocke tous les op\u00e9rateurs dans App Registry. Ces op\u00e9rateurs constituent la base de l'\u00e9cosyst\u00e8me de charges de travail d'OpenShift et du mod\u00e8le op\u00e9rationnel (dans le cadre des op\u00e9rations dites de \u00ab deuxi\u00e8me jour \u00bb, Day 2), orient\u00e9 vers les partenaires.<\/p>\n

Chaque cluster OpenShift 4 utilise des op\u00e9rateurs du OperatorHub int\u00e9gr\u00e9 pour publier le catalogue des op\u00e9rateurs disponibles pour installation et fournir des mises \u00e0 jour pour ceux d\u00e9j\u00e0 install\u00e9s. Avec la croissance de la popularit\u00e9 d'OpenShift 4, le nombre de clusters a \u00e9galement augment\u00e9 dans le monde entier. Chacun de ces clusters charge le contenu des op\u00e9rateurs pour activer le OperatorHub int\u00e9gr\u00e9, en utilisant App Registry \u00e0 l'int\u00e9rieur de quay.io comme backend. Dans notre recherche de la source du probl\u00e8me, nous avons n\u00e9glig\u00e9 que, avec la popularit\u00e9 croissante d'OpenShift, la charge sur l'une des fonctionnalit\u00e9s rarement utilis\u00e9es de quay.io augmentait \u00e9galement.<\/b>.<\/p>\n

Nous avons effectu\u00e9 une certaine analyse du trafic des requ\u00eates d'App Registry et avons examin\u00e9 le code du registre. Des d\u00e9fauts se sont imm\u00e9diatement r\u00e9v\u00e9l\u00e9s, entra\u00eenant une formation des requ\u00eates \u00e0 la base de donn\u00e9es de mani\u00e8re non optimale. Lors de faibles charges, cela ne posait pas de probl\u00e8me, mais lorsqu'elle augmentait, cela devenait source de probl\u00e8mes. App Registry avait deux points de terminaison probl\u00e9matiques, mal r\u00e9agissant \u00e0 l'augmentation de la charge : le premier fournissait la liste de tous les paquets dans le d\u00e9p\u00f4t, et le second renvoyait tous les blobs pour un paquet.<\/p>\n

R\u00e9solution des causes<\/h2>\n

\nLa semaine suivante, nous nous sommes concentr\u00e9s sur l'optimisation du code de l'App Registry et de son environnement. Des requ\u00eates SQL manifestement inefficaces ont \u00e9t\u00e9 retravaill\u00e9es, des appels de commande superflus \u00e9limin\u00e9s tar<\/code> (elle se lan\u00e7ait \u00e0 chaque extraction de blobs), un cache a \u00e9t\u00e9 ajout\u00e9 partout o\u00f9 cela \u00e9tait possible. Ensuite, des tests de performance \u00e0 grande \u00e9chelle ont \u00e9t\u00e9 r\u00e9alis\u00e9s et la vitesse de l'App Registry a \u00e9t\u00e9 compar\u00e9e avant et apr\u00e8s les modifications.<\/p>\n

Les requ\u00eates API, qui prenaient autrefois jusqu'\u00e0 trente secondes, s'ex\u00e9cutent d\u00e9sormais en millisecondes.<\/b>. La semaine prochaine, nous d\u00e9ploierons les modifications en production, et depuis, quay.io fonctionne de mani\u00e8re stable. Pendant ce temps, plusieurs pics de trafic ont \u00e9t\u00e9 observ\u00e9s sur l'endpoint de l'App Registry, mais les am\u00e9liorations apport\u00e9es ont emp\u00each\u00e9 toute interruption dans le fonctionnement de la base de donn\u00e9es.<\/p>\n

Qu'avons-nous appris ?<\/h2>\n

\nIl est clair que tout service cherche \u00e0 \u00e9viter les temps d'arr\u00eat. Dans notre cas, nous croyons que les pannes r\u00e9centes ont contribu\u00e9 \u00e0 am\u00e9liorer quay.io. Nous avons retenu plusieurs le\u00e7ons cl\u00e9s que nous souhaitons partager :<\/p>\n

    \n
  1. Les donn\u00e9es sur qui utilise votre service et comment ne sont jamais superflues.<\/b>Comme Quay \u00ab fonctionnait simplement \u00bb, nous n'avons jamais ressenti le besoin de consacrer du temps \u00e0 l'optimisation du trafic et \u00e0 la gestion de la charge. Tout cela a cr\u00e9\u00e9 une fausse impression de s\u00e9curit\u00e9, que le service pouvait se d\u00e9velopper ind\u00e9finiment.<\/li>\n
  2. Lorsque le service tombe, le r\u00e9tablissement de son fonctionnement est la priorit\u00e9 principale.<\/b>. Alors que Quay continuait de souffrir d'une base de donn\u00e9es bloqu\u00e9e lors de la premi\u00e8re panne, nos proc\u00e9dures standard n'avaient pas l'effet escompt\u00e9 et nous n'avons pas pu restaurer le service gr\u00e2ce \u00e0 elles. Cela a conduit \u00e0 une situation o\u00f9 nous avons d\u00fb passer du temps \u00e0 analyser et rassembler des donn\u00e9es dans l'espoir de trouver la cause profonde, au lieu de concentrer tous nos efforts sur la restauration des op\u00e9rations.<\/li>\n
  3. \u00c9valuez l'impact de chaque fonctionnalit\u00e9 du service.<\/b>. Les clients utilisaient rarement l'App Registry, ce qui ne le rendait pas prioritaire pour notre \u00e9quipe. Lorsque certaines fonctionnalit\u00e9s du produit sont \u00e0 peine utilis\u00e9es, leurs bogues refont surface rarement, et les d\u00e9veloppeurs cessent de surveiller le code. Il est facile de tomber dans l'illusion que tout va bien, jusqu'\u00e0 ce qu'une fonction se retrouve soudainement au centre d'un incident majeur.<\/li>\n<\/ol>\n

    <\/p>\n

    Et apr\u00e8s ?<\/h2>\n

    \nLe travail sur la stabilit\u00e9 du service ne s'arr\u00eate jamais et nous l'am\u00e9liorons constamment. Le volume de trafic sur quay.io continue de cro\u00eetre, et nous r\u00e9alisons que nous devons faire tout ce qui est en notre pouvoir pour m\u00e9riter la confiance de nos clients. C'est pourquoi nous travaillons actuellement sur les t\u00e2ches suivantes :<\/p>\n

      \n
    1. D\u00e9ploiement de r\u00e9pliques de bases de donn\u00e9es en lecture seule, pour aider le service \u00e0 g\u00e9rer le trafic correspondant en cas de probl\u00e8me avec l'instance principale de RDS.<\/li>\n
    2. Mise \u00e0 jour de l'instance de RDS. La version actuelle n'est pas, en soi, un probl\u00e8me. Plut\u00f4t, nous voulons simplement \u00e9liminer toute fausse piste (suivie lors de l'incident); maintenir le logiciel \u00e0 jour permettra d'\u00e9liminer un facteur suppl\u00e9mentaire en cas de futures pannes.<\/li>\n
    3. Mise en cache suppl\u00e9mentaire \u00e0 travers le cluster. Nous continuons \u00e0 rechercher des domaines o\u00f9 la mise en cache pourrait r\u00e9duire la charge sur la base de donn\u00e9es.<\/li>\n
    4. Ajout d'un pare-feu d'applications Web (WAF), afin de voir qui se connecte \u00e0 quay.io et pourquoi.<\/li>\n
    5. \u00c0 partir de la prochaine version, les clusters Red Hat OpenShift abandonneront l'App Registry au profit des catalogues d'op\u00e9rateurs, bas\u00e9s sur des images de conteneurs disponibles sur quay.io.<\/li>\n
    6. Une solution de remplacement \u00e0 long terme de l'App Registry pourrait \u00eatre la prise en charge des sp\u00e9cifications des artefacts de l'Open Container Initiative (OCI). Cela est actuellement mis en \u0153uvre sous forme de fonctionnalit\u00e9 native de Quay et sera disponible pour les utilisateurs lorsque la sp\u00e9cification elle-m\u00eame sera finalis\u00e9e.<\/li>\n<\/ol>\n

      \nTout ce qui pr\u00e9c\u00e8de fait partie des investissements continus de Red Hat dans quay.io alors que nous passons d'une petite \u00e9quipe \u00ab esprit start-up \u00bb \u00e0 une plateforme mature, g\u00e9r\u00e9e par des SRE. Nous savons que de nombreux clients comptent sur quay.io dans leur travail quotidien (y compris Red Hat !) et nous nous effor\u00e7ons d'\u00eatre aussi transparents que possible concernant les r\u00e9cents incidents et les efforts continus pour nous am\u00e9liorer.<\/p>\n

      P.S. de l'auteur<\/h2>\n

      \nLisez aussi dans notre blog :<\/p>\n