Banco de dados nas nuvens: para quem e por quê - a opinião dos especialistas em Data Egret

Acredita-se que o futuro seja o DB como Serviço. Vale a pena que todos disparem um DBA e acessem uma nuvem pública ou se esforcem para criar uma nuvem privada no Docker com o Kubernetes? Três especialistas do Data Egret - Alexei Lesovsky, Viktor Yegorov e Andrey Salnikov - no canal #RuPostgres ao vivo compartilharam suas opiniões sobre que tipo de projetos os modelos de nuvem são adequados.

O moderador e moderador da discussão foi Nikolay Samokhvalov, fundador do Postgres.ai e co-fundador da comunidade RuPostgres.org.



Sob o corte - transcrição da conversa.

- Hoje falaremos sobre o Postgres nas nuvens. E começarei com uma pergunta complicada: é verdade que você já tem mais da metade dos clientes nas nuvens?

Alexei: Eu acho que não. Parece menos da metade. Todo mundo fica sentado em seus próprios data centers ou aluga peças de ferro.

Mas antes de falar sobre as nuvens, vamos definir os termos. O que queremos dizer com "nuvens": Amazon, Google Cloud, DB como serviço?

- Diferenciaria o Postgres na nuvem, preparado em uma instância do Amazon EC2 (ou um analógico do Google), onde você pode, grosso modo, efetuar login via ssh e corrigir a configuração, e o Postgres sob controle (em inglês "gerenciado"), quando acesso direto no nível do arquivo ou no ssh, mas existe apenas a capacidade de conectar e executar consultas SQL. Devem, em princípio, ser considerados separadamente. E minha primeira pergunta foi sobre o Postgres gerenciado.

Alexei: Esses clientes são substancialmente menos da metade.

Victor: Bem, no primeiro caso - que vantagens significativas temos da nuvem? Qual é o significado da nuvem?

- No primeiro caso, usando várias ferramentas modernas, como patroni e kubernetes (falaremos sobre eles separadamente), você pode obter elasticidade, microsserviços e tudo mais. Isso não é o mesmo que apenas um pedaço de ferro. É como "animais de estimação x rebanho" - a atitude de passar a ferro como animal de estimação se torna uma relação com máquinas virtuais e com um rebanho. Você já não sabe que tipo de glândulas estão instaladas lá. Você não os encomendou, não trabalhou com o fornecedor, não pensou na topologia. Você pode economizar tempo.

Victor: Sim. Na minha opinião, o primeiro caso simplesmente simplifica o processo de compra de ferro novo. Você sabe do que precisa: quantos núcleos e RAM, quais unidades. E você escolhe uma máquina virtual a partir do que elas oferecem. É rápido Mas, caso contrário, você ainda precisará configurar e manter este servidor normalmente.

- E como você se sente com a sobrecarga adicionada pelas máquinas virtuais (aos processos dentro de uma máquina virtual que não possuem bare metal, sobrecarga de desempenho ou dificuldades de administração)? Algum de vocês mediu isso?

Alexei: A sobrecarga pode ser medida se você tiver controle sobre o hipervisor. Nos serviços públicos, não é - o que eles dão é o que você usa.

A sobrecarga dos sistemas de virtualização usuais que podem ser implantados em casa (KVM, Xen), medi há cinco anos e, em seguida, era de 7-8%. Além disso, dependia das configurações da máquina virtual e da carga de trabalho. Por exemplo, havia significativamente mais despesas gerais no Redis e no Postgres do que no Unicorn, que serve back-ends do Rails.

Talvez agora os números sejam diferentes.

- Mesmo 5-7% é uma sobrecarga aceitável em comparação com as vantagens de que Victor falou.

E como você altera a composição dos clientes: existe algum movimento em direção a bases gerenciadas?



Alexey: Não. A tendência é bastante oposta. As pessoas que trabalham com coisas como o RDS não têm flexibilidade para administrar e gerenciar. Como resultado, temos a mesma atitude de "gostar de animais de estimação", mas em casos do EC2.

Victor: Essa situação se aproxima. Existem clientes cujas principais bases de produção estão muito ocupadas. Naturalmente, eles são colocados nos pedaços de ferro alocados e sob supervisão constante. Porém, quando a empresa cresce, o desenvolvimento exige um grande número de instâncias de teste e desenvolvimento, e elas entram na virtualização. Ou seja, este é um caso híbrido: sob testes e ambientes de desenvolvimento, é possível comprar hardware ou alugar máquinas virtuais. Mas a produção permanece em um hardware sério normal.

