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

Nota do tradutor.<\/b>: no in\u00edcio de agosto, a Red Hat anunciou publicamente a resolu\u00e7\u00e3o de problemas de disponibilidade que surgiram nos meses anteriores para os usu\u00e1rios do seu servi\u00e7o Quay.io<\/a><\/noindex> (a base \u00e9 um registro para imagens de cont\u00eaineres, que veio \u00e0 empresa junto com a compra da CoreOS). Independentemente do seu interesse neste servi\u00e7o, o caminho que os engenheiros SRE da empresa percorreram para diagnosticar e resolver as causas da falha \u00e9 instrutivo.<\/i><\/p>\n

\"Post
\n
\nNa manh\u00e3 de 19 de maio (hor\u00e1rio de ver\u00e3o do leste da Am\u00e9rica do Norte, EDT), o servi\u00e7o quay.io caiu. A falha afetou tanto os consumidores do quay.io quanto os projetos de c\u00f3digo aberto que utilizam o quay.io como plataforma para a constru\u00e7\u00e3o e distribui\u00e7\u00e3o de software. A Red Hat valoriza a confian\u00e7a de ambos.<\/p>\n

A equipe de engenheiros SRE imediatamente se mobilizou para estabilizar o servi\u00e7o Quay o mais r\u00e1pido poss\u00edvel. No entanto, enquanto trabalhavam nisso, os clientes ficaram impossibilitados de enviar novas imagens e s\u00f3 conseguiam baixar as existentes de forma espor\u00e1dica. Por motivos desconhecidos, o banco de dados do quay.io travava ap\u00f3s a escalabilidade do servi\u00e7o para a capacidade total.<\/a><\/noindex><\/p>\n

\u00abO que mudou?<\/b>\u00bb \u2014 esta \u00e9 a primeira pergunta que costuma ser feita em situa\u00e7\u00f5es como esta. Notamos que pouco antes do problema, o cluster OpenShift Dedicated (no qual o quay.io opera) come\u00e7ou a ser atualizado para a vers\u00e3o 4.3.19. Como o quay.io opera no Red Hat OpenShift Dedicated (OSD), as atualiza\u00e7\u00f5es regulares eram comuns e nunca causaram problemas. Al\u00e9m disso, nos seis meses anteriores, atualizamos os clusters Quay v\u00e1rias vezes sem qualquer interrup\u00e7\u00e3o no servi\u00e7o.<\/p>\n

Enquanto tent\u00e1vamos restaurar o funcionamento do servi\u00e7o, outros engenheiros come\u00e7aram a preparar um novo cluster OSD com a vers\u00e3o anterior do software, para que, se necess\u00e1rio, pud\u00e9ssemos implantar tudo nele.<\/p>\n

An\u00e1lise da causa raiz<\/h2>\n

\nO principal sintoma da falha foi uma avalanche de dezenas de milhares de conex\u00f5es ao banco de dados, que tornou a inst\u00e2ncia do MySQL praticamente inoperante. Isso dificultou o diagn\u00f3stico do problema. Estabelecemos um limite no n\u00famero m\u00e1ximo de conex\u00f5es dos clientes para ajudar a equipe SRE a avaliar a quest\u00e3o. Nenhum tr\u00e1fego incomum para o banco de dados foi notado: na verdade, a maioria das solicita\u00e7\u00f5es era de leitura, e apenas algumas eram de grava\u00e7\u00e3o.<\/p>\n

Tamb\u00e9m tentamos identificar um padr\u00e3o no tr\u00e1fego do banco de dados que poderia ter causado essa avalanche. No entanto, n\u00e3o conseguimos encontrar nenhuma regularidade nos logs. Enquanto esper\u00e1vamos pela finaliza\u00e7\u00e3o do novo cluster com OSD 4.3.18, continuamos tentando iniciar os pods quay.io. Sempre que o cluster operava a plena capacidade, o banco de dados travava. Isso significava que era necess\u00e1rio reiniciar a inst\u00e2ncia RDS, al\u00e9m de todos os pods quay.io.<\/p>\n

