paint-brush
Streaming revolucionário: Apache Pulsar apresenta escalonamento automáticopor@datastax
414 leituras
414 leituras

Streaming revolucionário: Apache Pulsar apresenta escalonamento automático

por DataStax9m2023/07/13
Read on Terminal Reader

Muito longo; Para ler

Temos o prazer de apresentar o Kubernetes Autoscaling para Apache Pulsar, ou KAAP. KAAP é um operador do Kubernetes que está disponível no OperatorHub.
featured image - Streaming revolucionário: Apache Pulsar apresenta escalonamento automático
DataStax HackerNoon profile picture
0-item
1-item
2-item

O Apache Pulsar sempre se viu como nativo da nuvem. Está lá na página inicial:


“Apache® Pulsar™ é uma plataforma de transmissão e mensagens distribuídas de código aberto construída para a nuvem”


O Pulsar certamente incorpora muitos princípios nativos da nuvem, incluindo a separação da computação do armazenamento, onde o corretor Pulsar lida com a entrega de mensagens e o Apache BookKeeper lida com o armazenamento delas, e a ideia de componentes sem estado que podem ser dimensionados para cima e para baixo à vontade. a corretora Pulsar.


No entanto, ele nunca realmente cumpriu a promessa final da nuvem: dimensionamento automático. Pelo menos, não até hoje.


Tenho o prazer de apresentar o Kubernetes Autoscaling para Apache Pulsar, ou KAAP. KAAP é um operador do Kubernetes que está disponível no OperatorHub. Ele inclui todas as sutilezas que você esperaria de um operador do Kubernetes. Depois de instalar o operador em seu cluster Kubernetes, você pode obter um cluster Pulsar totalmente funcional aplicando uma única definição de recurso personalizado (CRD) como esta:


 apiVersion: kaap.oss.datastax.com/v1alpha1 kind: PulsarCluster metadata: name: pulsar spec: global: name: pulsar image: 'apachepulsar/pulsar:3.0.0'


O Pulsar tem vários componentes: ZooKeeper, BookKeeper, corretores e proxies. O operador lida com a configuração de todos eles com o PulsarCluster CRD. Como o operador trabalha no nível do cluster, você não precisa se preocupar com a forma como os componentes funcionam juntos. A operadora cuida disso para você.


Upgrades automáticos em estágios

Tendo operado um serviço de nuvem de produção para a Pulsar por mais tempo do que qualquer um que eu conheça (primeiro em Kesque e agora com DataStax Astra Streaming), sei em primeira mão quanto tempo leva para fazer uma atualização adequada de um cluster Pulsar. Embora você possa atualizar todos os componentes pelo YOLO de uma só vez, o método recomendado e mais seguro é atualizar cada componente um de cada vez, garantindo que cada componente tenha sido atualizado com sucesso antes de passar para o próximo.


Este é o processo que seguimos ao atualizar os clusters Pulsar em nosso serviço Astra Streaming porque a disponibilidade de nosso atendimento ao cliente é fundamental, mas é muito demorado para nossa equipe de engenharia de produção. Na verdade, este é o pedido número um que eles têm: você pode tornar as atualizações mais inteligentes e automáticas? Bem, com o KAAP, fizemos exatamente isso.


Com uma única alteração de linha no PulsarCluster CRD, você pode acionar uma atualização em estágios do seu cluster Pulsar. O operador KAAP orquestrará uma atualização cuidadosa e gradual do seu cluster. Obviamente, você deve monitorar as métricas durante a atualização, mas pode deixar o operador do KAAP dirigir (sem dormir ao volante).


Escalonamento automático de código aberto

As atualizações automáticas em etapas são boas, mas não é isso que me deixa mais animado com o KAAP. O conceito de recursos elásticos é uma promessa fundamental da nuvem. É por isso que muitos dos serviços da AWS têm “elastic” em seu nome. Eu (na verdade, ChatGPT ) fiz uma pesquisa rápida e há pelo menos 10 deles.


