O desenvolvimento de pipelines envolve diferentes fases e tarefas, como o desenvolvimento de código, os testes e a implementação em produção. Este documento explica:
- Considerações para a integração contínua e a entrega contínua (CI/CD) para suportar a criação, os testes e a implementação de pipelines automatizados em diferentes ambientes.
- Funcionalidades do Dataflow para otimizar o desempenho e a utilização de recursos na produção.
- Abordagens e pontos de controlo para atualizar pipelines de streaming em produção.
- Práticas recomendadas para melhorar a fiabilidade do pipeline na produção.
Integração contínua
A integração contínua (IC) requer que os programadores unam o código num repositório partilhado com frequência, o que é útil para aplicações que mudam muito, como Websites que são atualizados com frequência. Embora os pipelines de dados não mudem normalmente tanto como outros tipos de aplicações, as práticas de CI oferecem muitas vantagens para o desenvolvimento de pipelines. Por exemplo, a automatização de testes fornece feedback rápido quando são encontrados defeitos e reduz a probabilidade de regressões entrarem no código base.
A automatização de testes é uma parte importante da CI. Quando combinada com uma cobertura de testes adequada, a automatização de testes executa o conjunto de testes em cada commit de código. O seu servidor de CI pode funcionar em conjunto com uma ferramenta de automatização de compilação, como o Maven, para executar o conjunto de testes como um ou mais passos do pipeline de CI. Pode criar pacotes de código que passam com êxito nos testes unitários e nos testes de integração em artefactos de implementação a partir dos quais são iniciados pipelines. Esta compilação é denominada compilação aprovada.
O número e os tipos de artefactos de implementação criados a partir de uma compilação aprovada variam consoante a forma como os pipelines são iniciados. Com o SDK Java do Apache Beam, pode criar um pacote do código do pipeline num ficheiro JAR autoexecutável. Em seguida, pode armazenar o ficheiro JAR num contentor alojado no projeto para um ambiente de implementação, como o projeto de pré-produção ou de produção Google Cloud . Se usar modelos clássicos (um tipo de execução baseada em modelos), os artefactos de implementação incluem um ficheiro de modelo JSON, o ficheiro JAR para o seu pipeline e um modelo de metadados opcional. Em seguida, pode implementar os artefactos em diferentes ambientes de implementação através da entrega contínua, conforme explicado na secção seguinte.
Entrega e implementação contínuas
A entrega contínua (EC) copia os artefactos de implementação para um ou mais ambientes de implementação que estão prontos para serem lançados manualmente. Normalmente, os artefactos criados pelo servidor de CI são implementados num ou mais ambientes de pré-produção para executar testes completos. O ambiente de produção é atualizado se todos os testes completos forem aprovados com êxito.
Para pipelines em lote, a implementação contínua pode iniciar diretamente o pipeline como uma nova tarefa do Dataflow. Em alternativa, outros sistemas podem usar os artefactos para iniciar tarefas em lote quando necessário. Por exemplo, pode usar o Cloud Composer para executar tarefas de lote num fluxo de trabalho ou o Cloud Scheduler para agendar tarefas de lote.
Os pipelines de streaming podem ser mais complexos de implementar do que os pipelines de processamento em lote e, por isso, podem ser mais difíceis de automatizar através da implementação contínua. Por exemplo, pode ter de determinar como substituir ou atualizar um pipeline de streaming existente. Se não conseguir atualizar um pipeline ou optar por não o atualizar, pode usar outros métodos, como coordenar várias tarefas do Dataflow para minimizar ou evitar a interrupção da empresa.
Identidades e funções necessárias para a CI/CD
O pipeline de CI/CD interage com diferentes sistemas para criar, testar e implementar pipelines. Por exemplo, o pipeline precisa de aceder ao repositório do código-fonte. Para ativar estas interações, certifique-se de que o seu pipeline tem as identidades e as funções adequadas. As seguintes atividades de pipeline também podem exigir que o pipeline tenha identidades e funções específicas.
Testes de integração com serviços externos, incluindo a Google Cloud Platform
Quando usa o Direct Runner para executar testes ad hoc ou testes de integração de sistemas, o seu pipeline usa as credenciais predefinidas da aplicação (ADC) para obter credenciais. A forma como configura a ADC depende de onde o seu pipeline está a ser executado. Para mais informações, consulte o artigo Configure as Credenciais padrão da aplicação.
Certifique-se de que a conta de serviço usada para obter credenciais para recursos da Google Cloud Platform acedidos pelo pipeline tem funções e autorizações suficientes.
Implemente artefactos em diferentes ambientes de implementação
Sempre que possível, use credenciais únicas para cada ambiente (efetivamente para cada projeto) e limite o acesso aos recursos em conformidade.
Use contas de serviço únicas para cada projeto para ler e escrever artefactos de implementação em contentores de armazenamento. Consoante a sua pipeline use um modelo, o processo de implementação pode ter de preparar vários artefactos. Por exemplo, a criação e a preparação de um modelo do Dataflow requerem autorizações para escrever artefactos de implementação necessários para iniciar o seu pipeline, como o ficheiro de modelo do pipeline, num contentor do Cloud Storage.
Implemente pipelines em diferentes ambientes de implementação
Sempre que possível, use contas de serviço exclusivas para cada projeto para aceder e gerir Google Cloud recursos no projeto, incluindo o acesso ao próprio Dataflow.
A conta de serviço que usa para criar e gerir tarefas do Dataflow tem de ter autorizações do IAM suficientes para a gestão de tarefas. Para mais detalhes, consulte a secção Conta de serviço do Dataflow na página de segurança e autorizações do Dataflow.
A conta de serviço do trabalhador que usa para executar tarefas do Dataflow precisa de autorização para gerir recursos do Compute Engine enquanto a tarefa é executada e para gerir a interação entre o pipeline do Apache Beam e o serviço Dataflow. Para mais detalhes, consulte a secção Conta de serviço do Worker na página de segurança e autorizações do Dataflow.
Para especificar uma
conta de serviço de worker gerida pelo utilizador
para uma tarefa, use
a --serviceAccount opção de pipeline.
Se não especificar uma conta de serviço do trabalhador quando cria uma tarefa, o Dataflow tenta usar a conta de serviço predefinida do Compute Engine.
Em alternativa, recomendamos que especifique uma conta de serviço de worker gerida pelo utilizador
para ambientes de produção, porque a conta de serviço predefinida do Compute Engine
tem normalmente um conjunto de autorizações mais amplo do que as autorizações
necessárias para os seus trabalhos do Dataflow.
Em cenários de produção, recomendamos que use contas de serviço separadas para a gestão de tarefas do Dataflow e para a conta de serviço do trabalhador, o que oferece uma segurança melhorada em comparação com a utilização de uma única conta de serviço. Por exemplo, a conta de serviço usada para criar tarefas do Dataflow pode não precisar de aceder a origens de dados e destinos ou usar outros recursos usados pelo pipeline. Neste cenário, a conta de serviço do trabalhador usada para executar tarefas do Dataflow recebe autorizações para usar recursos do pipeline. É concedida a uma conta de serviço diferente para a criação de tarefas autorizações para gerir (incluindo criar) tarefas do Dataflow.
Exemplo de pipeline de CI/CD
O diagrama seguinte oferece uma vista geral e independente da ferramenta de CI/CD para pipelines de dados. Além disso, o diagrama mostra a relação entre as tarefas de desenvolvimento, os ambientes de implementação e os executores de pipelines.
O diagrama mostra as seguintes fases:
Desenvolvimento de código: durante o desenvolvimento de código, um programador executa o código do pipeline localmente através do Direct Runner. Além disso, os programadores usam um ambiente de sandbox para a execução de pipelines ad hoc através do Dataflow Runner.
Em pipelines de CI/CD típicos, o processo de integração contínua é acionado quando um programador faz uma alteração ao sistema de controlo de origem, como enviar novo código para um repositório.
Compilar e testar: o processo de integração contínua compila o código do pipeline e, em seguida, executa testes unitários e testes de integração de transformação com o Direct Runner. Também podem ser executados testes de integração de sistemas opcionais, que incluem testes de integração com origens e destinos externos através de pequenos conjuntos de dados de teste.
Se os testes forem bem-sucedidos, o processo de CI armazena os artefactos de implementação, que podem incluir ficheiros JAR, imagens Docker e metadados de modelos, necessários para iniciar o pipeline em localizações que são acessíveis ao processo de entrega contínua. Consoante os tipos de artefactos de implementação gerados, pode usar o Cloud Storage e o Artifact Registry para armazenar os diferentes tipos de artefactos.
Fornecer e implementar: o processo de fornecimento contínuo copia os artefatos de implementação para um ambiente de pré-produção ou disponibiliza estes artefatos para utilização nesse ambiente. Os programadores podem executar manualmente testes ponto a ponto usando o Dataflow Runner ou podem usar a implementação contínua para iniciar o teste automaticamente. Normalmente, uma abordagem de implementação contínua é mais fácil de ativar para pipelines em lote do que para pipelines de streaming. Como os pipelines em lote não são executados continuamente, é mais fácil substituí-los por uma nova versão.
O processo de atualização dos pipelines de streaming pode ser simples ou complexo e deve testar as atualizações no ambiente de pré-produção. Os procedimentos de atualização podem nem sempre ser consistentes entre lançamentos. Por exemplo, um pipeline pode mudar de tal forma que torna as atualizações no local impossíveis. Por este motivo, por vezes, é difícil automatizar as atualizações do pipeline através da implementação contínua.
Se todos os testes ponto a ponto forem aprovados, pode copiar os artefactos de implementação ou disponibilizá-los ao ambiente de produção como parte do processo de entrega contínua. Se o novo pipeline atualizar ou substituir um pipeline de streaming existente, use os procedimentos testados no ambiente de pré-produção para implementar o novo pipeline.
Execução de tarefas com ou sem modelo
Pode criar uma tarefa do Dataflow através do SDK do Apache Beam diretamente a partir de um ambiente de desenvolvimento. Este tipo de tarefa é denominado tarefa não baseada em modelos. Embora esta abordagem seja conveniente para os programadores, pode preferir separar as tarefas de desenvolvimento e execução de pipelines. Para fazer esta separação, pode usar modelos do Dataflow, que lhe permitem preparar e executar os seus pipelines como tarefas independentes. Depois de um modelo ser preparado, outros utilizadores, incluindo não programadores, podem executar as tarefas a partir do modelo através da CLI gcloud, daGoogle Cloud consola ou da API REST Dataflow.
O Dataflow oferece os seguintes tipos de modelos de tarefas:
- Modelos clássicos: os programadores usam o SDK Apache Beam para executar o código do pipeline e guardar o gráfico de execução serializado JSON como o modelo. O SDK Apache Beam prepara o ficheiro de modelo para uma localização do Cloud Storage, juntamente com todas as dependências necessárias para o código do pipeline.
- Modelos flexíveis: os programadores usam a CLI do Google Cloud para criar o pacote do pipeline como uma imagem do Docker, que é depois armazenada no Artifact Registry. Também é gerado automaticamente um ficheiro de especificação do modelo flexível e armazenado numa localização do Cloud Storage especificada pelo utilizador. O ficheiro de especificação do modelo flexível contém metadados que descrevem como executar o modelo, como parâmetros do pipeline.
Além das funcionalidades dos modelos flexíveis explicadas na documentação com link, os modelos flexíveis oferecem vantagens em relação aos modelos clássicos para gerir modelos.
- Com os modelos clássicos, podem ser armazenados vários artefactos, como ficheiros JAR, numa localização de preparação do Cloud Storage, mas sem funcionalidades para gerir estes vários artefactos. Em comparação, um modelo flexível está encapsulado numa imagem do Docker. A imagem inclui todas as dependências, exceto a especificação do modelo flexível, necessárias para o seu pipeline num artefacto de implementação gerido pelo Artifact Registry.
- Pode usar funcionalidades de gestão de imagens do Docker para os seus modelos flexíveis. Por exemplo, pode partilhar com segurança modelos flexíveis concedendo autorizações de obtenção (e, opcionalmente, de envio) ao Artifact Registry e usar etiquetas de imagens Docker para diferentes versões dos seus modelos flexíveis.
Os programadores podem usar modelos clássicos e modelos flexíveis para iniciar tarefas num projeto diferente do projeto que detém o registo e o contentor de armazenamento que aloja os recursos do modelo ou apenas o contentor de armazenamento se usar modelos clássicos. Esta funcionalidade é útil se precisar de isolar o processamento de dados de vários clientes em diferentes projetos e tarefas de pipeline. Com os modelos flexíveis, pode especificar ainda mais diferentes versões de uma imagem do Docker a usar quando inicia um pipeline. Esta funcionalidade simplifica a substituição faseada de pipelines de processamento em lote ou pipelines de streaming em vários projetos quando atualiza os modelos mais tarde.
Funcionalidades do Dataflow para otimizar a utilização de recursos
O Dataflow oferece as seguintes funcionalidades específicas do executor para otimizar a utilização de recursos, o que pode melhorar o desempenho e reduzir os custos:
- Streaming Engine: o Streaming Engine move a execução de pipelines de streaming dos trabalhadores de VMs para um serviço dedicado. As vantagens incluem uma melhor capacidade de resposta da escala automática, reduções nos recursos de VMs de trabalho consumidos e atualizações automáticas dos serviços sem nova implementação. Em alguns casos, também pode reduzir a utilização de recursos através do processamento pelo menos uma vez para exemplos de utilização que podem tolerar duplicados. A ativação do Streaming Engine é recomendada para pipelines de streaming. A funcionalidade está ativada por predefinição quando usa as versões mais recentes do SDK Java do Apache Beam ou do SDK Python.
- Dataflow Shuffle: o Dataflow Shuffle move as operações de mistura para pipelines em lote dos trabalhadores de VMs para um serviço dedicado. As vantagens incluem uma execução mais rápida para a maioria dos pipelines em lote, um consumo de recursos reduzido pelas VMs de trabalho, uma capacidade de resposta da escalabilidade automática melhorada e uma tolerância a falhas melhorada. A ativação do Dataflow Shuffle é recomendada para pipelines em lote. A funcionalidade está ativada por predefinição através do Apache Beam Java SDK e do Python SDK mais recente.
- Agendamento flexível de recursos (FlexRS): o FlexRS reduz os custos de processamento em lote através da utilização de técnicas de agendamento avançadas, do serviço Dataflow Shuffle e de uma combinação de instâncias de VMs preemptíveis e VMs normais.
Atualize pipelines de streaming em produção
Consulte o artigo Atualize um pipeline de streaming.
Ciclo de vida de uma tarefa do Dataflow
Uma tarefa do Dataflow passa por um ciclo de vida representado por vários estados da tarefa.
Para executar uma tarefa do Dataflow, envie-a para uma
região.
A tarefa é então encaminhada para um back-end do Dataflow disponível numa das zonas na região. Antes de o Dataflow atribuir um back-end,
verifica se tem quota e autorizações suficientes para executar a tarefa. Quando estas verificações de pré-publicação estão concluídas e é atribuído um back-end, a tarefa passa para o estado JOB_STATE_PENDING. Para tarefas
FlexRS, a atribuição de back-end pode ser atrasada para um momento futuro, e estas tarefas
entram num estado JOB_STATE_QUEUED.
O back-end atribuído seleciona a tarefa para execução e tenta iniciar os trabalhadores do Dataflow no seu projeto da Google Cloud Platform. A zona escolhida para as VMs de trabalho depende de vários fatores. Para tarefas em lote que usam o Dataflow Shuffle, o serviço também tenta garantir que o back-end do Dataflow e as VMs de trabalho estão localizados na mesma zona para evitar tráfego entre zonas.
Depois de os trabalhadores do Dataflow serem iniciados, pedem trabalho ao back-end do Dataflow. O back-end é responsável por dividir o trabalho em partes paralelizadas, denominadas pacotes, que são distribuídas entre os trabalhadores. Se os trabalhadores não conseguirem processar o trabalho existente e o dimensionamento automático estiver ativado, o back-end inicia mais trabalhadores para processar o trabalho. Da mesma forma, se forem iniciados mais trabalhadores do que o necessário, alguns são encerrados.
Depois de os trabalhadores do Dataflow serem iniciados, o back-end do Dataflow atua como o plano de controlo para orquestrar a execução da tarefa. Durante o processamento, o plano de dados da tarefa executa operações de mistura, como GroupByKey, CoGroupByKey e Combine.
Os trabalhos usam uma das seguintes implementações do plano de dados para operações de mistura:
- O plano de dados é executado nos trabalhadores do Dataflow e os dados de mistura são armazenados em discos persistentes.
- O plano de dados é executado como um serviço, externalizado das VMs de trabalho. Esta implementação tem duas variantes, que especifica quando cria a tarefa: Dataflow Shuffle para pipelines em lote e Streaming Engine para pipelines de streaming. A ordenação aleatória baseada em serviços melhora significativamente o desempenho e a escalabilidade das operações de ordenação aleatória de dados em comparação com a ordenação aleatória baseada em trabalhadores.
As tarefas de streaming que entram num estado JOB_STATE_RUNNING continuam a ser executadas indefinidamente até serem canceladas ou esvaziadas, a menos que ocorra uma falha na tarefa. As tarefas em lote são interrompidas automaticamente quando todo o processamento é concluído ou se ocorrer um erro irrecuperável. Consoante a forma como a tarefa é interrompida, o Dataflow define o estado da tarefa como um de vários estados terminais, incluindo JOB_STATE_CANCELLED, JOB_STATE_DRAINED ou JOB_STATE_DONE.
Práticas recomendadas para a fiabilidade do pipeline
Esta secção aborda as falhas que podem ocorrer quando trabalha com o Dataflow e as práticas recomendadas para tarefas do Dataflow.
Siga os princípios de isolamento
Uma recomendação geral para melhorar a fiabilidade geral do pipeline é seguir os princípios de isolamento por detrás das regiões e zonas. Certifique-se de que os seus pipelines não têm dependências críticas entre regiões. Se tiver um pipeline com dependência crítica de serviços de várias regiões, uma falha em qualquer uma dessas regiões pode afetar o seu pipeline. Para ajudar a evitar este problema, implemente em várias regiões para redundância e cópia de segurança.
Crie instantâneos do Dataflow
O Dataflow oferece uma funcionalidade de instantâneo que fornece uma cópia de segurança do estado de um pipeline. Pode restaurar a imagem instantânea do pipeline num novo pipeline de streaming do Dataflow noutra zona ou região. Em seguida, pode iniciar o reprocessamento de mensagens nos tópicos do Pub/Sub ou Kafka a partir da data/hora da captura instantânea. Se configurar instantâneos regulares dos seus pipelines, pode minimizar o tempo do objetivo de tempo de recuperação (RTO).
Para mais informações sobre as imagens instantâneas do Dataflow, consulte o artigo Usar imagens instantâneas do Dataflow.
Resolva falhas no envio de trabalhos
Envia tarefas do Dataflow sem modelos usando o SDK Apache Beam. Para enviar a tarefa, execute o pipeline usando o Dataflow Runner, que é especificado como parte das opções do pipeline. O SDK Apache Beam organiza os ficheiros no Cloud Storage, cria um ficheiro de pedido de tarefa e envia o ficheiro para o Dataflow.
Em alternativa, as tarefas criadas a partir de modelos do Dataflow usam métodos de envio diferentes, que dependem normalmente da API Templates.
Pode ver diferentes erros devolvidos pelo Dataflow que indicam falhas de tarefas para tarefas de modelos e não de modelos. Esta secção aborda diferentes tipos de falhas de envio de tarefas e práticas recomendadas para as processar ou mitigar.
Volte a tentar enviar tarefas após falhas temporárias
Se uma tarefa não for iniciada devido a um problema do serviço Dataflow, tente executar a tarefa novamente algumas vezes. A repetição atenua os problemas transitórios do serviço.
Mitigue as falhas zonais especificando uma região de trabalhadores
O fluxo de dados oferece disponibilidade regional e está disponível em várias regiões. Quando um utilizador envia uma tarefa para uma região sem especificar explicitamente uma zona, o Dataflow encaminha a tarefa para uma zona na região especificada com base na disponibilidade de recursos.
A opção recomendada para o posicionamento de tarefas é especificar uma região de trabalho
usando a flag --region
em vez da flag --zone sempre que possível. Este passo permite que o Dataflow ofereça um nível adicional de tolerância a falhas para os seus pipelines, escolhendo automaticamente a melhor zona possível para essa tarefa. As tarefas que especificam uma zona explícita não têm esta vantagem e falham se ocorrerem problemas na zona. Se o envio de uma tarefa falhar devido a um problema zonal, pode, muitas vezes, resolver o problema repetindo a tarefa sem especificar explicitamente uma zona.
Mitigue falhas regionais armazenando dados em várias regiões
Se uma região inteira estiver indisponível, experimente a tarefa numa região diferente. É importante pensar na disponibilidade dos seus dados quando as tarefas falham em várias regiões. Para se proteger contra falhas de uma única região sem copiar manualmente os dados para várias regiões, use Google Cloud recursos que armazenam automaticamente dados em várias regiões. Por exemplo, use contentores em duas regiões e multirregionais do Cloud Storage. Se uma região ficar indisponível, pode executar novamente o pipeline noutra região onde os dados estejam disponíveis.
Para ver um exemplo de utilização de serviços multirregionais com o Dataflow, consulte Alta disponibilidade e redundância geográfica.
Resolva falhas na execução de pipelines
Depois de uma tarefa ser enviada e aceite, as únicas operações válidas para a tarefa são as seguintes:
- cancelar para tarefas em lote
- atualizar, esgotar ou cancelar para trabalhos de streaming
Não pode alterar a localização dos trabalhos em execução depois de enviar o trabalho. Se não estiver a usar o FlexRS, as tarefas começam normalmente a processar dados alguns minutos após o envio. Os trabalhos FlexRS podem demorar até seis horas para que o processamento de dados comece.
Esta secção aborda as falhas na execução de tarefas e as práticas recomendadas para as resolver.
Monitorize tarefas para identificar e resolver problemas causados por erros transitórios
Para tarefas em lote, os pacotes que incluem um item com falhas são repetidos quatro vezes. O Dataflow termina a tarefa quando um único pacote falha quatro vezes. Este processo resolve muitos problemas temporários. No entanto, se ocorrer uma falha prolongada, o limite máximo de novas tentativas é normalmente atingido rapidamente, o que permite que a tarefa falhe rapidamente.
Para a monitorização e a gestão de incidentes, configure regras de alerta para detetar tarefas com falhas. Se uma tarefa falhar, inspecione os registos da tarefa para identificar falhas de tarefas causadas por itens de trabalho com falhas que excederam o limite de repetições.
Para tarefas de streaming, o Dataflow tenta novamente os itens de trabalho com falhas indefinidamente. O trabalho não é terminado. No entanto, a tarefa pode ficar bloqueada até o problema ser resolvido. Crie políticas de monitorização para detetar sinais de um pipeline parado, como um aumento na latência do sistema e uma diminuição na atualização dos dados. Implemente o registo de erros no código do pipeline para ajudar a identificar paragens do pipeline causadas por itens de trabalho que falham repetidamente.
Reinicie tarefas numa zona diferente se ocorrer uma indisponibilidade zonal
Depois de uma tarefa ser iniciada, os trabalhadores do Dataflow que executam o código do utilizador são limitados a uma única zona. Se ocorrer uma indisponibilidade zonal, as tarefas do Dataflow são frequentemente afetadas, consoante a extensão da indisponibilidade.
Para interrupções que afetam apenas os back-ends do Dataflow, os back-ends são migrados automaticamente para uma zona diferente pelo serviço gerido para que possam continuar a tarefa. Se a tarefa usar o Dataflow Shuffle, não é possível mover o back-end entre zonas. Se ocorrer uma migração do back-end do Dataflow, os trabalhos podem ser temporariamente interrompidos.
Se ocorrer uma indisponibilidade zonal, é provável que os trabalhos em execução falhem ou fiquem parados até a disponibilidade da zona ser restaurada. Se uma zona ficar indisponível durante um longo período, pare as tarefas (cancele as tarefas em lote e desative as tarefas de streaming) e, em seguida, reinicie-as para permitir que o Dataflow escolha uma zona nova e em bom estado.
Reinicie tarefas em lote numa região diferente se ocorrer uma interrupção regional
Se ocorrer uma interrupção regional numa região onde as suas tarefas do Dataflow estão a ser executadas, as tarefas podem falhar ou ficar paradas. Para tarefas em lote, reinicie a tarefa numa região diferente, se possível. É importante garantir que os seus dados estão disponíveis em diferentes regiões.
Mitigue as interrupções regionais através da utilização da alta disponibilidade ou da comutação por falha
Para trabalhos de streaming, consoante a tolerância a falhas e o orçamento da sua aplicação, tem diferentes opções para mitigar falhas. Para uma indisponibilidade regional, a opção mais simples e económica é aguardar até que a indisponibilidade termine. No entanto, se a sua aplicação for sensível à latência ou se o processamento de dados não puder ser interrompido ou tiver de ser retomado com um atraso mínimo, as secções seguintes abordam as opções.
Alta disponibilidade: sensível à latência sem perda de dados
Se a sua aplicação não tolerar a perda de dados, execute pipelines duplicados em paralelo em duas regiões diferentes e faça com que os pipelines consumam os mesmos dados. As mesmas origens de dados têm de estar disponíveis em ambas as regiões. As aplicações a jusante que dependem do resultado destes pipelines têm de poder alternar entre o resultado destas duas regiões. Devido à duplicação de recursos, esta opção envolve o custo mais elevado em comparação com outras opções. Para ver um exemplo de implementação, consulte a secção Alta disponibilidade e redundância geográfica.
Ativação pós-falha: sensível à latência com alguma potencial perda de dados
Se a sua aplicação puder tolerar uma potencial perda de dados, disponibilize a origem de dados de streaming em várias regiões. Por exemplo, usando o Pub/Sub, mantenha duas subscrições independentes para o mesmo tópico, uma para cada região. Se ocorrer uma indisponibilidade regional, inicie um pipeline de substituição noutra região e faça com que o pipeline consuma dados da subscrição de cópia de segurança.
Repita a subscrição de cópia de segurança para um momento adequado para manter a perda de dados ao mínimo sem sacrificar a latência. As aplicações a jusante têm de saber como mudar para o resultado do pipeline em execução, de forma semelhante à opção de alta disponibilidade. Esta opção usa menos recursos do que a execução de pipelines duplicados, porque apenas os dados são duplicados.
Alta disponibilidade e redundância geográfica
Pode executar vários pipelines de streaming em paralelo para o processamento de dados de alta disponibilidade. Por exemplo, pode executar duas tarefas de streaming paralelas em diferentes regiões, o que oferece redundância geográfica e tolerância a falhas para o processamento de dados.
Ao considerar a disponibilidade geográfica das origens e dos destinos de dados, pode operar pipelines completos numa configuração de várias regiões altamente disponível. O diagrama seguinte mostra um exemplo de implementação.
O diagrama mostra o seguinte fluxo:
O Pub/Sub é executado na maioria das regiões em todo o mundo, o que permite ao serviço oferecer um acesso rápido e global aos dados, ao mesmo tempo que lhe dá controlo sobre onde as mensagens são armazenadas. O Pub/Sub pode armazenar automaticamente mensagens publicadas na região mais próxima dos subscritores ou pode configurá-lo para usar uma região específica ou um conjunto de regiões através de políticas de armazenamento de mensagens. Google Cloud
Em seguida, o Pub/Sub entrega as mensagens aos subscritores em todo o mundo, independentemente do local onde as mensagens estão armazenadas. Os clientes do Pub/Sub não precisam de saber as localizações dos servidores aos quais se estão a ligar, porque os mecanismos de equilíbrio de carga globais direcionam o tráfego para oGoogle Cloud centro de dados mais próximo onde as mensagens são armazenadas.
O Dataflow é executado em regiões Google Cloud específicas. Ao executar pipelines paralelos em Google Cloud regiões separadas, pode isolar as suas tarefas de falhas que afetam uma única região. O diagrama mostra duas instâncias do mesmo pipeline, cada uma em execução numa região Google Cloud separada.
Os pipelines do Dataflow paralelos escrevem em duas regiões do BigQuery separadas, o que oferece redundância geográfica. Numa região, o BigQuery armazena automaticamente cópias dos seus dados em duas zonas diferentes Google Cloud . Para mais informações, consulte a secção Planeamento de desastres na documentação do BigQuery.