{"id":92806,"date":"2020-08-31T07:42:03","date_gmt":"2020-08-31T05:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita"},"modified":"2020-08-31T07:42:03","modified_gmt":"2020-08-31T05:42:03","slug":"kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"Como parar de se preocupar e come\u00e7ar a viver sem um mon\u00f3lito","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Como
\n
\nTodos n\u00f3s amamos hist\u00f3rias. Gostamos de nos reunir ao redor da fogueira para contar nossas vit\u00f3rias passadas, lutas ou simplesmente sobre nossas experi\u00eancias de trabalho.<\/p>\n

Hoje \u00e9 um dia exatamente assim. E mesmo que voc\u00ea n\u00e3o esteja ao redor de uma fogueira, temos uma hist\u00f3ria para voc\u00ea. Uma hist\u00f3ria sobre como come\u00e7amos a trabalhar com o armazenamento no Tarantool.<\/p>\n

Era uma vez, em nossa empresa, havia alguns 'mon\u00f3litos' e um 'teto' que todos compartilhavam, para o qual esses mon\u00f3litos se aproximavam lentamente, mas de forma constante, limitando o voo de nossa empresa, nosso desenvolvimento. E havia uma clara compreens\u00e3o: um dia, n\u00f3s ir\u00edamos bater nesse teto.
\n<\/a><\/noindex>
\nAgora, a ideologia de separa\u00e7\u00e3o de tudo e todos reina, desde a infraestrutura at\u00e9 a l\u00f3gica de neg\u00f3cios. Como resultado, por exemplo, temos dois DCs, praticamente independentes a n\u00edvel de rede. Mas, naquela \u00e9poca, tudo era bem diferente.<\/p>\n

Hoje em dia, existem muitas ferramentas e meios para fazer mudan\u00e7as, como CI\/CD, K8S, etc. Na era 'monol\u00edtica', n\u00e3o precis\u00e1vamos de tantas palavras estrangeiras. Bastava ajustar o 'armazenamento' no banco de dados.<\/p>\n

Mas o tempo avan\u00e7ou, e a quantidade de solicita\u00e7\u00f5es cresceu junto com ele, disparando RPS \u00e0s vezes acima das nossas possibilidades. Quando entramos no mercado da CEI, a carga no processador do DB do primeiro mon\u00f3lito n\u00e3o ca\u00eda abaixo de 90%, e o RPS se mantinha em torno de 2400. E n\u00e3o eram apenas pequenas sele\u00e7\u00f5es, mas grandes solicita\u00e7\u00f5es com muitas verifica\u00e7\u00f5es e JOINs, que percorreram quase metade dos dados em meio a um alto IO.<\/p>\n

Quando vendas completas come\u00e7aram a aparecer na 'Black Friday' \u2014 e a Wildberries foi uma das primeiras a realiz\u00e1-las na R\u00fassia \u2014 a situa\u00e7\u00e3o se tornou bastante triste. Pois, a carga nesses dias aumenta tr\u00eas vezes.
\nAh, esses 'tempos monol\u00edticos'! Tenho certeza de que voc\u00ea tamb\u00e9m j\u00e1 passou por isso e ainda n\u00e3o consegue entender como isso poderia acontecer com voc\u00ea.<\/p>\n

O que se pode fazer - a moda tamb\u00e9m se aplica \u00e0s tecnologias. H\u00e1 cerca de 5 anos, tivemos que repensar uma dessas modas, que era um site em .NET e servidor MS SQL, que guardava com carinho toda a l\u00f3gica do site. Guardava de tal forma que desmembrar esse mon\u00f3lito se tornou um prazer longo e bastante complicado.
\nUma pequena digress\u00e3o. <\/p>\n

Em v\u00e1rios eventos, costumo dizer: \"se voc\u00ea n\u00e3o desmantelou o monolito, ent\u00e3o voc\u00ea n\u00e3o cresceu!\" Estou interessado na sua opini\u00e3o sobre isso, por favor, escreva-a nos coment\u00e1rios.<\/p>\n

E ent\u00e3o ouviu-se o trov\u00e3o<\/h3>\n

