Confiabilidade no Azure Data Factory

O Azure Data Factory permite que você crie pipelines de dados flexíveis e poderosos para integração de dados sem servidor e transformação de dados. Como um serviço do Azure, o Data Factory fornece uma variedade de recursos para dar suporte aos seus requisitos de confiabilidade.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Data Factory resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) do Data Factory.

Visão geral da arquitetura de confiabilidade

O Data Factory consiste em vários componentes de infraestrutura. Cada componente dá suporte à confiabilidade da infraestrutura de várias maneiras.

Os componentes do Data Factory incluem:

• O serviço principal do Data Factory, que gerencia gatilhos de pipeline e supervisiona a coordenação das atividades de pipeline. O serviço principal também gerencia metadados para cada componente no data factory. A Microsoft gerencia o serviço principal.

• Runtimes de integração (IRs), que se conectam aos repositórios de dados e executam as atividades definidas no seu pipeline. Existem diferentes tipos de relatórios de imposto de renda.

  • IRs gerenciados pela Microsoft, que incluem o Azure IR e o Azure e SQL Server Integration Services (Azure-SSIS IR). A Microsoft gerencia os componentes que compõem esses runtimes. Em alguns cenários, você define configurações que afetam a resiliência de suas IRs.

  • Runtimes de integração auto-hospedada (SHIRs). A Microsoft fornece software que você pode executar em sua própria infraestrutura de computação para executar algumas partes de seus pipelines do Data Factory. Você é responsável pela implantação e gerenciamento de recursos de computação e pela resiliência desses recursos de computação.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Quando você usa o Data Factory, é importante se preparar para falhas transitórias, especialmente quando você projeta pipelines e atividades.

Idempotência

As suas atividades de pipeline devem ser idempotentes, o que significa que elas podem ser executadas novamente várias vezes sem causar efeitos adversos. Se ocorrer uma falha transitória como uma falha de rede ou uma interrupção de zona de disponibilidade, o Data Factory poderá executar novamente as atividades de pipeline. Essa nova execução pode criar registros duplicados.

Para evitar a inserção de registro duplicada devido a uma falha transitória, implemente as seguintes práticas recomendadas:

• Use identificadores exclusivos para cada registro antes de gravar no banco de dados. Essa abordagem pode ajudá-lo a encontrar e eliminar registros duplicados.

• Use uma estratégia upsert para conectores que dão suporte a upsert. Antes que ocorra a inserção de registro duplicada, use essa abordagem para verificar se já existe um registro. Se existir, atualize-o. Se ele não existir, insira-o. Por exemplo, comandos SQL como MERGE ou ON DUPLICATE KEY UPDATE usam essa abordagem de upsert.

• Use estratégias de ação de cópia. Para obter mais informações, consulte Verificação de consistência de dados na atividade de cópia.

Políticas de repetição

Você pode usar políticas de repetição para configurar partes do pipeline para tentar novamente se houver um problema, como falhas transitórias em recursos conectados. No Data Factory, você pode configurar políticas de repetição nos seguintes tipos de objeto de pipeline:

• Gatilhos de janela em cascata
• Atividades de execução

Para obter mais informações sobre como alterar ou desabilitar políticas de repetição para os seus gatilhos e atividades do data factory, confira Execuções de pipeline e gatilhos.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

O Data Factory dá suporte à redundância de zona, que fornece resiliência a falhas em zonas de disponibilidade.

Cada parte do Data Factory dá suporte à redundância de zona:

• Serviço principal: A Microsoft gerencia os componentes no serviço principal do Data Factory e os espalha entre zonas de disponibilidade.

  No entanto, após uma falha de zona, a Microsoft não garante o estado dos gatilhos periódicos.

• Irs: O suporte à redundância de zona depende do tipo de IR que você usa.

  • Um IR do Azure dá suporte à redundância de zona e a Microsoft gerencia essa funcionalidade.

    

  • Uma Azure-SSIS IR exige que você implante pelo menos dois nós. Esses nós são alocados automaticamente em zonas de disponibilidade diferentes.

    O diagrama a seguir mostra um pipeline com redundância de zona e um runtime de integração Azure-SSIS com dois nós que são implantados em zonas diferentes:

    

  • Um SHIR confere a responsabilidade de implantar a infraestrutura computacional para hospedar o runtime. Você pode implantar vários nós, como VMs (máquinas virtuais) individuais, e configurá-los para alta disponibilidade. Em seguida, você pode distribuir esses nós entre várias zonas de disponibilidade. Para obter mais informações, consulte Alta disponibilidade e escalabilidade.

Requirements

Os recursos do Data Factory com redundância de zona podem ser implantados em qualquer região que dê suporte a zonas de disponibilidade.

Custo

• Serviço principal: Nenhum custo adicional se aplica à redundância de zona.

