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

O Serviço Gerenciado para Apache Kafka é um Google Cloud serviço que ajuda você a executar clusters seguros, 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 brokers, incluindo o armazenamento, é totalmente automatizado. Para acompanhar as demandas dos clientes, você pode monitorar a vCPU e a utilização de outros recursos e ajustá-los para cima ou para baixo.

Ao definir a contagem de vCPUs e o tamanho da RAM, o serviço automatiza o redimensionamento e o provisionamento de brokers. 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 brokers

Ao configurar a vCPU total e o tamanho da RAM do cluster, o serviço provisiona novos brokers e escalona os atuais. Para uma configuração de cluster típica, a vCPU total e o tamanho da RAM são divididos igualmente entre todos os brokers. Isso significa que contagens fracionárias de vCPU por broker são permitidas, 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 brokers são escalonados verticalmente até 15 vCPUs por broker. Depois que esse limite é atingido, o serviço cria novos brokers. 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 vCPU total ou pela capacidade de memória do cluster. A proporção de escalonamento é de 1 broker para cada 15 vCPUs ou 120 gibibytes (GiB) de recursos, o que resultar em um número maior de brokers. A proporção de vCPU para 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 cálculo a seguir determinará o número de brokers:

  • Calcule o número de brokers necessários para contabilizar as vCPUs: ceiling(70 vCPUs / 15 vCPUs) = 5 brokers

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

Nesse cenário, o cluster tem 5 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 tempo de retenção em tópicos individuais para controlar o custo ou atender às 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 SSD discos permanentes para cada vCPU para equilibrar performance, disponibilidade e custo. Você recebe a cobrança 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 arquivos de segmento nesses discos permanentes. Depois que um segmento é lançado, ele é movido para o armazenamento de objetos permanentes 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 de 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 brokers recém-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 reequilíbrio automático.

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

O algoritmo de reequilíbrio é baseado na contagem de partições. Ele 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 o cluster 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 bootstrap têm um balanceador de carga, então há um único URL de bootstrap por cluster. Os URLs são os mesmos em todas as VPCs para que as configurações do cliente possam ser 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 requer um endpoint do PSC. Os endpoints são provisionados automaticamente.

Clusters seguros

O serviço oferece os seguintes recursos para segurança dos clusters: autenticação, autorização, criptografia, aplicação de patches 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 oferece suporte a dois métodos de autenticação: camada de autenticação e segurança simples (SASL, na sigla em inglês) 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 aceitas como principais ao usar SASL.

O serviço não oferece suporte a 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 emprega uma abordagem em camadas para autorização. O IAM controla ações de gerenciamento de clusters, 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 Google Cloud vinculações de papéis do IAM 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 por ACLs do Kafka. Para mais informações, consulte Configurar a autenticação mTLS.

É possível gerenciar ACLs do Kafka com as Google Cloud ferramentas ou ferramentas de terceiros do Kafka. 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 pela 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.

Aplicação de patches

A equipe de serviço acompanha as vulnerabilidades de segurança descobertas no código aberto. Quando o serviço descobre vulnerabilidades, ele aplica patches aos 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 de 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 aceitos. O JSON não é aceito.

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 Google Cloud console, 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 pelo 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. Esses conectores permitem conectar clusters do Serviço Gerenciado para Apache Kafka a vários sistemas, incluindo outras implantações do Kafka e Google Cloud serviços como BigQuery, Cloud Storage e Pub/Sub. 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 brokers individuais.

Para isso, todos os clusters são provisionados em uma configuração de três zonas com reconhecimento de rack. A configuração de tópico padrão exige pelo menos três réplicas. O reconhecimento de rack 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 falha de software, hardware ou rede, ele é substituído automaticamente. Quando o serviço detecta uma falha de broker, ele é reiniciado automaticamente, em uma máquina diferente, se necessário. Depois que o broker fica disponível, o Apache Kafka o integra ao cluster. A falha completa da zona pode impossibilitar a criação de um novo broker. No entanto, o cluster continua operando enquanto as outras duas zonas permanecerem 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 administração, monitoramento e geração de 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 infraestrutura como código.
  • UI no Google Cloud console 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 script 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 de 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 Serviço Gerenciado para Apache Kafka são executados na versão 3.7.1 do Apache Kafka. O serviço aplica patches automaticamente a 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 contínua, 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 permanente e o custo da vCPU são mais caros com o Serviço Gerenciado para Apache Kafka em comparação com a configuração de um sistema semelhante. Por outro lado, 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á pode executar no seu ambiente. Não é necessário mudar o código do aplicativo para migrá-lo 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 zona única ou duas zonas não são aceitos.

  • 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 é aceito.

  • As APIs JMX para métricas não são aceitas.

  • Embora seja possível mudar as configurações de 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á uma programação definida ou uma maneira de acioná-las manualmente. Como resultado, não é possível controlar quando essas mudanças entram em vigor. Exemplos de configurações 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 de 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.