\nVoltando ao nosso \"fogo de ch\u00e3o\". Para distribuir a carga da funcionalidade monol\u00edtica, decidimos dividir o sistema em microsservi\u00e7os baseados em tecnologias de c\u00f3digo aberto. Porque, no m\u00ednimo, a escalabilidade deles \u00e9 mais barata. E sab\u00edamos, com 100% de certeza, que precisar\u00edamos escalar (e muito). Afinal, j\u00e1 naquele momento, conseguimos acessar os mercados dos pa\u00edses vizinhos, e tanto o n\u00famero de registros quanto o n\u00famero de pedidos come\u00e7ou a crescer ainda mais.<\/p>\n

Ao analisar os primeiros candidatos para a migra\u00e7\u00e3o do monolito para microsservi\u00e7os, percebemos que em 80% os dados eram inseridos neles em 99% a partir de sistemas de back office, enquanto a leitura vinha da linha de frente. Isso se aplicava principalmente a alguns subsistemas importantes para n\u00f3s \u2014 dados dos usu\u00e1rios e o sistema de c\u00e1lculo do custo final dos produtos com base em informa\u00e7\u00f5es sobre descontos e cupons adicionais dos clientes.<\/p>\n

\u00c0 guisa de uma observa\u00e7\u00e3o. Agora \u00e9 assustador imaginar, mas al\u00e9m dos subsistemas mencionados, tamb\u00e9m foram extra\u00eddos do nosso monolito cat\u00e1logos de produtos, carrinho de usu\u00e1rios, sistema de busca de produtos, sistema de filtragem de cat\u00e1logos de produtos e diversos sistemas recomendativos. Para operar cada um deles, existem classes separadas de sistemas especializados, mas antes todos eles coexistiam em uma \u00fanica \"casa\". <\/p>\n

Planejamos transferir os dados de nossos clientes para um sistema de sharding. A funcionalidade de c\u00e1lculo do custo final dos produtos exigia boa escalabilidade em leitura, uma vez que gerava a maior carga de RPS e era a mais complicada de implementar para o banco de dados (muitos dados est\u00e3o envolvidos no processo de c\u00e1lculos). <\/p>\n

Como resultado, desenvolvemos um esquema que se combina bem com Tarantool.<\/p>\n

Na \u00e9poca, para o funcionamento dos microsservi\u00e7os, foram escolhidos esquemas de opera\u00e7\u00e3o com v\u00e1rios Data Centers em m\u00e1quinas virtuais e f\u00edsicas. Como mostrado nas ilustra\u00e7\u00f5es, foram aplicadas op\u00e7\u00f5es de replica\u00e7\u00e3o do Tarantool tanto no modo master-master quanto master-slave. <\/p>\n

\"Como
\nArquitetura. Op\u00e7\u00e3o 1. Servi\u00e7o de usu\u00e1rios<\/i><\/p>\n

Atualmente, existem 24 shards, cada um com 2 inst\u00e2ncias (uma em cada Data Center), todas no modo master-master.<\/p>\n

Acima do banco de dados est\u00e3o os aplicativos que interagem com as r\u00e9plicas do banco de dados. Os aplicativos trabalham com Tarantool atrav\u00e9s da nossa biblioteca personalizada, que implementa a interface do driver Go para Tarantool. Ela v\u00ea todas as r\u00e9plicas e pode funcionar com o mestre para leitura e grava\u00e7\u00e3o. Na ess\u00eancia, ela implementa o modelo de conjunto de r\u00e9plicas, ao qual foram adicionadas a l\u00f3gica de sele\u00e7\u00e3o de r\u00e9plicas, tentativas de repeti\u00e7\u00e3o, circuito de interrup\u00e7\u00e3o e limite de taxa.<\/p>\n

Al\u00e9m disso, h\u00e1 a possibilidade de configurar a pol\u00edtica de sele\u00e7\u00e3o de r\u00e9plicas em rela\u00e7\u00e3o \u00e0 shard. Por exemplo, usando round-robin.<\/p>\n

\"Como
\nArquitetura. Op\u00e7\u00e3o 2. Servi\u00e7o de c\u00e1lculo do custo final do produto.<\/i><\/p>\n

H\u00e1 v\u00e1rios meses, a maior parte das solicita\u00e7\u00f5es para o c\u00e1lculo do custo final dos produtos foi transferida para um novo servi\u00e7o, que, em princ\u00edpio, funciona sem bancos de dados, mas h\u00e1 algum tempo atr\u00e1s 100% do processamento era realizado pelo servi\u00e7o com Tarantool em funcionamento.<\/p>\n

