Confiabilidade: planejamento de desastres

Neste documento, você verá como a confiabilidade se aplica ao planejamento de desastres. Embora o termo de desastre possa invocar visões de desastres naturais, o escopo desta seção aborda falhas específicas da perda de uma máquina individual até a perda catastrófica de uma região. O primeiro é uma ocorrência cotidiana que é processada automaticamente pelo BigQuery. Já o segundo é algo que os clientes podem precisar projetar para processar a arquitetura que é necessária. É importante entender em qual escopo o planejamento de desastres passa para a responsabilidade do cliente.

O BigQuery oferece um SLA de 99,99% de tempo de atividade líder do setor. Isso é possível com a arquitetura regional do BigQuery que grava dados em duas zonas diferentes e provisiona capacidade de computação redundante. É importante lembrar que o SLA do BigQuery é o mesmo para regiões, como us-central1, e multirregiões, como EUA.

Tratamento automático de cenários

Como o BigQuery é um serviço regional, é de responsabilidade do BigQuery lidar com a perda automática de uma máquina ou mesmo de uma zona inteira. O fato de o BigQuery ser criado com base em zonas é abstraído dos usuários.

Perda de uma máquina

As falhas de máquina são uma ocorrência diária em uma escala em que o Google opera. O BigQuery foi projetado para lidar com falhas de máquina automaticamente, sem qualquer impacto na zona contida.
Internamente, a execução de uma consulta é dividida em pequenas tarefas que podem ser enviadas em paralelo para várias máquinas. A perda ou degradação repentina do desempenho da máquina é processada automaticamente pelo reenvio de trabalho para uma máquina diferente. Esse tipo de abordagem é crucial para reduzir a latência de cauda.

O BigQuery utiliza a codificação Reed–Solomon para armazenar uma cópia de seus dados de maneira eficiente e durável. No caso improvável de que várias falhas de máquina causem a perda de uma cópia zonal, os dados também são armazenados da mesma maneira em pelo menos uma outra zona. Nesse caso, o BigQuery detectará o problema e fará uma nova cópia zonal dos dados para restaurar a redundância.

Perda de uma zona

A disponibilidade subjacente de recursos de computação em qualquer zona não é suficiente para atender ao SLA de tempo de atividade de 99,99% do BigQuery. Portanto, o BigQuery fornece redundância zonal automática para slots de dados e computação. Embora as interrupções zonais de curta duração não sejam comuns, elas acontecem. No entanto, a automação do BigQuery faz o failover das consultas para outra zona em um ou dois minutos de qualquer interrupção grave. As consultas já em andamento podem não ser recuperadas imediatamente, mas as consultas recém-emitidas serão. As consultas em andamento demorariam muito para serem concluídas enquanto as consultas recém-enviadas seriam concluídas com rapidez.

Mesmo que uma zona fique indisponível por um período mais longo, não ocorrerá nenhuma perda de dados, porque o BigQuery grava dados de maneira síncrona em duas zonas. Portanto, mesmo em caso de perda zonal, os clientes não terão interrupções no serviço.

Cenários que exigem planejamento ou recuperação

Perda de região

O BigQuery não oferece durabilidade ou disponibilidade no evento extraordinariamente improvável e sem precedentes de perda física da região. Isso é válido para configurações de "regiões e multirregiões". Portanto, manter a durabilidade e a disponibilidade nesse cenário requer o planejamento do cliente. No caso de perda temporária, como uma interrupção de rede, considere a disponibilidade redundante se o SLA de 99,99% do BigQuery não for considerado suficiente.

Para evitar a perda de dados diante de uma perda regional destrutiva, é necessário fazer backup dos dados em outra localização geográfica. Por exemplo, é possível periodicamente exportar um snapshot dos seus dados para o Google Cloud Storage em outra região geograficamente distinta. Isso pode ser feito conforme descrito no caso de uso de processamento de dados em lote.
No caso de multirregiões do BigQuery, evite fazer backup nas regiões dentro do escopo da multirregião. Por exemplo, não faça backup dos dados nos EUA para a região us-central1. A região e a multirregião podem compartilhar domínios de falha e ter um destino compartilhado em desastre. Em vez disso, faça backup dos dados em uma região fora dos EUA, como northamerica-northeast1. Se os requisitos de residência de dados exigirem que os backups sejam armazenados nos EUA, é melhor desativar o pareamento de duas regiões, como us-central1 e us-east1.

