Migre do Kafka para o Pub/Sub

Este documento é útil se estiver a considerar migrar do Apache Kafka autogerido para o Pub/Sub, uma vez que pode ajudar a rever e considerar funcionalidades, preços e exemplos de utilização. Cada secção identifica um exemplo de utilização comum do Kafka e oferece orientações práticas para alcançar as mesmas capacidades no Pub/Sub.

Vista geral do Pub/Sub

O Pub/Sub é um serviço de mensagens assíncronas. O Pub/Sub desassocia os serviços que produzem eventos dos serviços que processam eventos. Pode usar o Pub/Sub como middleware orientado para mensagens ou para o carregamento e o fornecimento de eventos para pipelines de análise de streaming. Em ambos os cenários, uma aplicação de editor cria e envia mensagens para um tópico. As aplicações subscritoras criam uma subscrição de um tópico para receber mensagens do mesmo. Uma subscrição é uma entidade com nome que representa um interesse em receber mensagens sobre um tópico específico.

O Pub/Sub é executado em todas as Cloud de Confiance by S3NS regiões. O Pub/Sub direciona o tráfego do publicador para o centro de dados mais próximo onde o armazenamento de dados é permitido, conforme definido na política de restrição de localização de recursos. Cloud de Confiance by S3NS

O Pub/Sub pode ser integrado com muitos Cloud de Confiance serviços como o Dataflow, Cloud Storage, e o Cloud Run. Pode configurar estes serviços para funcionarem como origens de dados que podem publicar mensagens no Pub/Sub ou como destinos de dados que podem receber mensagens do Pub/Sub.

Vista geral do Kafka

O Apache Kafka é uma plataforma de streaming de eventos distribuída e de código aberto, e permite que as aplicações publiquem, subscrevam, armazenem e processem streams de eventos. O servidor Kafka é executado como um cluster de máquinas com o qual as aplicações cliente interagem para ler, escrever e processar eventos. Pode usar o Kafka para separar as aplicações, enviar e receber mensagens, monitorizar atividades, agregar dados de registo e processar streams.

No cluster Kafka, alguns nós do cluster são designados como agentes. Os agentes recebem mensagens dos produtores e armazenam-nas no disco. As mensagens armazenadas são organizadas por tópico e divididas em vários agentes diferentes no cluster. Os novos eventos publicados num tópico são anexados ao final de uma das partições do tópico. Em seguida, os consumidores podem obter mensagens dos corretores, que são lidas a partir do disco e enviadas para o consumidor.

Compreender as diferenças entre o Kafka e o Pub/Sub

O diagrama seguinte mostra as diferenças na estratégia de escalabilidade entre o Kafka e o Pub/Sub:

No diagrama anterior, cada M representa uma mensagem. Os agentes Kafka gerem várias partições ordenadas de mensagens, representadas pelas linhas horizontais de mensagens. Os consumidores leem mensagens de uma determinada partição que tem uma capacidade com base na máquina que aloja essa partição. O Pub/Sub não tem partições e, em vez disso, os consumidores leem a partir de um tópico que é automaticamente dimensionado de acordo com a procura. Configura cada tópico do Kafka com o número de partições necessárias para processar a carga de consumidores esperada. O Pub/Sub é dimensionado automaticamente com base na procura.

Comparar funcionalidades

A tabela seguinte compara as funcionalidades do Apache Kafka com as funcionalidades do Pub/Sub:

Compreender o armazenamento e a repetição de mensagens do Pub/Sub

Por predefinição, o Pub/Sub mantém as mensagens não reconhecidas durante um máximo de 7 dias, mas pode configurar as subscrições do Pub/Sub para manter as mensagens reconhecidas também durante um máximo de 7 dias, consoante a antiguidade da mensagem mais antiga (reconhecida ou não reconhecida) na subscrição. Ao reter as mensagens reconhecidas, pode reproduzir algumas ou todas essas mensagens com base numa data/hora. Quando repete mensagens com base numa data/hora , todas as mensagens recebidas após a data/hora são marcadas como não reconhecidas. As mensagens não acusadas são, em seguida, reenviadas.

Pode criar instantâneos de subscrições individuais a pedido sem ter de configurar a sua subscrição antecipadamente. Por exemplo, pode criar uma captura de ecrã quando implementar um novo código de subscritor, uma vez que pode ter de recuperar de reconhecimentos inesperados ou erróneos.

