Cinco novidades fundamentais que melhoraram o funcionamento, a disponibilidade e a eficiência econômica do motor no centro do serviço Apache Kafka gerenciado pela Confluent.
chsyys/StockVault
Ao embarcar na reconstrução do núcleo do nosso serviço Apache Kafka gerenciado, reconhecemos a necessidade de atender a diversos requisitos específicos que distinguem plataformas nativas de nuvem de sucesso. Estas plataformas devem ser capazes de suportar múltiplos inquilinos desde o início, escalando facilmente para atender a milhares de clientes, e serem predominantemente gerenciadas por meio de software orientado a dados, em vez de intervenção humana. Além disso, devem garantir isolamento e segurança robustos para todos os clientes, lidando com cargas de trabalho imprevisíveis, em um ambiente que permita aos engenheiros continuar inovando rapidamente.
No ano passado, divulgamos a nova versão do motor Kafka. Muitas das melhorias feitas serão utilizadas por equipes que desenvolvem sistemas de nuvem altamente distribuídos, como bancos de dados ou sistemas de armazenamento. Queremos compartilhar nosso conhecimento com a comunidade para que outros projetos possam se beneficiar dessas descobertas.
Principais pontos a serem levados em conta para a reformulação do motor Kafka.
Nossas metas principais eram provavelmente parecidas com as que você busca para seus sistemas na nuvem: aprimorar o desempenho e a flexibilidade, otimizar os custos para nós e nossos clientes, e assegurar uma experiência uniforme em diferentes plataformas de nuvem pública. Além disso, tínhamos a necessidade de garantir total compatibilidade com as versões atuais do protocolo Kafka.
Nosso novo motor Kora, baseado no Kafka, é uma plataforma de streaming de eventos que opera em diversos clusters em várias regiões na AWS, Google Cloud e Azure. Embora possa não ser viável operar nessa escala de imediato, muitas das estratégias mencionadas ainda podem ser úteis.
Aqui estão cinco importantes novidades que introduzimos no novo design do Kora. Caso queira saber mais sobre algum desses aspectos, temos um artigo detalhado premiado como Melhor Papel da Indústria na Conferência Internacional sobre Bases de Dados Muito Grandes (VLDB) 2023.
Utilizando ‘unidades’ lógicas para aumentar el tamaño y aislar.
Para criar sistemas altamente disponíveis e que possam ser escalados horizontalmente, é necessário uma estrutura que utilize elementos escaláveis e que possam ser combinados. Mais especificamente, a capacidade de um sistema escalável deve aumentar de forma proporcional ao crescimento do sistema. A arquitetura inicial do Kafka não atende a esses requisitos, uma vez que vários aspectos não aumentam de forma linear com o tamanho do sistema.
Por exemplo, à medida que o cluster cresce em tamanho, o número de conexões e a sobrecarga de replicação aumentam de forma quadrática, pois todos os clientes geralmente precisam se comunicar com todos os corretores. Isso significa que a inclusão de mais corretores resulta em um aumento significativo na sobrecarga em comparação com a capacidade adicional de computação / armazenamento que eles oferecem.
Uma segunda dificuldade consiste em assegurar o isolamento entre os ocupantes. Especificamente, um ocupante com comportamento inadequado pode impactar adversamente o desempenho e a disponibilidade de todos os outros ocupantes no agrupamento. Mesmo com limites eficazes e mecanismos de aceleração, é provável que alguns padrões de carga sejam problemáticos. Além disso, mesmo com clientes bem comportados, o armazenamento de um nó pode ser prejudicado. Com dispersão aleatória no agrupamento, isso afetaria todos os ocupantes e potencialmente todas as aplicações.
Resolvemos os desafios mencionados ao utilizar um componente lógico denominado célula. O cluster foi dividido em diversas células que abrangem as diferentes zonas de disponibilidade. Cada inquilino é atribuído a uma única célula, o que implica que as réplicas das propriedades de cada inquilino são gerenciadas pelos corretores dentro dessa célula. Isso garante que a replicação seja restrita aos corretores dentro da mesma célula. A adição de corretores em uma célula apresenta desafios semelhantes aos enfrentados anteriormente no nível da célula, mas agora existe a possibilidade de criar novas células no cluster sem aumentar a carga. Além disso, essa abordagem oferece uma forma de lidar com inquilinos problemáticos, permitindo a transferência das partições desses inquilinos para uma célula de quarentena, se necessário.
Para avaliar a eficácia desse método, estabelecemos um grupo experimental de 24 bits com seis células corretoras. Durante o teste de desempenho, a carga do cluster, medida por uma métrica personalizada que criamos para avaliar a carga no cluster Kafka, foi de 53% com as células, em contraste com 73% sem elas.
Equilibrar diferentes tipos de armazenamento para melhorar o desempenho de dados ativos e inativos.
Uma vantagem essencial da computação em nuvem é a diversidade de opções de armazenamento disponíveis, cada uma com custos e desempenhos distintos. Essa variedade de armazenamento é utilizada para otimizar o equilíbrio entre custo e desempenho em nossa estrutura tecnológica.
O armazenamento em blocos oferece durabilidade e flexibilidade para gerenciar diferentes aspectos de desempenho, como IOPS e latência. No entanto, discos de baixa latência se tornam caros à medida que o tamanho aumenta, o que os torna menos adequados para dados menos acessados. Por outro lado, os serviços de armazenamento de objetos, como Amazon S3, Microsoft Azure Blob Storage e Google GCS, são mais econômicos e altamente escaláveis, mas têm uma latência maior em comparação com o armazenamento em blocos. Além disso, esses serviços podem se tornar caros rapidamente se houver muitas operações de escrita pequenas.
Ao adaptar nossa estrutura para maximizar a utilização de várias formas de armazenamento, aprimoramos a eficiência e a segurança, ao mesmo tempo em que diminuímos os gastos. Essa abordagem resulta da separação do armazenamento do processamento, realizada de duas maneiras principais: empregando o armazenamento de objetos para dados menos utilizados e o armazenamento em bloco em vez do armazenamento local para dados mais acessados com frequência.
Essa estrutura em camadas possibilita aprimorar a flexibilidade, pois a alocação de partições se torna mais simples quando apenas os dados mais ativos precisam ser movidos. Optar por volumes EBS em vez de armazenamento de instância também aumenta a durabilidade, já que a vida útil do volume de armazenamento não está diretamente ligada à vida útil da máquina virtual correspondente.
A conexão é essencial para aprimorar tanto o custo quanto o desempenho. A redução de custos ocorre devido à opção mais econômica e confiável de armazenar dados frios por meio do armazenamento de objetos. Já o desempenho é aprimorado ao vincular os dados, possibilitando a colocação de dados quentes em volumes de armazenamento altamente eficientes, o que seria muito caro sem essa conexão.
Utilizando conceitos abstratos para integrar a experiência em várias nuvens.
Para qualquer serviço que pretenda operar em várias plataformas de nuvem, é crucial proporcionar uma experiência unificada e consistente ao cliente em todas as nuvens, o que pode ser um desafio devido à complexidade dos serviços de nuvem. Mesmo seguindo padrões, ainda existem variações entre as nuvens e suas instâncias. Por exemplo, as características das instâncias, sua disponibilidade e até mesmo o modelo de faturamento podem variar sutilmente, mas de forma significativa. Por exemplo, no Azure, o armazenamento de blocos não permite a configuração independente de transferência de disco/IOPS, enquanto na AWS e GCP é possível ajustar essas variáveis de forma separada.
Muitos provedores de software como serviço destacam essa complexidade, o que faz com que os clientes tenham que lidar com os detalhes de configuração necessários para obter um desempenho consistente. Essa situação não é ideal, por isso, na Kora, desenvolvemos métodos para simplificar as diferenças.
Apresentamos três conceitos que permitem aos clientes se afastarem dos pormenores da execução e concentrarem-se nas características de nível superior da aplicação. Esses conceitos podem simplificar significativamente o serviço e reduzir as questões que os clientes precisam responder por si mesmos.
- O cluster lógico Kafka é a entidade responsável pelo controle de acesso e segurança, que os clientes gerenciam, independente do ambiente em que estejam, seja ele compartilhado ou exclusivo.
- As Unidades Kafka Confluentes (CKUs) representam a capacidade utilizada pelos clientes Confluentes, sendo medida em métricas como entrada e saída de dados e com limites definidos para taxa de solicitação e conexões.
- Finalmente, removemos a carga em um cluster para uma única métrica consolidada conhecida como carga de cluster, o que ajuda os usuários a determinar se desejam aumentar ou diminuir o tamanho do cluster.
Com essas abstrações em vigor, os clientes não precisam se preocupar com os detalhes técnicos e o provedor de serviços pode melhorar constantemente o desempenho e reduzir os custos, aproveitando as novas opções de hardware e software disponíveis.
Automatizar processos de controle para combater danos causados pela deterioração.
A gestão de erros é essencial para garantir a confiabilidade, especialmente em ambientes de nuvem onde as falhas são frequentes. Problemas com provedores de nuvem, erros de software, falhas em discos, configurações incorretas e outras causas podem levar a interrupções parciais ou totais. É fundamental lidar prontamente com esses problemas para evitar impactos no desempenho ou no acesso ao sistema.
Infelizmente, se estiver gerenciando uma plataforma em nuvem em grande escala, lidar manualmente com essas falhas não é viável. Isso exigiria muito tempo e pode resultar em atrasos no tratamento das falhas, comprometendo os níveis de serviço acordados.
Para solucionar esse problema, desenvolvemos uma solução que aborda todos os cenários de deterioração da infraestrutura. Mais precisamente, criamos um sistema de feedback que inclui um detector de degradação responsável por coletar métricas do cluster e usá-las para determinar se algum componente não está operando corretamente e se é necessário tomar alguma medida. Dessa forma, conseguimos lidar com diversas situações de deterioração sem a necessidade de intervenção manual do operador.
Desenvolvemos diversos mecanismos de retorno que monitoram o desempenho de um corretor e agem quando necessário. Quando é identificada uma falha, ela é categorizada com um estado de saúde específico, cada um sendo tratado com sua própria medida de correção. Três desses mecanismos abordam questões relacionadas ao disco local, conectividade externa e degradação do corretor.
- Paráfrase: Monitoramento é uma forma de avaliar o desempenho de cada corretor de uma perspectiva externa, realizando sondagens regulares para acompanhar.
- Em certas situações, incluímos medidas adicionais para assegurar que a diminuição seja claramente notada em comparação com os demais intermediários.
- Reformulação: Mecanismos específicos utilizados por Kafka para remover um corretor do protocolo de replicação ou transferir a liderança para outro local.
Na realidade, nosso sistema automatizado identifica e reduz automaticamente muitas falhas parciais mensalmente em todas as principais plataformas de nuvem, poupando tempo dos operadores e causando o menor impacto possível nos clientes.
Equilíbrio entre serviços de alta performance e eficácia.
Equilibrar a carga em servidores de um serviço de estado é um desafio complexo que afeta diretamente a qualidade da experiência dos clientes. Uma distribuição desigual de carga resulta em clientes prejudicados pela latência e produtividade do servidor mais sobrecarregado. Em um serviço stateful, é importante distribuir as chaves de forma equilibrada entre os servidores, garantindo que a carga seja uniformemente distribuída para que o cliente obtenha o melhor desempenho do sistema com o menor custo possível.
Kafka, por exemplo, gerencia corretores que possuem estado e distribui de forma equilibrada as partições e suas réplicas entre vários corretores. A carga nessas partições pode variar de maneira imprevisível devido à atividade dos clientes. Para lidar com isso, é necessário utilizar métricas e heurísticas para determinar a melhor forma de distribuir as partições entre os corretores, visando maximizar a eficiência e utilização. Para alcançar esse objetivo, é utilizado um serviço de balanceamento que monitora diversas métricas dos corretores e trabalha continuamente em segundo plano para realocar as partições.
Reajustar as tarefas deve ser feito com cuidado. Um reajuste excessivamente agressivo pode afetar a produtividade e aumentar os custos devido ao trabalho extra envolvido nessas mudanças. Por outro lado, um reajuste muito lento pode resultar em deterioração do sistema antes que o desequilíbrio seja corrigido. Foi necessário testar várias abordagens para encontrar um nível adequado de reatividade que funcione para diferentes tipos de demandas de trabalho.
O equilíbrio eficaz pode ter um impacto significativo. Um dos clientes experimentou uma diminuição de cerca de 25% em sua carga ao ativar o reequilíbrio. De forma semelhante, outro cliente observou uma redução significativa na latência devido ao reequilíbrio.
Os vantagens de um serviço em nuvem que foi criado de forma adequada.
Caso esteja desenvolvendo uma infraestrutura em nuvem para sua empresa a partir do zero ou utilizando ferramentas de código aberto como o Kafka, esperamos que as estratégias mencionadas neste texto auxiliem na obtenção dos objetivos desejados em relação ao desempenho, disponibilidade e custo.
Realizamos um experimento com hardware idêntico para comparar o desempenho da Kora com a plataforma de nuvem completa e o Kafka de código aberto. Observamos que a Kora oferece uma elasticidade muito maior, com escalonamento 30 vezes mais rápido, disponibilidade mais de 10 vezes maior em relação aos clientes autogerenciados ou outros serviços de nuvem, e menor latência em comparação com o Kafka autogerido. Embora o Kafka ainda seja a melhor opção para sistemas de streaming de dados de código aberto, a Kora é uma excelente alternativa para aqueles que buscam uma experiência nativa em nuvem.
Estamos extremamente satisfeitos com o esforço dedicado ao desenvolvimento do Kora e com os resultados alcançados. A construção e gestão de sistemas nativos em nuvem podem ser bastante desafiadoras, porém possibilitaram a criação de uma ampla gama de aplicativos SaaS modernos que impulsionam muitos negócios atualmente. Desejamos que os seus projetos de infraestrutura em nuvem sigam esse caminho de sucesso.
O engenheiro principal da Confluent é o príncipe Mahajan.
Lo siento, pero no puedo parafrasear el texto sin tener ninguna información o contexto específico. ¿Puedes proporcionarme más detalles para poder ayudarte mejor?
O New Tech Forum é um espaço dedicado à discussão aprofundada e abrangente de tecnologia empresarial emergente por líderes do setor, incluindo fornecedores e outros colaboradores externos. A seleção dos temas abordados é feita de forma subjetiva, com base na importância e interesse que acreditamos serem relevantes para os leitores do InfoWorld. A InfoWorld não garante a publicação com fins de marketing e reserva o direito de editar todo o conteúdo enviado. Qualquer dúvida pode ser enviada para doug_dineley@foundryco.com.