- O Amazon RDS é usado para isso?

Alexey: Nossos clientes, pelo contrário, recusam o RDS. O motivo, como eu disse, é a falta de flexibilidade no gerenciamento.

As instâncias falham e, em alguns casos, o problema não é resolvido apenas com o aluguel de um pedaço de ferro mais poderoso.

Você não pode resolver muitos problemas sozinho - apenas com a ajuda do suporte.

- É possível dar exemplos? Parece que recentemente a Amazon comprou o OpenSCG - ótimos profissionais que deveriam ter desenvolvido o conhecimento interno do Postgres. E sei por experiência própria que há um exame. Se você abrir um ticket com o suporte do Amazon RDS e encontrar uma pessoa que não pode ajudá-lo, feche-o e abra-o novamente, chegando a um mais competente.

Alexey: O OpenSCG é, obviamente, uma equipe de profissionais. Mas a compra dessa equipe não fecha 100% das situações possíveis. Existem problemas que suportam rostos pela primeira vez. Isso também acontece conosco.

Dessas, em uma das réplicas do PostgreSQL 10.6, a média de carga do cliente no host aumentou repentinamente de 30 a 40 unidades, embora não haja carga. Uma batida subterrânea tão incompreensível. Isso não afeta muito, mas a própria imagem da recuperação média da carga é incompreensível. E ela irrita os administradores do cliente. Temos algumas hipóteses, o que a causou, mas até agora não fomos capazes de testá-las, porque o sistema é produtivo e nem tudo pode ser feito rapidamente lá.

E essas "batidas subterrâneas" surgem uma vez por ano e você começa a abordar a tarefa de maneira criativa. E o Amazon RDS é um número maior de instâncias, um número maior de instalações e tickets, respectivamente, e todos os tipos de situações são muito maiores.



Andrew: Gostaria de acrescentar sobre a comparação de instâncias RDS e EC2.
Tínhamos um cliente com produção em RDS. Ele procurou conselhos. O circuito de desenvolvimento estava localizado no Microsoft Azure; aparentemente, o Azure foi inicialmente considerado como o principal serviço de nuvem.

Eu arrastei a base do circuito de desenvolvimento do Azure para a Amazon no EC2 para me aproximar da produção e os problemas de previsão se aproximaram do banco de dados do produto.

Embora o servidor EC2 fosse duas vezes mais simples do que nas instâncias RDS e a carga de teste fosse maior que o produto, no circuito dev após minha instalação, os resultados foram muito melhores do que no Amazon na instância RDS em produção.

Suspeito que, devido à falta de conhecimento do PostgreSQL na empresa do cliente, o RDS tenha sido usado com a configuração padrão. Nós torcemos todas as configurações.

Como resultado, o cliente ficou muito impressionado. Voltei-me para o gerenciamento com uma proposta, em vez do RDS, para obter e configurar instâncias simples.

- A propósito, como foi medido, o que é melhor, o que é pior?

Andrew: O cliente analisou as métricas de seu aplicativo, a rapidez com que os dados foram baixados e processados.

- Estamos repreendendo o RDS, mas ele tem enormes vantagens - remove muitas dores de cabeça associadas à implantação, backups, replicação. Você concorda

Andrew: Sim. E, provavelmente, o principal motivo pelo qual o cliente permaneceu no RDS foi justamente na falta mencionada de conhecimento do PostgreSQL. Eles obtêm tudo o que precisam com o RDS, apenas pagam mais pelas instâncias.

- Além do Amazon RDS, existem outros postgres gerenciados baseados na nuvem. Você encontrou, por exemplo, o serviço Yandex?

Andrei: Encontrei suas máquinas virtuais e não gostei muito delas - as unidades NVMe não são muito honestas por lá. De fato, existem unidades conectadas através de uma rede.

- NVMe honesto (unidades locais) também é um problema. Google e Amazon têm NVMe, mas as unidades são efêmeras. Se você reiniciar a instância, perderá todos os dados porque recebe outra máquina virtual.