• Irs: O custo da redundância de zona varia dependendo do tipo de IR que você usa.

  • Um IR do Azure inclui redundância de zona sem custo adicional.

  • Uma Azure-SSIS IR exige que você implante pelo menos dois nós para obter redundância de zona. Para obter mais informações sobre como cada nó é cobrado, confira Exemplo de preços: executar pacotes SSIS em um Azure-SSIS IR.

  • Um SHIR exige que você implante e gerencie a infraestrutura de computação. Para obter resiliência de zona, você precisa espalhar seus recursos de computação em várias zonas. Dependendo do número de nós que você implanta e como os configura, você pode incorrer em custos extras dos serviços de computação subjacentes e de outros serviços de suporte. Não há nenhum custo extra para executar o SHIR em vários nós.

Configurar o suporte à zona de disponibilidade

• Serviço principal: Nenhuma configuração é necessária. O serviço principal do Data Factory dá suporte automaticamente à redundância de zona.

• Irs:

  • Um IR do Azure: nenhuma configuração é necessária. O IR do Azure habilita automaticamente a redundância de zona.

  • Um Azure-SSIS IR: nenhuma configuração necessária. Um Azure-SSIS IR habilita automaticamente a redundância de zona quando ele é implantado com dois ou mais nós.

  • Um SHIR exige que você configure sua própria resiliência, o que inclui a disseminação de seus nós em várias zonas de disponibilidade.

Planejamento e gerenciamento de capacidade

• Serviço principal: O serviço principal do Data Factory é dimensionado automaticamente com base na demanda e você não precisa planejar ou gerenciar a capacidade.

• Irs:

  • Um IR do Azure é dimensionado automaticamente com base na demanda e você não precisa planejar ou gerenciar a capacidade.

  • Uma Azure-SSIS IR exige que você configure especificamente o número de nós que você usa. Para se preparar para a falha da zona de disponibilidade, considere o excesso de provisionamento da capacidade do seu IR. O superprovisionamento permite que a solução tolere algum grau de perda de capacidade e ainda continue funcionando sem desempenho degradado. Para obter mais informações, consulte Gerenciar capacidade por excesso de provisionamento.

  • Um SHIR exige que você configure sua própria capacidade e dimensionamento. Considere o excesso de provisionamento ao implantar um SHIR.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando os recursos do Data Factory são configurados para redundância de zona e todas as zonas de disponibilidade estão operacionais.

• Roteamento de tráfego entre zonas: Durante operações normais, o Data Factory distribui automaticamente atividades de fluxo de dados, gatilhos e outros trabalhos entre instâncias saudáveis em cada zona de disponibilidade.

• Replicação de dados entre zonas: Em geral, o Data Factory é um serviço sem estado, portanto, nenhum estado precisa ser replicado entre zonas.

  No entanto, os gatilhos periódicos contêm estado, que pode não ser totalmente replicado entre zonas.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando os recursos do Data Factory são configurados para redundância de zona e há uma interrupção da zona de disponibilidade.

• Detecção e resposta: A plataforma Data Factory é responsável por detectar uma falha em uma zona de disponibilidade e responder. Não é necessário fazer nada para iniciar um failover de zona em seus pipelines ou outros componentes.

• Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar o Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas do Resource Health para notificá-lo de problemas. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.

• Solicitações ativas: todos os pipelines e gatilhos em andamento continuam sendo executados e você não enfrenta nenhuma interrupção imediata de uma falha de zona. No entanto, as atividades em andamento durante uma falha de zona podem falhar e ser reiniciadas. É importante projetar atividades para serem idempotentes, o que as ajuda a se recuperar de falhas de zona e outras falhas. Para obter mais informações, consulte Resiliência a falhas transitórias.

• Tempo de inatividade esperado: Nenhum tempo de inatividade é esperado durante uma falha de zona.

• Perda de dados esperada: No geral, o Data Factory é um serviço sem estado, portanto, nenhuma perda de dados é esperada durante uma falha de zona.

  No entanto, se você usar um gatilho periódico, o estado do gatilho poderá ser perdido após uma falha de zona. Você deve reiniciar ou executar novamente os gatilhos que estavam em execução no momento da falha de zona.

Recuperação de zona

Quando a zona de disponibilidade é recuperada, o Data Factory faz failback automaticamente para a zona original. Não é necessário fazer nada para iniciar um failback de zona em seus pipelines ou outros componentes.

No entanto, se você usar um SHIR, talvez seja necessário reiniciar os recursos de computação se eles tiverem sido interrompidos.

Testar falhas em zonas

Para o serviço principal e para IRs do Azure e do Azure-SSIS, o Data Factory gerencia o roteamento de tráfego, o failover e o failback para recursos com redundância de zona. Como esse recurso é totalmente gerenciado, você não precisa iniciar nem validar processos de falha da zona de disponibilidade.

Para SHIRs, você pode usar o Azure Chaos Studio para simular uma falha de zona de disponibilidade em uma VM do Azure.

Resiliência a falhas em toda a região

Os recursos do Data Factory são implantados em uma única região do Azure. Se a região ficar indisponível, sua fábrica de dados também ficará indisponível. No entanto, existem abordagens que você pode usar para ajudar a garantir resiliência diante de falhas regionais. Essas abordagens dependem de se a fábrica de dados está em uma região pareada ou não pareada, e dos seus requisitos e configurações específicos.

Failover gerenciado pela Microsoft para uma região emparelhada