Para evitar a indisponibilidade estendida, é necessário que os dados sejam replicados e os slots sejam provisionados em dois locais geograficamente separados do BigQuery. Assim como antes, evite misturar regiões e multirregiões, já que elas podem ter compartilhado o destino em um desastre.

A arquitetura mais confiável para uma configuração redundante da região é executar a quente-quente, também conhecido como ativo-ativo. Isso significa que a carga de trabalho é executada em paralelo na região principal e secundária. Embora ela seja mais cara, essa região garante a verificação contínua e funcionará se for preciso fazer failover para ela. Se a disponibilidade durante uma interrupção regional não for um problema, faça backup de dados em outra região para garantir a durabilidade.

Exclusão acidental ou corrupção de dados

Em virtude da arquitetura de controle de simultaneidade de várias versões do BigQuery, o BigQuery é compatível com viagens de tempo. Com esse recurso, é possível consultar dados de qualquer ponto nos últimos sete dias. Isso permite a restauração de todos os dados que foram excluídos, modificados ou corrompidos por engano em uma janela de sete dias. A viagem no tempo também funciona em tabelas excluídas.

O BigQuery também permite criar tabelas de snapshots. Com esse recurso, é possível fazer backup explicitamente de dados na mesma região por mais de sete dias na janela de viagem. Um snapshot é simplesmente uma operação de metadados e não resulta em nenhum byte de armazenamento extra. Isso pode aumentar a proteção contra exclusão acidental, mas não aumenta a durabilidade dos dados.

Casos de uso para recuperação de desastres

Análise em tempo real

Nesse caso de uso, os dados de streaming estão sendo ingeridos continuamente dos registros de endpoints no BigQuery. Proteger contra indisponibilidade estendida do BigQuery para toda a região requer replicar continuamente dados e slots de provisionamento em uma região diferente. Como a arquitetura é resiliente à indisponibilidade do BigQuery devido ao uso do Pub/Sub e do Dataflow no caminho de ingestão, esse alto nível de redundância provavelmente gerará gastos desnecessários.

Supondo que o usuário tenha configurado os dados do BigQuery em us-east4 para serem exportados todas as noites usando jobs de exportação para o Cloud Storage na classe Archive Storage em us-central1. Isso proporciona um backup durável em caso de perda de dados catastrófica na região us-east4. Nesse caso, o objetivo de ponto de recuperação (RPO) é de 24 horas, já que o último backup exportado pode ter até 24 horas de idade no pior dos casos. O objetivo de tempo de recuperação (RTO) é, potencialmente, dias, porque os dados precisam ser restaurados do backup do Cloud Storage para o BigQuery em us-central1. Se o BigQuery for provisionado em uma região diferente de onde os backups são colocados, os dados precisarão ser transferidos para essa região primeiro. Observe também que, a menos que você tenha comprado slots redundantes na região de recuperação com antecedência, pode haver um atraso extra ao receber a capacidade necessária do BigQuery provisionada de acordo com a quantidade solicitada.

Processamento de dados em lote

Para esse caso de uso, é essencial para os negócios que um relatório diário seja concluído em um prazo fixo a ser enviado para um regulador. A implementação da redundância executando duas instâncias separadas de todo o pipeline de processamento provavelmente é um gasto necessário. Usar duas regiões separadas, como us-west1 e us-east4, fornece separação geográfica e dois domínios de falha independentes em caso de indisponibilidade estendida de uma região ou até mesmo o evento improvável de perda permanente de região.

Supondo que o relatório seja entregue exatamente uma vez, precisamos reconciliar o caso esperado de ambos os pipelines com êxito. Uma estratégia razoável é simplesmente escolher o resultado do pipeline terminar primeiro, por exemplo, notificando um tópico do Pub/Sub sobre a conclusão bem-sucedida. Como alternativa, substitua o resultado e reverta o objeto do Cloud Storage. Se o pipeline terminar de gravar dados corrompidos, será possível recuperar restaurando a versão gravada pelo pipeline com conclusão primeiro no Cloud Storage.

Próximas etapas