{"id":55467,"date":"2020-01-21T00:00:00","date_gmt":"2020-01-20T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya"},"modified":"2020-02-18T14:03:35","modified_gmt":"2020-02-18T11:03:35","slug":"postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Ter\u00e7a-feira do Postgres n\u00ba 5: \"PostgreSQL e Kubernetes. CI\/CD. Automatiza\u00e7\u00e3o de testes\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ter\u00e7a-feira
\n
\nNo final do ano passado, ocorreu uma nova transmiss\u00e3o ao vivo da comunidade russa de PostgreSQL #RuPostgres<\/a><\/noindex>, na qual seu cofundador Nikolai Samokhvalov conversou com o diretor t\u00e9cnico da 'Flanta', Dmitry Stolyarov, sobre este SGBD no contexto do Kubernetes.<\/p>\n

Publicamos a transcri\u00e7\u00e3o da parte principal desta discuss\u00e3o, e no canal do YouTube da comunidade<\/a><\/noindex> est\u00e1 dispon\u00edvel a grava\u00e7\u00e3o completa:<\/a><\/noindex><\/p>\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Bancos de dados e Kubernetes<\/h2>\n

\nNS<\/b>: Hoje n\u00e3o vamos falar sobre VACUUM e CHECKPOINTs. Queremos discutir sobre Kubernetes. Sei que voc\u00ea j\u00e1 tem muitos anos de experi\u00eancia. Assisti seus v\u00eddeos e at\u00e9 revi alguns trechos\u2026 Vamos direto ao ponto: por que ter Postgres ou MySQL no K8s?<\/i><\/p>\n

DS<\/b>: N\u00e3o h\u00e1 uma resposta definitiva para essa pergunta, nem poderia haver. Mas, basicamente, \u00e9 a simplicidade e conveni\u00eancia\u2026 potenciais. Todos querem servi\u00e7os gerenciados.<\/p>\n

NS<\/b>: Para como RDS<\/a><\/noindex>, apenas que seja feito internamente?<\/i><\/p>\n

DS<\/b>: Sim: para ser como o RDS, s\u00f3 que em qualquer lugar.<\/p>\n

NS<\/b>: 'Em qualquer lugar' \u2014 isso \u00e9 um bom ponto. Em grandes empresas, tudo est\u00e1 em lugares diferentes. Mas por que, ent\u00e3o, se \u00e9 uma grande empresa, n\u00e3o optar por uma solu\u00e7\u00e3o pronta? Por exemplo, a Nutanix tem suas pr\u00f3prias solu\u00e7\u00f5es, e outras empresas (VMware\u2026) t\u00eam o mesmo 'RDS, s\u00f3 que internamente'.<\/i><\/p>\n

DS<\/b>: Mas aqui estamos falando de uma implementa\u00e7\u00e3o espec\u00edfica que funcionar\u00e1 apenas em certas condi\u00e7\u00f5es. E quando se trata de Kubernetes, h\u00e1 uma enorme diversidade de infraestrutura (que pode estar no K8s). Essencialmente, \u00e9 um padr\u00e3o para APIs na nuvem\u2026<\/p>\n

NS<\/b>: E ainda por cima \u00e9 gratuito!<\/i><\/p>\n

DS<\/b>: Isso n\u00e3o \u00e9 t\u00e3o importante. A gratuidade \u00e9 relevante para um segmento pequeno do mercado. O que realmente importa \u00e9 outra coisa\u2026 Voc\u00ea provavelmente deve se lembrar da apresenta\u00e7\u00e3o 'Bancos de dados e Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

NS<\/b>: Sim.<\/i><\/p>\n

DS<\/b>: Entendi que a recep\u00e7\u00e3o foi bem amb\u00edgua. Algumas pessoas acharam que eu estava dizendo: 'Vamos levar todos os bancos de dados para o Kubernetes!', enquanto outros acreditaram que eram bikes horr\u00edveis. Mas eu queria falar sobre outra coisa: 'Olhem o que est\u00e1 acontecendo, quais s\u00e3o os problemas e como podemos resolv\u00ea-los. \u00c9 vi\u00e1vel levar bancos de dados para Kubernetes? Para produ\u00e7\u00e3o? Bem, s\u00f3 se voc\u00ea gosta de\u2026 se envolver em certas coisas. Agora, para desenvolvimento \u2014 posso dizer que eu recomendo. Para desenvolvimento, a din\u00e2mica de criar\/remover ambientes \u00e9 muito importante.'<\/p>\n

NS: Quando voc\u00ea fala em dev, est\u00e1 se referindo a todos os ambientes que n\u00e3o s\u00e3o prod? Staging, QA\u2026<\/i><\/p>\n

DS<\/b>: Se estamos falando sobre perf-stands, provavelmente n\u00e3o, porque os requisitos s\u00e3o espec\u00edficos. Se estamos falando sobre casos especiais, onde um grande banco de dados \u00e9 necess\u00e1rio no staging, ent\u00e3o tamb\u00e9m, provavelmente n\u00e3o... Se for um ambiente est\u00e1tico e de longa dura\u00e7\u00e3o, qual \u00e9 a vantagem de ter o banco de dados no K8s?<\/p>\n

NS<\/b>: Nenhuma. Mas onde vemos ambientes est\u00e1ticos? Um ambiente est\u00e1tico est\u00e1 obsoleto j\u00e1 amanh\u00e3.<\/i><\/p>\n

DS<\/b>: Staging pode ser est\u00e1tico. Temos clientes...<\/p>\n

NS<\/b>: Sim, eu tamb\u00e9m tenho. \u00c9 um grande problema se voc\u00ea tem um banco de dados de 10 TB e o staging \u00e9 de 200 GB...<\/i><\/p>\n

