Visão geral do Serviço gerenciado para Apache Kafka

O Managed Service para Apache Kafka é um serviço Google Cloud que ajuda a executar clusters seguros e escalonáveis do Apache Kafka de código aberto. Esta página é uma visão geral do que o serviço automatiza e simplifica para você. Para mais informações sobre o Apache Kafka, consulte o site do Apache Kafka.

Dimensionamento e escalonamento simples

Para dimensionar ou escalonar um cluster do Serviço gerenciado para Apache Kafka, basta definir a contagem total de vCPUs e o tamanho da RAM do cluster. O gerenciamento de corretores, incluindo armazenamento, é totalmente automatizado. Para acompanhar as demandas dos clientes, monitore o uso de vCPU e outros recursos e ajuste-os para mais ou para menos.

Quando você define a contagem de vCPUs e o tamanho da RAM, o serviço automatiza o redimensionamento e o provisionamento de agentes. Se o aumento do tamanho do cluster exigir um novo broker, o serviço poderá reequilibrar automaticamente as partições entre os brokers.

Provisionamento de agentes

Quando você configura o tamanho total de vCPU e RAM para o cluster, o serviço provisiona novos corretores e escalona os atuais. Em uma configuração de cluster típica, o tamanho total da vCPU e da RAM é dividido igualmente entre todos os brokers. Isso significa que são permitidas contagens fracionárias de vCPU por broker, embora seja necessário um mínimo de uma vCPU por broker. Todos os clusters são distribuídos em três zonas. Isso significa que é necessário um mínimo de 3 vCPUs e 3 GiB de RAM por cluster.

À medida que você aumenta o tamanho do cluster, os agentes são escalonados verticalmente até 15 vCPUs por agente. Depois que esse limite é atingido, o serviço cria novos corretores. Quando você diminui o tamanho do cluster, os brokers atuais são reduzidos para uma única vCPU, mas não são excluídos.

O tamanho máximo do broker pode mudar a qualquer momento. Esse limite foi escolhido para manter o escalonamento linear da capacidade de processamento do broker com a contagem de vCPUs.

Algoritmo de escalonamento

O número de brokers é determinado pela capacidade total de vCPU ou memória do cluster. A proporção de escalonamento é de um broker para cada 15 vCPUs ou 120 gibibytes (GiB) de recursos, o que resultar em um número maior de brokers. A proporção vCPU:memória (vCPU:GiB) precisa ficar entre 1:1 e 1:8. Os brokers são distribuídos igualmente entre as três zonas, com uma diferença máxima de um.

Por exemplo, se você configurar um cluster com 70 vCPUs e 130 GiB de RAM, além de um fator de replicação de 3, o seguinte cálculo vai determinar o número de brokers:

Calcule o número de brokers necessários para vCPUs: ceiling(70 vCPUs / 15 vCPUs) = 5 brokers
Calcule o número de brokers necessários para a memória: ceiling(130 GiB / 120 GiB) = 2 brokers

Nesse cenário, o cluster tem cinco brokers porque o número de brokers é determinado pelo número de vCPUs. Duas das três zonas têm dois brokers atribuídos a elas, e a última zona tem um broker.

Gerenciamento de armazenamento

O gerenciamento de armazenamento é automatizado. Na maioria das situações, você é responsável por definir o período de retenção em tópicos individuais para controlar o custo ou atender às suas políticas de retenção de dados. Não é necessário provisionar e gerenciar discos permanentes.

O serviço depende do armazenamento em camadas (KIP-405). O armazenamento em camadas combina volumes de disco permanente pré-provisionados anexados a brokers com armazenamento de objetos praticamente ilimitado.

O serviço aloca pelo menos 100 GiB de discos permanentes SSD para cada vCPU, equilibrando desempenho, disponibilidade e custo. Você recebe uma fatura de 100 GiB por vCPU, embora o tamanho real do disco por broker possa exceder esse valor. O tamanho do disco por broker nunca é reduzido, mesmo que o cluster seja reduzido.

