Práticas recomendadas para publicar em um tópico do Pub/Sub

Na publicação, um cliente editor envia uma mensagem para um tópico do Pub/Sub. Veja algumas práticas recomendadas para publicar mensagens no Pub/Sub.

Neste documento, presumimos que você já conheça o processo de publicação de mensagens em um tópico do Pub/Sub.

Se você não tiver experiência com o Pub/Sub, consulte um dos guias de início rápido e saiba como executar o Pub/Sub usando o console, a CLI gcloud ou as bibliotecas de cliente.

Anexe uma assinatura ou ative a retenção de tópicos antes de começar a publicar

Se você começar a publicar em um tópico que não tenha um assinante anexado, as mensagens não serão retidas. Essas mensagens não podem ser entregues a assinaturas anexadas posteriormente. Portanto, antes de começar a publicar mensagens, siga um destes procedimentos:

Anexe uma assinatura a um tópico. Escolha um dos seguintes métodos:
- Crie uma assinatura e especifique um tópico durante o processo. Saiba como criar uma assinatura de pull, uma assinatura de push, uma assinatura do BigQuery ou uma assinatura do Cloud Storage.
- Selecione uma assinatura padrão ao criar um tópico.
Ative a retenção de mensagens de tópicos.

A retenção de mensagens de tópicos permite que uma assinatura reproduza mensagens publicadas antes da criação de uma assinatura. Se a retenção de mensagens de tópico estiver ativada, os custos de armazenamento das mensagens retidas pelo tópico serão cobrados do projeto em que o tópico estiver localizado.

Configurar mensagens em lote

No Pub/Sub, as mensagens em lote se referem ao processo de combinar várias mensagens em um lote que é publicado em uma única solicitação de publicação. Se você usa bibliotecas de cliente para publicar suas mensagens, os lotes serão ativados por padrão. O agrupamento (ou agrupamento) de mensagens ajuda o editor a melhorar a eficiência e enviar mensagens com uma capacidade maior. O processamento em lotes reduz o custo de publicação de dados. No entanto, os lotes também criam latência para mensagens individuais porque o editor espera o lote ser preenchido antes de publicá-lo.

A latência no Pub/Sub pode ser de dois tipos:

Latência de ponta a ponta é o tempo que leva para uma mensagem ser publicada por um editor e entregue aos assinantes correspondentes para processamento.
A latência de publicação é o tempo necessário para publicar uma mensagem.

Ao usar lotes, aumentar os dois tipos de latência é uma compensação para melhorar a eficiência e a capacidade.

Você pode agrupar mensagens em uma biblioteca de cliente com base no tamanho da solicitação de mensagem, no número de mensagens e no tempo. Ao definir configurações de lote, é possível encontrar o equilíbrio certo entre custo, capacidade e latência para atender ao seu caso de uso.

Os valores padrão para as variáveis de mensagens em lote e os nomes das variáveis podem ser diferentes entre as bibliotecas de cliente. Você pode especificar um ou todos os três valores na biblioteca de cliente. Se algum dos valores das variáveis de mensagens em lote for atendido, a biblioteca de cliente publicará o próximo lote de mensagens.

Para configurar mensagens em lote para um cliente editor, consulte Mensagens em lote em uma solicitação de publicação.

Configurar o controle de fluxo para picos de mensagens temporários

Se o cliente editor tiver que processar um grande número de mensagens, as solicitações de publicação poderão começar a se acumular na memória até que as mensagens não sejam publicadas com um erro Deadline exceeded.

Para lidar com picos transitórios na publicação de mensagens, use o controle de fluxo nas configurações do editor. O controle de fluxo do lado do editor impede que os recursos clientes do editor fiquem sobrecarregados com muitas solicitações pendentes. Se o cliente editor ficar restrito em termos de memória, CPU ou linhas de execução, um grande número de erros Deadline exceeded será gerado.

Para configurar o controle de fluxo na biblioteca de cliente, defina valores apropriados para as variáveis máximo de mensagens pendentes e máximo de bytes de mensagens pendentes. Esses valores equilibram a capacidade das mensagens e do sistema.

Para verificar se a biblioteca de cliente é compatível com o controle de fluxo do editor e configurá-lo, consulte Controle de fluxo.

Entenda a largura de banda e a latência da sua rede

A capacidade do editor é limitada pela largura de banda da rede e pelo número de solicitações enviadas. Se a largura de banda for boa, mas a latência da rede for alta, não sobrecarregue o sistema com muitas solicitações pequenas. O controle de fluxo do editor pode ajudar com problemas de rede do lado do cliente.

A capacidade de processamento do editor também está vinculada à CPU e à memória. Mais núcleos de máquina disponíveis permitem que você defina uma contagem de linhas de execução mais alta para melhorar a capacidade de publicação. Para entender melhor como maximizar o desempenho do streaming, consulte Como testar clientes do Cloud Pub/Sub para maximizar o desempenho do streaming.

Ajustar as variáveis de solicitação de nova tentativa para publicações com falha

Quando uma mensagem é publicada por um cliente editor, podem aparecer falhas de publicação. Essas falhas geralmente são causadas por gargalos do lado do cliente, como CPUs de serviço insuficientes, integridade da linha de execução ruim ou congestionamento da rede. O publisher retry policy determina o comportamento em caso de falha na entrega da mensagem. A política de nova tentativa define o número de vezes que o Pub/Sub tenta entregar a mensagem e o período entre cada tentativa.

Por exemplo, na biblioteca de cliente Java para Pub/Sub, o cliente editor contém os seguintes valores:

