Banco de dados nativo do Kubernetes: TiDB vs. Data Stax Astra DB

A look at two databases that have made claims to the Kubernetes native label: TiDB and DataStax Astra DB.

A revolução da computação em nuvem inspirou e se beneficiou de várias tendências inter-relacionadas. A disponibilidade de infraestrutura de nuvem pública de autoatendimento ajudou a impulsionar a adoção de arquiteturas de microsserviços e práticas de DevOps, incluindo automação e observabilidade.

O impulso para a conteinerização e a orquestração de contêineres levou à adoção generalizada do Kubernetes como um ambiente para gerenciar aplicativos nativos da nuvem.

Mas uma das áreas atrasadas nessa revolução são os dados e a infraestrutura de dados. Por muito tempo, os dados foram algo que viveu fora do Kubernetes, levando a muito esforço extra e complexidade para os desenvolvedores na implantação de aplicativos nativos da nuvem.

Um axioma frequentemente repetido nos primeiros anos do Kubernetes era que ele ainda não estava pronto para cargas de trabalho com estado. Felizmente, uma grande mudança está em andamento e atingiu um ponto de maturidade.

A transformação aconteceu lentamente inicialmente, começando com esforços para contentorizar os bancos de dados existentes. Isso funcionou relativamente bem em pequenos bancos de dados executados em um único nó de computação ou bancos de dados projetados em um mundo nativo da nuvem, como Apache Cassandra e DynamoDB, mas os desafios permaneceram.

Nos últimos dois a três anos, surgiu uma nova geração de bancos de dados. Esses bancos de dados “nativos do Kubernetes” foram projetados desde o início para serem executados nesse sistema de orquestração de código aberto.

Aqui, definiremos as qualidades que tornam um banco de dados nativo do Kubernetes e os benefícios de adotar um banco de dados nativo do Kubernetes. Para fazer isso, veremos dois bancos de dados que reivindicam o rótulo nativo do Kubernetes: TiDB e DataStax Astra DB.

MySQL nativo do Kubernetes com TiDB

Primeiro, vamos examinar um banco de dados com ênfase relacional: TiDB (abreviação de Titanium Database). O TiDB é um sistema de código aberto desenvolvido pela PingCAP que fornece um banco de dados compatível com MySQL e um banco de dados colunar para suportar processamento transacional e analítico híbrido (conhecido como HTAP, para abreviar).

Conforme mostrado na Figura 1 abaixo, o TiDB tem um design de microsserviço. A camada de consulta TiDB, bancos de dados TiKV MySQL, bancos de dados colunares TiFlash, nós Spark e gerenciamento de metadados são implantados como microsserviços escaláveis em seus clusters. Esse design separa o trabalho intensivo de computação do trabalho intensivo de armazenamento, pois as camadas de consulta e banco de dados são escalonáveis de forma independente.

Um compromisso crítico que os criadores do TiDB assumiram foi que o banco de dados só roda no Kubernetes.

Isso é suficiente para torná-lo nativo do Kubernetes?

Vamos cavar um pouco mais fundo.

Primeiro, o TiDB é implantado e gerenciado por um operador do Kubernetes usando recursos personalizados (CRDs). Os CRDs do TiDB incluem o TiDBCluster, que permite especificar o dimensionamento e a configuração de cada microsserviço e como os componentes da camada de banco de dados usam o armazenamento por meio dos volumes persistentes do Kubernetes. CRDs adicionais são usados para implantar ferramentas de monitoramento e gerenciar tarefas operacionais como backup e restauração.

O TiDB também possui uma extensão de agendador opcional que faz interface com o agendador K8s padrão para tomar decisões de agendamento mais conscientes do aplicativo. Essa ênfase no uso dos recursos existentes do Kubernetes, quando disponíveis, é a marca de um banco de dados nativo do Kubernetes.

Kubernetes Native Cassandra com DataStax Astra DB

Agora, observe outro banco de dados nativo do Kubernetes e observe algumas semelhanças e diferenças.

O Cassandra é um banco de dados NoSQL altamente escalável que foi um dos primeiros a afirmar ser nativo da nuvem, mas como é implantar o Cassandra no Kubernetes?

O DataStax Astra DB é uma versão do Cassandra que foi fatorada em microsserviços, conforme mostrado na Figura 2.

Assim como o TiDB, o banco de dados inclui microsserviços relacionados ao processamento de consultas e armazenamento de dados, bem como serviços para controle de identidade e acesso, reparo de dados e backup/restauração.

Os serviços de dados são particularmente interessantes em seu uso de armazenamento , com Volumes Persistentes do Kubernetes usados apenas para armazenamento em cache e armazenamento de objetos usado para persistência de longo prazo. Separar a compactação em seu serviço permite que esse processamento intensivo de computação ocorra em segundo plano sem afetar o desempenho dos serviços de dados que atendem ao tráfego de leitura e gravação.

O Astra DB é oferecido como um serviço gerenciado disponível em várias regiões de nuvem. Cada região contém um plano de dados composto pelos serviços mencionados acima, gerenciados por um operador Kubernetes, bem como serviços de infraestrutura, incluindo a pilha Kube-Promethus para observabilidade e etcd para gerenciamento de metadados.