DS<\/b>: Tenho um caso muito interessante! No staging, h\u00e1 um banco de produ\u00e7\u00e3o que est\u00e1 sendo modificado. E h\u00e1 um bot\u00e3o: 'mandar para produ\u00e7\u00e3o'. Essas mudan\u00e7as \u2014 as deltas \u2014 s\u00e3o integradas (aparentemente, simplesmente sincronizadas por API) na produ\u00e7\u00e3o. Essa \u00e9 uma op\u00e7\u00e3o bastante ex\u00f3tica.<\/p>\n

NS<\/b>: Vi startups no Vale que ainda est\u00e3o no RDS ou at\u00e9 mesmo no Heroku \u2014 essas s\u00e3o hist\u00f3rias de 2-3 anos atr\u00e1s \u2014 e eles baixam o dump para o laptop. Porque o banco ainda \u00e9 apenas 80 GB, e h\u00e1 espa\u00e7o no laptop. Depois, eles compram discos para cada um, para ter 3 bancos e desenvolver diferentes projetos. Isso acontece tamb\u00e9m. Tamb\u00e9m vi que n\u00e3o t\u00eam medo de copiar prod para staging \u2014 depende muito da empresa. Mas tamb\u00e9m vi que t\u00eam muito medo, e frequentemente falta tempo e pessoal. Mas antes de falarmos sobre esse t\u00f3pico, gostaria de ouvir sobre Kubernetes. Estou correto em entender que atualmente n\u00e3o tem em prod?<\/i><\/p>\n

DS<\/b>: Temos alguns bancos pequenos em prod. Falo sobre volumes de dezenas de gigabytes e servi\u00e7os n\u00e3o cr\u00edticos, para os quais n\u00e3o vale a pena fazer r\u00e9plicas (e n\u00e3o h\u00e1 necessidade). E desde que haja um armazenamento adequado em Kubernetes. Esse banco funcionava em uma m\u00e1quina virtual \u2014 digamos, na VMware, sobre um armazenamento SAN. N\u00f3s o colocamos em PV<\/a><\/noindex> e agora podemos transferi-lo de m\u00e1quina para m\u00e1quina.<\/p>\n

NS<\/b>: Bancos de dados desse tamanho, at\u00e9 100 GB, em bons discos e em uma boa rede, podem ser instalados em poucos minutos, certo? Uma velocidade de 1 GB por segundo \u2014 isso j\u00e1 n\u00e3o \u00e9 ex\u00f3tico.<\/i><\/p>\n

DS<\/b>: Sim, para uma opera\u00e7\u00e3o linear n\u00e3o \u00e9 um problema.<\/p>\n

NS<\/b>: Ok, sobre prod devemos apenas pensar. E se considerarmos Kubernetes para ambientes n\u00e3o-prod \u2014 como fazer? Vejo que na Zalando est\u00e3o desenvolvendo um operador<\/a><\/noindex>, no Crunchy est\u00e3o criando<\/a><\/noindex>, h\u00e1 algumas outras op\u00e7\u00f5es. E temos OnGres<\/a><\/noindex> \u2014 \u00e9 o nosso bom amigo Alvaro da Espanha: eles fazem n\u00e3o apenas operador<\/a><\/noindex>, mas uma distribui\u00e7\u00e3o inteira (StackGres<\/a><\/noindex>), onde al\u00e9m do pr\u00f3prio Postgres, decidimos incluir backup, proxy Envoy\u2026<\/i><\/p>\n

DS<\/b>: Para que serve o Envoy? Para balanceamento de tr\u00e1fego do Postgres?<\/p>\n

NS<\/b>: Sim. Eles veem isso assim: se pegarmos uma distribui\u00e7\u00e3o Linux e o kernel, o PostgreSQL padr\u00e3o \u00e9 o kernel, e eles querem criar uma distribui\u00e7\u00e3o que seja amig\u00e1vel a nuvens e que opere no Kubernetes. Eles integram componentes (backups etc.) e ajustam para que funcionem bem.<\/i><\/p>\n

DS<\/b>: Muito legal! Basicamente, \u00e9 um software para criar seu pr\u00f3prio Postgres gerenciado.<\/p>\n

NS<\/b>: Distribui\u00e7\u00f5es Linux t\u00eam problemas cont\u00ednuos: como criar drivers para suportar todo o hardware. E a ideia deles \u00e9 que funcionem no Kubernetes. Sei que recentemente na Zalando vimos uma depend\u00eancia do AWS, e isso n\u00e3o \u00e9 muito bom. N\u00e3o deveria haver uma depend\u00eancia de infraestrutura espec\u00edfica \u2014 qual \u00e9 o sentido nisso?<\/i><\/p>\n

DS<\/b>: N\u00e3o sei em que situa\u00e7\u00e3o a Zalando se vinculou, mas atualmente no Kubernetes o storage \u00e9 feito de forma que n\u00e3o \u00e9 poss\u00edvel tirar um backup em disco de maneira gen\u00e9rica. Recentemente, na \u00faltima vers\u00e3o do padr\u00e3o \u2014 a especifica\u00e7\u00e3o CSI<\/a><\/noindex> \u2014 foi implementada a possibilidade de snapshots, mas onde isso foi realizado? Honestamente, ainda est\u00e1 muito cru... Tentamos a CSI sobre AWS, GCE, Azure, vSphere, mas assim que come\u00e7amos a usar, j\u00e1 d\u00e1 para ver que ainda n\u00e3o est\u00e1 pronto.<\/p>\n