Andrei: Eles comentaram comigo na Yandex Cloud que eles tinham o NVMe honesto no DB como serviço, mas ainda não encontrei esse serviço. Aparentemente, existe uma arquitetura ligeiramente diferente no nível da provisão de recursos.

Eles trabalham muito duro no DB como serviço, pois o usam em seus serviços. Apenas existem diferentes pontos de entrada para clientes externos e uso interno.

- E o que você acha, existem perspectivas para o Postgres russo na nuvem? Vai decolar ou não decolar?

Andrew:

A Yandex possui uma excelente equipe, bastante experiente, com bons conhecimentos. Eu acho que eles vão decolar.

Primeiro, eles próprios operam muitos Postgres (mais de 1000 bancos de dados em seus projetos) e, desde explorar, todos os cones e pontos doloridos funcionarão e serão corrigidos mais rapidamente. Penso que o cliente receberá o serviço final de qualidade bastante boa.

E há uma demanda por essas soluções. Faça uma startup que, no início, não pode ter o conhecimento necessário no Postgres por vários motivos: caro, eles não entendem o ponto, tente tecnologias diferentes. Para ele, essa é uma boa solução, pois nesses serviços existem “reviravoltas” limitadas que não devem ser distorcidas e, se eu acho, haverá suporte técnico.

É verdade que o Yandex Cloud ainda está no início, e poucas funcionalidades são apresentadas no momento.

- Temos perguntas na sala de bate-papo: o que você acha do fato de que, ao emitir máquinas virtuais, alguém pode sentar-se fisicamente nessa máquina (limitação, tempo de roubo).



Victor: Sim, existe essa experiência. Eu só queria mencionar isso. Existem clientes que possuem seus próprios sistemas de virtualização implantados. De tempos em tempos, eles pedem para ver um servidor que não é do produto e vemos uma situação incompreensível: não observamos os motivos pelos quais ele deve quebrar nesse servidor. Em seguida, redirecionamos as perguntas para seus administradores com uma solicitação para ver o que está acontecendo no host.

- E o que fazer, existe um efeito semelhante na Amazônia? Existem métodos para determinar que você está "espremido"? pgbench para dirigir?

Alexei: Não me lembro disso. Mas a maneira usual é determinar através do tempo de roubo. Nos gráficos de monitoramento, como regra, não vemos grandes valores.

- Eu sinto que você não gosta muito do Postgres gerenciado. Isso se deve ao fato de o RDS levar o seu trabalho?

Alexey: Não. Isso é mais provável devido ao fato de que simplesmente não o temos. O Postgres gerenciado é bom porque você pode implantar a infraestrutura com o clique de um botão. Desde que você seja uma startup e apenas adicione ou leia dados sem lógica lógica, tudo estará bem. E quando você cruza uma determinada linha, por exemplo, você começa a executar muitas JOINs, executa SQL complexo, a tarefa surge para otimizar consultas e o RDS deixa de ser suficiente. É preciso mais liberdade e influência, mas as ferramentas disponíveis não ajudam a resolver os problemas profundos associados ao descarte de recursos no próprio Postgres. Há apenas a oportunidade de aumentar o poder do pedaço de ferro: pagou mais dinheiro - recebido.

Andrew: Não há muita antipatia pelo RDS e medo de trabalhar. O problema é diferente. Suponha que uma startup use o RDS, ele dê tudo a eles. Mas ele não aumentou sua experiência no Postgres. Em seguida, digamos um tiro de inicialização. As cargas estão crescendo - a escrita e a leitura aumentaram. Na ausência de sua experiência, uma startup precisa procurar pessoas do lado. DBAs graves vêm e veem que não conseguem extrair mais do RDS, mas a partir de uma instância normal do EC2 é bem possível obter mais desempenho, como no exemplo mencionado anteriormente. Se tivéssemos permissão no RDS, talvez pudéssemos ajustar e melhorar o banco de dados, mas não o fizemos.

- O problema com o acesso está sendo resolvido. Existem Postgres gerenciados que fornecem acesso ssh (e até mesmo completamente root), por exemplo, uma pequena empresa Aiven da Finlândia. Por padrão, eles não dão acesso root, mas o fundador (e eu conversamos com ele algumas vezes) falou sobre sua disponibilidade para conceder acesso mediante solicitação.

