Neste guia, apresentamos uma compreensão e uma visão geral dos recursos de confiabilidade do Pub/Sub. Os tópicos abordados neste documento incluem:
- Por que usar o Pub/Sub?
- Failover
- Como ajustar editores
- Ajustar inscritos
- Como usar snapshots e buscar implantações seguras
Por que usar o Pub/Sub?
Como um paradigma de mensagens, a publicação/assinatura foi projetada para desacoplar os produtores de mensagens dos consumidores dessas mensagens. Em vez de os produtores enviarem solicitações diretas aos consumidores com os dados, eles publicam esses dados em um serviço do Pub/Sub, como o Pub/Sub. O serviço envia essas mensagens de maneira assíncrona aos consumidores interessados que se inscreveram.
O resultado é que o serviço absorve todas as complexidades de encontrar consumidores interessados nos dados. O serviço também gerencia a taxa em que os consumidores recebem os dados, com base na capacidade deles. Essa separação permite que os produtores de dados gravem mensagens em alta escala com baixa latência, independentemente do comportamento dos consumidores.
O Pub/Sub oferece entrega de mensagens altamente escalonável e confiável. Embora o serviço lide com grande parte disso automaticamente, você tem controle sobre diferentes aspectos dos editores e assinantes que podem afetar a disponibilidade e o desempenho. O restante deste guia fornece alguns detalhes sobre esses aspectos
Failover
O Pub/Sub é um serviço global: os tópicos e as assinaturas não estão inerentemente
vinculados a regiões específicas, e as mensagens fluem dentro do serviço Pub/Sub entre
as regiões quando necessário. Ao usar o endpoint global, pubsub.googleapis.com,
editores e assinantes se conectam à região mais próxima da rede onde
o Pub/Sub é executado. Ao usar os endpoints de localização, como
us-central1-pubsub.googleapis.com, os editores e assinantes se conectam ao Pub/Sub
na região especificada. Ao executar editores ou assinantes fora de Google Cloud,
é melhor usar endpoints de localização para garantir que as mensagens fluam entre
as regiões esperadas de maneira consistente. O restante desta seção fala sobre como
criar tópicos e assinaturas. Além disso, também vamos abordar como posicionar editores e assinantes para
oferecer suporte a diferentes tipos de failover e redundância de dados.
Semântica de failover padrão
Considere um caso em que há apenas um tópico e uma assinatura. Os editores estão localizados em regiões dos Estados Unidos e da Austrália, e os assinantes estão localizados nas Google Cloud regiões da Europa e da Austrália. No caso em que todos os assinantes têm capacidade suficiente para receber mensagens, o fluxo de mensagens é semelhante a este:
Os Ps representam editores, e os S representam assinantes. O hexágono azul representa o serviço do Pub/Sub. Os cilindros representam os locais em que as mensagens são armazenadas. Elas são sempre mantidas em várias zonas na região em que são publicadas. O Pub/Sub prefere enviar mensagens na mesma região em que foram publicadas quando os assinantes estão disponíveis. Caso contrário, ele enviará as mensagens para a região mais próxima da rede com assinantes que tenham capacidade. Portanto, como mostrado na imagem anterior, as mensagens publicadas nos Estados Unidos são entregues aos assinantes na Europa, e as mensagens publicadas na Austrália permanecem na Austrália.
As seções a seguir discutem o que acontece em diferentes cenários de falha.
Assinantes na Europa estão indisponíveis
Suponha que os assinantes na Europa foram desativados ou falharam com frequência e não conseguiram manter uma conexão com o Pub/Sub. Se isso ocorresse, o serviço começaria a entregar mensagens para assinantes na Austrália:
Assinantes na Europa e na Austrália estão indisponíveis
Caso todos os assinantes estejam indisponíveis, o Pub/Sub armazenará as mensagens até a duração da retenção de mensagens configurada.
Quando os assinantes se reconectarem, as mensagens serão entregues, a menos que a interrupção dure mais do que a duração configurada para a retenção de mensagens. Por padrão, a retenção de mensagens de assinatura é definida como sete dias. Você também pode configurar a retenção de mensagens em um tema por até 31 dias. Não escolha uma duração de retenção de mensagens menor do que a interrupção máxima que você espera ou está disposto a tolerar.
O Pub/Sub não está disponível na Europa
Embora seja raro, você também pode querer lidar com casos em que o próprio Pub/Sub não está disponível. A indisponibilidade do Pub/Sub se manifesta como longos períodos de erros inesperados em solicitações de publicação ou assinatura ou a incapacidade de entregar mensagens publicadas aos assinantes. Por exemplo, se o Pub/Sub estivesse inativo na região da Europa, o cenário será muito parecido com o de quando os assinantes estiverem inativos:
Observe que, nesse caso, os assinantes na Europa não fazem failover para outra região, mesmo que estejam usando o endpoint global. O Pub/Sub não faz failover automático intencionalmente. Imagine que os próprios assinantes estão causando um problema inesperado no Pub/Sub que resulta em indisponibilidade. Esse problema é tratado como uma grande interrupção. No entanto, o escopo do impacto da interrupção pode estar restrito à região a que os assinantes se conectaram. Se o serviço permitir que eles façam failover para outra região, os assinantes também poderão causar indisponibilidade, resultando em uma falha em cascata em todo o serviço.
Os editores na Austrália não estão disponíveis
Se os editores de uma região ficarem indisponíveis, as mensagens já publicadas ainda serão entregues aos assinantes mais próximos:
Eventualmente, todas as mensagens serão consumidas e reconhecidas pelos assinantes. Ao enviar mensagens, o Pub/Sub tenta minimizar a distância da rede. Portanto, os assinantes na região da Austrália poderão parar de receber mensagens se os assinantes na Europa tiverem capacidade suficiente para processar todas as mensagens publicadas nos Estados Unidos.
O Pub/Sub não está disponível nos Estados Unidos
O Pub/Sub grava mensagens de forma síncrona em várias zonas dentro de uma região. Portanto, uma interrupção zonal não é suficiente para impedir a entrega de mensagens. Toda a região precisa estar indisponível. Se o Pub/Sub ficar indisponível em uma região onde os editores estão enviando mensagens, essas mensagens poderão não ser entregues até que o serviço seja totalmente restaurado:
A mensagem ainda é entregue (supondo que o período de retenção de mensagens não tenha passado), atrasada pela duração da interrupção. Assim como os assinantes, os editores nos Estados Unidos também não fazem failover para outra região quando o serviço falha. Esse comportamento ajuda a evitar a probabilidade de falhas em cascata nas regiões devido a um editor ou assinante com falha.
Isolamento
A semântica detalhada de failover padrão afeta o isolamento de dados e como a indisponibilidade de editores, assinantes ou o próprio Pub/Sub pode afetar o fluxo de mensagens. Seu caso de uso pode precisar de diferentes níveis de isolamento. Por exemplo, você pode exigir a entrega intrarregional de todas as mensagens.
Se não quiser isolamento, a semântica de failover padrão detalhada é suficiente. Crie um único tópico e uma única assinatura, além de editores e assinantes de locais em todas as regiões selecionadas. Se os assinantes ficarem indisponíveis ou o Pub/Sub estiver inativo na região a que eles se conectam, a entrega será feita para os assinantes em outra região.
Para isolamento regional, em que é garantido que os dados não sairão de uma região, crie um tópico e uma assinatura para lidar com mensagens em cada região. Localize editores e assinantes em cada uma dessas regiões e peça que eles publiquem e assinem o tópico regional e a assinatura correspondentes, respectivamente. Também é necessário usar endpoints regionais para garantir que os dados sejam movidos apenas dentro da região. No caso de falhas do editor, do assinante ou do Pub/Sub em uma única região, a entrega da mensagem é interrompida nessa região. A entrega de mensagens sobre tópicos e assinaturas para outras regiões não será afetada.
Por fim, o isolamento zonal, em que é garantido que os dados vão ficar dentro de uma única zona, não é possível no Pub/Sub. Se você precisa que zonas individuais sejam independentes, use o Pub/Sub Lite.
Failover e redundância controlados pelo cliente
A semântica de failover padrão do Pub/Sub pode não garantir totalmente que as mensagens sempre possam fluir de editores para assinantes se houver uma interrupção do serviço. As interrupções podem ocorrer em vários locais diferentes, incluindo seus clientes, no serviço em que os editores ou assinantes são executados, na rede ou até mesmo raramente no próprio Pub/Sub. Se você precisar que seus serviços sejam resilientes a essas interrupções, implemente suas próprias redundâncias. Normalmente, essas redundâncias incluem o uso de várias instâncias de clientes editores e assinantes, em que cada uma usa um endpoint de localização diferente.
Você pode precisar de resiliência a dois escopos diferentes de impacto: zonal ou regional. Estas são as opções de configuração para cada um.
Resiliência zonal
O Pub/Sub tem replicação entre zonas integrada. Não é necessário seguir etapas especiais para lidar com interrupções de zona única que afetam o próprio serviço. No entanto, para ter resiliência a interrupções para seus clientes ou sua rede, é melhor executar editores e assinantes com capacidade suficiente em várias zonas dentro da região. Se uma única zona ficar inativa, os clientes na outra zona poderão captar o tráfego e processar as mensagens. É uma prática recomendada não publicar alterações nesses clientes simultaneamente. Assim, se um bug for introduzido, as outras zonas intactas poderão continuar processando mensagens.
Resiliência regional
Para ser resiliente a falhas regionais, configure redundâncias adicionais nos editores e assinantes. É possível executar editores e assinantes em várias regiões para lidar com a possibilidade de interrupções nesses clientes ou na rede.
Se você quiser se proteger contra possíveis falhas do Pub/Sub em uma região, será necessário ter um mecanismo de failover pronto para lidar com essa interrupção. As abordagens possíveis são um equilíbrio entre a latência da entrega de mensagens de ponta a ponta e seu custo.
Para minimizar a latência caso o custo não seja uma preocupação, a melhor estratégia é sempre publicar e assinar simultaneamente em diferentes regiões. Primeiro, escolha o número de regiões em que você quer redundância. Em seguida, embora não seja estritamente necessário, você pode configurar um tópico e uma assinatura para cada uma dessas regiões.
Cada editor cria quantos clientes editores houver no número de regiões (um para cada região) e usa um endpoint de localização diferente para garantir que as mensagens sejam direcionadas a regiões distintas. Se você usar tópicos separados, cada cliente editor precisará publicar no tópico por região correspondente. Para cada mensagem, o editor chama a publicação em cada cliente. Com as publicações redundantes, não é necessário repetir as publicações se uma delas falhar.
Da mesma forma, cada assinante cria vários clientes assinantes, um para cada região, e usa um endpoint de localização para se conectar a uma região diferente. Se você usar assinaturas diferentes para cada região, cada cliente precisará usar a assinatura correspondente. As regiões usadas para editores e assinantes não precisam ser as mesmas. Os assinantes recebem mensagens das três assinaturas e as processam.
Essa configuração tem vários recursos e requisitos importantes:
- Qualquer interrupção de região única não afeta o processamento de mensagens já publicadas, nem aquelas publicadas durante a interrupção. Como as mensagens foram publicadas em várias regiões, elas ainda estarão disponíveis em outras regiões caso uma região fique inativa. Durante a interrupção, as chamadas de publicação falham na região afetada, mas são bem-sucedidas nas outras.
- A latência de processamento de mensagens não é afetada, desde que uma das regiões pelas quais as mensagens estão fluindo esteja disponível.
- O processamento da mensagem precisa ser idempotente. Como cada mensagem será entregue várias vezes, o processamento de mensagens precisa ser resiliente a cópias. No caso de uma interrupção regional, algumas dessas duplicatas podem vir muito mais tarde do que a primeira vez em que a mensagem foi entregue. Essas duplicatas provavelmente vieram de uma região diferente que não estava sofrendo uma interrupção.
A execução com esse tipo de redundância oferece a mais alta resiliência a qualquer tipo de interrupção. Para serviços internos do Google que dependem do Pub/Sub e exigem a maior disponibilidade, essa configuração é preferível. No entanto, essa configuração tem a compensação de multiplicar o custo de entrega de mensagens pelo número de regiões usadas. Há também o custo extra do uso de rede inter-regional para mensagens que precisam ser movidas entre regiões.
Outra abordagem para a redundância é fazer o failover apenas quando as solicitações falharem ou as mensagens não estiverem fluindo dos editores para os assinantes como esperado. Nesse cenário, você tem uma região principal para a qual direciona seus editores e assinantes por endpoints de localização. Como antes, elas não precisam ser a mesma região. Você também tem uma região substituta para editores e assinantes que é usada quando a região principal não está disponível.
Os editores publicam somente na região principal (por meio do endpoint de localização) quando as solicitações são enviadas. Sempre que for determinado que a região está inativa, os editores começarão a publicar na região substituta. Há duas maneiras de determinar que a região está inativa e fazer o failover. Isso pode ser feito por um processo manual, e a configuração pode ser atualizada dinamicamente nos editores. Os editores também poderão atualizar a configuração por conta própria se a taxa de erros nas solicitações de publicação for alta o suficiente.
Os assinantes sempre precisam se conectar à região principal usando o endpoint de localização. É possível decidir se o assinante pode usar a região substituta com um ou mais dos seguintes gatilhos:
- Sempre assine a região substituta. Nesse caso, o assinante mantém uma conexão com a região principal e com a região de fallback a todo tempo. As mesmas regiões podem ser usadas para a instância principal e a substituta de editores e assinantes. Se esse for o caso, o assinante só precisará receber mensagens pela região de backup em caso de failover do editor.
- Detectar manualmente e mudar os assinantes para a região substituta por meio de uma configuração. Se você detectar uma interrupção, poderá fazer o failover para a região de fallback e, em seguida, voltar para a região principal quando a interrupção tiver diminuído.
- Fazer failover em erros de assinantes. Se as solicitações do assinante estiverem retornando erros, use isso como uma indicação de que você precisa fazer failover para a região do substituto. Observe que as bibliotecas de cliente do Pub/Sub repetem as solicitações de envio por streaming internamente em erros temporários. Portanto, talvez você não consiga detectar longos períodos de erros inesperados. Além disso, espera-se que a taxa de erro de pull de streaming seja de 100%, mesmo durante a operação normal.
- Faça o failover caso o assinante passe por um longo período inesperadamente sem receber mensagens. Supondo que haja uma publicação consistente de mensagens, os assinantes sempre podem receber mensagens. Se elas passarem por um longo período sem receber mensagens, pode haver um problema da assinatura no Pub/Sub na região primária. Isso é corrigido com o failover para a região de fallback.
Das quatro opções, a primeira é a ideal. Uma conexão de assinante não gera custos se não há mensagens fluindo nela. O único custo está no tamanho da instância extra da biblioteca de cliente do assinante, que pode ser insignificante. Você também precisa estar atento ao número de conexões de pull de streaming aberto por cota de região.
A vantagem desse segundo modelo é que não há um multiplicador no custo do Pub/Sub, já que as mensagens são publicadas apenas uma vez. No entanto, a desvantagem é que, para determinados tipos de interrupção, as mensagens publicadas antes do início da interrupção podem não estar disponíveis até que ela seja resolvida. As mensagens armazenadas na região indisponível talvez não sejam entregues aos assinantes, independentemente de onde eles estejam conectados. As mensagens publicadas durante a interrupção para a região de fallback podem estar disponíveis. Além disso, pode haver um período de indisponibilidade com maiores taxas de erro para os editores ou assinantes. Isso depende do método usado para detectar uma interrupção e do tempo para fazer o failover para a região de fallback.
Independentemente da opção escolhida, esteja ciente de como ela pode interagir com os recursos do Pub/Sub. Tanto a entrega solicitada quanto a entrega exata oferecem garantias em uma região. Por exemplo, se você usar a técnica de redundância de failover, a entrega da mensagem só será garantida para mensagens publicadas na mesma região. O assinante pode receber mensagens publicadas na região substituta antes das mensagens publicadas na região principal, mesmo que as mensagens tenham sido publicadas na região principal primeiro.
Como ajustar editores
Independentemente das opções de failover escolhidas, há algumas etapas extras de ajuste que você precisa seguir nos próprios editores. O ajuste do comportamento do editor garante a performance ideal sob grande carga. O agrupamento de mensagens em lote é uma maneira de reduzir a latência para reduzir o custo, mas não é uma preocupação de confiabilidade e, portanto, não será abordado neste documento. Em vez disso, concentre-se em alguns dos outros parâmetros úteis para ajustar a confiabilidade, incluindo configurações de repetição e controle de fluxo.
As publicações podem falhar por diferentes motivos, incluindo os temporários, como indisponibilidade da rede, ou que exigem intervenção do usuário, como mudanças de permissão. A biblioteca de cliente do Pub/Sub tenta erros temporários usando os parâmetros especificados nas configurações de nova tentativa. Essas configurações controlam o comportamento da espera exponencial em novas tentativas de RPCs de publicação que falham por motivos temporários. Embora as configurações padrão geralmente funcionem bem na maioria dos cenários, há situações em que convém ajustar esses valores.
As duas propriedades que você mais provavelmente quer ajustar são o tempo limite da RPC inicial e o tempo limite total. O tempo limite do RPC inicial é o período em que o primeiro RPC de publicação é fornecido para ser concluído. Se algum RPC falhar ou expirar, outro será tentado com um tempo limite mais longo até que o número total de solicitações ou o tempo limite total seja excedido.
O tempo limite inicial poderá ser ajustado se o editor tiver restrição de rede ou estiver longe do data center Google Cloud mais próximo que executa o Pub/Sub. As restrições de rede podem ser limitações na capacidade da máquina em que o editor está sendo executado ou podem ser o resultado de outros serviços executados na mesma máquina que usam muita rede. Com o tempo limite definido muito curto, os RPCs iniciais podem falhar repetidamente, resultando em mais tentativas (com tempos limite mais longos) necessárias para a publicação. A necessidade repetida de novas tentativas aumenta a latência de publicação. Nessa situação, aumentar o tempo limite inicial pode resultar em publicações mais rápidas.
Se a conexão de rede não for confiável, aumentar o tempo limite total e o tempo limite inicial pode ajudar. Um aumento no tempo limite total dá ao RPC de publicação mais tempo para ser concluído. Quando as RPCs de publicação falham consistentemente com erros de prazo excedido, ajuste esses valores.
Erros de prazo contínuo excedido na publicação também podem indicar a necessidade de ajustar o controle de fluxo do editor. Essas configurações permitem que você garanta que seus editores sejam resilientes a picos de tráfego de entrada que geram mais mensagens a serem enviadas ao Pub/Sub. Um grande aumento nas solicitações enviadas pode sobrecarregar a CPU, a memória ou a capacidade da rede do editor. Quando a publicação está sobrecarregada, ela não consegue processar solicitações ou respostas de publicação antes do tempo limite. Isso resulta em ainda mais solicitações de publicação e, por fim, atinge o tempo limite total. O controle de fluxo do editor limita o número de mensagens ou bytes que podem estar pendentes sem uma resposta da solicitação de publicação. Limitar o número de solicitações dessa maneira mantém a utilização de recursos em um nível gerenciável, mesmo durante picos. Dependendo de como seu editor opera, é possível permitir que RPCs de publicação subsequentes aguardem a capacidade, permitindo que a publicação bloqueie novas solicitações. Como alternativa, é possível enviar de volta aos autores da chamada do serviço fazendo com que o controle de fluxo retorne um erro quando a capacidade for atingida. Você configura como a biblioteca de cliente do editor responde com o comportamento limite excedido.
Ajustar inscritos
O ajuste dos assinantes também pode ser necessário para garantir uma operação confiável. Assim como os editores, é possível ajustar as configurações de controle de fluxo dos assinantes para garantir que não sejam sobrecarregados. A biblioteca de cliente do assinante usa pull de streaming, em que o cliente abre um stream persistente para o servidor e o servidor envia mensagens conforme elas ficam disponíveis. No caso de um grande aumento nas mensagens publicadas, o assinante pode receber mais mensagens do que consegue processar. Com o controle de fluxo em vigor, o número de mensagens não confirmadas pendentes para o cliente em um determinado momento é limitado. Isso reduz o número de mensagens processadas simultaneamente e distribui o processamento por um período mais longo. A propagação da carga permite que os assinantes permaneçam sob quaisquer limitações de recursos que afetem o processamento de mensagens, o que pode resultar em um efeito em cascata que se desenvolve na incapacidade de processar qualquer mensagem.
Somente o controle de fluxo é suficiente se você espera apenas que picos na quantidade de dados processem que, em última análise, recuem. Se o tráfego estiver aumentando ao longo do tempo devido ao maior uso, o controle de fluxo protege os assinantes. No entanto, isso pode resultar em um backlog que continua a se acumular e faz com que as mensagens não sejam entregues antes que a duração da retenção de mensagens passe. Nesses casos, também é possível definir o escalonamento automático para aumentar o número de assinantes em resposta a um número crescente de mensagens não confirmadas. A configuração depende da plataforma de computação usada para seus assinantes. Por exemplo, com o escalonador automático do Compute Engine, é possível fazer o escalonamento com base em métricas como o número de mensagens não entregues. O uso do escalonamento automático e do controle de fluxo garante que seus assinantes sejam resilientes a outros picos de curto prazo na capacidade de processamento das mensagens e ao crescimento de longo prazo que exigem mais poder de computação. Siga as Práticas recomendadas para usar métricas do Pub/Sub como um sinal de escalonamento.
Use snapshots e procure implantações seguras
A perda de mensagens geralmente é um evento catastrófico. O Pub/Sub oferece entrega pelo menos uma vez para todas as mensagens publicadas. No entanto, o processamento correto dessas mensagens depende do comportamento do assinante. Se as mensagens forem confirmadas com êxito, o Pub/Sub não as entregará novamente. Portanto, um bug introduzido no novo código de assinante implantado que confirma as mensagens sem tê-las processado corretamente pode resultar em perda de mensagens induzida pelo assinante. O Pub/Sub oferece o recurso de snapshot e busca, que pode ajudar a garantir o processamento correto de todas as mensagens, mesmo diante de bugs de assinantes.
O padrão para cada implantação de assinante precisa ser o seguinte:
O tempo de espera antes de determinar se o novo assinante está funcionando pode variar de acordo com seu caso de uso. A única maneira de sair do fluxo de etapas é quando um assinante é considerado trabalhando. Nesse momento, o snapshot pode ser excluído.
O uso do snapshot e da busca não substitui as práticas recomendadas sobre a primeira execução de software em um ambiente que não é de produção e a implantação gradual na produção. Elas fornecem um nível adicional de proteção para garantir o processamento confiável dos dados. A desvantagem é que a busca pelo snapshot pode resultar na entrega duplicada de mensagens que seu assinante processou. No entanto, como o Pub/Sub tem semântica de entrega pelo menos uma vez por padrão, os assinantes já são resilientes ao reenvio da mensagem.