NS<\/b>: Por isso, \u00e0s vezes \u00e9 necess\u00e1rio se vincular \u00e0 infraestrutura. Acho que isso ainda est\u00e1 numa fase inicial \u2014 problemas de crescimento. Pergunta: o que voc\u00ea aconselharia para iniciantes que querem experimentar PgSQL no K8s? Que operador, talvez?<\/i><\/p>\n

DS<\/b>: O problema \u00e9 que para n\u00f3s o Postgres representa apenas 3%. Temos uma lista muito extensa de diferentes softwares no Kubernetes, n\u00e3o vou listar tudo. Por exemplo, Elasticsearch. H\u00e1 muitos operadores: alguns est\u00e3o se desenvolvendo ativamente, outros n\u00e3o. Estabelecemos requisitos do que deve constar em um operador para que o consider\u00e1ssemos s\u00e9rio. O operador \u00e9 especificamente para Kubernetes \u2014 n\u00e3o no 'operador para fazer algo nas condi\u00e7\u00f5es da Amazon'... Na pr\u00e1tica, usamos um \u00fanico operador de forma bastante massiva (= quase todos os clientes), para Redis<\/a><\/noindex> (em breve publicaremos um artigo sobre ele)<\/i>.<\/p>\n

NS<\/b>: E para MySQL, tamb\u00e9m n\u00e3o existe? Sei que a Percona... como agora eles lidam tanto com MySQL, quanto com MongoDB e Postgres, deveriam lan\u00e7ar algo universal: para todos os bancos de dados, para todos os provedores de nuvem.<\/i><\/p>\n

DS<\/b>: N\u00e3o conseguimos olhar para os operadores do MySQL. Para n\u00f3s, isso n\u00e3o \u00e9 o foco principal no momento. MySQL funciona bem de forma aut\u00f4noma. Por que usar um operador se voc\u00ea pode simplesmente iniciar o banco de dados\u2026 Voc\u00ea pode iniciar um cont\u00eainer Docker com PostgreSQL ou pode simplesmente inici\u00e1-lo de maneira simples.<\/p>\n

NS<\/b>: Essa tamb\u00e9m foi uma pergunta. Sem operador nenhum?<\/i><\/p>\n

DS<\/b>: Sim, 100% do tempo temos PostgreSQL funcionando sem operador. Por enquanto, assim \u00e9. Estamos usando ativamente um operador para Prometheus e para Redis. Temos planos de encontrar um operador para Elasticsearch \u2014 isso \u00e9 o que mais \u201cpegamos\u201d porque queremos us\u00e1-lo 100% das vezes no Kubernetes. Assim como tamb\u00e9m queremos garantir que o MongoDB sempre seja instalado no Kubernetes. Aqui surgem certas necessidades \u2014 h\u00e1 uma sensa\u00e7\u00e3o de que nesses casos podemos fazer algo. Quanto ao Postgres, nem olhamos. Claro, sabemos da exist\u00eancia de v\u00e1rias op\u00e7\u00f5es, mas, de fato, temos uma implementa\u00e7\u00e3o aut\u00f4noma.<\/p>\n

Banco de dados para testes no Kubernetes<\/h2>\n

\nNS<\/b>: Vamos mudar para o tema de testes. Como fazer a implementa\u00e7\u00e3o de mudan\u00e7as no banco de dados \u2014 do ponto de vista da perspectiva DevOps. Temos microsservi\u00e7os, muitos bancos, e sempre h\u00e1 algo mudando. Como assegurar um CI\/CD adequado para que do ponto de vista do SGBD tudo esteja em ordem. Qual \u00e9 a sua abordagem?<\/i><\/p>\n

DS<\/b>: N\u00e3o pode haver uma \u00fanica resposta. Existem v\u00e1rios par\u00e2metros. O primeiro \u00e9 o tamanho do banco que queremos implementar. Voc\u00ea mesmo mencionou que nas empresas a abordagem para ter uma c\u00f3pia do banco de produ\u00e7\u00e3o no ambiente de dev e staging varia.<\/p>\n

NS<\/b>: Sob a pol\u00edtica de GDPR, penso que est\u00e3o cada vez mais cautelosos... Posso te dizer que na Europa j\u00e1 come\u00e7aram a aplicar multas.<\/i><\/p>\n

DS<\/b>: Mas muitas vezes \u00e9 poss\u00edvel escrever um software que faz um dump do production e o ofusca. Assim, temos dados de produ\u00e7\u00e3o (snapshot, dump, c\u00f3pia bin\u00e1ria...), mas anonimizados. Em vez disso, podem existir scripts de gera\u00e7\u00e3o: podem ser fixtures ou apenas um script que gera uma base de dados grande. O problema \u00e9: quanto tempo leva para criar a imagem base? E quanto tempo leva para implant\u00e1-la no ambiente desejado?<\/p>\n

Chegamos a um esquema: se o cliente tiver um conjunto de dados de fixture (vers\u00e3o m\u00ednima do banco), usamos isso por padr\u00e3o. Quando se trata de ambientes de review, quando criamos um branch, temos uma inst\u00e2ncia do aplicativo criada \u2014 implantamos um banco pequeno l\u00e1. Mas ficou bem feito e uma variante<\/a><\/noindex>, quando fazemos um dump do production uma vez por dia (\u00e0 noite) e montamos um container Docker com PostgreSQL e MySQL com esses dados carregados. Se precisar implantar essa imagem 50 vezes, isso \u00e9 feito de forma bastante simples e r\u00e1pida.<\/p>\n

NS<\/b>: Simplesmente copiando?<\/i><\/p>\n

DS<\/b>: Os dados s\u00e3o armazenados diretamente na imagem Docker. Ou seja, temos uma imagem pronta, mesmo que de 100 GB. Gra\u00e7as \u00e0s camadas no Docker, podemos desdobrar essa imagem o n\u00famero necess\u00e1rio de vezes rapidamente. \u00c9 um m\u00e9todo simples, mas funciona bem.<\/p>\n