Salvaguarda integrada com tópicos de mensagens não entregues

O Pub/Sub oferece funcionalidades semelhantes ao processamento de erros do Kafka 2.0 e à forma como o Kafka Connect processa tópicos de mensagens não entregues. Para notificar o Pub/Sub de que uma mensagem foi entregue com êxito, os subscritores de tópicos do Pub/Sub podem confirmar as mensagens que recebem e processam. Se os seus subscritores não conseguirem processar mensagens durante algum tempo, o Pub/Sub pode encaminhar automaticamente estas mensagens para um tópico de mensagens rejeitadas e armazená-las para acesso posterior. Pode configurar o número de tentativas que o Pub/Sub faz para entregar as mensagens antes de enviar a mensagem para o tópico de mensagens rejeitadas.

Remover mensagens duplicadas no Pub/Sub com o Dataflow

O Pub/Sub envia cada mensagem publicada, pelo menos, uma vez para cada subscrição. Em geral, a acomodação da entrega mais do que uma vez requer que o seu subscritor seja idempotente ao processar mensagens. Se os seus subscritores existentes não conseguirem operar de forma idempotente, pode incorporar o Dataflow para remover mensagens duplicadas. Se os seus subscritores virem uma taxa elevada de mensagens duplicadas, isto pode indicar que não estão a reconhecer corretamente as mensagens ou que o prazo de reconhecimento é demasiado curto.

Ordenação de mensagens no Pub/Sub

Se as suas aplicações subscritoras do Kafka dependerem da ordenação de mensagens, pode suportar este requisito no Pub/Sub quando usar chaves de ordenação. Atualmente, a ordenação é garantida para mensagens publicadas numa determinada região. Para tirar partido da ordenação de mensagens, certifique-se de que os seus publicadores e subscritores usam pontos finais de localização para encaminhar as suas mensagens para a região correta.

Compreender as responsabilidades do serviço autoalojado em comparação com o serviço gerido

A tabela seguinte compara a funcionalidade alojada por si com o Kafka e a funcionalidade gerida pela Google através do Pub/Sub:

Limites de tamanho das mensagens do Pub/Sub e soluções alternativas

O Kafka e o Pub/Sub têm um bom desempenho quando processam grandes volumes de mensagens pequenas. O Kafka não impõe um limite máximo ao tamanho das mensagens e permite-lhe configurar o tamanho das mensagens permitido, enquanto o Pub/Sub limita as mensagens a 10 MB. Pode enviar indiretamente payloads maiores armazenando primeiro o objeto no Cloud Storage, conforme mostrado no diagrama seguinte:

A imagem anterior mostra que, quando o publicador armazena o objeto no Cloud Storage, publica uma mensagem que contém o URL desse objeto armazenado. Quando o subscritor recebe a mensagem com o URL, transfere o ficheiro do Cloud Storage e continua o processamento como habitualmente.

Comparação de custos do Kafka e do Pub/Sub

A forma como estima e gere os custos no Pub/Sub é diferente da forma como o faz no Kafka. Os custos de um cluster Kafka nas instalações ou na nuvem incluem o custo das máquinas, do disco, da rede, das mensagens recebidas e enviadas, bem como os custos gerais de gestão e manutenção destes sistemas e da respetiva infraestrutura. Quando gere um cluster Kafka, muitas vezes, as máquinas têm de ser atualizadas e corrigidas manualmente, a capacidade do cluster tem de ser planeada e a implementação da recuperação de desastres envolve um planeamento e testes extensivos. Tem de inferir e agregar todos estes vários custos para determinar o seu verdadeiro custo total de propriedade (TCO).

A preçário do Pub/Sub inclui a transferência de dados de publicadores e para subscritores, bem como o custo do armazenamento temporário de mensagens não reconhecidas. Paga exatamente os recursos que consome, dimensionando automaticamente a respetiva capacidade de acordo com os requisitos da sua aplicação e orçamento.

Criar arquiteturas a pensar na fiabilidade

