Este documento é útil se você estiver pensando em migrar do Apache Kafka autogerenciado para Pub/Sub, porque ele pode ajudar revisar e considerar os recursos, os preços e os casos de uso. Cada seção identifica um caso de uso comum do Kafka e oferece orientações práticas para alcançar os mesmos recursos no Pub/Sub.
Visão geral do Pub/Sub
O Pub/Sub é um serviço de mensagens assíncronas. O Pub/Sub dissocia serviços que produzem eventos de serviços que processam eventos. É possível usar o Pub/Sub como middleware orientado a mensagens ou ingestão e entrega de eventos para pipelines de análise de streaming. Em ambos os cenários, um aplicativo de editor cria e envia mensagens para um tópico. Para receber essas mensagens, os aplicativos do assinante criam uma assinatura de um tópico. Uma assinatura é uma entidade nomeada que representa um interesse em receber mensagens sobre um tópico específico.
O Pub/Sub é executado em todas as regiões do Google Cloud. O Pub/Sub direciona o tráfego do editor para o data center do Google Cloud mais próximo em que é permitido o armazenamento de dados, conforme definido na política de restrição de local de recursos.
O Pub/Sub pode se integrar a muitos serviços do Google Cloud comofluxo ,Armazenamento em nuvem ,Cloud Run para criar um anexo da VLAN de monitoramento. É possível configurar esses serviços para servirem como origens de dados que podem publicar mensagens no Pub/Sub ou como coletores de dados que podem receber mensagens do Pub/Sub.
Visão geral do Kafka
O Apache Kafka é uma plataforma de streaming de eventos, distribuída e de código aberto que permite que os aplicativos publiquem, assinem, armazenem e processem streams de eventos. O servidor Kafka é executado como um cluster de máquinas com as quais os aplicativos clientes interagem para ler, gravar e processar eventos. É possível usar o Kafka para separar aplicativos, enviar e receber mensagens, rastrear atividades, agregar dados de registro e processar fluxos.
Dentro do cluster do Kafka, alguns nós do cluster são designados como agentes. Os agentes recebem mensagens dos produtores e os armazenam no disco. As mensagens armazenadas são organizadas por tópico e particionadas por vários agentes diferentes no cluster. Novos eventos publicados em um tópico são anexados ao final de uma das partições do tópico. Os consumidores podem buscar mensagens de agentes, que são lidas no disco e enviadas ao consumidor.
Noções básicas sobre as diferenças entre o Kafka e o Pub/Sub
O diagrama a seguir mostra as diferenças na estratégia de escalonamento entre o Kafka e o Pub/Sub:
No diagrama anterior, cada M representa uma mensagem. Os agentes do Kafka gerenciam várias partições ordenadas de mensagens, representadas pelas linhas horizontais de mensagens. Os consumidores leem mensagens de uma partição específica que tem capacidade com base na máquina que hospeda essa partição. O Pub/Sub não tem partições, e os consumidores leem de um tópico que realiza o escalonamento automático de acordo com a demanda. Você configura cada tópico do Kafka com o número de partições necessárias para processar a carga de consumidor esperada. O Pub/Sub é escalonado automaticamente com base na demanda.
Comparação de recursos
A tabela a seguir compara os recursos do Apache Kafka com os recursos do Pub/Sub:
| Apache Kafka | Pub/Sub | |
|---|---|---|
| Ordem das mensagens | Sim em partições | Sim, dentro de tópicos |
| Eliminação de mensagens duplicadas | Sim | Sim usando o Dataflow |
| Enviar inscrições | Não | Sim |
| Fila de mensagens inativas (fila de mensagens não processáveis) |
A partir da versão 2.0 | Sim |
| Transações | Sim | Não |
| Armazenamento de mensagens | Limitado apenas pelo armazenamento de máquina disponível | 31 dias. Um tópico pode reter mensagens publicadas, inclusive mensagens confirmadas, por no máximo 31 dias. Essa opção pode ser configurada pela propriedade `message_retention_duration` do tópico. |
| Repetição da mensagem | Sim | Sim |
| Localidade | Cluster local pode ser replicado usando o MirrorMaker | Serviço distribuído global com locais de armazenamento de mensagens configuráveis |
| Geração de registros e monitoramento | Autogerenciado | Automatização com Cloud Logging e Cloud Monitoring |
| Processamento de stream | Sim com KSQL | Sim com o Dataflow |
Como compreender o armazenamento e a repetição de mensagens do Pub/Sub
Por padrão, o Pub/Sub mantém mensagens não confirmadas por até sete dias, mas também é possível configurar assinaturas do Pub/Sub para reter mensagens confirmadas. por até sete dias, dependendo da idade da mensagem mais antiga (confirmada ou não confirmada) na assinatura. Retendo mensagens confirmadas, é possível reproduzir algumas ou todas elas com base em um carimbo de data/hora. Quando você reproduz mensagens com base em um carimbo de data/hora, todas as mensagens recebidas após o carimbo são marcadas como não confirmadas. As mensagens não confirmadas serão reenviadas.
É possível criar snapshots de assinaturas individuais sob demanda sem precisar configurar sua assinatura com antecedência. Por exemplo, é possível criar um snapshot ao implantar um novo código de assinante, porque talvez seja necessário se recuperar de confirmações inesperadas ou errôneas.
Segurança integrada com tópicos de mensagens inativas
O Pub/Sub fornece recursos semelhantes ao tratamento de erros do Kafka 2.0 e à maneira como o Kafka Connect processa tópicos de mensagens inativas. Para notificar o Pub/Sub de que uma mensagem foi entregue, os assinantes aos tópicos do Pub/Sub podem reconhecer as mensagens recebidas e processadas. Caso seus assinantes não possam processar mensagens por algum tempo, o Pub/Sub pode encaminhá-las automaticamente para um tópico de mensagens inativas e armazená-las para acesso posterior. É possível configurar o número de tentativas que o Pub/Sub faz para entregar as mensagens antes de enviá-las ao tópico de mensagens inativas.
Como remover mensagens no Pub/Sub usando o Dataflow
O Pub/Sub entrega cada mensagem publicada pelo menos uma vez para cada assinatura. Em geral, acomodar mais de uma entrega requer que o assinante seja idempotente ao processar as mensagens. Se os assinantes não conseguirem operar de maneira idempotente, incorpore o Dataflow para eliminar a duplicação de mensagens. Se os assinantes veem uma taxa alta de mensagens duplicadas, isso pode indicar que eles não estão confirmando corretamente as mensagens ou que seu prazo de confirmação é muito curto.
Ordem das mensagens no Pub/Sub
Se os aplicativos de assinantes do Kafka dependerem da ordem das mensagens, você poderá oferecer esse requisito em Pub/Sub ao usar chaves de ordenação. Atualmente, a ordenação é garantida para mensagens publicadas em uma determinada região. Para aproveitar a ordenação de mensagens, verifique se os editores e assinantes usam endpoints locais para encaminhar as mensagens à região correta.
Noções básicas sobre responsabilidades de serviços auto-hospedados e gerenciados
A tabela a seguir compara qual recurso é auto-hospedado com o Kafka e qual é gerenciado pelo Google com o Pub/Sub:
| Apache Kafka | Pub/Sub | |
|---|---|---|
| Disponibilidade | Implantar o Kafka manualmente em outros locais | Implantada em todas as regiões do Google Cloud para alta disponibilidade e baixa latência |
| Recuperação de desastres | Projete e mantenha seu próprio backup e replicação | Gerenciado pelo Google |
| Gerenciamento de infraestrutura | Implementar e operar manualmente máquinas virtuais (VMs) ou máquinas. Mantenha versões e patches consistentes. | Gerenciado pelo Google |
| Planejamento de capacidade | Planeje manualmente as necessidades de armazenamento e computação com antecedência | Gerenciado pelo Google |
| Suporte | Nenhuma | Suporte 24 horas por telefone e suporte disponíveis |
Limites e soluções alternativas de tamanho de mensagem do Pub/Sub
O Kafka e o Pub/Sub têm um bom desempenho ao manipular grandes volumes de mensagens pequenas. O Kafka não limita o tamanho da mensagem e permite que você configure o tamanho permitido dela, enquanto o Pub/Sub limita as mensagens a 10 MB. É possível enviar payloads maiores armazenando primeiro o objeto no Cloud Storage, conforme mostrado no diagrama a seguir:
A imagem anterior mostra que, quando o editor armazena o objeto no Cloud Storage, ele publica uma mensagem contendo o URL para esse objeto armazenado. Quando o assinante recebe a mensagem contendo o URL, ele faz o download do arquivo do Cloud Storage e continua o processamento conforme o normal.
Comparação de custo do Kafka e do Pub/Sub
A maneira como você estima e gerencia os custos no Pub/Sub é diferente da Kafka. Os custos de um cluster do Kafka no local ou na nuvem incluem o custo de máquinas, disco, rede, mensagens de entrada e saída, bem como os custos indiretos de gerenciamento e manutenção desses sistemas e a infraestrutura relacionada. Ao gerenciar um cluster Kafka, geralmente as máquinas precisam ser atualizadas e corrigidas manualmente, a capacidade do cluster geralmente precisa ser planejada, e a implementação da recuperação de desastres envolve um planejamento e teste extensivos. É preciso inferir e agregar todos esses custos para determinar o verdadeiro custo total de propriedade (TCO).
Os preços do Pub/Sub incluem a transferência de dados de editores e assinantes, além do custo de armazenamento temporário de mensagens não confirmadas. Você paga exatamente pelos recursos que consome, escalonando automaticamente a capacidade de acordo com os requisitos do aplicativo e orçamento.
Arquitetura para confiabilidade
O Pub/Sub é um serviço global gerenciado que é executado em todas as regiões do Google Cloud. Os tópicos do Pub/Sub são globais, o que significa que são visíveis e acessíveis em qualquer local do Google Cloud. No entanto, qualquer mensagem é armazenada em uma única região do Google Cloud, mais próxima do editor e permitida pela política de localização de recursos. Assim, um tópico pode ter mensagens armazenadas em diferentes regiões no Google Cloud. O Pub/Sub é resistente a interrupções zonais. Durante uma interrupção regional, as mensagens armazenadas nessa região específica podem ficar inacessíveis até que o serviço seja restaurado. Dependendo dos seus requisitos de disponibilidade, é possível usar endpoints de serviço local para implementar uma política de failover se ocorrer uma interrupção regional.
Segurança e autenticação
O Apache Kafka é compatível com vários mecanismos de autenticação, incluindo autenticação baseada em certificados de cliente, Kerberos, LDAP, e nome de usuário e senha. Para autorização, o Kafka é compatível com o uso de listas de controle de acesso (ACLs, na sigla em inglês) para determinar quais produtores e consumidores têm acesso a quais tópicos.
O Pub/Sub é compatível com autenticação para contas de usuário e contas de serviço do Google Cloud. O controle de acesso granular a tópicos e assinaturas do Pub/Sub é regido pelo gerenciamento de acesso e identificação (IAM, na sigla em inglês) no Google Cloud. As operações do Pub/Sub têm limitação de taxa ao usar contas de usuário. Se você precisar fazer transações de alto volume, poderá usar contas de serviço para interagir com o Pub/Sub.
Como planejar sua migração para o Pub/Sub
Qualquer migração para o Google Cloud começa com a avaliação das cargas de trabalho e a criação da base.
Migração em fases usando o conector de Kafka do Pub/Sub
O conector do Kafka do Pub/Sub (em inglês) permite que você migre sua infraestrutura do Kafka para o Pub/Sub em fases.
É possível configurar o conector do Pub/Sub para encaminhar todas as mensagens sobre tópicos específicos do Kafka para o Pub/Sub. Em seguida, você pode atualizar aplicativos de assinantes individuais para receber mensagens sobre esses tópicos do Pub/Sub, enquanto os aplicativos do editor continuam a publicar mensagens no Kafka. Essa abordagem em fases permite atualizar, testar e monitorar os aplicativos inscritos de maneira iterativa, minimizando o risco de tempo de inatividade e erro.
Esta seção inclui dois diagramas que podem ajudar você a visualizar esse processo em duas fases distintas. O diagrama a seguir mostra a configuração durante a fase de migração:
No diagrama anterior, os assinantes atuais continuam recebendo as mensagens do Kafka e você os atualiza um a um para receber as mensagens do Pub/Sub.
Depois que todos os assinantes de um tópico em particular são atualizados para receber mensagens do Pub/Sub, você pode atualizar os aplicativos do editor desse tópico para publicar mensagens no Pub/Sub. Em seguida, você pode testar e monitorar os fluxos de mensagens de ponta a ponta para verificar a configuração.
No diagrama a seguir, veja a configuração depois que todos os assinantes recebem mensagens do Pub/Sub:
Com o tempo, todos os editores são atualizados para publicar diretamente no Pub/Sub, e sua migração estará concluída. Muitas equipes usam essa abordagem para atualizar os aplicativos em paralelo. O Kafka pode coexistir com o Pub/Sub pelo tempo necessário para garantir uma migração bem-sucedida.
Como monitorar o Pub/Sub
Durante e após a migração do Kafka para o Pub/Sub, é importante monitorar os aplicativos. O Pub/Sub exporta métricas usando o Cloud Monitoring, que pode ajudar a fornecer visibilidade sobre o desempenho, o tempo de atividade e a integridade geral dos seus aplicativos. Por exemplo, é possível garantir que os assinantes acompanhem o fluxo de mensagens monitorando o número de mensagens não entregues. Para monitorar mensagens não entregues, você cria alertas quando o carimbo de data/hora da mensagem não confirmada mais antiga ultrapassa um determinado limite. Também é possível monitorar a integridade do serviço Pub/Sub monitorando a métrica de contagem de solicitações de envio e examinando os códigos de resposta.
A seguir
- Análise de stream com o Pub/Sub.
- Referência da API Pub/Sub.
- Documentação do Monitoring do Pub/Sub.
- Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.