A nuvem permite que você adquira e libere recursos sob demanda, para que você possa usar técnicas de escalonamento automático para corresponder ao número de recursos que seu aplicativo está usando com a carga nele. À medida que a carga aumenta, você pode adicionar automaticamente mais recursos. À medida que a carga diminui, você pode liberar recursos. Como os provedores de nuvem cobram pelo uso de recursos, o escalonamento automático pode ajudar você a fazer o uso mais eficiente de seus gastos com nuvem.


Tenho certeza de que todos podemos pensar em exemplos de serviços em nuvem que apresentam escalonamento automático nos bastidores. A maioria desses serviços “elásticos” da AWS funciona assim. No entanto, a implementação do escalonamento automático é proprietária, bloqueada no repositório privado de um fornecedor. Às vezes, eles falam sobre como implementaram o escalonamento automático, como neste papel sobre AWS DynamoDB, ou este postagem no blog sobre como o Confluent Cloud torna o Kafka elástico. Mas ninguém, que eu saiba, tornou sua implementação de escalonamento automático de código aberto, disponível gratuitamente para todos os usuários sob uma licença de código verdadeiramente aberto. Isso é exatamente o que estamos fazendo com o KAAP.


O KAAP adiciona recursos sofisticados de escalonamento automático ao seu Pulsar (ou Luna Streaming , nossa distribuição Pulsar) sob uma licença Apache 2.0. Você pode conferir em nosso Repositório GitHub . Se gostar, lembre-se de dar uma estrela.


Pulsar + dimensionamento automático: uma combinação perfeita

O KAAP oferece uma maneira de adicionar dimensionamento automático ao Pulsar ao executar no Kubernetes. Não é um simples horizontal Pod Autoscaler (HPA) anexado a uma implantação do Pulsar Broker, mas um sofisticado autoscaler que funciona com os componentes existentes nativos da nuvem do Pulsar para fornecer um sistema de mensagens e streaming verdadeiramente elástico. Na minha opinião, esta é uma combinação que não pode ser batida.


Escalonamento de corretor sem estado

Vamos dar uma olhada nas duas principais dimensões de escalonamento automático do KAAP. Primeiro, veremos os corretores da Pulsar. Como você deve saber, os corretores Pulsar não têm estado, o que significa que você pode escalá-los e reduzi-los facilmente, conforme necessário. Mas o que você talvez não saiba é que o Pulsar possui um mecanismo integrado de balanceamento de carga do broker que monitora continuamente a CPU, a memória e a largura de banda da rede em cada broker. Usando essas informações e um dos algoritmos de balanceamento de carga configuráveis, o Pulsar moverá tópicos de corretor para corretor para evitar que um corretor seja sobrecarregado.


Uma solução de dimensionamento automático ingênua seria configurar um Kubernetes Horizontal Pod Autoscaler (HPA) nos agentes e, quando alguma métrica como CPU ficar alta, escalar outro pod do agente. Mas isso pode não ser realmente necessário porque o balanceador de carga do corretor Pulsar pode decidir mudar os tópicos para equilibrar a carga ao mesmo tempo. Agora você escalou um pod de agente que não é necessário porque o balanceador de carga do Pulsar equilibrou as coisas. Portanto, agora o HPA decide reduzir o pod do novo broker, o que faz com que quaisquer novos tópicos criados nele sejam movidos para um broker existente. Como você pode imaginar, o balanceador de carga Pulsar e um HPA podem criar uma confusão de corretores subindo e descendo e os tópicos mudando de corretor para corretor.


O KAAP evita esse problema integrando-se diretamente com o balanceador de carga do Pulsar. O KAAP escala os agentes quando as métricas de todo o cluster do balanceador de carga do Pulsar sugerem que o cluster está próximo da capacidade, não quando um único pod do agente está ocupado. E ele só reduz um agente se o uso de todo o cluster cair abaixo de um limite configurado. O operador KAAP trabalha com o balanceador de carga do corretor Pulsar, não contra ele.