O banco de dados do servi\u00e7o consiste em 4 mestres, dos quais o sincronizador coleta dados, e cada um desses mestres distribui dados para r\u00e9plicas somente de leitura atrav\u00e9s da replica\u00e7\u00e3o. Cada mestre tem cerca de 15 dessas r\u00e9plicas.<\/p>\n

Em ambas as esquemas, na aus\u00eancia de um DC, o aplicativo pode obter dados do segundo.<\/p>\n

Vale ressaltar que em Tarantool a replica\u00e7\u00e3o \u00e9 bastante flex\u00edvel e pode ser configurada em tempo real. Em outros sistemas, j\u00e1 ocorreram dificuldades. Por exemplo, ao modificar os par\u00e2metros max_wal_senders e max_replication_slots no PostgreSQL, \u00e9 necess\u00e1rio reiniciar o mestre, o que em v\u00e1rios casos pode causar interrup\u00e7\u00e3o nas conex\u00f5es entre o aplicativo e o SGBD.<\/p>\n

Busque e voc\u00ea encontrar\u00e1!<\/h3>\n

\nPor que n\u00e3o fizemos \"como as pessoas normais\" e escolhemos uma abordagem at\u00edpica? Depende do que se considera normal. Muitos fazem um cluster com Mongo e o distribuem por tr\u00eas DCs geograficamente distribu\u00eddos.<\/p>\n

Naquela \u00e9poca, j\u00e1 est\u00e1vamos com dois projetos em Redis. O primeiro - cache, e o segundo era um armazenamento persistente para dados que n\u00e3o eram muito cr\u00edticos. Com este \u00faltimo, tivemos algumas dificuldades, em parte por nossa culpa. \u00c0s vezes, volumes consider\u00e1veis de dados estavam armazenados na chave, e de vez em quando o site enfrentava problemas. Utiliz\u00e1vamos esse sistema em uma configura\u00e7\u00e3o master-slave. E houve muitos casos em que algo acontecia com o mestre e a replica\u00e7\u00e3o falhava. <\/p>\n

Ou seja, o Redis \u00e9 bom para tarefas stateless, e n\u00e3o para stateful. Na verdade, ele permitia resolver a maioria dos problemas, mas apenas se fossem solu\u00e7\u00f5es de chave-valor com alguns \u00edndices. Por\u00e9m, o Redis tinha um desempenho bastante insatisfat\u00f3rio em termos de persist\u00eancia e replica\u00e7\u00e3o. Al\u00e9m disso, havia reclama\u00e7\u00f5es sobre a performance.<\/p>\n

Consideramos o MySQL e o PostgreSQL. Mas o primeiro n\u00e3o se firmou conosco, e o segundo por si s\u00f3 \u00e9 um produto bastante complexo, tornando invi\u00e1vel construir servi\u00e7os simples sobre ele.
\nTestamos RIAK, Cassandra, at\u00e9 mesmo um banco de dados gr\u00e1fico. Todas essas s\u00e3o solu\u00e7\u00f5es bastante nichadas, que n\u00e3o se encaixavam como uma ferramenta universal para a cria\u00e7\u00e3o de servi\u00e7os.<\/p>\n

No final, decidimos pelo Tarantool.<\/p>\n

Entramos em contato quando ele estava na vers\u00e3o 1.6. O que nos atraiu foi o simp\u00f3sio entre key-value e a funcionalidade de um banco de dados relacional. Possui \u00edndices secund\u00e1rios, transa\u00e7\u00f5es e spaces, que s\u00e3o como tabelas, por\u00e9m n\u00e3o simples, permitindo armazenar diversas colunas. Mas a killer feature do Tarantool eram os \u00edndices secund\u00e1rios combinados com key-value e transacionalidade.<\/p>\n

A comunidade de l\u00edngua russa, sempre pronta para ajudar no chat, tamb\u00e9m desempenhou um papel importante. Usamos isso ativamente e est\u00e1vamos sempre no chat. Al\u00e9m disso, a persist\u00eancia era decente, sem erros ou falhas evidentes. Se olharmos nossa hist\u00f3ria com o Tarantool, tivemos muitas dores e falhas com a replica\u00e7\u00e3o, mas nunca perdemos dados por causa dele!<\/p>\n