O Data Factory dá suporte ao failover gerenciado pela Microsoft para data factories em regiões emparelhadas, com exceção do Sul do Brasil e Sudeste da Ásia. No caso improvável de uma falha prolongada na região, a Microsoft pode iniciar um failover regional da instância do Data Factory.

Devido aos requisitos de residência de dados no Sul do Brasil e no Sudeste Asiático, os dados do Data Factory são armazenados somente na região local usando o armazenamento de redundância de zona do Azure Storage. Para o Sudeste Asiático, todos os dados são armazenados em Cingapura. Para o Sul do Brasil, todos os dados são armazenados no Brasil.

Para data factories em regiões não emparelhadas ou no Sul do Brasil ou Sudeste da Ásia, a Microsoft não executa failover regional em seu nome.

Failover de IRs

Para se preparar para um failover, pode haver algumas considerações adicionais, dependendo do IR usado por você.

• Você pode configurar o IR do Azure para resolver automaticamente a região que ele usa. Se a região estiver definida para resolver automaticamente e houver uma interrupção na região primária, o IR do Azure fará failover automaticamente para a região emparelhada. Esse failover está sujeito a limitações. Para configurar a região do IR do Azure para a sua implementação de atividade ou expedição na configuração do IR, defina a região para resolução automática.

• O failover do Azure-SSIS IR é gerenciado separadamente de um failover gerenciado pela Microsoft do data factory. Para obter mais informações, consulte soluções personalizadas de várias regiões para resiliência.

• Um SHIR é executado na infraestrutura pela qual você é responsável, portanto, um failover gerenciado pela Microsoft não se aplica a SHIRs. Para obter mais informações, consulte soluções personalizadas de várias regiões para resiliência.

Reconfiguração pós-failover

Depois que um failover gerenciado pela Microsoft for concluído, você poderá acessar o pipeline do Data Factory na região emparelhada. No entanto, após a conclusão do failover, talvez seja necessário executar alguma reconfiguração para IRs ou outros componentes. Esse processo inclui o restabelecimento da configuração de rede.

Soluções personalizadas de várias regiões para resiliência

Se você precisar que seus pipelines sejam resilientes a interrupções regionais e precisar de controle sobre o processo de failover, considere usar um pipeline controlado por metadados.

• Configure o controle do código-fonte para o Data Factory para controlar e auditar quaisquer alterações nos metadados. Você pode usar essa abordagem para acessar seus arquivos JSON de metadados para pipelines, conjuntos de dados, serviços vinculados e gatilhos. O Data Factory dá suporte a diferentes tipos de repositório Git, como o Azure DevOps e o GitHub. Para obter mais informações, consulte o controle de origem no Data Factory.

• Use um sistema de CI/CD (integração contínua e entrega contínua), como o Azure DevOps, para gerenciar seus metadados e implantações de pipeline. Você pode usar CI/CD para restaurar rapidamente as operações em uma instância em outra região. Se uma região não estiver disponível, você poderá provisionar um novo data factory manualmente ou por meio da automação. Depois que o novo data factory for criado, você poderá restaurar os seus pipelines, conjuntos de dados e JSON de serviços vinculados do repositório Git existente. Para obter mais informações, consulte BCDR (continuidade de negócios e recuperação de desastre) para pipelines do Data Factory e do Azure Synapse Analytics.

Dependendo do IR que você usa, pode haver outras considerações.

• Uma Azure-SSIS IR usa um banco de dados armazenado no Banco de Dados SQL do Azure ou na Instância Gerenciada de SQL do Azure. Você pode configurar a replicação geográfica ou um grupo de failover para esse banco de dados. O banco de dados Azure-SSIS está localizado em uma região primária do Azure que tem acesso de leitura/gravação. O banco de dados é replicado continuamente para uma região secundária que tem acesso somente leitura. Se a região primária não estiver disponível, um failover será disparado, o que fará com que os bancos de dados primários e secundários troquem de funções.

  Você também pode configurar um par do Azure SSIS IR em espera duplo que funcione em sincronia com um Banco de Dados SQL do Azure ou um grupo de failover da Instância Gerenciada de SQL.

  Para obter mais informações, consulte Configurar um IR Azure-SSIS para BCDR.

• Um SHIR é executado na infraestrutura que você gerencia. Se o SHIR for implantado em uma VM do Azure, você poderá usar o Azure Site Recovery para disparar o failover de VM para outra região.

Backup e restauração

O Data Factory dá suporte a CI/CD por meio da integração de controle do código-fonte, para que você possa fazer backup dos metadados de uma instância do data factory. Os pipelines de CI/CD implantam esses metadados diretamente em um novo ambiente. Para obter mais informações, consulte CI/CD no Data Factory.

Contrato de nível de serviço

O acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O Data Factory fornece SLAs de disponibilidade separados para:

• A taxa de sucesso das chamadas à API que você faz, como aquelas para gerenciar o data factory.
• O número de execuções de atividade que começam a ser executadas.

As execuções de atividade podem ser brevemente adiadas e exigem que todas as dependências necessárias para executar a tarefa tenham sido atendidas.

Conteúdo relacionado

• Confiabilidade no Azure