Olá, residentes de Khabrovsk. Aulas da primeira turma do curso começam hoje . A este respeito, gostaríamos de contar como ocorreu o webinar aberto deste curso.
В falamos sobre os desafios que os bancos de dados SQL enfrentam na era das nuvens e do Kubernetes. Ao mesmo tempo, analisamos como os bancos de dados SQL se adaptam e sofrem mutações sob a influência desses desafios.
O webinar foi realizado , gerente de entrega de prática do Google Cloud na EPAM Systems.
Quando as árvores eram pequenas...
Primeiramente, vamos lembrar como começou a escolha do SGBD no final do século passado. Porém, isso não será difícil, pois a escolha de um SGBD naquela época começava e terminava Oracle.
No final dos anos 90 e início dos anos 2, basicamente não havia escolha quando se tratava de bancos de dados escaláveis industriais. Sim, havia IBM DBXNUMX, Sybase e alguns outros bancos de dados que iam e vinham, mas em geral eles não eram tão perceptíveis no contexto do Oracle. Conseqüentemente, as habilidades dos engenheiros daquela época estavam de alguma forma ligadas à única escolha que existia.
O Oracle DBA precisava ser capaz de:
- instale o Oracle Server do kit de distribuição;
- configurar o servidor Oracle:
- init.ora;
- ouvinte.ora;
- criar:
- espaços de tabelas;
- esquemas;
- usuários;
— realizar backup e restauração;
— realizar monitoramento;
— lidar com solicitações abaixo do ideal.
Ao mesmo tempo, não houve nenhum requisito especial do Oracle DBA:
- ser capaz de escolher o SGBD ideal ou outra tecnologia para armazenar e processar dados;
- fornecer alta disponibilidade e escalabilidade horizontal (isso nem sempre foi um problema do DBA);
- bom conhecimento da área temática, infraestrutura, arquitetura de aplicativos, SO;
- carregar e descarregar dados, migrar dados entre diferentes SGBDs.
Em geral, se falamos da escolha daquela época, lembra a escolha de uma loja soviética do final dos anos 80:
Nosso tempo
Desde então, é claro, as árvores cresceram, o mundo mudou e ficou mais ou menos assim:
O mercado de DBMS também mudou, como pode ser visto claramente no último relatório do Gartner:
E aqui deve-se notar que as nuvens, cuja popularidade está crescendo, ocuparam seu nicho. Se lermos o mesmo relatório do Gartner, veremos as seguintes conclusões:
- Muitos clientes estão no caminho de migrar aplicativos para a nuvem.
- As novas tecnologias aparecem pela primeira vez na nuvem e não é um facto que alguma vez irão migrar para infraestruturas fora da nuvem.
- O modelo de preços pré-pagos tornou-se comum. Todo mundo quer pagar apenas pelo que usa, e isso nem é uma tendência, mas simplesmente uma constatação de um fato.
E agora?
Hoje estamos todos na nuvem. E as questões que nos surgem são questões de escolha. E é enorme, mesmo que falemos apenas da escolha de tecnologias de SGBD no formato On-premises. Também temos serviços gerenciados e SaaS. Assim, a escolha só fica mais difícil a cada ano.
Junto com questões de escolha, há também Fatores limitantes:
- preço. Muitas tecnologias ainda custam dinheiro;
- habilidades. Se falamos de software livre, então surge a questão das competências, uma vez que o software livre exige competência suficiente das pessoas que o implantam e operam;
- funcional. Nem todos os serviços que estão disponíveis na nuvem e construídos, digamos, até mesmo no mesmo Postgres, têm os mesmos recursos do Postgres On-premises. Este é um fator essencial que precisa ser conhecido e compreendido. Além disso, este fator torna-se mais importante do que o conhecimento de algumas capacidades ocultas de um único SGBD.
O que se espera do DA/DE agora:
- bom conhecimento da área temática e da arquitetura da aplicação;
- a capacidade de selecionar corretamente a tecnologia SGBD adequada, levando em consideração a tarefa em questão;
- a capacidade de selecionar o método ideal para implementar a tecnologia selecionada no contexto das limitações existentes;
- capacidade de realizar transferência e migração de dados;
- capacidade de implementar e operar soluções selecionadas.
Abaixo exemplo com base no GCP demonstra como funciona a escolha de uma ou outra tecnologia para trabalhar com dados dependendo de sua estrutura:
Observe que o PostgreSQL não está incluído no esquema, e isso ocorre porque está oculto na terminologia Cloud SQL. E quando chegarmos ao Cloud SQL, precisaremos fazer uma escolha novamente:
Deve-se notar que esta escolha nem sempre é clara, por isso os desenvolvedores de aplicativos são muitas vezes guiados pela intuição.
Total:
- Quanto mais você avança, mais urgente se torna a questão da escolha. E mesmo se você olhar apenas para GCP, serviços gerenciados e SaaS, alguma menção ao RDBMS aparece apenas na 4ª etapa (e o Spanner está por perto). Além disso, a escolha do PostgreSQL aparece no 5º passo, e ao lado dele também estão o MySQL e o SQL Server, ou seja tem muito de tudo, mas você tem que escolher.
- Não devemos esquecer as restrições num contexto de tentações. Basicamente todo mundo quer uma chave inglesa, mas é cara. Como resultado, uma solicitação típica se parece com isto: “Por favor, torne-nos um Spanner, mas pelo preço do Cloud SQL, vocês são profissionais!”
O que fazer?
Sem pretender ser a verdade última, digamos o seguinte:
Precisamos mudar nossa abordagem de aprendizagem:
- não adianta ensinar como os DBAs eram ensinados antes;
- o conhecimento de um produto não é mais suficiente;
- mas conhecer dezenas no nível de um é impossível.
Você precisa saber não só e não quanto custa o produto, mas:
- caso de uso de sua aplicação;
- diferentes métodos de implantação;
- vantagens e desvantagens de cada método;
- produtos similares e alternativos para fazer uma escolha informada e ideal e nem sempre a favor de um produto familiar.
Você também precisa ser capaz de migrar dados e compreender os princípios básicos de integração com ETL.
Caso real
Num passado recente, era necessário criar um backend para uma aplicação móvel. Quando o trabalho começou, o backend já havia sido desenvolvido e estava pronto para implementação, e a equipe de desenvolvimento passou cerca de dois anos neste projeto. As seguintes tarefas foram definidas:
- construir CI/CD;
- revisar a arquitetura;
- colocar tudo em operação.
O aplicativo em si era microsserviços, e o código Python/Django foi desenvolvido do zero e diretamente no GCP. Quanto ao público-alvo, assumiu-se que seriam duas regiões - EUA e UE, e o tráfego foi distribuído através do Global Load balancer. Todas as cargas de trabalho e de computação foram executadas no Google Kubernetes Engine.
Quanto aos dados, existiam 3 estruturas:
- Armazenamento na núvem;
- Banco de dados;
- CloudSQL (PostgreSQL).
Alguém pode se perguntar por que o Cloud SQL foi escolhido? Para dizer a verdade, tal questão causou uma espécie de pausa estranha nos últimos anos - há uma sensação de que as pessoas ficaram tímidas em relação aos bancos de dados relacionais, mas mesmo assim continuam a usá-los ativamente ;-).
No nosso caso, o Cloud SQL foi escolhido pelos seguintes motivos:
- Conforme mencionado, a aplicação foi desenvolvida em Django e possui um modelo para mapeamento de dados persistentes de um banco de dados SQL para objetos Python (Django ORM).
- A própria estrutura suportava uma lista bastante finita de SGBDs:
- PostgreSQL;
- MariaDB;
- Mysql;
- Oracle
- SQLite.
Conseqüentemente, o PostgreSQL foi escolhido nesta lista de forma bastante intuitiva (bem, na verdade não cabe à Oracle escolher).
O que estava faltando:
- o aplicativo foi implantado apenas em 2 regiões, e uma terceira apareceu nos planos (Ásia);
- A base de dados estava localizada na região da América do Norte (Iowa);
- por parte do cliente havia preocupações sobre possíveis atrasos de acesso da Europa e da Ásia e interrupções em serviço em caso de tempo de inatividade do DBMS.
Apesar do próprio Django poder trabalhar com vários bancos de dados em paralelo e dividi-los em leitura e escrita, não havia tanta escrita na aplicação (mais de 90% é leitura). E em geral, e em geral, se fosse possível fazer réplica de leitura da base principal na Europa e Ásia, esta seria uma solução de compromisso. Bem, o que há de tão complicado nisso?
A dificuldade era que o cliente não queria desistir de usar serviços gerenciados e Cloud SQL. E os recursos do Cloud SQL são atualmente limitados. O Cloud SQL é compatível com alta disponibilidade (HA) e réplica de leitura (RR), mas o mesmo RR é compatível apenas em uma região. Tendo criado um banco de dados na região americana, você não pode fazer uma réplica de leitura na região europeia usando o Cloud SQL, embora o próprio Postgres não impeça que você faça isso. A correspondência com funcionários do Google não levou a lugar nenhum e terminou com promessas do tipo “conhecemos o problema e estamos trabalhando nele, algum dia o problema será resolvido”.
Se listarmos brevemente os recursos do Cloud SQL, será mais ou menos assim:
1. Alta disponibilidade (HA):
- dentro de uma região;
- via replicação de disco;
- Os mecanismos PostgreSQL não são usados;
- controle automático e manual possível - failover/failback;
- Ao alternar, o DBMS fica indisponível por vários minutos.
2. Leia a réplica (RR):
- dentro de uma região;
- Hot Standby;
- Replicação de streaming do PostgreSQL.
Além disso, como é habitual, ao escolher uma tecnologia deparamo-nos sempre com alguns limitações:
- o cliente não queria criar entidades e usar IaaS, exceto por meio do GKE;
- o cliente não gostaria de implantar PostgreSQL/MySQL de autoatendimento;
- Bem, em geral, o Google Spanner seria bastante adequado se não fosse pelo seu preço, porém, o Django ORM não pode funcionar com ele, mas é uma coisa boa.
Considerando a situação, o cliente recebeu uma pergunta complementar: “Você pode fazer algo semelhante para que seja como o Google Spanner, mas também funcione com Django ORM?”
Opção de solução nº 0
A primeira coisa que me veio à mente:
- permaneça no CloudSQL;
- não haverá qualquer forma de replicação integrada entre regiões;
- tente anexar uma réplica a um Cloud SQL existente do PostgreSQL;
- inicie uma instância do PostgreSQL em algum lugar e de alguma forma, mas pelo menos não toque no master.
Infelizmente, descobriu-se que isso não pode ser feito, porque não há acesso ao host (está em um projeto completamente diferente) - pg_hba e assim por diante, e também não há acesso sob superusuário.
Opção de solução nº 1
Após mais reflexão e tendo em conta as circunstâncias anteriores, a linha de pensamento mudou um pouco:
- Ainda estamos tentando permanecer no CloudSQL, mas estamos migrando para o MySQL, pois o Cloud SQL by MySQL possui um mestre externo, que:
— é um proxy para MySQL externo;
- parece uma instância do MySQL;
- inventado para migrar dados de outras nuvens ou locais.
Como a configuração da replicação do MySQL não requer acesso ao host, a princípio tudo funcionou, mas foi muito instável e inconveniente. E quando fomos mais longe, ficou completamente assustador, porque implantamos toda a estrutura com terraform, e de repente descobriu-se que o mestre externo não era suportado por terraform. Sim, o Google tem uma CLI, mas por algum motivo tudo funcionava aqui de vez em quando - às vezes é criado, às vezes não é criado. Talvez porque a CLI tenha sido inventada para migração externa de dados e não para réplicas.
Na verdade, neste ponto ficou claro que o Cloud SQL não é adequado. Como dizem, fizemos tudo o que podíamos.
Opção de solução nº 2
Como não foi possível permanecer na estrutura do Cloud SQL, tentamos formular requisitos para uma solução de compromisso. Os requisitos acabaram sendo os seguintes:
- trabalho em Kubernetes, aproveitamento máximo de recursos e capacidades de Kubernetes (DCS, ...) e GCP (LB, ...);
- falta de lastro de um monte de coisas desnecessárias na nuvem, como proxy HA;
- a capacidade de executar PostgreSQL ou MySQL na região principal de HA; nas demais regiões - HA do RR da região principal mais sua cópia (para confiabilidade);
- multi master (não queria contatá-lo, mas não era muito importante)
.
Como resultado dessas demandas, pDBMS adequado e opções de ligação:
- Galeria MySQL;
- BarataDB;
- Ferramentas PostgreSQL
:
-pgpool-II;
— Patroni.
Galeria MySQL
A tecnologia MySQL Galera foi desenvolvida pela Codership e é um plugin para InnoDB. Peculiaridades:
- multimestre;
- replicação síncrona;
- lendo de qualquer nó;
- gravando em qualquer nó;
- mecanismo HA integrado;
- Há um gráfico Helm da Bitnami.
barataDB
De acordo com a descrição, a coisa é absolutamente uma bomba e é um projeto de código aberto escrito em Go. O principal participante é o Cockroach Labs (fundado por pessoas do Google). Este SGBD relacional foi originalmente projetado para ser distribuído (com escalabilidade horizontal pronta para uso) e tolerante a falhas. Seus autores da empresa delinearam o objetivo de “combinar a riqueza da funcionalidade SQL com a acessibilidade horizontal familiar às soluções NoSQL”.
Um bom bônus é o suporte para o protocolo de conexão pós-gresso.
pgpool
Este é um complemento do PostgreSQL, na verdade, uma nova entidade que assume todas as conexões e as processa. Possui seu próprio balanceador de carga e analisador, licenciado sob a licença BSD. Oferece amplas oportunidades, mas parece um tanto assustador, porque a presença de uma nova entidade pode se tornar a fonte de algumas aventuras adicionais.
Patroni
Esta foi a última coisa que meus olhos encontraram e, como descobri, não foi em vão. Patroni é um utilitário de código aberto, que é essencialmente um daemon Python que permite manter automaticamente clusters PostgreSQL com vários tipos de replicação e troca automática de funções. A coisa acabou sendo muito interessante, pois se integra bem ao cuber e não introduz nenhuma entidade nova.
O que você escolheu no final?
A escolha não foi fácil:
- barataDB - fogo, mas escuro;
- Galeria MySQL - também não é ruim, é usado em muitos lugares, mas no MySQL;
- pgpool - muitas entidades desnecessárias, integração moderada com a nuvem e K8s;
- Patroni - excelente integração com K8s, sem entidades desnecessárias, integra-se bem com GCP LB.
Assim, a escolha recaiu sobre Patroni.
Descobertas
É hora de resumir brevemente. Sim, o mundo da infraestrutura de TI mudou significativamente e isto é apenas o começo. E se antes as nuvens eram apenas mais um tipo de infraestrutura, agora tudo é diferente. Além disso, inovações nas nuvens aparecem constantemente, vão aparecer e, talvez, apareçam apenas nas nuvens e só então, pelo esforço das startups, serão transferidas para On-premises.
Quanto ao SQL, o SQL viverá. Isso significa que você precisa conhecer PostgreSQL e MySQL e saber trabalhar com eles, mas ainda mais importante é saber utilizá-los corretamente.
Fonte: habr.com