initialRetryDelay. O atraso inicial que o editor aguarda antes de tentar novamente uma operação de publicação. O valor padrão é 100 milliseconds.
retryDelayMultiplier. O fator de multiplicação usado para calcular o atraso entre novas tentativas. O valor padrão é 4. Isso significa que o atraso entre novas tentativas é de até 100 milliseconds * 4 = 400 milliseconds na segunda nova tentativa e de até 400 milliseconds * 4 = 1600 milliseconds na terceira.
maxRetryDelay. O atraso máximo que o editor aguarda antes de tentar novamente uma operação de publicação. O valor padrão é 60 seconds.
initialRpcTimeout. O tempo limite inicial que o editor aguarda até que a chamada RPC seja concluída. O valor padrão é 5 seconds.
rpcTimeoutMultiplicador. O fator de multiplicação usado para calcular o tempo limite da RPC. O valor padrão é 4.0. Isso significa que o tempo limite da chamada de RPC é de 5 seconds * 4 = 20 seconds na segunda tentativa e de até 10 seconds * 4 = 40 seconds na terceira.
maxRpcTimeout. O tempo limite máximo que o editor aguarda a conclusão da chamada RPC. O valor padrão é 600 seconds.
totalTimeout. O tempo limite total para a operação de publicação. Isso inclui o tempo gasto aguardando a conclusão da chamada RPC e o tempo gasto entre novas tentativas. O valor padrão é 600 seconds.

Faça ajustes nos valores especificados apenas se você achar que as configurações de nova tentativa padrão não são suficientes para seu caso de uso. Por exemplo, publicar um grande número de mensagens não exigiria que você aumentasse os valores initialRetryDelay e maxRetryDelay. No entanto, é possível ajustar o controle de fluxo e os lotes nessas circunstâncias. Se você estiver publicando usando uma conexão de Internet lenta ou com limitação de largura de banda, poderá testar os valores das variáveis initialRpcTimeout, maxRpcTimeout e rpcTimeoutMultiplier. Para valores recomendados, consulte Falha nas operações de publicação com DEADLINE_EXCEEDED.

Usar a política de armazenamento de mensagens para garantir a localidade dos dados

A política de armazenamento de mensagens de tópico do Pub/Sub oferece uma maneira de garantir que as mensagens publicadas em um tópico nunca sejam mantidas fora de um conjunto de regiões do Google Cloud especificado, independente da origem das solicitações de publicação.

Use a política de armazenamento de mensagens para especificar uma lista de regiões do Google Cloud em que o Pub/Sub tem permissão para armazenar dados de mensagens em disco. Quando uma mensagem é publicada em uma região que não está na lista, a solicitação é encaminhada para a região permitida mais próxima para processamento. A política pode ser configurada em um tópico ou como uma política organizacional para um projeto, uma pasta do projeto ou uma organização inteira. Quando uma política da organização é configurada, a política de tópico individual só pode ser alterada de maneira que não viole a política da organização.

Por exemplo, uma empresa que opera na Europa pode usar a política de armazenamento de mensagens para garantir que todos os dados sejam armazenados nas regiões da UE para cumprir as leis locais.

Para mais informações, consulte Configurar políticas de armazenamento de mensagens.

Práticas recomendadas para mensagens ordenadas na publicação

Se você usa a ordem das mensagens, verifique o seguinte:

Use endpoints locais. A ordem das mensagens é preservada no lado da publicação e em uma região. Em outras palavras, se você estiver publicando mensagens em várias regiões, apenas as mensagens dentro da mesma região serão entregues em uma ordem consistente. Se todas as suas mensagens forem publicadas na mesma região, mas seus assinantes estiverem espalhados por regiões, os assinantes receberão todas as mensagens em ordem. Use um endpoint local para publicar mensagens na mesma região.
Configure uma função de publicação de currículos. Quando uma biblioteca de cliente repete uma solicitação e a mensagem tem uma chave de ordem, a biblioteca de cliente tenta repetir a solicitação repetidamente, independentemente das configurações de repetição. Se ocorrer um erro que não possa ser repetido, a biblioteca de cliente não publicará a mensagem e deixará de publicar outras mensagens com a mesma chave de ordem. Quando estiver tudo pronto para continuar publicando em uma chave de ordem que tenha uma publicação com falha, chame o método resumePublish.

Resumo das práticas recomendadas

A tabela a seguir resume as práticas recomendadas neste documento:

Tópico	Tarefa
Configurar a retenção de mensagens	Anexe uma assinatura antes de publicar ou ativar a retenção de mensagens.
Agrupar mensagens em lote em uma solicitação de publicação	Mensagens em lote ou em grupo para aumentar a eficiência do editor e enviar mensagens com uma capacidade maior.
Controle de fluxo	Defina o controle de fluxo nas configurações do editor para lidar com picos de tráfego temporários.
Como testar clientes do Pub/Sub para maximizar o desempenho de streaming	Escalone a capacidade do editor com um aumento nos núcleos de máquina disponíveis e na largura de banda da rede.
Repetir solicitações	Faça ajustes nos valores especificados da política de nova tentativa do editor somente se as configurações padrão não forem suficientes para seu caso de uso.
Configurar políticas de armazenamento de mensagens	Use a política de armazenamento de mensagens para armazenar dados de mensagens no disco apenas em locais específicos.
Use um endpoint de localização ao usar chaves de ordenação na publicação	Ao usar mensagens ordenadas, use um endpoint de localização e configure uma função de publicação de currículo para falhas de publicação.