A implementa\u00e7\u00e3o come\u00e7ou de forma dif\u00edcil.<\/h3>\n

\nNaquela \u00e9poca, nosso principal stack de desenvolvimento era .NET, para o qual n\u00e3o havia conector para o Tarantool. Come\u00e7amos imediatamente a desenvolver em Go. Com Lua tamb\u00e9m foi razoavelmente bem. O principal problema naquele momento era a depura\u00e7\u00e3o: no .NET tudo era excelente, mas mergulhar no mundo do Lua embutido, onde voc\u00ea n\u00e3o tem outro debug al\u00e9m dos logs, era complicado. Al\u00e9m disso, a replica\u00e7\u00e3o, por algum motivo, periodicamente falhava, e precis\u00e1vamos entender a estrutura do motor Tarantool. O chat ajudava nisso, a documenta\u00e7\u00e3o em menor grau, e \u00e0s vezes consult\u00e1vamos o c\u00f3digo. Naquele momento, a documenta\u00e7\u00e3o era bem fraca.<\/p>\n

Assim, ao longo de v\u00e1rios meses, conseguimos aprender e obter resultados satisfat\u00f3rios no trabalho com Tarantool. Organizamos em git as pr\u00e1ticas padr\u00e3o que ajudavam na cria\u00e7\u00e3o de novos microsservi\u00e7os. Por exemplo, quando surgia a tarefa de criar um novo microsservi\u00e7o, o desenvolvedor consultava o c\u00f3digo-fonte da solu\u00e7\u00e3o padr\u00e3o no reposit\u00f3rio, e a cria\u00e7\u00e3o de algo novo n\u00e3o levava mais do que uma semana. <\/p>\n

Foi um tempo especial. Naquele per\u00edodo, era comum chegar at\u00e9 o administrador na mesa ao lado e pedir: \"Me d\u00ea uma virtual\". Em cerca de trinta minutos, a m\u00e1quina j\u00e1 estava com voc\u00ea. Voc\u00ea mesmo se conectava, instalava tudo, e eles direcionavam o tr\u00e1fego para ela.<\/p>\n

Hoje em dia isso j\u00e1 n\u00e3o \u00e9 mais poss\u00edvel: \u00e9 preciso implementar monitoramento no servi\u00e7o, registrar logs, cobrir a funcionalidade com testes, solicitar uma virtual ou providenciar algo no Kubernetes, etc. No geral, isso ser\u00e1 melhor, embora mais demorado e trabalhoso.<\/p>\n

Dividir para conquistar. Como est\u00e1 a situa\u00e7\u00e3o com Lua?<\/h3>\n

\nHouve um dilema s\u00e9rio: algumas equipes n\u00e3o conseguiam aplicar mudan\u00e7as de forma confi\u00e1vel em um servi\u00e7o com uma quantidade significativa de l\u00f3gica em Lua. Muitas vezes, isso resultava em falhas no servi\u00e7o. <\/p>\n

Ou seja, os desenvolvedores preparam alguma mudan\u00e7a. O Tarantool come\u00e7a a realizar a migra\u00e7\u00e3o, enquanto a r\u00e9plica ainda utiliza o c\u00f3digo antigo; algum DDL chega atrav\u00e9s da replica\u00e7\u00e3o, algo mais, e o c\u00f3digo simplesmente quebra porque isso n\u00e3o foi considerado. Como resultado, o procedimento de atualiza\u00e7\u00e3o para os administradores estava detalhado em uma folha A4: parar a replica\u00e7\u00e3o, atualizar isso, reiniciar a replica\u00e7\u00e3o, desligar aqui, atualizar ali. Um pesadelo! <\/p>\n

No final das contas, agora, frequentemente tentamos n\u00e3o fazer nada em Lua. Simplesmente usamos iproto (um protocolo bin\u00e1rio para interagir com o servidor), e tudo. Pode ser que faltem conhecimentos aos desenvolvedores, mas, sob essa perspectiva, o sistema \u00e9 complexo.<\/p>\n

N\u00e3o seguimos cegamente esse roteiro. Hoje n\u00e3o temos preto ou branco: ou tudo em Lua, ou tudo em Go. J\u00e1 entendemos como podemos combinar para evitar problemas com a migra\u00e7\u00e3o mais tarde.<\/p>\n