Os planos de dados são gerenciados por um plano de controle que pode ser executado em uma ou mais nuvens para gerenciar contas e bancos de dados de clientes e provisionar clusters Kubernetes em novas regiões.

Um aspecto inovador do Astra DB é sua arquitetura multilocatária, na qual vários bancos de dados de usuários podem compartilhar os mesmos microsserviços e infraestrutura de suporte, diminuindo a economia de unidade para usuários de menor escala.

À medida que os usuários aumentam seus aplicativos, eles podem migrar para recursos dedicados para obter o desempenho ideal em escala, tudo com base no “ pagamento conforme o uso ”.

Princípios do banco de dados nativo do Kubernetes

Com base em nossas observações de TiDB e Astra DB, podemos obter algumas ideias sobre o que torna um banco de dados Kubernetes nativo. Muitos deles correspondem a uma lista de princípios para dados nativos da nuvem, que descrevi em um artigo anterior :

• Arquitetura de microsserviços combináveis: primeiro, um banco de dados dividido em microsserviços constituintes permite que cada serviço seja dimensionado de forma independente. Alguns tipos de processamento intensivo de computação podem até ser dimensionados para zero para uma verdadeira solução sem servidor, especialmente quando combinados com um design multitenant.
• Trate a computação, a rede e o armazenamento como mercadorias: os microsserviços compostos de um banco de dados nativo do Kubernetes devem fazer uso máximo das APIs do Kubernetes para gerenciar os recursos fundamentais dos aplicativos nativos da nuvem: recursos de computação, como StatefulSets e implantações para gerenciar cargas de trabalho, o subsistema Persistent Volume para armazenamento , entrada e serviços do Kubernetes para expor o acesso à rede aos dados e muito mais. Isso inclui aproveitar os recursos já presentes no Kubernetes, como etcd para gerenciamento de metadados, em vez de trazer componentes com funcionalidade duplicada.
• Aproveite as melhores práticas do Kubernetes: seguir padrões comuns para aplicativos Kubernetes trará vários benefícios operacionais, por exemplo, expor verificações de vivacidade e prontidão em cada microsserviço para ajudar na disponibilidade e expor métricas por meio da API Prometheus PromQL para observabilidade . Por padrão, o próprio Kubernetes define um ótimo exemplo que os bancos de dados devem seguir para saber como ser seguro: usando Kubernetes Secrets para distribuir credenciais de segurança, expondo apenas as portas conforme necessário e assim por diante.
• Gerenciamento declarativo por meio de operadores: um banco de dados nativo do Kubernetes deve incorporar os princípios do Kubernetes de gerenciamento declarativo por meio de operadores e recursos personalizados, em vez de depender de UIs e CLIs de gerenciamento de banco de dados herdado. Quando necessário, os pontos de extensão do Kubernetes, como extensões do agendador, podem ser usados para adicionar comportamento específico do aplicativo . O objetivo é uma separação clara da funcionalidade do plano de dados (gerenciamento de dados) da funcionalidade do plano de controle (gerenciamento do banco de dados).

Bancos de dados e outras infraestruturas de dados que adotam fielmente esses princípios trarão benefícios, incluindo alto desempenho para custo ideal em todas as escalas , menor complexidade operacional resultando em menor tempo de lançamento no mercado e soluções em conformidade com os padrões que atendem às demandas atuais de alta disponibilidade e segurança.

O futuro da infraestrutura de dados nativa do Kubernetes

Ainda há muito progresso a ser feito e não se limita apenas aos bancos de dados. Os princípios nativos do Kubernetes podem ser aplicados a outros tipos de infraestrutura de dados, incluindo streaming, análise e aprendizado de máquina.

As soluções nativas do Kubernetes continuarão avançando em implantações multicluster e multinuvem para escalar globalmente e adotarão princípios de multilocação e sem servidor para melhor otimização de custos.

O próprio Kubernetes tem espaço para melhorias ao adicionar mais flexibilidade aos StatefulSets e suporte para federação de vários clusters.

A chave para o progresso contínuo é a colaboração aberta. A comunidade Data on Kubernetes é um grupo altamente ativo de geeks de dados que reúne criadores de aplicativos com uso intensivo de dados e a infraestrutura que os suporta.

Junte-se a nós para falar sobre ideias como desenvolver operadores reutilizáveis que podem gerenciar vários bancos de dados ou definir um conjunto comum de CRDs para conceitos como backup/restauração e carregamento de dados. Juntos, continuaremos expandindo o horizonte da computação em nuvem para o benefício de todos.

Saiba mais sobre os bancos de dados nativos do Kassandra e muito mais no encontro digital Cassandra Forward em 14 de março de 2023.

Este artigo é baseado no Capítulo 7, “The Kubernetes Native Database,” do livro O'Reilly “ Managing Cloud Native Data on Kubernetes ” de Jeff Carpenter e Patrick McFadin.

[

Por Jeff Carpenter, DataStax

Jeff Carpenter trabalhou como engenheiro e arquiteto de software em vários setores e como defensor do desenvolvedor na DataStax, ajudando os engenheiros a obter sucesso com o Apache Cassandra. Ele está envolvido em vários projetos de código aberto nos ecossistemas Cassandra e Kubernetes, incluindo Stargate e K8ssandra. Ele é coautor dos livros da O'Reilly "Cassandra: The Definitive Guide" e "Managing Cloud Native Data on Kubernetes".