NS<\/b>: Depois, quando voc\u00ea testa, isso muda diretamente dentro do Docker, certo? Copy-on-write dentro do Docker \u2014 descartamos e recome\u00e7amos, tudo certo. \u00d3timo! E voc\u00ea j\u00e1 est\u00e1 utilizando isso plenamente?<\/i><\/p>\n

DS<\/b>: H\u00e1 bastante tempo.<\/p>\n

NS<\/b>: N\u00f3s lidamos com coisas muito semelhantes. Contudo, n\u00e3o usamos o copy-on-write do Docker, mas algum outro.<\/i><\/p>\n

DS<\/b>: Ele n\u00e3o \u00e9 gen\u00e9rico. Mas o do Docker funciona em toda parte.<\/p>\n

NS<\/b>: Em teoria, sim. Mas tamb\u00e9m temos m\u00f3dulos, podemos fazer diferentes m\u00f3dulos e trabalhar com diferentes sistemas de arquivos. Aqui est\u00e1 o ponto. N\u00f3s, do lado do Postgres, vemos tudo isso de maneira diferente. Agora olhei do lado do Docker e vi que tudo funciona para voc\u00eas. Mas se a base for gigantesca, por exemplo, 1 TB, ent\u00e3o isso j\u00e1 demora tudo: tanto as opera\u00e7\u00f5es noturnas quanto colocar tudo no Docker... E se forem 5 TB a serem colocados no Docker... Ou est\u00e1 tudo bem?<\/i><\/p>\n

DS<\/b>: Qual a diferen\u00e7a: s\u00e3o apenas blobs, apenas bits e bytes.<\/p>\n

NS<\/b>: A diferen\u00e7a \u00e9 a seguinte: voc\u00ea faz isso atrav\u00e9s de dump e restore?<\/i><\/p>\n

DS<\/b>: N\u00e3o necessariamente. As maneiras de gerar essa imagem podem ser diferentes.<\/p>\n

NS<\/b>: Para alguns clientes, fizemos com que, em vez de gerar regularmente a imagem base, a mantiv\u00e9ssemos constantemente atualizada. Na verdade, \u00e9 uma r\u00e9plica, mas os dados n\u00e3o s\u00e3o obtidos diretamente do mestre, e sim atrav\u00e9s de um arquivo. Um arquivo bin\u00e1rio, onde os WALs s\u00e3o aplicados todos os dias, e os backups tamb\u00e9m s\u00e3o feitos l\u00e1... Esses WALs depois s\u00e3o transferidos \u2014 com um pequeno atraso (literalmente 1-2 segundos) \u2014 para a imagem base. A partir da\u00ed, clonamos de qualquer maneira \u2014 atualmente, por padr\u00e3o, usamos ZFS.<\/i><\/p>\n

DS<\/b>: Mas com ZFS voc\u00ea est\u00e1 limitado a um n\u00f3.<\/p>\n

NS<\/b>: Sim. Mas o ZFS tem uma m\u00e1gica extra send<\/a><\/noindex>: com ela \u00e9 poss\u00edvel enviar um snapshot e at\u00e9 (eu ainda n\u00e3o testei muito isso, mas...) \u00e9 poss\u00edvel enviar a delta entre dois PGDATA<\/code>. Na verdade, temos mais uma ferramenta que n\u00e3o consideramos muito para essas tarefas. No PostgreSQL existe pg_rewind<\/a><\/noindex>, funcionando como um \u00abrsync inteligente\u00bb, ignorando muitas coisas que n\u00e3o precisam ser observadas, pois realmente n\u00e3o houve mudan\u00e7as. Podemos fazer uma r\u00e1pida sincroniza\u00e7\u00e3o entre dois servidores e voltar no tempo da mesma forma.<\/i><\/p>\n

Ent\u00e3o, tentamos, desse lado mais DBA, criar uma ferramenta que permita fazer o mesmo que voc\u00ea mencionou: temos um banco, mas queremos testar algo 50 vezes, quase ao mesmo tempo.<\/i><\/p>\n

DS<\/b>: 50 vezes significa que voc\u00ea precisa solicitar 50 inst\u00e2ncias Spot.<\/p>\n

NS<\/b>: N\u00e3o, fazemos tudo em uma m\u00e1quina.<\/i><\/p>\n

DS<\/b>: Mas como voc\u00ea vai implementar 50 vezes se esse \u00fanico banco, digamos, tem um terabyte? Provavelmente, ele precisa de, digamos, 256 GB de RAM?<\/p>\n

NS<\/b>: Sim, \u00e0s vezes precisa de muita mem\u00f3ria \u2014 isso \u00e9 normal. Mas aqui vai um exemplo da vida real. Em uma m\u00e1quina de produ\u00e7\u00e3o, temos 96 n\u00facleos e 600 GB. Para o banco de dados, usamos 32 n\u00facleos (at\u00e9 mesmo 16 n\u00facleos \u00e0s vezes) e de 100 a 120 GB de mem\u00f3ria.<\/i><\/p>\n

DS<\/b>: E cabe ali 50 c\u00f3pias?<\/p>\n

NS<\/b>: A c\u00f3pia \u00e9 uma s\u00f3, depois funciona o copy-on-write (com ZFS)... Vou explicar em detalhes.<\/i><\/p>\n

Por exemplo, temos um banco de dados de 10 TB. O disco foi feito, e o ZFS ainda comprimiu seu tamanho em 30-40%. Como n\u00e3o fazemos testes de carga, o tempo de resposta exato n\u00e3o \u00e9 importante para n\u00f3s: pode ser at\u00e9 2 vezes mais lento \u2014 tudo bem.<\/i><\/p>\n

