De alguma forma, historicamente, a indústria de TI está dividida em dois campos condicionais por qualquer motivo: aqueles que são “a favor” e aqueles que são “contra”. Além disso, o objeto das disputas pode ser completamente arbitrário. Qual sistema operacional é melhor: Win ou Linux? Em um smartphone Android ou iOS? Você deve armazenar tudo nas nuvens ou colocá-lo em um armazenamento RAID frio e colocar os parafusos em um cofre? O pessoal de PHP tem o direito de ser chamado de programador? Estas disputas são, por vezes, de natureza exclusivamente existencial e não têm outra base senão o interesse desportivo.
Acontece que com o advento dos containers e toda essa culinária querida com docker e k8s condicionais, começaram os debates “a favor” e “contra” o uso de novas capacidades em diversas áreas do backend. (Vamos fazer uma ressalva de que embora o Kubernetes seja mais frequentemente indicado como orquestrador nesta discussão, a escolha desta ferramenta específica não é de fundamental importância. Em vez disso, você pode substituí-la por qualquer outra que lhe pareça mais conveniente e familiar .)
E, ao que parece, esta seria uma simples disputa entre os dois lados da mesma moeda. Tão insensato e impiedoso quanto o eterno confronto entre Win e Linux, no qual existem pessoas adequadas em algum lugar no meio. Mas no caso da conteinerização nem tudo é tão simples. Normalmente nessas disputas não existe lado certo, mas no caso de “usar” ou “não usar” containers para armazenamento de bancos de dados, tudo vira de cabeça para baixo. Porque, num certo sentido, tanto os defensores como os opositores desta abordagem têm razão.
Lado positivo
O argumento do Light Side pode ser brevemente descrito em uma frase: “Olá, 2k19 está fora da janela!” Parece populismo, claro, mas se analisarmos a situação detalhadamente, temos as suas vantagens. Vamos resolvê-los agora.
Digamos que você tenha um grande projeto web. Poderia ter sido inicialmente construído com base em uma abordagem de microsserviços, ou em algum momento chegou a isso através de um caminho evolutivo - isso não é muito importante, na verdade. Você dispersou nosso projeto em microsserviços separados, configurou orquestração, balanceamento de carga e escalonamento. E agora, com a consciência tranquila, você toma um mojito em uma rede durante os efeitos do habra, em vez de levantar servidores caídos. Mas em todas as ações você deve ser consistente. Muitas vezes, apenas o próprio aplicativo – o código – é conteinerizado. O que mais temos além do código?
Isso mesmo, dados. O coração de qualquer projeto são seus dados: podem ser um SGBD típico - MySQL, Postgre, MongoDB ou armazenamento usado para pesquisa (ElasticSearch), armazenamento de valor-chave para cache - por exemplo, redis, etc. falaremos sobre opções de implementação de back-end distorcidas quando o banco de dados travar devido a consultas mal escritas e, em vez disso, falaremos sobre como garantir a tolerância a falhas desse mesmo banco de dados sob carga do cliente. Afinal, quando colocamos nosso aplicativo em contêineres e permitimos que ele seja escalonado livremente para processar qualquer número de solicitações recebidas, isso naturalmente aumenta a carga no banco de dados.
Na verdade, o canal de acesso ao banco de dados e o servidor no qual ele é executado tornam-se o buraco da agulha em nosso belo back-end conteinerizado. Ao mesmo tempo, o principal motivo da virtualização de contentores é a mobilidade e flexibilidade da estrutura, o que nos permite organizar a distribuição dos picos de carga por toda a infraestrutura à nossa disposição da forma mais eficiente possível. Ou seja, se não contentorizarmos e implementarmos todos os elementos existentes do sistema no cluster, estaremos cometendo um erro muito grave.
É muito mais lógico agrupar não apenas a aplicação em si, mas também os serviços responsáveis pelo armazenamento dos dados. Ao agrupar e implantar servidores web que funcionam de forma independente e distribuem a carga entre si no k8s, já estamos resolvendo o problema de sincronização de dados - os mesmos comentários nas postagens, se tomarmos como exemplo alguma mídia ou plataforma de blog. De qualquer forma, temos uma representação intra-cluster, mesmo virtual, do banco de dados como um ExternalService. A questão é que o banco de dados em si ainda não está agrupado - os servidores web implantados no cubo recebem informações sobre mudanças de nosso banco de dados de combate estático, que gira separadamente.
Você sente uma pegadinha? Usamos k8s ou Swarm para distribuir a carga e evitar travar o servidor web principal, mas não fazemos isso para o banco de dados. Mas se o banco de dados travar, toda a nossa infraestrutura em cluster não fará sentido - para que servem as páginas da Web vazias que retornam um erro de acesso ao banco de dados?
Por isso é necessário agrupar não só os servidores web, como normalmente se faz, mas também a infraestrutura de banco de dados. Só assim podemos garantir uma estrutura que funciona plenamente numa equipa, mas ao mesmo tempo independente umas das outras. Além disso, mesmo que metade de nosso back-end “entra em colapso” sob carga, o restante sobreviverá, e o sistema de sincronização de bancos de dados entre si dentro do cluster e a capacidade de escalar e implantar indefinidamente novos clusters ajudarão a atingir rapidamente a capacidade necessária - se ao menos houvesse racks no data center.
Além disso, o modelo de banco de dados distribuído em clusters permite levar esse mesmo banco de dados onde for necessário; Se estamos falando de um serviço global, então é bastante ilógico criar um cluster web em algum lugar na área de São Francisco e ao mesmo tempo enviar pacotes ao acessar um banco de dados na região de Moscou e vice-versa.
Além disso, a conteinerização do banco de dados permite construir todos os elementos do sistema no mesmo nível de abstração. O que, por sua vez, permite gerenciar esse mesmo sistema diretamente do código, pelos desenvolvedores, sem o envolvimento ativo dos administradores. Os desenvolvedores pensaram que era necessário um SGBD separado para o novo subprojeto - fácil! escrevi um arquivo yaml, carreguei-o no cluster e pronto.
E, claro, a operação interna é bastante simplificada. Diga-me, quantas vezes você fechou os olhos quando um novo membro da equipe colocou as mãos no banco de dados de combate para trabalhar? Qual, na verdade, é o único que você tem e está girando agora? Claro, somos todos adultos aqui, e em algum lugar temos um backup novo, e ainda mais longe - atrás da prateleira com pepinos e esquis velhos da vovó - outro backup, talvez até em um armazenamento refrigerado, porque seu escritório já pegou fogo uma vez. Mas, mesmo assim, cada 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 ao seu redor. Bem, quem o conhece, um novato, talvez ele esteja com as mãos cruzadas? É assustador, você concordará.
A conteinerização e, de fato, a topologia física distribuída do banco de dados do seu projeto ajudam a evitar esses momentos de validação. Não confie em um novato? OK! Vamos dar a ele seu próprio cluster para trabalhar e desconectar o banco de dados dos outros clusters - sincronização apenas por push manual e rotação síncrona de duas chaves (uma para o líder da equipe e outra para o administrador). E todo mundo está feliz.
E agora é hora de nos tornarmos oponentes do clustering de banco de dados.
Lado escuro
Argumentando por que não vale a pena contentorizar o banco de dados e continuar a executá-lo em um servidor central, não vamos nos rebaixar à retórica das ortodoxias e declarações como “os avôs administravam bancos de dados em hardware, e nós também!” Em vez disso, vamos tentar chegar a uma situação em que a conteinerização realmente pague dividendos tangíveis.
Concordo, os projetos que realmente precisam de uma base em um contêiner podem ser contados nos dedos de uma mão, mesmo que não seja o melhor operador de fresadora. Na maioria das vezes, até mesmo o uso do k8s ou do Docker Swarm em si é redundante - muitas vezes essas ferramentas são utilizadas devido ao hype geral das tecnologias e às atitudes do “todo-poderoso” na pessoa dos gêneros para empurrar tudo para o nuvens e contêineres. Bem, porque agora está na moda e todo mundo faz isso.
Em pelo menos metade dos casos, usar Kubernetis ou apenas Docker em um projeto é redundante. A questão é que nem todas as equipes ou empresas terceirizadas contratadas para manter a infraestrutura do cliente estão cientes disso. É pior quando os contêineres são impostos, pois custa uma certa quantidade de moedas ao cliente.
Em geral, existe uma opinião de que a máfia docker/cube está esmagando estupidamente os clientes que terceirizam essas questões de infraestrutura. Afinal, para trabalhar com clusters, precisamos de engenheiros que sejam capazes disso e que entendam de maneira geral a arquitetura da solução implementada. Certa vez, já descrevemos nosso caso com a publicação Republic - lá treinamos a equipe do cliente para trabalhar na realidade do Kubernetis e todos ficaram satisfeitos. E foi decente. Muitas vezes, os “implementadores” k8s tomam como refém a infraestrutura do cliente - porque agora só eles entendem como tudo funciona lá; não há especialistas do lado do cliente.
Agora imagine que desta forma terceirizamos não só a parte do servidor web, mas também a manutenção do banco de dados. Dissemos que o TB é o coração, e a perda do coração é fatal para qualquer organismo vivo. Em suma, as perspectivas não são as melhores. Portanto, em vez de exagerar no Kubernetis, muitos projetos simplesmente não deveriam se preocupar com a tarifa normal da AWS, que resolverá todos os problemas de carga em seu site/projeto. Mas a AWS não está mais na moda e as exibições valem mais do que dinheiro - infelizmente, também no ambiente de TI.
OK. Talvez o projeto realmente precise de clustering, mas se tudo estiver claro com aplicativos sem estado, como podemos organizar uma conectividade de rede decente para um banco de dados clusterizado?
Se estamos falando de uma solução de engenharia integrada, que é a transição para o k8s, então nossa principal dor de cabeça é a replicação de dados em um banco de dados clusterizado. Alguns SGBDs são inicialmente bastante fiéis à 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 SGBD para nosso projeto não é a capacidade de replicação com custos mínimos de recursos e engenharia. Principalmente se o projeto não foi inicialmente planejado como um microsserviço, mas simplesmente evoluiu nessa direção.
Achamos que não há necessidade de falar sobre a velocidade das unidades de rede - elas são lentas. Aqueles. Ainda não temos uma oportunidade real, se algo acontecer, de reiniciar uma instância do DBMS em algum lugar onde haja mais, por exemplo, potência do processador ou RAM livre. Veremos rapidamente o desempenho do subsistema de disco virtualizado. Conseqüentemente, o SGBD deve ser fixado em seu próprio conjunto pessoal de máquinas localizadas nas proximidades. Ou é necessário, de alguma forma, resfriar separadamente a sincronização de dados suficientemente rápida para as supostas reservas.
Continuando com o tópico dos sistemas de arquivos virtuais: os volumes do Docker, infelizmente, não estão isentos de problemas. Em geral, no que diz respeito ao armazenamento fiável de dados a longo prazo, gostaria de me contentar com os esquemas mais simples do ponto de vista técnico. E adicionar uma nova camada de abstração do FS do contêiner ao FS do host pai é um risco por si só. Mas quando a operação do sistema de suporte à conteinerização também encontra dificuldades na transmissão de dados entre essas camadas, então é realmente um desastre. Neste momento, a maioria dos problemas conhecidos pela humanidade progressista parecem ter sido erradicados. Mas você entende, quanto mais complexo o mecanismo, mais fácil ele quebra.
Diante de todas essas “aventuras”, é muito mais lucrativo e fácil manter o banco de dados em um só lugar, e mesmo que seja necessário conteinerizar a aplicação, deixá-la rodar sozinha e através do gateway de distribuição receber 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 ao mínimo a probabilidade de erros e dessincronização.
Para onde estamos levando? Além disso, a conteinerização de bancos de dados é apropriada quando há uma necessidade real. Você não pode preencher um banco de dados de aplicativo completo e girá-lo como se tivesse duas dúzias de microsserviços – não funciona dessa maneira. E isso deve ser claramente compreendido.
Em vez de saída
Se você está esperando uma conclusão clara “virtualizar o banco de dados ou não”, então iremos decepcioná-lo: não estará aqui. Porque na hora de criar qualquer solução de infraestrutura é preciso guiar-se não pela moda e pelo progresso, mas, antes de tudo, pelo bom senso.
Existem projetos para os quais os princípios e ferramentas que acompanham o Kubernetis se encaixam perfeitamente, e nesses projetos há paz pelo menos na área de backend. E há projetos que não precisam de conteinerização, mas de uma infraestrutura normal de servidores, porque fundamentalmente não podem ser redimensionados para o modelo de cluster de microsserviços, porque cairão.
Fonte: habr.com