Cada líder de partição armazena mensagens em buffer em arquivos de segmento nesses discos permanentes. Depois que um segmento é lançado, ele é movido para o armazenamento de objetos persistentes com suporte do Cloud Storage regional. O tamanho desses arquivos de segmento é definido pelas configurações log.roll.ms e log.segment.bytes.

Embora esses detalhes sejam úteis para entender, o armazenamento é gerenciado pelo serviço. As configurações específicas, como a quantidade de capacidade do disco permanente por vCPU, são detalhes de implementação que podem mudar. Você não tem acesso direto aos buckets do Cloud Storage usados para armazenamento permanente.

Reequilíbrio

Para que os novos brokers provisionados sejam úteis na manutenção da performance, parte do tráfego dos brokers atuais precisa ser movida para essas novas máquinas. Para facilitar isso, ative o rebalanceamento automático.

Com o rebalanceamento automático ativado, quando um novo agente é provisionado, o serviço reequilibra automaticamente as partições dos agentes atuais. O modelo de armazenamento em camadas verifica se uma quantidade relativamente pequena de dados precisa ser copiada para novos brokers, acelerando o rebalanceamento.

O algoritmo de rebalanceamento é baseado na contagem de partições. Ela não considera o tráfego real veiculado por cada partição.

Rede flexível

O serviço torna um cluster acessível de qualquer VPC com segurança. Isso inclui acesso de várias VPCs, projetos e regiões.

Para configurar a rede de um cluster, forneça o conjunto de sub-redes em que ele está acessível. O serviço provisiona endereços IP particulares para os servidores bootstrap e brokers em cada sub-rede. Ele também configura o Cloud DNS particular com URLs para cada endereço IP. Os servidores de inicialização têm um balanceador de carga, então há um único URL de inicialização por cluster. Os URLs são os mesmos em todas as VPCs, para que as configurações do cliente sejam consistentes em todos os ambientes.

Esse nível de flexibilidade é alcançado graças ao Private Service Connect (PSC). Cada endereço IP alocado para um cluster exige um endpoint do PSC. Os endpoints são provisionados automaticamente.

Clusters seguros

O serviço oferece os seguintes recursos para a segurança dos clusters: autenticação, autorização, criptografia, aplicação de patch e isolamento de recursos. Ele também não permite conexões e armazenamento não autenticados e não criptografados.

Autenticação

O serviço é compatível com dois métodos de autenticação: camada simples de autenticação e segurança (SASL) e TLS mútuo (mTLS). A autenticação mTLS está disponível em clusters criados após 24 de junho de 2025. Todas as conexões com clusters gerenciados são autenticadas com um principal que é uma identidade do IAM usando SASL ou um certificado de cliente usando mTLS. Contas humanas, de serviço e federadas são compatíveis como principais ao usar o SASL.

O serviço não é compatível com outros protocolos, incluindo SASL/GSSAPI, SASL/SCRAM-SHA-256 e SASL/SCRAM-SHA-512. O serviço também não permite conexões não autenticadas.

Autorização

O serviço usa uma abordagem em camadas para autorização. O IAM controla ações de gerenciamento de cluster, como criar, atualizar e excluir recursos. A autorização para principais autenticados depende do método usado:

SASL: os principais que usam o IAM são autorizados por associações de papéis do IAMGoogle Cloud ou com ACLs do Kafka no cluster. Para mais informações, consulte Configurar a autenticação SASL.
mTLS: os principais que fazem a autenticação com mTLS são autorizados pelas ACLs do Kafka. Para mais informações, consulte Configurar a autenticação mTLS.

É possível gerenciar ACLs do Kafka com as ferramentas Google Cloud ou de terceiros. Para mais informações sobre como configurar o IAM e as ACLs do Kafka, consulte Controle de acesso com o IAM e as ACLs do Kafka.

Criptografia

A criptografia é obrigatória. Todas as conexões com clusters precisam usar TLS. Os certificados TLS apresentados pelos brokers são assinados pelo Public Certificate Authority. Os dados armazenados são sempre criptografados. Escolha se quer usar chaves de criptografia gerenciadas pelo Google ou pelo cliente (CMEK) para criptografia em repouso.

Patch