N\u00f3s oferecemos aos programadores, QA, DBA, etc., a possibilidade de realizar testes em 1-2 fluxos. Por exemplo, eles podem iniciar alguma migra\u00e7\u00e3o. Ela n\u00e3o precisa de 10 n\u00facleos imediatamente \u2014 precisa apenas de 1 backend do Postgres, 1 n\u00facleo. A migra\u00e7\u00e3o ser\u00e1 iniciada \u2014 pode ser que autovacuum<\/a><\/noindex> outra migra\u00e7\u00e3o inicie, ent\u00e3o o segundo n\u00facleo ser\u00e1 usado. Temos entre 16 e 32 n\u00facleos dedicados, ent\u00e3o 10 pessoas podem trabalhar ao mesmo tempo, sem problemas.<\/i><\/p>\n

Como fisicamente PGDATA<\/code> \u00e9 id\u00eantica, acontece que estamos enganando o Postgres, na verdade. A quest\u00e3o \u00e9 a seguinte: iniciam-se, por exemplo, 10 Postgres simultaneamente. Qual \u00e9 o problema geralmente? Instalando shared_buffers<\/a><\/noindex>, digamos, em 25%. Portanto, seriam 200 GB. Voc\u00ea n\u00e3o consegue iniciar mais de tr\u00eas deles, pois a mem\u00f3ria acaba.<\/i><\/p>\n

Mas chegamos a um ponto em que percebemos que isso n\u00e3o era necess\u00e1rio: configuramos shared_buffers em 2 GB. O PostgreSQL possui effective_cache_size<\/a><\/noindex>, e na realidade s\u00f3 ele afeta os planos<\/a><\/noindex>. O que configuramos para 0,5 TB. E nem importa que na verdade n\u00e3o existam: ele cria planos como se existissem.<\/i><\/p>\n

Portanto, quando testamos alguma migra\u00e7\u00e3o, podemos reunir todos os planos \u2014 veremos como isso acontecer\u00e1 em produ\u00e7\u00e3o. Os segundos ser\u00e3o diferentes (mais lentos), mas os dados que realmente lemos e os planos (quais s\u00e3o os JOINs, etc.) ser\u00e3o exatamente os mesmos que em produ\u00e7\u00e3o. E, paralelamente, podemos executar muitos desses testes em uma m\u00e1quina.<\/i><\/p>\n

DS<\/b>: Voc\u00ea n\u00e3o acha que h\u00e1 alguns problemas aqui? O primeiro \u00e9 que essa solu\u00e7\u00e3o funciona apenas no PostgreSQL. Essa abordagem \u00e9 muito espec\u00edfica, n\u00e3o \u00e9 gen\u00e9rica. O segundo \u00e9 que o Kubernetes (e tudo o que est\u00e1 se movendo em dire\u00e7\u00e3o \u00e0s tecnologias de nuvem) pressup\u00f5e uma infinidade de n\u00f3s, e esses n\u00f3s s\u00e3o ef\u00eameros. No seu caso, \u00e9 um n\u00f3 stateful, persistente. Essas coisas me causam contradi\u00e7\u00f5es.<\/p>\n

NS<\/b>: Primeiro \u2014 concordo, isso \u00e9 uma hist\u00f3ria puramente do Postgres. Acho que se tivermos algum direct IO e um buffer de pool quase sob toda a mem\u00f3ria, esse m\u00e9todo n\u00e3o funcionar\u00e1 \u2014 os planos ser\u00e3o diferentes. Mas por enquanto, estamos trabalhando apenas com o Postgres, pensando em outros n\u00e3o.<\/i><\/p>\n

Sobre o Kubernetes. Voc\u00ea mesmo sempre diz que nossa base \u00e9 persistente. Se a inst\u00e2ncia cair, o principal \u00e9 manter o disco. Nossa plataforma tamb\u00e9m est\u00e1 toda em Kubernetes, e o componente com PostgreSQL \u2014 separado (embora um dia ele esteja l\u00e1 tamb\u00e9m). Portanto, \u00e9 assim: a inst\u00e2ncia caiu, mas n\u00f3s salvamos seu PV e simplesmente conectamos a outra (nova) inst\u00e2ncia, como se nada tivesse acontecido.<\/i><\/p>\n

DS<\/b>: Na minha vis\u00e3o, criamos pods no Kubernetes. O K8s \u00e9 el\u00e1stico: os n\u00f3s s\u00e3o solicitados conforme necess\u00e1rio. A tarefa \u00e9 simplesmente criar um pod e dizer que ele precisa de X recursos, e ent\u00e3o o K8s se encarrega do resto. Mas o suporte a armazenamentos no Kubernetes ainda \u00e9 inst\u00e1vel: no 1.16<\/a><\/noindex>, neste teste de 2015 1.17<\/a><\/noindex> (esse lan\u00e7amento saiu semanas<\/i> atr\u00e1s) essas funcionalidades est\u00e3o se tornando apenas beta.<\/p>\n

Ap\u00f3s meio ano a um ano, ele se tornar\u00e1 mais ou menos est\u00e1vel, ou pelo menos ser\u00e1 declarado como tal. Ent\u00e3o, a possibilidade de snapshots e redimensionamento resolver\u00e1 completamente sua tarefa. Porque voc\u00ea j\u00e1 tem uma base. Sim, ela pode n\u00e3o ser muito r\u00e1pida, mas a velocidade depende do que est\u00e1 'por tr\u00e1s', pois algumas implementa\u00e7\u00f5es conseguem copiar e realizar copy-on-write no n\u00edvel do subsistema de disco.<\/p>\n