Aumentar e diminuir o armazenamento: Notável!

Dimensionar a camada de computação (ou serviço) do Pulsar é ótimo, mas não é suficiente para uma verdadeira implementação de dimensionamento automático. Claro, o número de mensagens (ou eventos) que precisam ser processadas pode variar ao longo do tempo, mas e quanto ao número de mensagens que precisam ser armazenadas? Provavelmente todos nós já tivemos que lidar com um acúmulo de mensagens devido a uma falha de um sistema downstream. À medida que a interrupção se arrasta, o armazenamento disponível no sistema de streaming começa a ficar baixo.


Este é um cenário em que a Pulsar e sua dependência do BookKeeper brilham. Para adicionar capacidade de armazenamento a um cluster Pulsar, basta adicionar um novo nó BookKeeper, carinhosamente chamado de “bookie”. Como o armazenamento do BookKeeper é baseado em segmentos de tópicos e não em tópicos inteiros, o novo agenciador de apostas está imediatamente disponível para aliviar a pressão sobre o armazenamento, com qualquer reequilíbrio penoso de tópicos ou qualquer outra intervenção operacional.


A KAAP pode, é claro, cuidar desse caso para você. Ele monitora constantemente o uso do disco dos nós do bookie e, se o armazenamento disponível estiver ficando baixo, ele escalará um novo nó do bookie. Isso não é tão notável (pelo menos para o Pulsar). É bastante simples adicionar uma nova réplica no Kubernetes, mesmo que seja com estado e suportada por volumes persistentes. Mas e quando a interrupção terminar e a lista de pendências for eliminada? Agora você está preso com um nó extra de bookie consumindo recursos que não são mais necessários?


Não com KAAP, você não é. Assim que o armazenamento do BookKeeper cair abaixo de um limite configurado, o operador KAAP orquestrará cuidadosamente a remoção do nó de bookie desnecessário. Ele faz isso de maneira muito segura, garantindo que nenhuma mensagem seja perdida e que o fator de replicação necessário seja mantido o tempo todo. Por exemplo, se você configurou o Pulsar para manter três cópias de cada mensagem (escrever e confirmar o quorum, ambos iguais a três), o KAAP interage com o BookKeeper para copiar as mensagens do bookie que está sendo reduzido para outros bookies, a fim de garantir que haja pelo menos três cópias da mensagem disponíveis. Assim que isso for concluído com sucesso, ele prosseguirá com a remoção do agenciador de apostas desnecessário.


Com o KAAP, você obtém o dimensionamento automático do armazenamento em seu cluster Pulsar para cima e para baixo, para que possa otimizar o uso de armazenamento em seu cluster e não ficar preso à capacidade ociosa após um infeliz incidente de produção. Eu não sei sobre você, mas eu acho que é bastante notável.


Ferramentas de conscientização e migração de zona

O KAAP pode fazer atualizações em estágios e um dimensionamento inteligente do seu cluster Pulsar. Mas há mais. Para operar um cluster altamente disponível em um provedor de nuvem, é importante levar em consideração as zonas de disponibilidade (AZ). Se você não distribuir seus componentes, especialmente o BookKeeper, pelas zonas de disponibilidade, não conseguirá sobreviver a uma falha de AZ e fornecer vários noves de disponibilidade.


Felizmente, o Pulsar possui excelentes recursos integrados, como reconhecimento de rack, para oferecer suporte a implantações de alta disponibilidade. A parte complicada é que, para configurá-lo corretamente, você precisa configurar o Kubernetes corretamente com reconhecimento de zona e também configurar o Pulsar. O operador KAAP oferece cobertura ao apresentar o conceito de conjuntos de recursos, que permitem agrupar componentes e dar a eles reconhecimento de rack. O operador KAAP aplicará automaticamente as configurações Kubernetes e Pulsar com base em sua configuração declarativa de conjuntos de recursos. Os conjuntos de recursos são flexíveis, permitindo que você ofereça suporte a uma variedade de opções de implantação do Pulsar.