A equipe de serviços rastreia as vulnerabilidades de segurança descobertas no código de código aberto. Quando o serviço descobre vulnerabilidades, ele corrige seus clusters automaticamente.

Isolamento de recursos

Outro recurso de segurança do serviço é o isolamento de recursos. O serviço gerenciado implanta clusters em projetos de locatário em uma VPC particular inacessível por endereços IP públicos. Cada um dos seus projetos tem um projeto de locatário dedicado, com uma conta de agente de serviço dedicada. Isso ajuda a limitar o escopo do acesso concedido ao serviço.

Registro de esquema

Para simplificar a coordenação entre produtores e consumidores, o Serviço Gerenciado para Apache Kafka inclui uma API de registro de esquema. Um registro fornecido pelo serviço atua como um repositório de esquemas compartilhados entre aplicativos.

O serviço implementa a API REST do Confluent Schema Registry que ajuda na integração com aplicativos Kafka atuais. Os formatos de esquema Apache Avro e Protocol Buffer (Protobuf) são compatíveis. JSON não é compatível.

O Serviço gerenciado para Apache Kafka também oferece uma API administrativa e um conjunto de ferramentas para gerenciar registros e esquemas. O conjunto de ferramentas inclui o console do Google Cloud , a CLI gcloud e as bibliotecas de cliente.

Para mais informações sobre o registro de esquema, consulte a Visão geral do registro de esquema.

Integração de dados com o Kafka Connect

O Serviço Gerenciado para Apache Kafka simplifica a integração de dados com o Kafka Connect. O Kafka Connect oferece vários plug-ins de conector integrados hospedados em clusters do Connect. Esses conectores são usados para migração, backup, recuperação de desastres, alta disponibilidade e integração de dados. Com eles, é possível conectar seus clusters do Serviço Gerenciado para Apache Kafka a vários sistemas, incluindo outras implantações do Kafka e serviços do Google Cloud, como BigQuery, Cloud Storage e Pub/Sub. Google Cloud O Kafka Connect oferece integração de dados escalonável e confiável com menor sobrecarga operacional e monitoramento e geração de registros integrados.

Para saber mais sobre o Kafka Connect, consulte a Visão geral do Kafka Connect.

Clusters de alta disponibilidade

O objetivo do serviço é fornecer clusters regionais para aplicativos essenciais. Especificamente, o serviço protege você contra falhas de zonas ou corretores individuais.

Para isso, todos os clusters são provisionados em uma configuração de três zonas compatível com racks. A configuração de tópico padrão exige pelo menos três réplicas. A capacidade de reconhecimento de racks garante que as réplicas sejam criadas em zonas diferentes. O número mínimo padrão de réplicas sincronizadas é dois. Isso significa que o cluster pode tolerar a perda completa de uma zona ou de um broker.

Quando um broker falha devido a uma falha de software, hardware ou rede, ele é substituído automaticamente. Quando o serviço detecta uma falha no broker, ele o reinicia automaticamente, em uma máquina diferente, se necessário. Depois que o agente estiver disponível, o Apache Kafka o integrará ao cluster. Uma falha completa na zona pode impossibilitar a criação de um novo broker. No entanto, o cluster continua operando enquanto as outras duas zonas permanecem disponíveis.

Além desses recursos específicos, uma lista crescente de ferramentas e processos internos mantém proativamente a integridade do serviço, do código do Apache Kafka e das atualizações. Os backups de dados e metadados são mantidos em vários níveis, permitindo que o serviço se recupere de muitos erros humanos e falhas de software.

O serviço não oferece proteção contra falhas regionais ou de duas zonas. Para aplicativos que exigem esse nível de proteção, recomendamos executar dois clusters regionais separados. É possível sincronizar os dados entre dois clusters usando ferramentas como o MirrorMaker 2.0 do Kafka Connect.

Ferramentas para seu estilo de administração

O serviço tem como objetivo oferecer um conjunto completo de ferramentas para seu estilo de gerenciamento e solução de problemas de cluster. Isso inclui ferramentas para administrar, monitorar e gerar registros.