NS<\/b>: Al\u00e9m disso, \u00e9 necess\u00e1rio que todos os motores (Amazon, Google\u2026) comecem a suportar essa vers\u00e3o \u2014 isso tamb\u00e9m leva algum tempo.<\/i><\/p>\n

DS<\/b>: Por enquanto, n\u00e3o os estamos usando. Estamos usando o nosso.<\/p>\n

Desenvolvimento local em Kubernetes<\/h2>\n

\nNS<\/b>: Voc\u00ea j\u00e1 teve esse desejo, quando precisa levantar todos os pods em uma \u00fanica m\u00e1quina e fazer um pequeno teste? Para rapidamente obter uma prova de conceito, ver se o aplicativo funciona no Kubernetes, sem precisar alocar v\u00e1rias m\u00e1quinas para isso. Existe o Minikube, certo?<\/i><\/p>\n

DS<\/b>: Eu acho que esse caso \u2014 a implanta\u00e7\u00e3o em um \u00fanico n\u00f3 \u2014 \u00e9 exclusivamente sobre desenvolvimento local. Ou algumas manifesta\u00e7\u00f5es desse padr\u00e3o. Existe Minikube<\/a><\/noindex>, existe k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. Estamos indo na dire\u00e7\u00e3o de usar Kubernetes IN Docker. Come\u00e7amos a trabalhar com isso para testes.<\/p>\n

NS<\/b>: Eu costumava pensar que isso era uma tentativa de empacotar todos os pods em uma \u00fanica imagem Docker. Mas descobri que isso era completamente diferente. Mesmo assim, existem cont\u00eaineres separados, pods separados \u2014 apenas no Docker.<\/i><\/p>\n

DS<\/b>: Sim. E l\u00e1 h\u00e1 uma simula\u00e7\u00e3o bem interessante, mas a ideia \u00e9 essa\u2026 Temos uma ferramenta para implanta\u00e7\u00e3o \u2014 werf<\/a><\/noindex>. Queremos adicionar um modo \u2014 digamos werf up<\/code>: \u201cLevante meu Kubernetes local\u201d. E ent\u00e3o inicie um werf follow<\/code>. Assim, o desenvolvedor pode editar no IDE, enquanto um processo em execu\u00e7\u00e3o no sistema v\u00ea as altera\u00e7\u00f5es e recompila as imagens, reaplica-as no K8s local. Assim, queremos tentar resolver o problema do desenvolvimento local.<\/p>\n

Snapshots e clonagem de DB na realidade do K8s<\/h2>\n

\nNS<\/b>: Voltando ao copy-on-write. Eu percebi que as nuvens tamb\u00e9m t\u00eam snapshots. Eles funcionam de maneira diferente. Por exemplo, no GCP: voc\u00ea tem uma inst\u00e2ncia de v\u00e1rios terabytes na costa leste dos EUA. Voc\u00ea faz snapshots periodicamente. Levanta uma c\u00f3pia do disco a partir do snapshot na costa oeste \u2014 em alguns minutos j\u00e1 est\u00e1 tudo pronto, funciona muito r\u00e1pido, apenas precisa preencher o cache na mem\u00f3ria. Mas esses clones (snapshots) s\u00e3o para provisionar um novo volume. Isso \u00e9 legal, quando voc\u00ea precisa criar muitas inst\u00e2ncias.<\/i><\/p>\n

Mas para testes, me parece que os snapshots que voc\u00ea menciona no Docker ou que eu menciono no ZFS, btrfs e at\u00e9 LVM\u2026 \u2014 eles permitem, na verdade, n\u00e3o criar dados novos em uma \u00fanica m\u00e1quina. Na nuvem, voc\u00ea ainda vai pagar por eles a cada vez e vai esperar n\u00e3o segundos, mas minutos (e no caso lazy load<\/a><\/noindex>, possivelmente, horas).<\/i><\/p>\n

Em vez disso, voc\u00ea pode obter esses dados em um ou dois segundos, rodar o teste e descart\u00e1-los. Esses snapshots resolvem diferentes tarefas. No primeiro caso \u2014 para escalar e obter novas r\u00e9plicas, e no segundo \u2014 para testes.<\/i><\/p>\n

DS<\/b>: N\u00e3o concordo. Fazer a clonagem de volumes de forma adequada \u00e9 uma tarefa da nuvem. N\u00e3o olhei para a implementa\u00e7\u00e3o deles, mas sei como fazemos isso no hardware. Temos Ceph, e nele podemos dizer a qualquer volume f\u00edsico (RBD<\/a><\/noindex>) e obter em quest\u00e3o de dezenas de milissegundos um segundo volume com as mesmas caracter\u00edsticas, clone<\/i> IOPS e assim por diante. \u00c9 preciso entender que l\u00e1 dentro tem um complicado copy-on-write. Por que a nuvem n\u00e3o faz da mesma forma? Estou certo de que eles est\u00e3o, de alguma forma, tentando fazer isso.<\/a><\/noindex>e outros. \u00c9 preciso entender que existe um astuto copy-on-write por tr\u00e1s. Por que a nuvem n\u00e3o faria o mesmo? Tenho certeza de que eles v\u00e3o tentar fazer isso de alguma forma.<\/p>\n

NS<\/b>: Por que \u00e9 necess\u00e1rio levantar uma inst\u00e2ncia inteira? Temos uma inst\u00e2ncia com 32 n\u00facleos, outra com 16... e cabe um certo n\u00famero de usu\u00e1rios \u2014 por exemplo, quatro. Quando pedimos o quinto, j\u00e1 se levanta uma nova inst\u00e2ncia que depois ser\u00e1 removida.<\/i><\/p>\n

