{"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\/es\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem sobre la indisponibilidad de Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota de traducci\u00f3n.<\/b>: a principios de agosto, Red Hat inform\u00f3 p\u00fablicamente sobre la soluci\u00f3n a los problemas de disponibilidad que hab\u00edan surgido en meses anteriores para los usuarios de su servicio. Quay.io<\/a><\/noindex> (con un registro para im\u00e1genes de contenedores heredado por la compa\u00f1\u00eda con la compra de CoreOS). Independientemente de su inter\u00e9s en este servicio como tal, es fascinante el camino que recorrieron los ingenieros de SRE de la compa\u00f1\u00eda para diagnosticar y resolver las causas de la interrupci\u00f3n.<\/i><\/p>\n

\"Post
\n
\nEl 19 de mayo, temprano en la ma\u00f1ana (hora del este de EE. UU. - EDT), el servicio quay.io se cay\u00f3. La interrupci\u00f3n afect\u00f3 tanto a los consumidores de quay.io como a los proyectos de c\u00f3digo abierto que utilizan quay.io como plataforma para construir y distribuir software. Red Hat valora la confianza de ambos.<\/p>\n

El equipo de ingenieros de SRE se puso a trabajar de inmediato para estabilizar el servicio de Quay lo m\u00e1s r\u00e1pido posible. Sin embargo, mientras se ocupaban de eso, los clientes se vieron impedidos de enviar nuevas im\u00e1genes, y solo ocasionalmente pod\u00edan recuperar las existentes. Por una raz\u00f3n desconocida, la base de datos de quay.io se bloque\u00f3 tras escalar el servicio a su plena capacidad.<\/a><\/noindex><\/p>\n

\u00ab\u00bfQu\u00e9 ha cambiado?<\/b>\u00bb \u2014 esta es la primera pregunta que se suele hacer en tales casos. Notamos que poco antes del problema, el cl\u00faster de OpenShift Dedicated (en el que se ejecuta quay.io) comenz\u00f3 a actualizarse a la versi\u00f3n 4.3.19. Dado que quay.io funciona en Red Hat OpenShift Dedicated (OSD), las actualizaciones regulares eran una operaci\u00f3n habitual y nunca hab\u00edan causado problemas. Adem\u00e1s, en los seis meses anteriores hab\u00edamos actualizado los cl\u00fasteres de Quay varias veces sin interrupciones en el servicio.<\/p>\n

Mientras intent\u00e1bamos restaurar el servicio, otros ingenieros comenzaron a preparar un nuevo cl\u00faster de OSD con la versi\u00f3n anterior del software, para desplegarlo en caso de ser necesario.<\/p>\n

An\u00e1lisis de causas ra\u00edz<\/h2>\n

\nEl principal s\u00edntoma de la falla fue una avalancha de decenas de miles de conexiones a la base de datos, lo que hizo que la instancia de MySQL resultara pr\u00e1cticamente inoperante. Esto dificult\u00f3 la diagnosis del problema. Establecimos un l\u00edmite en el n\u00famero m\u00e1ximo de conexiones de los clientes para ayudar al equipo de SRE a evaluar la situaci\u00f3n. No notamos tr\u00e1fico inusual hacia la base de datos: de hecho, la mayor\u00eda de las solicitudes eran de lectura, y solo unas pocas eran de escritura.<\/p>\n

Tambi\u00e9n intentamos identificar un patr\u00f3n en el tr\u00e1fico de la base de datos que pudiera haber causado esta avalancha. Sin embargo, no se encontraron patrones en los registros. Esperando la finalizaci\u00f3n del nuevo cl\u00faster con OSD 4.3.18, continuamos intentando iniciar los pods de quay.io. Cada vez que el cl\u00faster alcanzaba su plena capacidad, la base de datos se colgaba. Esto significaba que era necesario reiniciar la instancia de RDS adem\u00e1s de todos los pods de quay.io.<\/p>\n

Para la tarde, estabilizamos el servicio en modo solo lectura y desactivamos la mayor\u00eda de las funciones no esenciales (como la recolecci\u00f3n de basura en el espacio de nombres) para reducir la carga en la base de datos. Los bloqueos cesaron, pero la causa nunca fue encontrada<\/b>. El nuevo cl\u00faster OSD estaba listo, y trasladamos el servicio, conectamos el tr\u00e1fico y continuamos con la monitorizaci\u00f3n.<\/p>\n

Quay.io funcion\u00f3 de manera estable en el nuevo cl\u00faster OSD, as\u00ed que volvimos a los registros de la base de datos, pero no pudimos encontrar ninguna correlaci\u00f3n que explicara los bloqueos. Los ingenieros de OpenShift trabajaron junto a nosotros, tratando de entender si los cambios en Red Hat OpenShift 4.3.19 podr\u00edan haber causado problemas con Quay. Sin embargo, no se descubri\u00f3 nada, y no pudimos reproducir el problema en condiciones de laboratorio<\/b>.<\/p>\n

El segundo fallo<\/h2>\n

\nel 28 de mayo, poco antes del mediod\u00eda EDT, quay.io volvi\u00f3 a caer con el mismo s\u00edntoma: el funcionamiento de la base de datos se bloqueaba. Y nuevamente volcamos todos nuestros esfuerzos en la investigaci\u00f3n. Primero, era necesario restaurar el funcionamiento del servicio. Sin embargo, esta vez, reiniciar el RDS y reiniciar los pods de quay.io no sirvi\u00f3 de nada.<\/b>: otra avalancha de conexiones inund\u00f3 la base de datos. \u00bfPero por qu\u00e9?<\/p>\n

Quay est\u00e1 escrito en Python, y cada pod opera como un \u00fanico contenedor monol\u00edtico. En el entorno de ejecuci\u00f3n del contenedor, se ejecutan muchas tareas en paralelo. Usamos la biblioteca gevent<\/code> la competencia de gunicorn<\/code> para procesar solicitudes web. Cuando llega una solicitud a Quay (a trav\u00e9s de nuestra propia API o a trav\u00e9s de la API de Docker), se le asigna un worker de gevent. Normalmente, este worker deber\u00eda conectarse a la base de datos. Despu\u00e9s del primer fallo, descubrimos que los workers de gevent se conectaban a la base de datos utilizando la configuraci\u00f3n predeterminada.<\/p>\n

Dado el considerable n\u00famero de pods de Quay y miles de solicitudes por segundo, un gran n\u00famero de conexiones a la base de datos te\u00f3ricamente podr\u00eda sobrecargar la instancia de MySQL. Gracias a la monitorizaci\u00f3n, se sab\u00eda que Quay procesaba un promedio de 5,000 solicitudes por segundo. Aproximadamente el mismo n\u00famero de conexiones a la base de datos. 5,000 conexiones se acomodaban dentro de las capacidades de nuestra instancia de RDS (lo que no se puede decir de decenas de miles). Por alguna raz\u00f3n, hubo picos inesperados en el n\u00famero de conexiones.<\/b>, sin embargo, no notamos ninguna correlaci\u00f3n con las solicitudes entrantes.<\/p>\n

Esta vez decidimos firmemente encontrar y eliminar la fuente del problema, en lugar de limitarnos a reiniciar. En la base de c\u00f3digo de Quay se realizaron cambios que limitaban el n\u00famero de conexiones a la base de datos para cada worker.<\/b> gevent. Este n\u00famero se convirti\u00f3 en un par\u00e1metro de configuraci\u00f3n: era posible cambiarlo 'en caliente', sin necesidad de reconstruir una nueva imagen del contenedor. Para averiguar cu\u00e1ntas conexiones se pod\u00edan manejar realmente, se llevaron a cabo varias pruebas con el entorno de staging, en las que se establec\u00edan diferentes valores para ver c\u00f3mo esto afectar\u00eda a los escenarios de pruebas de carga. Al final, se descubri\u00f3 que Quay comienza a arrojar errores 502 cuando el n\u00famero de conexiones supera las 10,000.<\/b><\/p>\n

Inmediatamente desplegamos esta nueva versi\u00f3n en producci\u00f3n y comenzamos a monitorear el gr\u00e1fico de conexiones a la base de datos. En el pasado, la base se bloqueaba aproximadamente despu\u00e9s de 20 minutos. Tras 30 minutos sin problemas, comenzamos a tener esperanzas, y tras una hora, confianza. Recuperamos el tr\u00e1fico de escritura en el sitio y comenzamos el an\u00e1lisis postmortem.<\/p>\n

Logrando sortear el problema que causaba el bloqueo, no pudimos determinar sus verdaderas causas.<\/b>Se confirm\u00f3 que no estaba relacionada con ning\u00fan cambio en OpenShift 4.3.19, ya que lo mismo sucedi\u00f3 en la versi\u00f3n 4.3.18, que anteriormente funcionaba con Quay sin ning\u00fan problema.<\/p>\n

Algo m\u00e1s estaba claramente oculto en el cl\u00faster.<\/p>\n

Un examen detallado<\/h2>\n

\nQuay.io ha utilizado la configuraci\u00f3n predeterminada para conectarse a la base de datos sin problemas durante seis a\u00f1os. \u00bfQu\u00e9 ha cambiado? Es evidente que durante todo este tiempo, el tr\u00e1fico en quay.io ha ido en aumento constante. En nuestro caso, parec\u00eda que se hab\u00eda alcanzado un umbral que desencaden\u00f3 una avalancha de conexiones. Continuamos revisando los registros de la base de datos despu\u00e9s del segundo fallo, pero no encontramos patrones ni conexiones obvias.<\/p>\n

Mientras tanto, el equipo de SRE estaba trabajando en mejoras en la observabilidad de las solicitudes en Quay y en la salud general del servicio. Se desplegaron nuevas m\u00e9tricas y paneles de monitoreo<\/b>, que mostraban qu\u00e9 partes de Quay son m\u00e1s demandadas por los clientes.<\/p>\n

Quay.io funcion\u00f3 normalmente hasta el 9 de junio. En la ma\u00f1ana (hora EDT) fuimos testigos de un aumento significativo en el n\u00famero de conexiones a la base de datos. Esta vez no hubo tiempo de inactividad,<\/b>, ya que un nuevo par\u00e1metro limitaba su cantidad y no permit\u00eda exceder la capacidad de MySQL. Sin embargo, durante aproximadamente media hora, muchos usuarios experimentaron una lentitud en el funcionamiento de quay.io. R\u00e1pidamente recopilamos todos los datos posibles utilizando las herramientas de monitoreo a\u00f1adidas. De repente, apareci\u00f3 un patr\u00f3n.<\/p>\n

Justo antes del aumento en el n\u00famero de conexiones, un gran n\u00famero de solicitudes llegaron al API de App Registry<\/b>. App Registry es una funci\u00f3n poco conocida de quay.io. Permite almacenar cosas como charts de Helm y contenedores con metadatos ricos. La mayor\u00eda de los usuarios de quay.io no utilizan esta funci\u00f3n, pero Red Hat OpenShift la utiliza activamente. OperatorHub en OpenShift almacena todos los operadores en App Registry. Estos operadores forman la base del ecosistema de cargas de trabajo de OpenShift y del modelo operativo (dentro de las operaciones del \"segundo d\u00eda\", Day 2) orientado a partners.<\/p>\n

Cada cl\u00faster de OpenShift 4 utiliza operadores del OperatorHub integrado para publicar un cat\u00e1logo de operadores disponibles para instalaci\u00f3n y proporcionar actualizaciones para los ya instalados. Con el aumento de popularidad de OpenShift 4, tambi\u00e9n ha aumentado el n\u00famero de cl\u00fasteres en todo el mundo. Cada uno de estos cl\u00fasteres carga el contenido de los operadores para iniciar el OperatorHub integrado, utilizando App Registry dentro de quay.io como backend. En la b\u00fasqueda de la causa del problema, pasamos por alto que, con el crecimiento gradual de la popularidad de OpenShift, tambi\u00e9n aumentaba la carga sobre una de las funciones raramente usadas de quay.io.<\/b>.<\/p>\n

Realizamos un an\u00e1lisis del tr\u00e1fico de solicitudes del App Registry y revisamos el c\u00f3digo del registro. Inmediatamente salieron a la luz deficiencias que provocaron que las solicitudes a la base de datos se formaran de manera no \u00f3ptima. Con una carga ligera no causaban problemas, pero al incrementarse se convirtieron en fuente de inconvenientes. El App Registry ten\u00eda dos endpoints problem\u00e1ticos que no respond\u00edan bien ante el aumento de carga: el primero devolv\u00eda una lista de todos los paquetes en el repositorio, el segundo devolv\u00eda todos los blobs para un paquete.<\/p>\n

Eliminaci\u00f3n de las causas<\/h2>\n

\nDurante la siguiente semana nos dedicamos a optimizar el c\u00f3digo del propio App Registry y su entorno. Se reescribieron las consultas SQL ineficaces, se eliminaron llamadas innecesarias al comando tar<\/code> (se ejecutaba en cada extracci\u00f3n de blobs), se agreg\u00f3 almacenamiento en cach\u00e9 donde fue posible. Luego se realiz\u00f3 una extensa prueba de rendimiento y se compar\u00f3 la velocidad de App Registry antes y despu\u00e9s de los cambios.<\/p>\n

Las solicitudes de API que antes tomaban hasta medio minuto, ahora se ejecutaban en milisegundos.<\/b>. La pr\u00f3xima semana implementamos los cambios en producci\u00f3n, y desde entonces quay.io ha funcionado de manera estable. Durante este tiempo, se observaron varios picos repentinos de tr\u00e1fico en el endpoint de App Registry, pero las mejoras realizadas evitaron interrupciones en la base de datos.<\/p>\n

\u00bfQu\u00e9 hemos aprendido?<\/h2>\n

\nEs evidente que cualquier servicio busca evitar tiempos de inactividad. En nuestro caso, creemos que las recientes fallas ayudaron a que quay.io fuera mejor. De esto hemos aprendido algunas lecciones clave que queremos compartir:<\/p>\n

    \n
  1. Los datos sobre qui\u00e9n y c\u00f3mo usa su servicio nunca son superfluos.<\/b>Como Quay 'simplemente funcionaba', nunca tuvimos la necesidad de dedicar tiempo a optimizar el tr\u00e1fico y gestionar la carga. Todo esto cre\u00f3 una falsa sensaci\u00f3n de seguridad de que el servicio podr\u00eda escalar indefinidamente.<\/li>\n
  2. Cuando el servicio falla, la recuperaci\u00f3n de su funcionamiento es la principal prioridad.<\/b>. Debido a que Quay continu\u00f3 sufriendo de una base de datos bloqueada durante la primera interrupci\u00f3n, nuestros procedimientos est\u00e1ndar no tuvieron el efecto esperado y no pudimos restaurar el servicio con su ayuda. Esto llev\u00f3 a una situaci\u00f3n en la que se necesit\u00f3 tiempo para analizar y recopilar datos con la esperanza de encontrar la causa principal, en lugar de dirigir todos los esfuerzos a la recuperaci\u00f3n de la operatividad.<\/li>\n
  3. Eval\u00fae el impacto de cada una de las funciones del servicio<\/b>. Los clientes rara vez utilizaban App Registry, por lo que no era una prioridad para nuestro equipo. Cuando algunas funciones del producto se utilizan muy poco, los errores de estas aparecen raramente y los desarrolladores dejan de supervisar el c\u00f3digo. Es f\u00e1cil caer en el error de pensar que as\u00ed debe ser, hasta que de repente esta funci\u00f3n se encuentra en el centro de un incidente a gran escala.<\/li>\n<\/ol>\n

    <\/p>\n

    \u00bfQu\u00e9 sigue?<\/h2>\n

    \nEl trabajo para garantizar la estabilidad del servicio nunca se detiene y estamos mejor\u00e1ndolo continuamente. Los vol\u00famenes de tr\u00e1fico en quay.io siguen creciendo y somos conscientes de que debemos hacer todo lo posible para cumplir con la confianza de nuestros clientes. Por lo tanto, actualmente estamos trabajando en las siguientes tareas:<\/p>\n

      \n
    1. Despliegue de r\u00e9plicas de bases de datos solo de lectura para ayudar al servicio a manejar el tr\u00e1fico correspondiente en caso de problemas con la instancia principal de RDS.<\/li>\n
    2. Actualizaci\u00f3n de la instancia de RDS. La versi\u00f3n actual por s\u00ed misma no es un problema. M\u00e1s bien, solo queremos eliminar una pista falsa (que seguimos durante la interrupci\u00f3n); mantener el software actualizado ayudar\u00e1 a eliminar otro factor en caso de futuras desconexiones.<\/li>\n
    3. Caching adicional en todo el cl\u00faster. Seguimos buscando \u00e1reas donde el caching pueda reducir la carga en la base de datos.<\/li>\n
    4. Adici\u00f3n de un firewall de aplicaciones web (WAF) para ver qui\u00e9n y por qu\u00e9 se conecta a quay.io.<\/li>\n
    5. A partir de la pr\u00f3xima versi\u00f3n, los cl\u00fasteres de Red Hat OpenShift abandonar\u00e1n App Registry en favor de Cat\u00e1logos de Operadores (Operator Catalogs) basados en im\u00e1genes de contenedores disponibles en quay.io.<\/li>\n
    6. La sustituci\u00f3n a largo plazo de App Registry podr\u00eda ser el soporte para las especificaciones de artefactos de la Open Container Initiative (OCI). Actualmente se est\u00e1 implementando como funcionalidad nativa de Quay y estar\u00e1 disponible para los usuarios cuando se finalice la especificaci\u00f3n.<\/li>\n<\/ol>\n

      \nTodo lo anterior es parte de las continuas inversiones de Red Hat en quay.io a medida que hacemos la transici\u00f3n de un peque\u00f1o equipo \"de estilo startup\" a una plataforma madura, gestionada por SRE. Sabemos que muchos de nuestros clientes dependen de quay.io en su trabajo diario (\u00a1incluyendo a Red Hat!) y nos esforzamos por ser lo m\u00e1s transparentes posible acerca de las recientes interrupciones y los esfuerzos continuos para mejorar.<\/p>\n

      P.D. del traductor<\/h2>\n

      \nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n