O serviço gerenciado para Apache Kafka é exposto como uma API do Google Cloud. Isso significa que você pode gerenciar clusters e recursos de cluster usando APIs REST e gRPC. Vários clientes e interfaces são fornecidos para essas APIs, incluindo

Provedores do Terraform, se você preferir a abordagem de infraestrutura como código.
UI console Google Cloud para trabalho interativo em um navegador.
A CLI gcloud para trabalho interativo em um shell.
Bibliotecas de cliente em Java, Python, Go e outras linguagens para desenvolvimento e programação de scripts personalizados.

Para monitoramento e solução de problemas, o serviço exporta métricas para o Cloud Monitoring. Algumas das métricas estão disponíveis na UI do serviço. Um conjunto completo está disponível no Cloud Monitoring para trabalho interativo, configuração de alertas e exportação para outros sistemas.

O serviço também exporta registros do broker para o Cloud Logging. Eles podem ser pesquisados e usados para criar métricas e alertas com base em registros.

Upgrades e patches

Os clusters do Managed Service para Apache Kafka são executados na versão 3.7.1 do Apache Kafka. O serviço corrige automaticamente vulnerabilidades de segurança críticas.

As atualizações da infraestrutura subjacente, incluindo o sistema operacional e as camadas de orquestração, são contínuas e automáticas. Os brokers são atualizados com uma reinicialização gradual, sem tempo de inatividade para o cluster.

O serviço não atualiza automaticamente o código do Apache Kafka em execução nos brokers para novas versões secundárias.

Custo transparente

O modelo de preços do Serviço gerenciado para Apache Kafka é semelhante às cobranças que você vê ao executar o Apache Kafka por conta própria no Compute Engine. Você paga pelos recursos provisionados (vCPU, RAM e armazenamento local) e consumidos (armazenamento permanente e transferência de dados). O armazenamento persistente e o custo de vCPU são maiores com o Serviço Gerenciado para Apache Kafka em comparação com a configuração de um sistema semelhante por conta própria. Em contraste, os preços de transferência de dados e armazenamento local são semelhantes entre o Serviço Gerenciado para Apache Kafka e o Kafka autogerenciado. Para mais informações sobre preços, consulte Preços do serviço gerenciado para Apache Kafka.

Compatível porque executamos o Apache Kafka

Por fim, o Serviço gerenciado para Apache Kafka executa o mesmo software de código aberto que você já usa no seu ambiente. Não é necessário mudar o código do aplicativo para migrar para o serviço.

Limitações

O Serviço Gerenciado para Apache Kafka tem as seguintes limitações:

Cada cluster precisa ter recursos iguais em cada uma das três zonas. Clusters do Serviço Gerenciado para Apache Kafka de uma ou duas zonas não são compatíveis.
Não é possível escolher as zonas ao criar o cluster.
Não é possível configurar o volume de armazenamento local em um cluster.
O Serviço gerenciado para Apache Kafka é executado no modo KRaft. O modo Zookeeper não é compatível.
As APIs JMX para métricas não são compatíveis.
A compactação de temas com zstd não é compatível. Os valores aceitos para compression.type incluem lz4, gzip, snappy e uncompressed.
Embora seja possível mudar as configurações do broker com o modo de atualização read-only a qualquer momento, essas mudanças só entram em vigor quando os brokers são reiniciados. As reinicializações acontecem periodicamente como parte dos processos de manutenção e upgrade do Google, mas não há um cronograma definido nem uma maneira de acioná-las manualmente. Por isso, não é possível controlar quando essas mudanças entram em vigor. Exemplos de configurações de read-only incluem auto.create.topics.enable e background.threads. As atualizações de configurações com o modo de atualização cluster-wide, como message.max.bytes, não exigem reinicializações e entram em vigor imediatamente.
Alguns parâmetros de configuração do broker são gerenciados pelo serviço e não podem ser atualizados. Isso inclui broker.id e configurações relacionadas ao armazenamento, como remote.log.storage.system.enable.

A seguir

Apache Kafka® é uma marca registrada da The Apache Software Foundation ou afiliadas nos Estados Unidos e/ou em outros países.