Este guia fornece uma compreensão e uma imagem geral das funcionalidades de fiabilidade do Pub/Sub.
Porquê o Pub/Sub?
Como paradigma de mensagens, a publicação/subscrição foi concebida para separar os produtores de mensagens dos consumidores dessas mensagens. Em vez de os produtores enviarem pedidos diretos aos consumidores com os dados, publicam esses dados num serviço Pub/Sub, como o Pub/Sub. O serviço envia essas mensagens de forma assíncrona aos consumidores interessados que subscreveram.
O resultado é que o serviço absorve todas as complexidades de encontrar consumidores interessados nos dados. O serviço também gere a taxa à qual os consumidores recebem os dados, com base na respetiva capacidade. A desvinculação permite que os produtores de dados escrevam mensagens em grande escala com baixa latência, independentemente do comportamento dos consumidores.
O Pub/Sub oferece uma entrega de mensagens altamente escalável e fiável. Embora o serviço trate grande parte disto automaticamente, tem controlo sobre diferentes aspetos dos seus publicadores e subscritores que podem afetar a disponibilidade e o desempenho. O resto deste guia fornece alguns detalhes sobre estes aspetos.
Isolamento
Por predefinição, o Pub/Sub é um serviço global: os tópicos e as subscrições
não estão inerentemente associados a regiões específicas, e as mensagens fluem no
serviço Pub/Sub entre regiões quando necessário. Quando usa o ponto final global, os publicadores e os subscritores ligam-se à região mais próxima da rede onde o Pub/Sub é executado.pubsub.googleapis.com Quando usa os endpoints regionais, como us-central1-pubsub.googleapis.com, ou os endpoints de localização, como pubsub.us-central1.rep.googleapis.com, os publicadores e os subscritores ligam-se ao Pub/Sub na região especificada. Quando executa
publicadores ou subscritores fora de Google Cloud, é melhor usar
pontos finais regionais ou de localização para garantir que as mensagens fluem entre as
regiões esperadas de forma consistente.
Isolamento regional
Para minimizar a infraestrutura da qual as operações de publicação e subscrição dependem fora de uma única região e para garantir que todos os dados permanecem isolados nessa região, siga estes passos:
Crie um tópico por região.
Embora o espaço de nomes do Pub/Sub seja global e não possa associar tópicos e subscrições a uma região específica, os metadados de todos os recursos são replicados para repositórios de dados locais na região. Por conseguinte, depois de criar um recurso, a respetiva configuração fica disponível mesmo em caso de um problema noutra região. Tenha em atenção que as atualizações às configurações do tópico ou da subscrição podem não ser propagadas imediatamente em caso de indisponibilidade.
Evite usar pontos finais globais.
Em alternativa, use endpoints regionais, quando disponíveis, e endpoints de localização, quando os endpoints regionais não estiverem disponíveis. Os pontos finais regionais oferecem um maior isolamento regional, mas ainda não estão disponíveis em todas as regiões.
Use uma política de armazenamento de mensagens e defina
enforceInTransitcomoTrue.Com a opção Aplicar em trânsito ativada, os dados nunca saem da região e todos os clientes que se ligam ao tópico numa região específica definem a política de armazenamento de mensagens para essa região.
Com os tópicos configurados desta forma, pode ter a certeza de que todas as operações de publicação e subscrição escrevem e leem dados exclusivamente na região. No caso de falhas do publicador, subscritor ou Pub/Sub numa única região, a entrega de mensagens é interrompida nessa região. A entrega de mensagens sobre tópicos e subscrições para outras regiões não é afetada.
Se também precisar que as operações administrativas e o espaço de nomes dos seus tópicos e subscrições estejam isolados regionalmente, considere usar o Managed Service for Apache Kafka.
Failover
Se não precisar de isolamento regional, pode tirar partido da capacidade do Pub/Sub de enviar mensagens de forma eficiente em várias regiões para alcançar capacidades de comutação por falha multirregional. O resto desta secção aborda a forma de criar tópicos e subscrições, bem como de posicionar publicadores e subscritores para suportar diferentes tipos de comutação por falha e redundância de dados.
Semântica de comutação por falha predefinida
Considere um caso em que existe um único tópico e subscrição. Os publicadores estão localizados em regiões dos Estados Unidos e da Austrália, e os subscritores estão localizados nas Google Cloud regiões da Europa e da Austrália. No caso em que todos os subscritores têm capacidade suficiente para receber mensagens, o fluxo de mensagens é o seguinte:
Os P representam os publicadores e os S representam os subscritores. O hexágono azul representa o serviço Pub/Sub. Os cilindros representam os locais onde as mensagens são armazenadas (as mensagens são sempre mantidas em várias zonas na região onde são publicadas). O Pub/Sub prefere enviar mensagens na mesma região onde foram publicadas quando existem subscritores disponíveis. Caso contrário, envia as mensagens para a região mais próxima da rede com subscritores que tenham capacidade. Por conseguinte, conforme mostrado na imagem anterior, as mensagens publicadas nos Estados Unidos são entregues aos subscritores na Europa, e as mensagens publicadas na Austrália permanecem na Austrália.
As secções seguintes abordam o que acontece em diferentes cenários de falha.
Os subscritores na Europa estão indisponíveis
Suponha que os subscritores na Europa foram recusados ou falham frequentemente e não conseguem manter uma ligação ao Pub/Sub. Se isto ocorresse, o serviço começaria a entregar mensagens aos subscritores na Austrália:
Os subscritores na Europa e na Austrália não estão disponíveis
Se todos os subscritores estiverem indisponíveis, o Pub/Sub armazena as mensagens até à duração de retenção de mensagens configurada.
Assim que os subscritores restabelecerem a ligação, as mensagens são entregues, a menos que a indisponibilidade dure mais do que a duração da retenção de mensagens configurada. Por predefinição, a retenção de mensagens de subscrição está definida para 7 dias. Também pode configurar a retenção de mensagens num tópico durante um máximo de 31 dias. Não escolha uma duração de retenção de mensagens inferior à indisponibilidade máxima que espera ou está disposto a tolerar.
O Pub/Sub não está disponível na Europa
Embora seja raro, também pode querer lidar com casos em que o Pub/Sub está indisponível. A indisponibilidade do Pub/Sub manifesta-se como períodos prolongados de erros inesperados em pedidos de publicação ou subscrição, ou a incapacidade de entregar mensagens publicadas aos subscritores. Por exemplo, se o Pub/Sub estivesse indisponível na região da Europa, o cenário seria muito semelhante ao de quando os subscritores estão indisponíveis:
Tenha em atenção que, neste caso, os subscritores na Europa não transitam para outra região, mesmo que usem o ponto final global. O Pub/Sub não faz intencionalmente a comutação por falha automática. Imagine que são os próprios subscritores que estão a causar um problema inesperado no Pub/Sub que resulta na indisponibilidade. Este tipo de problema é tratado como uma indisponibilidade grave. No entanto, o âmbito do impacto da indisponibilidade pode ser limitado à região à qual os subscritores se ligaram. Se o serviço lhes permitisse a comutação por falha para outra região, os subscritores também poderiam causar indisponibilidade nessa região, o que resultaria numa falha em cascata no serviço.
Os publicadores na Austrália não estão disponíveis
Se os publicadores numa região ficarem indisponíveis, as mensagens já publicadas continuam a ser entregues aos subscritores mais próximos:
Eventualmente, todas as mensagens são consumidas e reconhecidas pelos subscritores. Ao enviar mensagens, o Pub/Sub tenta minimizar a distância da rede. Por conseguinte, os subscritores na região da Austrália podem deixar de receber mensagens se os subscritores 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 escreve mensagens de forma síncrona em várias zonas numa região. Por conseguinte, uma indisponibilidade ao nível da zona não é suficiente para impedir a entrega de mensagens. Toda a região tem de estar indisponível. Se o Pub/Sub ficar indisponível numa região onde os publicadores estão a enviar mensagens, as mensagens nessa região podem não ser entregues até o serviço ser totalmente restaurado:
A mensagem é, em última análise, entregue (assumindo que o período de retenção da mensagem não expirou), com um atraso correspondente à duração da indisponibilidade. Tenha em atenção que, tal como os subscritores, os publicadores nos Estados Unidos também não transitam para outra região quando o serviço falha. Este comportamento ajuda a evitar a probabilidade de falhas em cascata nas regiões devido a um publicador ou subscritor com defeito.
Comutação por falha e redundância controladas pelo cliente
A semântica de alternativa predefinida do Pub/Sub pode não garantir totalmente que as mensagens podem sempre fluir dos publicadores para os subscritores se houver uma interrupção em qualquer lugar entre eles. As indisponibilidades podem ocorrer em vários locais diferentes, incluindo nos seus clientes, no serviço no qual os seus publicadores ou subscritores são executados, na rede ou, raramente, no próprio Pub/Sub. Se precisar que os seus serviços sejam resilientes a estas falhas, tem de implementar as suas próprias redundâncias. Normalmente, estas redundâncias incluem a utilização de várias instâncias de clientes publicadores e subscritores em que cada uma usa um ponto final de localização diferente.
Pode querer resiliência para dois âmbitos de impacto diferentes: zonal ou regional. Seguem-se as opções de configuração para cada uma.
Resiliência zonal
O Pub/Sub tem replicação entre zonas integrada. Não tem de tomar medidas especiais para lidar com interrupções de uma única zona que afetem o próprio serviço. No entanto, para ter resiliência a interrupções para os seus clientes ou rede, é melhor executar publicadores e subscritores com capacidade suficiente em várias zonas na região. Se uma única zona estiver inativa, os clientes na outra zona podem receber o tráfego e processar as mensagens. É uma prática recomendada não publicar alterações nestes clientes em simultâneo para que, se for introduzido um erro, as outras zonas não alteradas possam continuar a processar mensagens.
Resiliência regional
Para garantir a resiliência em caso de falhas regionais, configure redundâncias adicionais nos seus publicadores e subscritores. Pode executar publicadores e subscritores em várias regiões para lidar com a possibilidade de interrupções nesses clientes ou na rede.
Se quiser ser resiliente contra potenciais falhas do Pub/Sub numa região, tem de ter um mecanismo de alternativa pronto para lidar com essa indisponibilidade. As abordagens possíveis são um compromisso entre a latência de entrega de mensagens ponto a ponto e o seu custo.
Para minimizar a latência no caso de o custo não ser uma preocupação, a melhor estratégia é publicar e subscrever sempre em simultâneo em diferentes regiões. Primeiro, escolha o número de regiões nas quais quer redundância. Em seguida, embora não seja estritamente necessário, pode configurar um tópico e uma subscrição para cada uma dessas regiões.
Cada publicador cria tantos clientes publicadores quantas regiões existirem (um para cada região) e usa um ponto final de localização diferente para garantir que as mensagens são direcionadas para regiões distintas. Se usar tópicos separados, cada cliente publicador tem de publicar no tópico correspondente por região. Para cada mensagem, o publicador chama a publicação em cada cliente. Com as publicações redundantes, não é necessário tentar novamente as publicações se alguma falhar.
Da mesma forma, cada subscritor cria esse número de clientes subscritores, um para cada região, e usa um ponto final de localização para se ligar a uma região diferente. Se usar subscrições diferentes para cada região, cada cliente subscritor tem de usar a subscrição correspondente. Tenha em atenção que as regiões usadas para publicadores e subscritores não têm necessariamente de ser as mesmas. Os subscritores recebem mensagens nas três subscrições e processam-nas.
Esta configuração tem várias funcionalidades e requisitos principais:
- Qualquer indisponibilidade de uma única região não afeta o processamento de mensagens já publicadas, nem as publicadas durante a indisponibilidade. Uma vez que as mensagens foram publicadas em várias regiões, continuam disponíveis noutras regiões, caso uma região esteja inativa. Durante a indisponibilidade, as chamadas de publicação falham na região afetada, mas têm êxito nas outras.
- A latência do processamento de mensagens não é afetada, desde que qualquer uma das regiões através das quais as mensagens estão a fluir esteja disponível.
- O processamento de mensagens tem de ser idempotente. Uma vez que cada mensagem vai ser enviada várias vezes, o processamento de mensagens tem de ser resiliente a duplicados. No caso de uma indisponibilidade regional, algumas dessas duplicações podem chegar muito mais tarde do que a primeira vez que a mensagem foi entregue. É provável que esses duplicados sejam provenientes de uma região diferente que não estava a sofrer uma indisponibilidade.
A execução com este tipo de redundância oferece a maior capacidade de recuperação a qualquer tipo de interrupções. Para serviços Google internos que dependem do Pub/Sub e requerem a disponibilidade mais elevada, esta configuração é preferível. No entanto, esta configuração tem a desvantagem de multiplicar o custo da entrega de mensagens pelo número de regiões usadas. Também existe o custo adicional da utilização da rede inter-regional para mensagens que têm de se deslocar entre regiões.
Outra abordagem à redundância é só fazer failover quando os pedidos falham ou as mensagens não fluem dos publicadores para os subscritores como esperado. Neste cenário, tem uma região principal para a qual direciona os seus publicadores e subscritores através de pontos finais de localização. Tal como antes, não têm de ser da mesma região. Também tem uma região alternativa para publicadores e subscritores que é usada quando a região principal está indisponível.
Os publicadores publicam apenas na região principal (através do ponto final de localização) quando os respetivos pedidos são enviados com êxito. Sempre que se determina que a região está inativa, os publicadores começam a publicar na região alternativa. A determinação de que a região está inativa e a comutação por falha podem ser feitas de duas formas. Pode ser feito através de um processo manual e a configuração é atualizada dinamicamente nos publicadores. Os publicadores também podem atualizar a configuração se a taxa de erro nos pedidos de publicação for suficientemente elevada.
Os subscritores têm sempre de se ligar à região principal através do ponto final de localização. Pode decidir que o subscritor pode usar a região alternativa com um ou mais dos seguintes acionadores:
- Subscrever sempre a região alternativa. Neste caso, o subscritor mantém uma ligação à região principal e à região alternativa em todos os momentos. As mesmas regiões podem ser usadas para a região principal e alternativa para publicadores e subscritores. Se for este o caso, o subscritor só deve receber mensagens através da região de cópia de segurança se o publicador tiver sofrido uma comutação por falha.
- Detetar e mudar manualmente os subscritores para a região alternativa através de uma configuração. Se detetar uma indisponibilidade, pode fazer failover para a região alternativa e, em seguida, voltar para a região principal quando a indisponibilidade tiver diminuído.
- Comutação por falha em erros de subscritores. Se os pedidos de subscritores estiverem a devolver erros, pode usar isto como uma indicação de que tem de mudar para a região alternativa. Tenha em atenção que as bibliotecas de cliente do Pub/Sub tentam novamente os pedidos de obtenção de streaming internamente em erros transitórios, pelo que pode não conseguir detetar que existem longos períodos de erros inesperados. Além disso, a taxa de erro de obtenção de streaming deve ser de 100%, mesmo durante o funcionamento normal.
- Comutação em caso de falha se o subscritor passar um período inesperadamente longo sem receber mensagens. Partindo do princípio de que existe uma publicação consistente de mensagens, os subscritores podem sempre receber mensagens. Se passar um período prolongado sem receber mensagens, pode haver um problema do lado da subscrição no Pub/Sub na região principal. Isto é corrigido através da comutação para a região alternativa.
De todas as quatro opções, a primeira é a ideal. Uma associação de subscritor não custa nada se não houver mensagens a fluir na mesma. O único custo está na pegada da instância adicional da biblioteca de cliente subscritor, que pode ser insignificante. Também tem de ter em atenção a quota de ligações de obtenção de streaming abertas por região.
A vantagem deste segundo modelo é que não existe um multiplicador no custo do Pub/Sub, uma vez que as mensagens só são publicadas uma vez. No entanto, a desvantagem é que, para determinados tipos de indisponibilidade, as mensagens publicadas antes do início da indisponibilidade podem não estar disponíveis até que a indisponibilidade seja resolvida. As mensagens armazenadas na região indisponível podem não ser entregues aos subscritores, independentemente do local onde estão ligados. As mensagens publicadas durante a interrupção na região alternativa podem estar disponíveis. Além disso, pode haver um período de indisponibilidade com taxas de erro aumentadas para os publicadores ou os subscritores. Isto depende do método usado para detetar uma indisponibilidade e do tempo de comutação para a região alternativa.
Independentemente da opção escolhida, tenha em atenção a forma como esta pode interagir com as funcionalidades do Pub/Sub. O fornecimento ordenado e o fornecimento exatamente uma vez oferecem as respetivas garantias numa região. Por exemplo, se usar a técnica de redundância de comutação por falha, a entrega de mensagens só é garantida por ordem para mensagens publicadas na mesma região. O subscritor pode receber mensagens publicadas na região alternativa antes das mensagens publicadas na região principal, mesmo que as mensagens tenham sido publicadas primeiro na região principal.