Andrew: A questão não é apenas o acesso. Por que estamos melhor com glândulas puras? Porque temos muitos clientes diferentes e cada um tem sua própria infraestrutura. E as infraestruturas estão tão distantes que a metodologia geral que funciona da mesma maneira em todos os lugares, simplesmente não podemos. Porque existem aqueles que têm seu próprio hardware, e eles simplesmente não podem hospedar em algum lugar (de acordo com algumas de suas próprias regras e restrições), e há aqueles que estão nas nuvens.

- Você quer dizer que a definição de índices não utilizados depende do pedaço de ferro? Ou algumas outras coisas comuns?

Andrew: Do ponto de vista da administração, é o esquema do banco de dados e a definição de índices não utilizados que as nuvens não são diferentes de seu hardware. Tudo é unificado.

A diferença entre uma nuvem e uma peça real de hardware - na camada entre a base e especificamente o hardware que fica abaixo - é o sistema operacional e as virtualizações usadas. Quando você tem bancos de dados grandes, é importante para você a rapidez com que as unidades enviam e recebem dados, com que eficiência a memória e o processador são usados, por isso é extremamente importante reduzir a influência dessa camada para que o banco de dados funcione com mais eficiência.

- Outra pergunta da platéia: e as configurações do kernel?

Victor: No EC2, essas coisas são personalizáveis.

- Existem novas soluções para a classe "Postgres gerenciado" de fornecedores conhecidos, além das usuais Amazon e Google. Por exemplo, a Nutanix e a SAP anunciaram em 2018 a criação de soluções baseadas no Postgres. Você não acha que todos esses caras nos levam ao surgimento de algumas decisões que farão o mesmo, mas apenas no seu pedaço de ferro? Para que você possa clicar no botão e implantar o novo Postgres, onde os backups e a replicação já estão configurados.

Alexei: Parece-me que a SAP e outros não são totalmente lucrativos. Estes são grandes fornecedores de ferro e software. Eles fazem um produto com o objetivo de ganhar dinheiro. Venda pelo menos suporte. Portanto, devemos ver como eles lucram com isso. Se esse modelo de entrega de produtos é benéfico para eles, por que não?

- Eu quis dizer um pouco diferente. Especificamente, esses caras não publicam nada em código aberto e doam de graça. Mas você não acha que alguém do menor, mas brincalhão, fará algo assim? Talvez isso se concentre no Kubernetes, Operator Framework. Já existem alguns desenvolvimentos que os operadores estão fazendo - Zalando, por exemplo. E você não acha que o RDS baseado em nuvem ajuda a uma transição gradual para essas soluções? Vemos como você pode viver sem subir nas configurações com as mãos.

Alexey: Acontece que não é bem gerenciado.

Mesmo assim, você precisará de especialistas que monitorem tudo isso e subam ao palco se algo der errado.

Até o próprio Kubernetes é uma máquina muito complexa, com muitos componentes sob o capô. Formalmente, são apenas cinco binários. Mas a interação entre eles é descrita por volumes de documentação e muitas informações em salas de bate-papo, boletins informativos e Grupos do Google. I.e. você ainda precisa de um especialista que siga esta cozinha.

Além disso, tudo isso está se desenvolvendo muito dinamicamente. A compatibilidade com versões anteriores é interrompida de uma liberação para outra. I.e. tudo é muito instável e instável. Quando tudo se acalmar, talvez tenhamos um produto adequado, estável e confiável. Mas até agora, nem tudo é muito.

Victor: Estamos começando a falar sobre o fato de termos uma camada adicional de infraestrutura que precisa ser gerenciada - para orquestrar esse Kubernetes.

Não concordo que ele sempre funcione magicamente com o clique de um botão da maneira que queremos. É necessário manter especialistas relevantes.

E a segunda - nossos clientes estão constantemente se adaptando às mudanças nos negócios. Consequentemente, a carga no banco de dados está mudando constantemente. E se lambemos tudo há três meses, como resultado de todas as solicitações funcionarem como deveriam, e tudo estava bem, uma nova solicitação pode ser recebida hoje ou amanhã, ou devido a alterações nos dados, a solicitação existente deixará de funcionar como deveria. E precisamos analisar a situação e entrar nas configurações do sistema. E é essa automação que, ao que me parece, dificulta muito essas instâncias gerenciadas. Quando as nuvens atingem tal estado que também se adaptam a tais situações, eu não sei. Porém, embora essa seja uma parte significativa do trabalho que precisa ser realizado, é necessário adaptar as configurações do banco de dados às mudanças no padrão de solicitações recebidas.