DS<\/b>: Sim, interessante, no Kubernetes \u00e9 uma hist\u00f3ria diferente. Nossa base de dados n\u00e3o est\u00e1 no K8s, e \u00e9 uma inst\u00e2ncia \u00fanica. No entanto, para clonar uma base de dados multi-terabyte, n\u00e3o leva mais do que dois segundos.<\/p>\n

NS<\/b>: Isso \u00e9 incr\u00edvel. Mas meu argumento inicial \u00e9 que isso n\u00e3o \u00e9 uma solu\u00e7\u00e3o gen\u00e9rica. Sim, \u00e9 \u00f3timo, mas s\u00f3 funciona com Postgres e apenas em um \u00fanico n\u00f3.<\/i><\/p>\n

DS<\/b>: Ele n\u00e3o \u00e9 adequado apenas para Postgres: esses planos, como descrevi, funcionar\u00e3o apenas nele. Mas se n\u00e3o nos preocupamos com os planos, e precisamos apenas de todos os dados para testes funcionais, ent\u00e3o isso serve para qualquer SGBD.<\/p>\n

NS<\/b>: Muitos anos atr\u00e1s fizemos algo semelhante com snapshots LVM. \u00c9 o cl\u00e1ssico. Essa abordagem foi usada de forma bastante ativa. O problema s\u00e3o os n\u00f3s stateful \u2014 \u00e9 uma dor de cabe\u00e7a. Porque n\u00e3o podemos derrub\u00e1-los, devemos sempre lembrar deles...<\/i><\/p>\n

DS<\/b>: Voc\u00ea n\u00e3o v\u00ea aqui uma possibilidade de hibridiza\u00e7\u00e3o? Suponha que o stateful seja um pod, ele est\u00e1 funcionando para v\u00e1rias pessoas (muitos testadores). Temos um volume, mas gra\u00e7as ao sistema de arquivos, os clones s\u00e3o locais. Se o pod falhar, o disco permanece \u2014 o pod levantar\u00e1, coletar\u00e1 informa\u00e7\u00f5es sobre todos os clones, levantar\u00e1 tudo de volta e dir\u00e1: 'Aqui est\u00e3o seus clones nessas portas, continuem trabalhando com eles'.<\/p>\n

NS<\/b>: Tecnologicamente, isso significa que dentro do Kubernetes \u00e9 um \u00fanico pod, dentro do qual rodamos muitos Postgres.<\/i><\/p>\n

DS<\/b>: Tecnicamente, isso significa que dentro do Kubernetes \u00e9 um pod, dentro do qual executamos v\u00e1rios Postgres.<\/p>\n

NS<\/b>: N\u00e3o. Isso \u00e9 poss\u00edvel, mas requer um bom planejamento.<\/i><\/p>\n

DS<\/b>: \u00c9 necess\u00e1rio adicionar aqui quest\u00f5es de seguran\u00e7a. Esse tipo de organiza\u00e7\u00e3o implica que o pod tenha altos privil\u00e9gios (capabilities), pois ele pode realizar opera\u00e7\u00f5es n\u00e3o padronizadas no sistema de arquivos... Mas reitero: eu acredito que, a m\u00e9dio prazo, o Kubernetes ir\u00e1 corrigir o armazenamento, e as nuvens resolver\u00e3o toda a quest\u00e3o dos volumes \u2014 tudo ir\u00e1 \"funcionar simplesmente\". Haver\u00e1 redimensionamento, clonagem... Existe um volume \u2014 dizemos: \"Crie um novo com base naquele\", \u2014 e em um segundo e meio teremos o que precisamos.<\/p>\n

NS<\/b>: N\u00e3o acredito em um segundo e meio para muitos terabytes. No Ceph voc\u00ea faz isso manualmente, e est\u00e1 falando sobre nuvens. V\u00e1 para a nuvem, fa\u00e7a um clone do volume EBS de v\u00e1rios terabytes na EC2 e veja qual ser\u00e1 o desempenho. Isso n\u00e3o vai levar alguns segundos. Estou muito curioso para saber quando eles alcan\u00e7ar\u00e3o essa m\u00e9trica. Entendo o que voc\u00ea est\u00e1 dizendo, mas permito-me discordar.<\/i><\/p>\n

DS<\/b>: Ok, mas disse que a m\u00e9dio prazo, n\u00e3o a curto prazo. Dentro de alguns anos.<\/p>\n

Sobre o operador para PostgreSQL da Zalando<\/h2>\n

\nNo meio desta reuni\u00e3o, Aleksey Klyukin, um ex-desenvolvedor da Zalando, tamb\u00e9m se juntou a ela e contou a hist\u00f3ria do operador PostgreSQL:<\/p>\n

\u00c9 \u00f3timo que esse tema tenha sido abordado: tanto Postgres quanto Kubernetes. Quando come\u00e7amos a trabalhar nisso na Zalando em 2017, era um t\u00f3pico que todos queriam desenvolver, mas ningu\u00e9m estava fazendo. Todos j\u00e1 estavam adotando Kubernetes, mas quando pergunt\u00e1vamos como lidar com bancos de dados, at\u00e9 pessoas como Kelsey Hightower<\/a><\/noindex>, que pregavam K8s, diziam aproximadamente o seguinte:<\/p>\n

\"V\u00e1 para servi\u00e7os gerenciados e os utilize, n\u00e3o execute bancos de dados no Kubernetes. Caso contr\u00e1rio, seu K8s decidir\u00e1, por exemplo, fazer uma atualiza\u00e7\u00e3o, desligar\u00e1 todos os n\u00f3s, e seus dados desaparecer\u00e3o para muito longe\".<\/i><\/p>\n