Onde o Tarantool est\u00e1 presente atualmente?
\nO Tarantool \u00e9 utilizado no servi\u00e7o de c\u00e1lculo do custo final dos produtos com desconto, conhecido como \"Promotaizer\". Como j\u00e1 mencionado anteriormente, ele est\u00e1 sendo substitu\u00eddo por um novo servi\u00e7o de cat\u00e1logo com pre\u00e7os pr\u00e9-calculados, mas h\u00e1 seis meses todos os c\u00e1lculos eram feitos no \"Promotaizer\". Antes, metade de sua l\u00f3gica foi escrita em Lua. H\u00e1 dois anos, o servi\u00e7o se tornou um reposit\u00f3rio, e a l\u00f3gica foi reescrita em Go, porque a mec\u00e2nica do funcionamento dos descontos mudou um pouco e o servi\u00e7o estava com falta de desempenho. <\/p>\n

Um dos servi\u00e7os mais cr\u00edticos \u00e9 o perfil de usu\u00e1rio. Ou seja, todos os usu\u00e1rios da Wildberries s\u00e3o armazenados no Tarantool, que conta com cerca de 50 milh\u00f5es de usu\u00e1rios. Sistema shardizado por ID de usu\u00e1rio, distribu\u00eddo por diversos DCs com integra\u00e7\u00e3o em servi\u00e7os Go.
\nNo RPS, o \"Promotaizer\" j\u00e1 foi l\u00edder, atingindo at\u00e9 6 mil solicita\u00e7\u00f5es. Em determinado momento, tivemos entre 50 e 60 inst\u00e2ncias. Atualmente, o l\u00edder em RPS s\u00e3o os perfis de usu\u00e1rios, com cerca de 12 mil. Este servi\u00e7o utiliza sharding personalizado com divis\u00e3o por intervalos de IDs de usu\u00e1rios. O servi\u00e7o atende mais de 20 m\u00e1quinas, mas isso \u00e9 excessivo; planejamos reduzir os recursos alocados, pois 4 a 5 m\u00e1quinas s\u00e3o suficientes.<\/p>\n

O servi\u00e7o de sess\u00f5es \u00e9 nosso primeiro servi\u00e7o no vshard e no Cartridge. A configura\u00e7\u00e3o do vshard e a atualiza\u00e7\u00e3o do Cartridge demandaram um certo esfor\u00e7o, mas, no final, tudo funcionou.<\/p>\n

O servi\u00e7o para exibir diferentes banners no site e no aplicativo m\u00f3vel foi um dos primeiros lan\u00e7ados no Tarantool. Este servi\u00e7o \u00e9 not\u00e1vel porque tem cerca de 6 a 7 anos, ainda est\u00e1 em opera\u00e7\u00e3o e nunca foi reiniciado. Foi aplicada replica\u00e7\u00e3o master-master. Nunca houve falhas.<\/p>\n

H\u00e1 um exemplo do uso do Tarantool para a funcionalidade de cat\u00e1logos r\u00e1pidos em sistemas de estoque, para verificar rapidamente as informa\u00e7\u00f5es em alguns casos. Tentamos usar o Redis para isso, mas os dados em mem\u00f3ria ocupavam mais espa\u00e7o do que no Tarantool.<\/p>\n

Os servi\u00e7os de lista de espera, assinaturas de clientes, tend\u00eancias atuais de stories e produtos adiados tamb\u00e9m operam com o Tarantool. O \u00faltimo servi\u00e7o ocupa cerca de 120 GB na mem\u00f3ria. \u00c9 o servi\u00e7o mais volumoso dentre os mencionados. <\/p>\n

Conclus\u00e3o<\/h3>\n

\nGra\u00e7as aos \u00edndices secund\u00e1rios, em combina\u00e7\u00e3o com key-value e a transacionalidade, Tarantool \u00e9 uma \u00f3tima op\u00e7\u00e3o para arquiteturas baseadas em microsservi\u00e7os. No entanto, encontramos dificuldades ao implementar mudan\u00e7as em servi\u00e7os com muita l\u00f3gica em Lua \u2014 os servi\u00e7os frequentemente paravam de funcionar. N\u00e3o conseguimos superar isso e, com o tempo, chegamos a diferentes combina\u00e7\u00f5es de Lua e Go: sabemos onde utilizar uma linguagem e onde utilizar a outra.<\/p>\n

O que mais ler sobre o assunto<\/b><\/p>\n