Na noite, estabilizamos o servi\u00e7o no modo somente leitura e desativamos o m\u00e1ximo de fun\u00e7\u00f5es n\u00e3o essenciais (como a coleta de lixo no namespace) para reduzir a carga no banco de dados. As interrup\u00e7\u00f5es cessaram, mas a causa n\u00e3o foi encontrada<\/b>. O novo cluster OSD estava pronto, migramos o servi\u00e7o, conectamos o tr\u00e1fego e continuamos a monitoramento.<\/p>\n

Quay.io funcionava de forma est\u00e1vel no novo cluster OSD, ent\u00e3o voltamos aos logs do banco de dados, mas n\u00e3o conseguimos encontrar uma correla\u00e7\u00e3o que explicasse os bloqueios. Os engenheiros do OpenShift trabalharam conosco, tentando entender se as mudan\u00e7as na Red Hat OpenShift 4.3.19 poderiam ter causado problemas com o Quay. No entanto, nada foi descoberto, e n\u00e3o conseguimos reproduzir o problema em condi\u00e7\u00f5es de laborat\u00f3rio<\/b>.<\/p>\n

A segunda falha<\/h2>\n

\n28 de maio, pouco antes do meio-dia EDT, quay.io caiu novamente com o mesmo sintoma: o funcionamento do banco de dados foi bloqueado. E mais uma vez, reunimos todos os recursos para investigar. Antes de tudo, precis\u00e1vamos restaurar o funcionamento do servi\u00e7o. No entanto, Desta vez, reiniciar o RDS e reiniciar os pods quay.io n\u00e3o levou a nada.<\/b>Quay \u00e9 escrito em Python e cada pod funciona como um \u00fanico cont\u00eainer monol\u00edtico. No ambiente de execu\u00e7\u00e3o do cont\u00eainer, v\u00e1rias tarefas paralelas s\u00e3o executadas ao mesmo tempo. Utilizamos a biblioteca<\/p>\n

gevent gunicorn<\/code> sob para processar as requisi\u00e7\u00f5es da web. Quando uma solicita\u00e7\u00e3o chega ao Quay (atrav\u00e9s de nossa pr\u00f3pria API, ou atrav\u00e9s da API do Docker), um trabalhador gevent \u00e9 atribu\u00eddo a ele. Normalmente, esse trabalhador deve se conectar ao banco de dados. Ap\u00f3s a primeira falha, descobrimos que os trabalhadores gevent estavam se conectando ao banco de dados, utilizando as configura\u00e7\u00f5es padr\u00e3o.<\/code> para processar as solicita\u00e7\u00f5es da web. Quando o Quay recebe uma solicita\u00e7\u00e3o (via nossa pr\u00f3pria API ou pela API do Docker), um worker gevent \u00e9 atribu\u00eddo a ela. Normalmente, esse worker deve se conectar ao banco de dados. Ap\u00f3s a primeira falha, descobrimos que os workers gevent estavam se conectando ao banco de dados usando as configura\u00e7\u00f5es padr\u00e3o.<\/p>\n

Dado o n\u00famero significativo de pods Quay e milhares de solicita\u00e7\u00f5es recebidas por segundo, um grande n\u00famero de conex\u00f5es ao banco de dados poderia teoricamente sobrecarregar a inst\u00e2ncia MySQL. Atrav\u00e9s do monitoramento, sab\u00edamos que o Quay processa em m\u00e9dia 5 mil solicita\u00e7\u00f5es por segundo. Aproximadamente o mesmo n\u00famero de conex\u00f5es ao banco de dados. 5 mil conex\u00f5es estavam dentro das capacidades da nossa inst\u00e2ncia RDS (o que n\u00e3o pode ser dito sobre dezenas de milhares). Por alguma raz\u00e3o, ocorreram picos inesperados no n\u00famero de conex\u00f5es<\/b>, no entanto, n\u00e3o notamos qualquer correla\u00e7\u00e3o com as solicita\u00e7\u00f5es de entrada.<\/p>\n