E se você já estiver executando seu Pulsar usando um gráfico do Helm ou talvez apenas alguma mágica de manifesto do Kubernetes? O KAAP tem uma ferramenta de migração para te ajudar. Você pode apontar a ferramenta de migração para sua implantação Kubernetes Pulsar existente e ela gerará automaticamente uma configuração CRD correspondente que você pode usar para que o operador KAAP assuma a operação de seu cluster para você.


A Pilha KAAP

O operador KAAP tem muitos recursos excelentes, turbinando seu cluster Pulsar regular em uma máquina de escalonamento automático bem oleada e altamente disponível. Mas, como alguém que opera clusters Pulsar de produção há muito tempo, sei que há muitas outras considerações para criar um cluster Pulsar de produção, como gerenciamento, autenticação e monitoramento de certificados TLS.


É por isso que incluímos o que chamamos de pilha KAAP com o operador. É um gráfico abrangente do Helm que instala o operador KAAP juntamente com ferramentas de produção críticas, incluindo:

  • Gerente de certificado
  • Keycloak
  • Prometheus Stack (Grafana)
  • Dashboards do Pulsar Grafana


Essas são ferramentas indispensáveis ao executar nossos clusters Pulsar de produção e não queríamos deixá-lo na mão, então reunimos todas e as integramos em um pacote conveniente.


Por que usar o KAAP?

Então você já ouviu falar sobre todos os excelentes recursos do Kubernetes Autoscaling para Apache Pulsar. Você pode criar um cluster Pulsar inteiro com um único CRD. Você pode colocar suas atualizações no piloto automático e permitir que o operador KAAP execute atualizações seguras e graduadas. Você pode escalar automaticamente os corretores do Pulsar para cima e para baixo com base no balanceador de carga do Pulsar broker dizendo que os agentes estão ficando sobrecarregados, e você pode escalar os nós do BookKeeper para cima e para baixo (!) com segurança com base nos requisitos de armazenamento de seus clusters. Você pode configurar facilmente seu cluster para reconhecimento de zona de disponibilidade para alta disponibilidade. E ainda inclui uma ferramenta de migração para que você possa migrar facilmente de sua implantação antiga baseada em Helm para uma baseada em operador KAAP turbinado.


Então, muitos recursos excelentes, mas quais são os benefícios do KAAP? Eu posso pensar em vários:


  • Configure e opere facilmente clusters Pulsar altamente disponíveis em execução no Kubernetes, resultando em menos esforço para você e suas equipes de produção
  • Simplifique drasticamente o dimensionamento do Pulsar para corresponder às demandas em constante mudança, dimensionando automaticamente os recursos do cluster para corresponder à demanda
  • Reduza o custo total de propriedade de um cluster Pulsar eliminando o provisionamento para picos de carga ou superprovisionamento como resultado de incidentes de produção
  • Evite o bloqueio do fornecedor usando todas as tecnologias de código aberto


Na minha opinião, lançar o KAAP é um momento verdadeiramente inovador no espaço de streaming e mensagens. Nenhum outro projeto de código aberto combina o poder de streaming e mensagens do Apache Pulsar com a promessa final da computação em nuvem: dimensionamento totalmente elástico e automático. Estou ansioso para que você experimente. Entre nas Discussões do GitHub em nosso repositório e deixe-nos saber o que você pensa!


Descubra mais

Se você quiser se aprofundar tecnicamente no KAAP, dê uma olhada nesta postagem do blog . Você pode encontrar a documentação completa para KAAP aqui . E aqui é o repositório do GitHub.


Por Chris Bartholomew, DataStax


Esta história foi distribuída pela Datastax sob o programa Brand As An Author da HackerNoon. Saiba mais sobre o programa aqui: https://business.hackernoon.com/brand-as-author