De alguma forma, historicamente, o setor de TI, por qualquer motivo, está dividido em dois campos condicionais: a favor e contra. Além disso, o assunto da controvérsia pode ser absolutamente arbitrário. Qual sistema operacional é melhor: Win ou Linux? Em um smartphone Android ou iOS? Mantenha tudo nas nuvens ou faça o upload para um armazenamento RAID frio e coloque os parafusos em um cofre? Os schnicks do PHP têm o direito de ser chamados de programadores? Essas disputas são, às vezes, de natureza exclusivamente existencial e não têm outra base além do interesse esportivo.
Aconteceu que, com o advento dos contêineres e de toda essa amada cozinha com estivadores e k8s condicionais, as disputas pró e contra começaram a usar novas oportunidades em várias áreas do back-end. (Faremos uma reserva antecipada de que, embora na maioria das vezes o Kubernetes seja indicado como orquestrador nesta discussão, a escolha deste instrumento não importa. Em vez disso, você pode substituir qualquer outro que lhe pareça mais conveniente e familiar.)
E, ao que parece, seria um argumento simples sobre os dois lados da mesma moeda. Tão sem sentido e sem piedade quanto o eterno confronto Win vs Linux, no qual pessoas adequadas existem para si mesmas em algum lugar no meio. Isso é apenas no caso da conteinerização não é tão simples. Geralmente, em tais disputas, não existe o lado certo, mas no caso de contêineres “aplicar” ou “não aplicar” para armazenar o banco de dados, tudo fica de cabeça para baixo. Porque, em certo sentido, apoiadores e oponentes de tal abordagem estão certos.
Bright Side
Você pode descrever brevemente os argumentos do Bright Side com uma frase: "Olá, 2k19 fora da janela!" Parece populismo, é claro, mas se você se aprofundar na situação em detalhes, ela terá suas vantagens. Vamos analisá-los agora.
Suponha que você tenha um grande projeto da web. Inicialmente, ele poderia ser construído com base em uma abordagem de microsserviço ou, em algum momento, evoluiu de maneira evolutiva - na verdade, isso não é muito importante. Você dispersou nosso projeto em microsserviços separados, configurou orquestração, balanceamento de carga, dimensionamento. E agora, com a consciência limpa, beba mojito na rede durante um efeito habr, em vez de aumentar os servidores caídos. Mas todas as ações devem ser consistentes. Muitas vezes, apenas o aplicativo em si é contêiner - o código. O que mais temos além do código?
Certo, dados. O coração de qualquer projeto é seus dados: ele pode ser um DBMS típico - MySQL, Postgre, MongoDB ou armazenamento usado para pesquisa (ElasticSearch), armazenamento de valor-chave para armazenamento em cache - por exemplo, redis etc. Agora não falaremos sobre opções de implementação de back-end torto quando o banco de dados falhar devido a consultas mal escritas e, em vez disso, falaremos sobre garantir a tolerância a falhas desse mesmo banco de dados sob carga do cliente. De fato, quando contêineres nosso aplicativo e permitimos que ele seja escalado livremente para lidar com qualquer número de solicitações recebidas, isso naturalmente aumenta a carga no banco de dados.
De fato, o canal para acessar o banco de dados e o servidor no qual ele gira torna-se o olho da agulha em nosso belo back-end em contêiner. Ao mesmo tempo, o principal motivo da virtualização de contêineres é a mobilidade e a plasticidade da estrutura, o que possibilita organizar a distribuição do pico de carga em toda a infraestrutura disponível para nós da maneira mais eficiente possível. Ou seja, se não contivermos e agruparmos todos os elementos disponíveis do sistema em um cluster, cometeremos um erro muito sério.
É muito mais lógico agrupar não apenas o aplicativo em si, mas também os serviços responsáveis pelo armazenamento de dados. Ao agrupar e implantar, trabalhando e distribuindo independentemente a carga de servidores da Web nos k8s, já resolvemos o problema da sincronização de dados - os mesmos comentários para as postagens, se você usar algum tipo de mídia ou plataforma de blog como exemplo. De qualquer forma, iniciamos uma representação intracluster, até virtual, do banco de dados como um ExternalService. A questão é que o próprio banco de dados ainda não foi armazenado em cluster - os servidores da Web implantados no cubo obtêm informações sobre as alterações de nossa base de combate estática, que gira separadamente.
Sinta a pegadinha? Usamos o k8s ou o Swarm para distribuir a carga e evitar a queda do servidor web principal, mas não fazemos isso no banco de dados. Afinal, se o banco de dados falhar, em toda a infraestrutura em cluster não faz sentido - de que serve páginas da Web vazias que retornam um erro de acesso ao banco de dados?
É por isso que não apenas os servidores da web precisam ser agrupados, como geralmente é feito, mas também a infraestrutura do banco de dados. Somente dessa maneira podemos garantir que elementos da mesma estrutura que estejam totalmente operacionais em uma equipe, mas ao mesmo tempo, sejam independentes um do outro. Ao mesmo tempo, mesmo que metade do nosso back-end sob carga "desmorone", o restante sobreviverá, e o sistema de sincronização do banco de dados entre si no cluster e a possibilidade de dimensionamento e implantação infinitos de novos clusters ajudarão a alcançar rapidamente as capacidades necessárias - haveria racks no data center .
Além disso, o modelo de banco de dados distribuído em clusters permite levar esse mesmo banco de dados para onde for necessário; se estamos falando de um serviço global, é ilógico distorcer um cluster da Web em algum lugar da área de São Francisco e, ao mesmo tempo, gerar pacotes ao acessar o banco de dados na região de Moscou e vice-versa.
Além disso, a conteinerização do banco de dados permite criar todos os elementos do sistema no mesmo nível de abstração. O que, por sua vez, torna possível gerenciar esse sistema diretamente do código, pelos desenvolvedores, sem o envolvimento ativo dos administradores. Os desenvolvedores pensaram que precisavam de um DBMS separado para um novo subprojeto - fácil! escreveu um arquivo yaml, carregado no cluster e pronto.
Bem, é claro, a operação interna é bastante simplificada. Diga-me, quantas vezes você apertou os olhos nos momentos em que um novo membro da equipe enfiou as mãos no banco de dados de combate para trabalhar? Qual, de fato, está girando agora? É claro que todos nós aqui somos adultos e, em algum lugar, temos um novo backup, e ainda mais - atrás de uma prateleira com pepinos da avó e esquis velhos - outro backup, possivelmente até em um armazenamento a frio, porque uma vez que seu escritório estava pegando fogo. Mas, ainda assim, toda introdução de um novo membro da equipe com acesso à infraestrutura de combate e, é claro, ao banco de dados de combate é um balde de validol para todos os que estão ao redor. Bem, quem, um novato, sabe, talvez ele esteja apertando os olhos? Assustador, concordo.
A conteinerização e, de fato, a topologia do banco de dados físico distribuído do seu projeto ajudam a evitar esses momentos válidos. Não confie no novato? Ok Criaremos nosso próprio cluster para ele e o desconectaremos do restante dos clusters de banco de dados - sincronização apenas por envio manual e rotação simultânea de duas chaves (um líder de equipe, o segundo administrador). E todo mundo está feliz.
E agora é hora de trocar de roupa nos oponentes da conteinerização de banco de dados.
Lado escuro
Argumentando por que não é necessário containerizar o banco de dados e continuar a rotacioná-lo em um servidor central, não vamos nos inclinar para a retórica da ortodoxia e declarações como "avós transformaram o banco de dados em hardware, e vamos!" Em vez disso, vamos tentar chegar a uma situação em que a conteinerização realmente traga dividendos tangíveis.
Você deve admitir que os projetos que realmente precisam de uma base no contêiner podem ser contados com os dedos de uma mão como o melhor operador de fresadora. Na maioria das vezes, até mesmo o uso de k8s ou Docker Swarm é redundante - muitas vezes eles recorrem a essas ferramentas devido à natureza hype geral da tecnologia e às "mais poderosas" na pessoa de gênero para conduzir tudo para nuvens e contêineres. Bem, porque agora está na moda e todo mundo faz.
Pelo menos na metade dos casos, usar o kubernetis ou apenas uma janela de encaixe em um projeto é redundante. A questão é que nem todas as equipes ou empresas de terceirização contratadas para atender à infraestrutura do cliente estão cientes disso. Pior - quando os contêineres são impostos, porque aumentam em uma certa quantidade de moedas para o cliente.
Em geral, há uma opinião de que o docker / mafia cubo esmaga estupidamente os clientes que terceirizam esses problemas de infraestrutura. De fato, para trabalhar com clusters, você precisa de engenheiros capazes disso e que compreendam a arquitetura da solução implementada em geral. De alguma forma, já descrevemos nosso caso com a edição da República - treinamos a equipe do cliente para trabalhar nas realidades dos kubernetis e todos ficaram satisfeitos. E foi decente. Muitas vezes, os "implementadores" do k8 tomam refém da infraestrutura do cliente - agora eles só entendem como tudo funciona lá, não há especialistas no lado do cliente.
Agora imagine que dessa maneira fornecemos não apenas a parte do servidor da web para a terceirização, mas também a manutenção do banco de dados. Dissemos que um DB é um coração e a perda de coração é fatal para qualquer organismo vivo. Em suma, as perspectivas não são as melhores. Portanto, em vez do hype kubernetis, muitos projetos simplesmente não devem enlouquecer com a tarifa normal da AWS, que resolverá todos os problemas com a carga em seu site / projeto. Mas a AWS não está mais na moda e as exibições são mais caras que o dinheiro - infelizmente também no ambiente de TI.
Ok Talvez o projeto realmente precise de cluster, mas se tudo estiver claro com aplicativos sem estado, como podemos organizar o fornecimento decente de conectividade de rede para o banco de dados em cluster?
Se estamos falando de uma solução de engenharia contínua, que parece ser a transição para o k8s, nossa principal dor de cabeça é a replicação de dados em um banco de dados em cluster. Alguns DBMSs são inicialmente bastante leais à distribuição de dados entre suas instâncias individuais. Muitos outros não são tão acolhedores. E, muitas vezes, o principal argumento na escolha de um DBMS para o nosso projeto não é a capacidade de replicar com recursos mínimos e custos de engenharia. Especialmente se o projeto não foi originalmente planejado como um microsserviço, mas simplesmente evoluiu nessa direção.
Não precisamos falar sobre a velocidade das unidades de rede - elas são lentas. I.e. ainda não temos uma possibilidade real; nesse caso, atualizar uma instância do DBMS em algum lugar, onde há mais, por exemplo, capacidades do processador ou RAM livre. Rapidamente, encontramos o desempenho de um subsistema de disco virtualizado. Consequentemente, o DBMS deve ser pregado em seu próprio conjunto pessoal de máquinas nas proximidades. Ou, é necessário separar de alguma forma a sincronização suficientemente rápida da sincronização de dados com as reservas estimadas.
Continuando o tema do FS virtual: Docker Volumes, infelizmente, não são isentos de problemas. Em geral, no caso de armazenamento de dados confiável a longo prazo, eu gostaria de gerenciar com os esquemas técnicos mais simples. E adicionar uma nova camada de abstração do contêiner FS ao host pai FS é um risco por si só. Mas quando também há dificuldades na transmissão de dados entre essas camadas na operação do sistema de suporte à conteinerização, é realmente um desastre. No momento, a maioria dos problemas conhecidos pela humanidade progressista parece ser erradicada. Mas você mesmo entende que, quanto mais complexo o mecanismo, mais fácil ele quebra.
À luz de todas essas "aventuras", é muito mais lucrativo e fácil manter o banco de dados em um só lugar, e mesmo se você precisar de conteinerização do aplicativo, deixe-o girar sozinho e através do gateway de distribuição receba comunicação simultânea com o banco de dados, que será lido e gravado apenas uma vez e em um só lugar Essa abordagem reduz a probabilidade de erros e má sincronização para valores mínimos.
Para o que estamos levando? Além disso, a conteinerização do banco de dados é apropriada onde houver uma necessidade real. Você não pode amontoar a base do aplicativo completo e girá-la como se tivesse duas dúzias de microsserviços - isso não funciona. E isso deve ser claramente entendido.
Em vez de saída
Se você está esperando a conclusão inteligível de "virtualizar ou não o banco de dados", então estamos desapontados: ele não estará aqui. Porque, ao criar qualquer solução de infraestrutura, não se deve guiar pela moda e pelo progresso, mas, antes de tudo, pelo bom senso.
Existem projetos nos quais os princípios e ferramentas que acompanham o kubernetis se encaixam perfeitamente e, nesses projetos, a paz ocorre pelo menos na área de back-end. E existem projetos que não precisam de conteinerização, mas uma infraestrutura de servidor normal, porque eles basicamente não podem ser redimensionados para um modelo de cluster de microsserviço, porque eles cairão.