Desta vez, decidimos firmemente encontrar e eliminar a fonte do problema, em vez de nos contentar com uma reinicializa\u00e7\u00e3o. No c\u00f3digo do Quay foram feitas altera\u00e7\u00f5es para limitar o n\u00famero de conex\u00f5es ao banco de dados para cada worker.<\/b> gevent. Esse n\u00famero se tornou um par\u00e2metro na configura\u00e7\u00e3o: agora era poss\u00edvel alter\u00e1-lo 'em tempo real', sem a necessidade de criar uma nova imagem de cont\u00eainer. Para descobrir quantas conex\u00f5es poderiam ser realmente processadas, foram realizados v\u00e1rios testes no ambiente de staging, variando os valores para observar como isso afetaria os cen\u00e1rios de teste de carga. No final, descobriu-se que o Quay come\u00e7a a retornar erros 502 quando o n\u00famero de conex\u00f5es excede 10 mil.<\/b><\/p>\n

Imediatamente implementamos essa nova vers\u00e3o em produ\u00e7\u00e3o e come\u00e7amos a monitorar o gr\u00e1fico de conex\u00f5es ao banco de dados. No passado, o banco travava em cerca de 20 minutos. Ap\u00f3s 30 minutos sem problemas, come\u00e7amos a ter esperan\u00e7a, e ap\u00f3s uma hora, confian\u00e7a. Recuperamos o tr\u00e1fego de grava\u00e7\u00e3o no site e iniciamos a an\u00e1lise postmortem.<\/p>\n

Conseguimos contornar o problema que levava ao bloqueio, mas n\u00e3o identificamos suas verdadeiras causas<\/b>. Confirmou-se que n\u00e3o estava relacionada a quaisquer mudan\u00e7as na vers\u00e3o 4.3.19 do OpenShift, uma vez que o mesmo aconteceu na vers\u00e3o 4.3.18, que anteriormente funcionou com o Quay sem quaisquer problemas.<\/p>\n

Claramente havia algo mais oculto no cluster.<\/p>\n

Uma investiga\u00e7\u00e3o detalhada<\/h2>\n

\nO Quay.io usou por seis anos as configura\u00e7\u00f5es padr\u00e3o para se conectar ao banco de dados sem quaisquer problemas. O que mudou? \u00c9 claro que, durante todo esse tempo, o tr\u00e1fego no quay.io cresceu constantemente. No nosso caso, parecia que um certo limite havia sido atingido, servindo como um gatilho para uma avalanche de conex\u00f5es. Continuamos a analisar os logs do banco de dados ap\u00f3s a segunda falha, mas n\u00e3o encontramos padr\u00f5es ou rela\u00e7\u00f5es \u00f3bvias.<\/p>\n

Enquanto isso, a equipe de SRE estava fazendo melhorias na observabilidade das solicita\u00e7\u00f5es no Quay e na sa\u00fade geral do servi\u00e7o. Novas m\u00e9tricas e pain\u00e9is de monitoramento foram implementados<\/b>, mostrando quais partes do Quay est\u00e3o em maior demanda pelos clientes.<\/p>\n

O Quay.io funcionou normalmente at\u00e9 9 de junho. Na manh\u00e3 (hor\u00e1rio EDT), testemunhamos novamente um aumento significativo no n\u00famero de conex\u00f5es ao banco de dados. Desta vez, n\u00e3o ocorreu downtime<\/b>, uma vez que uma nova configura\u00e7\u00e3o limitava seu n\u00famero e impedia que superasse a capacidade do MySQL. No entanto, por cerca de meia hora, muitos usu\u00e1rios notaram um desempenho lento do quay.io. Coletamos rapidamente todos os dados poss\u00edveis, utilizando as ferramentas de monitoramento adicionadas. De repente, um padr\u00e3o se manifestou.<\/p>\n