Decidimos criar um operador que, ao contr\u00e1rio desse conselho, executaria bancos de dados Postgres no Kubernetes. E t\u00ednhamos uma boa justificativa \u2014 Patroni<\/a><\/noindex>. Este \u00e9 um failover autom\u00e1tico para PostgreSQL, feito corretamente, ou seja, utilizando etcd, consul ou ZooKeeper como reposit\u00f3rio de informa\u00e7\u00f5es sobre o cluster. Um reposit\u00f3rio que fornecer\u00e1 a todos, que perguntarem, por exemplo, quem \u00e9 o l\u00edder atual, a mesma informa\u00e7\u00e3o \u2014 apesar de estarmos tudo distribu\u00eddo, \u2014 para evitar um split brain. Al\u00e9m disso, tivemos imagem Docker<\/a><\/noindex> para ele.<\/p>\n

Na verdade, a necessidade de auto failover surgiu para a empresa ap\u00f3s a migra\u00e7\u00e3o de um data center interno para a nuvem. A nuvem era baseada em uma solu\u00e7\u00e3o pr\u00f3pria de PaaS (Platform-as-a-Service). Era open source, mas para configur\u00e1-la foi necess\u00e1rio um grande esfor\u00e7o. Chamava-se STUPS<\/a><\/noindex>.<\/p>\n

Inicialmente, n\u00e3o havia nenhum Kubernetes. Para ser mais preciso, quando a solu\u00e7\u00e3o pr\u00f3pria foi implantada, o K8s j\u00e1 existia, mas estava t\u00e3o imaturo que n\u00e3o era adequado para produ\u00e7\u00e3o. Isso foi, na minha opini\u00e3o, em 2015 ou 2016. At\u00e9 2017, o Kubernetes tornou-se razoavelmente maduro \u2014 surgiu a necessidade de migra\u00e7\u00e3o para l\u00e1.<\/p>\n

E j\u00e1 t\u00ednhamos um cont\u00eainer Docker. Havia PaaS que usava Docker. Por que n\u00e3o tentar o K8s? Por que n\u00e3o escrever nosso pr\u00f3prio operador? Murat Kabilov, que veio at\u00e9 n\u00f3s do Avito, come\u00e7ou isso como um projeto por iniciativa pr\u00f3pria \u2014 \"brincar\" \u2014 e o projeto \"decolou\".<\/p>\n

Mas, na verdade, eu queria falar sobre AWS. Por que historicamente houve c\u00f3digo relacionado \u00e0 AWS...<\/p>\n

Quando voc\u00ea inicia qualquer coisa no Kubernetes, \u00e9 preciso entender que o K8s \u00e9 um trabalho em progresso. Ele est\u00e1 sempre se desenvolvendo, melhorando e, periodicamente, at\u00e9 quebrando. \u00c9 necess\u00e1rio acompanhar cuidadosamente todas as mudan\u00e7as no Kubernetes e estar preparado, se necess\u00e1rio, para se aprofundar e descobrir como funciona em detalhes \u2014 talvez mais do que voc\u00ea gostaria. Isso \u00e9, na verdade, comum a qualquer plataforma na qual voc\u00ea est\u00e1 executando seus bancos de dados...<\/p>\n

Assim, quando fizemos o operador, t\u00ednhamos um Postgres que trabalhava com um volume externo (neste caso \u2014 EBS, j\u00e1 que est\u00e1vamos trabalhando na AWS). O banco de dados cresceu e, em algum momento, foi necess\u00e1rio fazer um resize: por exemplo, o tamanho original do EBS era de 100 TB, o banco cresceu para isso, agora queremos aumentar o EBS para 200 TB. Como? Suponha que voc\u00ea possa fazer um dump\/restaura\u00e7\u00e3o em uma nova inst\u00e2ncia, mas isso \u00e9 demorado e gera inatividade.<\/p>\n

Por isso, quer\u00edamos um redimensionamento que aumentasse a parti\u00e7\u00e3o EBS e, em seguida, dissesse ao sistema de arquivos para utilizar o novo espa\u00e7o. E fizemos isso, mas na \u00e9poca o Kubernetes n\u00e3o tinha nenhuma API para a opera\u00e7\u00e3o de redimensionamento. Como est\u00e1vamos trabalhando na AWS, escrevemos o c\u00f3digo para sua API.<\/p>\n

Nada impede de fazer o mesmo para outras plataformas. No operador, n\u00e3o h\u00e1 a limita\u00e7\u00e3o de que ele s\u00f3 pode ser executado na AWS; em outras plataformas, ele vai funcionar. Em geral, este \u00e9 um projeto Open Source: se algu\u00e9m quiser acelerar a disponibiliza\u00e7\u00e3o de uma nova API \u2014 fique \u00e0 vontade. H\u00e1 GitHub<\/a><\/noindex>, pull requests \u2014 a equipe da Zalando tenta respond\u00ea-las rapidamente e promover o operador. Pelo que sei, o projeto participou<\/a><\/noindex> do Google Summer of Code e de outras iniciativas semelhantes. A Zalando est\u00e1 trabalhando ativamente nele.\n<\/p><\/blockquote>\n

<\/p>\n

P.S. B\u00f4nus!<\/h2>\n

\nSe voc\u00ea est\u00e1 interessado no tema PostgreSQL e Kubernetes, tamb\u00e9m chamamos a aten\u00e7\u00e3o para o fato de que na semana passada ocorreu o seguinte Postgres-ter\u00e7a-feira, onde Nikolai conversou com Alexander Kukushkin da Zalando<\/b>. O v\u00eddeo est\u00e1 dispon\u00edvel aqui<\/a><\/noindex>.<\/p>\n

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

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