O Pub/Sub é um serviço gerido global que é executado em todas as Cloud de Confiance regiões. Os tópicos do Pub/Sub são globais, o que significa que são visíveis e acessíveis a partir de qualquer Cloud de Confiance localização. No entanto, qualquer mensagem é armazenada numa única região que está mais próxima do publicador e é permitida pela política de localização de recursos. Cloud de Confiance Assim, um tópico pode ter mensagens armazenadas em diferentes regiões em todo o Cloud de Confiance. O Pub/Sub é resistente a falhas de energia zonais. Durante uma indisponibilidade regional, as mensagens armazenadas nessa região específica podem ficar inacessíveis até o serviço ser restaurado. Consoante os seus requisitos de disponibilidade, pode usar pontos finais de serviços de localização para implementar uma política de comutação em caso de falha se ocorrer uma indisponibilidade regional.

Segurança e autenticação

O Apache Kafka suporta vários mecanismos de autenticação, incluindo a autenticação baseada em certificados de cliente, o Kerberos, o LDAP e o nome de utilizador e a palavra-passe. Para autorização, o Kafka suporta a utilização de listas de controlo de acesso (ACLs) para determinar que produtores e consumidores têm acesso a que tópicos.

O Pub/Sub suporta a autenticação para Cloud de Confiance contas de utilizador e contas de serviço. O controlo de acesso detalhado aos tópicos e subscrições do Pub/Sub é regido pela gestão de identidade e de acesso (IAM) no Cloud de Confiance. As operações do Pub/Sub estão limitadas por taxa quando usa contas de utilizador. Se precisar de fazer transações de grande volume, pode usar contas de serviço para interagir com o Pub/Sub.

Planeie a sua migração para o Pub/Sub

Qualquer migração para o Cloud de Confiance começa com a avaliação das suas cargas de trabalho e a criação da sua base.

Migração faseada com o conetor Pub/Sub Kafka

O conetor Pub/Sub Kafka permite-lhe migrar a sua infraestrutura Kafka para o Pub/Sub em fases.

Pode configurar o conetor Pub/Sub para encaminhar todas as mensagens em tópicos específicos do Kafka para o Pub/Sub. Em seguida, pode atualizar as aplicações de subscrição individuais para receber mensagens sobre esses tópicos do Pub/Sub, enquanto as suas aplicações de publicação continuam a publicar mensagens no Kafka. Esta abordagem faseada permite-lhe atualizar, testar e monitorizar as aplicações de subscritores de forma iterativa, o que minimiza o risco de erro e tempo de inatividade.

Esta secção inclui dois diagramas que podem ajudar a visualizar este processo em duas fases distintas. O diagrama seguinte mostra a configuração durante a fase de migração:

No diagrama anterior, os subscritores atuais continuam a receber mensagens do Kafka e atualiza os subscritores um a um para receberem mensagens do Pub/Sub.

Depois de todos os subscritores de um determinado tópico terem sido atualizados para receber mensagens do Pub/Sub, pode atualizar as aplicações do publicador para esse tópico de modo a publicar mensagens no Pub/Sub. Em seguida, pode testar e monitorizar os fluxos de mensagens ponto a ponto para validar a configuração.

O diagrama seguinte mostra a configuração depois de todos os subscritores estarem a receber mensagens do Pub/Sub:

Ao longo do tempo, todos os seus publicadores são atualizados para publicar diretamente no Pub/Sub e, em seguida, a migração é concluída. Muitas equipas usam esta abordagem para atualizar as respetivas aplicações em paralelo. O Kafka pode coexistir com o Pub/Sub durante o tempo necessário para garantir uma migração bem-sucedida.

Monitoring Pub/Sub

Durante e após a migração do Kafka para o Pub/Sub, é importante monitorizar as suas aplicações. O Pub/Sub exporta métricas através do Cloud Monitoring, o que pode ajudar a fornecer visibilidade do desempenho, do tempo de atividade e do estado geral das suas aplicações. Por exemplo, pode garantir que os seus subscritores estão a acompanhar o fluxo de mensagens monitorizando o número de mensagens não entregues. Para monitorizar mensagens não entregues, crie alertas quando a data/hora da mensagem não confirmada mais antiga exceder um determinado limite. Também pode monitorizar o estado do próprio serviço Pub/Sub monitorizando a métrica de contagem de pedidos de envio e examinando os códigos de resposta.

O que se segue?

• Transmita estatísticas com o Pub/Sub.
• Referência da API Pub/Sub.
• Documentação do Monitoring Pub/Sub.
• Criar arquiteturas de recuperação de desastres para interrupções da infraestrutura na nuvem.
• Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.