Antes do aumento no n\u00famero de conex\u00f5es, um grande n\u00famero de solicita\u00e7\u00f5es foi feito \u00e0 API do App Registry<\/b>. O App Registry \u00e9 uma fun\u00e7\u00e3o pouco conhecida do quay.io. Ele permite armazenar itens como gr\u00e1ficos Helm e cont\u00eaineres com metadados ricos. A maioria dos usu\u00e1rios do quay.io n\u00e3o utiliza essa fun\u00e7\u00e3o, mas ela \u00e9 amplamente usada pelo Red Hat OpenShift. O OperatorHub no OpenShift armazena todos os operadores no App Registry. Esses operadores formam a base do ecossistema de cargas de trabalho do OpenShift e do modelo operacional (no contexto das opera\u00e7\u00f5es do \"segundo dia\", Day 2) voltado para parceiros.<\/p>\n

Cada cluster OpenShift 4 utiliza operadores do OperatorHub embutido para publicar um cat\u00e1logo de operadores dispon\u00edveis para instala\u00e7\u00e3o e fornecer atualiza\u00e7\u00f5es para os j\u00e1 instalados. Com o aumento da popularidade do OpenShift 4, o n\u00famero de clusters globalmente tamb\u00e9m cresceu. Cada um desses clusters carrega o conte\u00fado dos operadores para iniciar o OperatorHub embutido, usando o App Registry dentro do quay.io como backend. Na busca pela origem do problema, perdemos de vista o fato de que, com o crescimento gradual da popularidade do OpenShift, a carga sobre uma das fun\u00e7\u00f5es raramente utilizadas do quay.io tamb\u00e9m aumentava.<\/b>.<\/p>\n

Realizamos uma an\u00e1lise do tr\u00e1fego de solicita\u00e7\u00f5es do App Registry e analisamos o c\u00f3digo do registro. Imediatamente, defici\u00eancias foram identificadas, que faziam as solicita\u00e7\u00f5es ao banco de dados serem formadas de maneira n\u00e3o otimizada. Com baixa carga, elas n\u00e3o causavam problemas, mas com o aumento da carga, tornavam-se fonte de problemas. O App Registry tinha dois endpoints problem\u00e1ticos, que tinham uma m\u00e1 resposta ao aumento da carga: o primeiro retornava uma lista de todos os pacotes no reposit\u00f3rio, o segundo retornava todos os blobs para um pacote.<\/p>\n

Elimina\u00e7\u00e3o das causas<\/h2>\n

\nDurante toda a semana seguinte, nos dedicamos \u00e0 otimiza\u00e7\u00e3o do c\u00f3digo do App Registry e de seu ambiente. As consultas SQL claramente ineficazes foram reformuladas, chamadas desnecess\u00e1rias de comando foram eliminadas tar<\/code> (ela era acionada a cada extra\u00e7\u00e3o de blobs), o cache foi adicionado em todos os lugares poss\u00edveis. Em seguida, realizamos um teste de desempenho extensivo e comparamos a velocidade do App Registry antes e depois das altera\u00e7\u00f5es.<\/p>\n

As consultas da API, que antes levavam at\u00e9 meio minuto, agora eram executadas em milissegundos.<\/b>. Na pr\u00f3xima semana, implantamos as altera\u00e7\u00f5es em produ\u00e7\u00e3o, e desde ent\u00e3o o quay.io tem funcionado de forma est\u00e1vel. Durante esse tempo, observamos alguns picos repentinos de tr\u00e1fego no endpoint do App Registry, mas as melhorias realizadas evitaram interrup\u00e7\u00f5es no banco de dados.<\/p>\n

O que aprendemos?<\/h2>\n

\n\u00c9 claro que qualquer servi\u00e7o procura evitar interrup\u00e7\u00f5es. No nosso caso, acreditamos que as recentes falhas ajudaram a tornar o quay.io melhor. Aprendemos algumas li\u00e7\u00f5es importantes que gostar\u00edamos de compartilhar:<\/p>\n

    \n
  1. As informa\u00e7\u00f5es sobre quem e como utiliza seu servi\u00e7o nunca s\u00e3o desnecess\u00e1rias.<\/b>Como o Quay \"simplesmente funcionava\", nunca sentimos a necessidade de gastar tempo otimizando o tr\u00e1fego e gerenciando a carga. Tudo isso criou uma falsa sensa\u00e7\u00e3o de seguran\u00e7a de que o servi\u00e7o poderia escalar indefinidamente.<\/li>\n
  2. Quando o servi\u00e7o falha, restaurar seu funcionamento \u00e9 a principal prioridade.<\/b>Como o Quay continuou a sofrer com um banco de dados bloqueado durante a primeira falha, nossos procedimentos padr\u00e3o n\u00e3o tiveram o efeito esperado e n\u00e3o conseguimos restaurar o servi\u00e7o com a ajuda deles. Isso levou a uma situa\u00e7\u00e3o em que tivemos que gastar tempo analisando e coletando dados na esperan\u00e7a de encontrar a causa raiz \u2014 em vez de direcionar todos os esfor\u00e7os para a restaura\u00e7\u00e3o do funcionamento.<\/li>\n
  3. Avalie o impacto de cada uma das fun\u00e7\u00f5es do servi\u00e7o.<\/b>Os clientes raramente utilizavam o App Registry, portanto, ele n\u00e3o era uma prioridade para nossa equipe. Quando algumas fun\u00e7\u00f5es do produto s\u00e3o quase n\u00e3o utilizadas, seus bugs aparecem raramente e os desenvolvedores param de acompanhar o c\u00f3digo. \u00c9 f\u00e1cil ser v\u00edtima da ilus\u00e3o de que deve ser assim \u2014 at\u00e9 que repentinamente essa fun\u00e7\u00e3o se torne o centro de um grande incidente.<\/li>\n<\/ol>\n

    <\/p>\n

    E agora?<\/h2>\n

    \nO trabalho para garantir a estabilidade do servi\u00e7o nunca para e estamos constantemente melhorando-o. Os volumes de tr\u00e1fego em quay.io continuam a crescer, e estamos cientes de que devemos fazer todo o poss\u00edvel para justificar a confian\u00e7a dos clientes. Portanto, atualmente estamos trabalhando nas seguintes tarefas:<\/p>\n

      \n
    1. Implanta\u00e7\u00e3o de r\u00e9plicas de banco de dados apenas para leitura, para ajudar o servi\u00e7o a lidar com o tr\u00e1fego correspondente em caso de problemas com a inst\u00e2ncia prim\u00e1ria do RDS.<\/li>\n
    2. Atualiza\u00e7\u00e3o da inst\u00e2ncia do RDS. A vers\u00e3o atual por si s\u00f3 n\u00e3o \u00e9 um problema. Em vez disso, queremos remover um falso diagn\u00f3stico (que seguimos durante a falha); manter o software atualizado eliminar\u00e1 mais um fator em caso de futuras interrup\u00e7\u00f5es.<\/li>\n
    3. Cache adicional em todo o cluster. Continuamos a buscar \u00e1reas onde o cache pode ajudar a reduzir a carga no banco de dados.<\/li>\n
    4. Adi\u00e7\u00e3o de um firewall de aplicativos da web (WAF), para ver quem est\u00e1 se conectando ao quay.io e por qu\u00ea.<\/li>\n
    5. A partir da pr\u00f3xima vers\u00e3o, os clusters do Red Hat OpenShift abandonar\u00e3o o App Registry em favor de cat\u00e1logos de operadores (Operator Catalogs), baseados em imagens de cont\u00eaineres dispon\u00edveis em quay.io.<\/li>\n
    6. Uma substitui\u00e7\u00e3o a longo prazo para o App Registry pode ser o suporte \u00e0s especifica\u00e7\u00f5es de artefatos da Open Container Initiative (OCI). No momento, isso est\u00e1 sendo implementado como uma funcionalidade nativa do Quay e estar\u00e1 dispon\u00edvel para os usu\u00e1rios assim que a especifica\u00e7\u00e3o for finalizada.<\/li>\n<\/ol>\n

      \nTudo o que foi mencionado acima faz parte dos cont\u00ednuos investimentos da Red Hat na quay.io \u00e0 medida que fazemos a transi\u00e7\u00e3o de uma pequena equipe \"no esp\u00edrito de uma startup\" para uma plataforma madura, gerida por SRE. Sabemos que muitos de nossos clientes contam com a quay.io em seu dia a dia (incluindo a Red Hat!) e nos esfor\u00e7amos para sermos o mais transparentes poss\u00edvel sobre as falhas recentes e os esfor\u00e7os cont\u00ednuos para melhorar.<\/p>\n

      P.S. do tradutor<\/h2>\n

      \nConfira tamb\u00e9m em nosso blog:<\/p>\n