E como a própria nuvem é uma carga administrativa adicional, é mais fácil para nós quando essa camada simplesmente não existe, porque podemos nos concentrar nos problemas do banco de dados.

Se o cliente deseja viver na nuvem e possui a experiência, não temos nada contra. O principal é que temos a oportunidade, quando o banco de dados não ficar muito bom, suba (de preferência pelo ssh), verifique tudo e tenha acesso a todas as estatísticas.

Alexey: Não necessariamente pelo ssh. Mas, em qualquer caso, são necessárias ferramentas de diagnóstico. Porque o diagnóstico por email é muito longo e tedioso. É irritante quando você envia um link de bate-papo para a solicitação a ser executada, por outro lado, o cliente clica nesse link, copia a solicitação e depois copia o resultado para você ou envia uma captura de tela. Isso é o tempo todo.

É muito mais fácil conectar-se e ver diretamente, testar algumas de suas hipóteses e agir mais a partir delas.

- Você tem algum exemplo ativo de onde o Kubernetes já está sendo usado e o Postgres mora nele?

Alexei: Infelizmente não. Mas eu realmente gostaria. Eu realmente gosto de Kubernetes, estou perto de seu conceito e filosofia.

Na minha opinião, o Kubernetes é algo que incentiva as pessoas a programar mais, criar mais um produto, sem pensar em coisas paralelas, como a estrutura interna da infraestrutura.

Um papel semelhante costumava ser desempenhado pelo OOP. Apareceu e muitas pessoas se interessaram nessa área, porque a programação se tornou um pouco mais fácil. O Kubernetes também fecha muitas coisas por si só, as esconde sob o capô e permite que uma pessoa se concentre no aspecto criativo e programa mais.

O Kubernetes implementa suporte para instâncias, lares e o aplicativo funciona. Se ele travar repentinamente - bem, o Kubernetes o lançará novamente. I.e. o desenvolvedor e o administrador estão livres de dores de cabeça e rastreamento constante. Eu gosto dessa resposta à situação. Quando algo cai, é reiniciado automaticamente.

, , . — , , . .

– , ?

: , . , . - , . , , Kubernetes. Kubernetes . CNCF . , .

– - kubernetes_ru. github, Kubernetes: . Postgres, .

, , , . , Kubernetes – , . - IT.

– , Amazon Aurora PostgreSQL Serverless ? , , . , . .. .

:

. .

, . , , . : , . , - . .

– . . , , .

: . , . , , – . , , , , .

I.e. . – , , 70% . . .

, , « », .

– . , , DBA : - , - — , ?

: , , , – DBA, SQL-developer. Oracle SQL-developer, , , , . , Oracle. . DBA , - .

DBA — - «» , .

Kubernetes. , . . , Kubernetes . , volume . I.e. , . , .

– ?

: .

, . , , . , Postgres ( ). Postgres - . I.e. (, ), .

, .

, , . . . .

– ?

: - . , , .

, Cassandra. . I.e. — , Kubernetes.

, , . , , .

I.e. . DBA, , – . , , - – .

– ?

: . , . , , , Kubernetes . , , , , - - Kubernetes ( ).

: Kubernetes. – patroni. Zalando Kubernetes. , , ( – , Amazon , ). , – . , – . – - Kubernetes.

– RDS. EC2 Postgres . patroni ( https://github.com/zalando/patroni ), .

: , , - high availability.

– . — , ?

: , - .
Zalando DBA, patroni. I.e. , Kubernetes , DBA .

– . DBA, DBA «» «».

: , . . , , .

– - Kubernetes? ?

: - , . Kubernetes – , . Kubernetes - . . DBA. Kubernetes (, Kubernetes , , ).

- , , - - -.

: ( Kubernetes ), - . , — — . - , , , , , , .

:

. Kubernetes , . , . .

, — . , Postgres- , , . .

: …

– .. : - — dev environment, production – Kubernetes. ...

: latency , , . .

– , . .
, HighLoad++ .

PS .