Resiliência do Data Lake e soluções analíticas na AWS

Por Hugo Rozestraten, Arquiteto de Soluções AWS Brasil e
Carolina Ferreira, Arquiteto de Soluções AWS Brasil

Uma das questões que surgem quando trabalhamos com Data Lake e soluções analíticas é a resiliência, uma vez que o consumo dos dados ganha cada vez mais importância para os negócios, e estes são impactados de diversas maneiras pela disponibilidade ou intermitência dos dados.

A resiliência é a capacidade de uma carga de trabalho se recuperar de interrupções de infraestrutura ou serviço, adquirir dinamicamente recursos de computação para atender à demanda e mitigar interrupções.

Do ponto de vista de negócio a resiliência está relacionada aos riscos potenciais que a perda, atraso, vazamento ou compromisso de dados pode trazer. Na indústria financeira, uma das mais avançadas neste assunto, o risco à resiliência é definido e gerenciado baseado em considerações de negócio:

• Impacto financeiro: calculado como perda de faturamento para cada minuto que uma aplicação está indisponível;
• Resposta a regulações: o potencial risco de uma multa ou restrições de negócio em função do não cumprimento das normas exigidas pelos órgãos regulatórios;
• Oportunidade de negócio: o impacto de perder clientes devido ao incidente de disponibilidade;
• Reputação: negócios de longo prazo impactados por exploração de incidentes pela imprensa;
• Usuários impactados: a magnitude do impacto aos clientes devido ao incidente;
• Perda de dados: risco de perda de informações confidenciais ou informações críticas de clientes durante o incidente;

Estes impactos de negócio, quando traduzidos para a arquitetura das aplicações de dados refletem em algumas perspectivas:

• Durabilidade: uma vez que o dado esteja armazenado, se houver algum incidente, há risco de perda de dados?
• Disponibilidade: em um incidente, quanto tempo os usuários ficam sem acesso aos dados? Qual o tempo para reestabelecer o acesso? Como ficam as integrações, elas são afetadas? Se tiver um pico de acessos, minha solução continua disponível?
• Latência: os usuários precisam ter acesso aos dados no momento apropriado para a tomada de decisões. Um incidente pode atrasar a entrega destes dados?
• Segurança: o acesso à informação está restrito às pessoas que podem acessá-las? Em caso de um incidente uma pessoa conseguiria acessar os dados sem a autenticação e autorização?
• Regulatória: a solução contém as certificações exigidas e está aderente aos processos estabelecidos pelos órgãos regulatórios?
• Custo: notadamente, soluções mais resilientes tendem a ter um custo mais elevado, pois partem do princípio da redundância e replicação para aumentar a tolerância a falhas, aumentando consideravelmente os componentes da arquitetura.

Aplicações tem requerimentos de disponibilidade e durabilidade apontados pelo RTO (Recovery time objective), tempo de recuperação após a falha, que reflete na indisponibilidade em tempo, e pelo RPO (Recovery point objective), que diz respeito aos dados perdidos gerados logo antes da falha e que ainda não tinham uma replicação ou cópia.

Na tabela a seguir, um exemplo da indústria financeira de classificação da criticidade de aplicações e seus respectivos RTO e RPO para desenho de soluções resilientes:

Observamos que, ambientes na categoria Platinum possuem RTO e RPO menores se comparados às outras classes. Isso se deve pois, na análise de negócio, seja pelo impacto financeiro, obrigações regulatórias ou outros fatores de risco, esses ambientes geram um prejuízo elevado caso sejam interrompidos.

Infraestrutura da AWS

Para entender as possibilidades de arquiteturas resilientes para o Data Lake e soluções analíticas na AWS, é importante entender sobre a estrutura de regiões e zonas de disponibilidade.

Regiões

Uma região na AWS é um local físico no mundo onde agrupamos datacenters. Chamamos de Zona de Disponibilidade (AZ) cada grupo lógico de datacenters dentro de uma região. Cada região da AWS consiste em várias AZs isoladas e separadas fisicamente em uma área geográfica, assim na Região sa-east-1 (São Paulo) temos conjuntos de datacenters separados para alta disponibilidade.

Cada AZ tem energia, refrigeração e segurança física independentes e está conectada por meio de redes redundantes de latência baixa.

Aplicações na AWS que necessitam de alta disponibilidade podem projetar seus aplicativos para serem executados em várias AZs, a fim de obter tolerância a falhas ainda maior dentro da mesma região. As regiões de infraestrutura da AWS atendem aos mais altos níveis de segurança, conformidade e proteção de dados.

Zonas de Disponibilidade

Uma zona de disponibilidade (AZ) é um ou mais datacenters distintos com energia, rede e conectividade redundantes em uma região da AWS.

Todas as AZs, em uma região estão interconectadas por redes de alta largura de banda e baixa latência, conforme figura acima. Fibra metropolitana dedicada e totalmente redundante são utilizadas para proporcionar redes de alto taxa de transferência e baixa latência.

Todo o tráfego entre as AZs é criptografado e cada AZ é fisicamente separada, por uma distância significativa (dezenas de quilômetros), das demais, embora todas estejam a um raio de até 100 km entre si.

Solução analítica

A solução analítica a seguir é composta por vários componentes, tendo como fonte de dados um ambiente “on premises”, que é o início de muitos ambientes analíticos na AWS.

Da ingestão até o consumo de dados, temos diferentes fontes de dados, como bases de dados relacionais, streaming de dados e arquivos. Estes são armazenados no Amazon S3, transformados pelo Amazon EMR e AWS Glue e consumidos usando um Data Warehouse Amazon Redshift e engine de query Amazon Athena. Quanto a questão de gerenciamento, a gestão de acessos é controlado pelo AWS Lake Formation e os dados são catalogados utilizando o AWS Glue data catalog.

Ingestão

Para a ingestão de dados de streaming temos opções que podem capturar, continuamente, gigabytes de dados por segundo de centenas de milhares de origens. Alguns exemplos são “clickstreams” de sites, streaming de eventos de banco de dados, transações financeiras, “feeds” de mídia social, logs de TI e eventos de rastreamento de local.

O Amazon Kinesis Data Streams (KDS) é um serviço de streaming de dados em tempo real com escalabilidade massiva e resiliência, é um serviço totalmente gerenciado pela AWS e você faz uma configuração de volume de dados por segundo e a infraestrutura do serviço é provisionada de forma transparente, com alta disponibilidade usando o conceito de Multi-AZ (múltiplas Availability zones).

O Amazon Kinesis Data Firehose é a maneira mais fácil de carregar de forma confiável dados de streaming em data lakes, datastores e serviços de análises. Ele pode capturar, transformar e entregar dados de streaming para os serviços Amazon S3, Amazon Redshift e Amazon Elasticsearch Service; endpoints HTTP genéricos e provedores de serviços como Datadog, New Relic, MongoDB e Splunk.  Sua infraestrutura também é provisionada de forma transparente, com alta disponibilidade usando o conceito de Multi-AZ (múltiplas zonas de disponibilidade).

O Amazon MSK é um serviço totalmente gerenciado que facilita a criação e execução de aplicativos que usam o Apache Kafka para processar dados de streaming. O Apache Kafka é uma plataforma de código aberto para criação de pipelines de dados de streaming e aplicativos em tempo real. O serviço também conta com disponibilidade em Multi-AZ, onde você configura a replicação para seus tópicos e eles são replicados em diferentes zonas de disponibilidade, assim como os brokers do Kafka, que você configura em 3 zonas de disponibilidade para failover automático.

Para a ingestão de dados a partir de Bancos de Dados três ferramentas são comumente usadas, de acordo com cada caso de uso:

• AWS Data Migration Service – full load e CDC (change data capture);
• AWS Lake Formation BluePrints – full load e incremental baseado em chave, setup muito rápido e fácil, que utiliza componentes do AWS Glue;
• Sqoop (dentro do Amazon EMR) – full load e incremental baseado em chave;

 AWS Data Migration Service

AWS Database Migration Service (AWS DMS) é um serviço na nuvem que facilita a migração de bases de dados relacionais, Data Warehouses, bases de dados NoSQL e outros tipos de armazenamento de dados. O AWS DMS permite fazer migrações de um só vez (full load) e replicar, de forma continua, as alterações da minha origem (CDC – Change Data Capture), possibilitando manter o destino em sincronia com a fonte de dado.

É possível fazer migrações homogêneas de uma tecnologia para ela mesma, como por exemplo de um Oracle on premises para um RDS Oracle na AWS, ou migrações heterogêneas, de uma plataforma para outra, como a migração de dados de um SQL Server para um MySQL. Para o tipo de migração heterogênea, pode-se usar o AWS Schema Conversion Tool (AWS SCT) para traduzir esquemas de banco de dados para uma nova plataforma.

Todas as origens e destinos suportados pelos AWS DMS podem ser consultados na documentação.

Lake Formation Blue Prints

O AWS Lake Formation é um serviço que facilita a configuração de um data lake seguro. O Lake Formation permite a coleta e catalogação de dados armazenados em bancos de dados e serviços de armazenamento de objeto, a movimentação de dados para um novo data lake no  Amazon S3, a limpeza e classificação dos dados utilizando algoritmos de Machine Learning e, por fim, a proteção no acesso de dados confidenciais

O Lake Formation cria um fluxo de trabalho que encapsula uma completa atividade de extração, transformação e carregamento (ETL) composto de várias tarefas. Os fluxos de trabalho geram crawlers, jobs e gatilhos do AWS Glue para orquestrar o carregamento e a atualização dos dados. Você também pode criar fluxos de trabalho no AWS Glue. Como o Lake Formation permite que você crie um fluxo de trabalho a partir de um blueprint, a criação desses fluxos de trabalho é simples e automatizada.

Sqoop

Apache Sqoop é uma ferramenta para transferência de dados entre os bancos de dados do Amazon S3, do Hadoop, do HDFS e do RDBMS. Por estar presente no Amazon EMR, o processo de implementação do Apache Sqoop pode ser feito em poucos cliques. O Sqoop consegue gravar uma saída para uma tabela do HCatalog no Amazon S3. Além disso, no EMR, o Sqoop pode ajudar na movimentação de dados provenientes de bancos de dados através da conexão JDBC com banco, como o MariaDB, PostgreSQL, SQL Server, MySQL, e Oracle.

Para a ingestão de armazenamento de arquivos e de bloco podemos utilizar as ferramentas: Transfer Family for SFTP e Data Sync.

AWS DataSync

O AWS DataSync é um serviço de transferência de dados online que simplifica, automatiza, e acelera a movimentação de dados entre os sistemas de armazenamento on premises e os serviços de armazenamento da AWS, e também entre os próprios serviços da AWS. Esse serviço automatiza grande parte do fluxo de movimentação de dados, como: monitoramento, escrita, criptografia, verificação de integridade de dados, otimização da largura de banda, e recuperação em caso de falha.

O AWS DataSync pode copiar dados entre Network File System (NFS), Server Message Block (SMB), AWS Snowcone, buckets do Amazon Simple Storage Service (Amazon S3) e arquivos armazenados no Amazon Elastic File System (Amazon EFS) ou Amazon FSx for Windows File Server.

AWS Transfer para SFTP

O AWS Transfer oferece transferência gerenciada de arquivos diretamente para o S3 (importação e exportação), sendo compatível com Secure File Transfer Protocol (SFTP), File Transfer Protocol over SSL (FTPS), e File Transfer Protocol (FTP). Com este serviço, não é preciso configurar infraestrutura, incluindo o ajuste de escalabilidade e arquitetura multi-AZ.

Armazenamento

O Amazon Simple Storage Service (Amazon S3) é um serviço de armazenamento de objetos que oferece escalabilidade líder do setor, disponibilidade de dados, segurança e performance.

A integração total do Amazon S3 com as ferramentas analíticas em alto volume, a possibilidade de trabalhar com arquivos de qualquer formato, a replicação de dados dentro da região e o baixo custo, fazem com que ele seja a solução ideal para a manutenção de todo dado bruto (raw data) ingerido, além de dados de análise gerados em volumes grandes, e particionados.

O Amazon S3 fornece recursos de gerenciamento fáceis de usar, de maneira que você possa organizar os dados e configurar controles de acesso refinados para atender a requisitos específicos, sejam comerciais, organizacionais ou de conformidade. O Amazon S3 foi projetado para 99,999999999% (11 9s) de durabilidade e armazena dados para milhões de aplicativos para empresas de todo o mundo.

Ainda com relação ao Amazon S3, isolamos os dados logicamente de forma que a gestão de acesso fique facilitada, criando separação entre dados brutos, stage, analíticos e dados de sandbox.

Os permissionamentos no Amazon S3 são muito granulares e podem ser totalmente controlados via AWS Lake Formation que é um serviço que torna mais fácil para você ingerir, limpar, catalogar, transformar e proteger seus dados e torná-los disponíveis para análise.

Todo dado no S3 é replicado pelo menos 6 (seis) vezes, em 3 conjuntos de data centers distintos na mesma região (por exemplo São Paulo), isto faz com que já tenhamos backup totalmente disponível de todo o dado, que ainda pode ser gerenciado através de versionamento de todos os objetos. Devido ao baixo custo de armazenamento nenhum dado bruto é apagado, e sim movido para modalidades de cobrança ainda menores como a classe de armazenamento  Glacier, permitindo que por questões de auditoria ou eventual mudança nas transformações seja possível reprocessar qualquer dado do Data Lake.

Processamento

O Amazon EMR é um serviço gerenciado com Spark e Hadoop (Hive, Sqoop, Pig, etc.) que permite a execução de processamento de dados de baixo custo e utiliza como armazenamento permanente o Amazon S3.

No Amazon EMR, os clusters transientes (clusters que são desligados automaticamente após a finalização dos Jobs) reduzem em geral para 5% da necessidade de tempo de máquina em um ambiente analítico. Além disso, com o Amazon EMR, é possível utilizar somente algumas máquinas ou escalar para centenas ou milhares de nós, fazendo com que linearmente possamos trabalhar com qualquer volume de dados.

Outro ponto importante é que para o mesmo dado no Amazon S3 podemos testar novas versões de software sem impacto para outras aplicações.

O Amazon EMR permite a utilização de Notebooks (Jupyter ou Zeppelin) que facilitam o desenvolvimento de novas transformações e scripts.

O AWS Lake Formation/Glue Workflow permite criar agendamento de steps no Amazon EMR utilizando um python shell, colocar dependências e ações em paralelo ou sequenciais, este mesmo local pode ser utilizado para disparar criação de tabelas, ou execução de procedures no Amazon Redshift.

Data Warehouse

Para a utilização de modelos multidimensionais o Amazon Redshift permite a união de dois mundos anteriormente separados, o Data Lake e o Data Warehouse.

Com o Amazon Redshift Spectrum podemos acessar dados no Data Lake no Amazon S3 em alta performance e realizar joins com tabelas de dimensões internas no Redshift. O Redshift Spectrum simplifica o acesso ao dado uma vez que em um único endpoint ODBC/JDBC pode-se realizar consultas em qualquer dado do Data Lake ou do próprio Redshift.

O Redshift possui snapshots automáticos, disponíveis em qualquer zona de disponibilidade da região em que estiver e, a qualquer momento, pode-se utilizar esses snapshots para a criação de um cluster restaurado ou restauração de tabelas individuais.

Exploração de Dados

O Amazon Athena é um serviço serverless (sem alocação de servidores) escalável que entrega um engine SQL com Presto direto para o Data Lake.

O baixo custo do serviço junto com a alta performance e escalabilidade que não necessita de nenhum setup, fazem com que consultas ad hoc possam ser executadas em poucos segundos, sem impactar o processamento em outros componentes da arquitetura como o EMR e Redshift.

É possível ter um controle de acesso e utilização granular para os grupos de usuários do Amazon Athena.

Resiliência da solução

Na figura abaixo temos os principais serviços das soluções analíticas e como eles são distribuídos, em sua maioria, automaticamente pelas zonas de disponibilidade de uma região.

Para a resiliência dos dados em uma região o Amazon S3 cria uma cópia automática de todos os seus dados em 3 zonas de disponibilidades distintas dentro da região, como São Paulo por exemplo. Desta forma, todo dado no Amazon S3 tem 6 cópias gerenciadas automaticamente, sem necessidade de configuração adicional e com dezenas de quilômetros entre cada data centers, o que garante recuperação mesmo em uma catástrofe de perda em até duas zonas de disponibilidade.

O versionamento é uma opção do Amazon S3 e pode ser usado para preservar, recuperar e restaurar todas as versões de cada objeto armazenado em um bucket do Amazon S3. Com o versionamento, você pode se recuperar, facilmente, de ações não intencionais do usuário e de falhas de aplicativo.

Esta replicação dos dados no S3 faz com que o processamento do Amazon EMR possa ocorrer em qualquer uma das AZs, sem necessidade de fixá-lo a uma AZ específica. Por característica transiente, este cluster pode subir em uma ou outra AZ, realizar o processamento e desligar, subindo na próxima execução em uma das outras AZs.

O Amazon Redshift replica todos os dados dentro de um cluster de Data Warehouse quando é carregado e também faz continuamente um backup dos dados novos para o S3. O Amazon Redshift mantém pelo menos três cópias de seus dados (a original, a réplica nos nós computacionais e uma cópia de backup no Amazon S3). A replicação para o S3, já permite que no caso de uma falha, o ambiente do Redshift seja reestabelecido em uma outra zona de disponibilidade da região, porém podemos aumentar essa segurança implementando a replicação do backup para uma outra região através da funcionalidade de replicação entre regiões.

O Amazon EMR tem volumes de armazenamento internos, porém os dados processados são sempre persistidos no Amazon S3, aproveitando a resiliência desta camada. Assim como no Redshift, no caso de perda de nós dentro do cluster eles são repostos sem perda de dado, e em caso de uma falha do cluster, em menos de 15 minutos pode ter outro cluster no ar em outra AZ ou na mesma conforme escolher.

O AWS DMS é criado em Multi-AZ tendo uma cópia síncrona para failover em outra AZ em caso de falha da principal para continuidade da replicação dos dados.

Os serviços gerenciados AWS Glue, AWS Lake Formation, Amazon AWS Transfer for SFTP, Amazon Kinesis e Amazon MSK, são serviços que estão disponíveis em 3 AZs, tendo failover transparente em caso de perda de uma AZ.

Recuperação de falhas

Se considerarmos um ambiente dentro de uma região, os componentes da arquitetura têm a resiliência própria de cada serviço. Por exemplo, uma falha de um nó de cluster de Redshift a recuperação é instantânea, pois o dado já está replicado em outro nó, e se houver a falha do cluster todo a recuperação é a partir do Amazon S3. A recuperação também pode ser feita de uma tabela caso tenha ocorrido algum erro humano ou de programação lógica. Por padrão, os snapshots do Redshift ocorrem a cada 5 GB de dados ou 8 horas, mas podem ser agendados para ocorrerem para uma frequência máxima de 1 hora.

A arquitetura como um todo tem a resiliência a falha completa de uma AZ.

Os dados no Amazon S3 são replicados 6 vezes e são a base de dados para o Amazon Athena e Amazon EMR, assim, sua alta disponibilidade e durabilidade entregam para o Athena e EMR um RPO bastante baixo. O backup via snapshot do Redshift por sua vez também está no Amazon S3.

Dentro de uma Região, considerando falha de uma AZ inteira (conjunto de data centers):

No caso de uma replicação entre regiões, o Amazon S3 já está disponível com RTO e RPO próximos a zero. Os dados do catálogo do Glue também podem ser replicados para uma região secundária, assim como os snapshots do Redshift. Neste caso, o Athena e o Glue estarão disponíveis como os dados do S3, enquanto que o Amazon EMR é disponibilizado em menos de 15 minutos, já o Redshift é restaurado a partir de um cross region snapshot em minutos com RPO de aproximadamente 2 horas de acordo com a agenda de snapshots.

Resiliência Multi-região

Para continuidade de negócios após a falha de uma região inteira, podemos habilitar a replicação de dados entre regiões (“Cross-region replication”, CRR) do Amazon S3, que realiza automaticamente a cópia dos arquivos gravados para a segunda região, por exemplo de São Paulo para uma região na América do Norte.

A replicação de dados do Amazon S3 permite a cópia automática e assíncrona dos objetos dos buckets. Os buckets configurados para replicação de objetos podem pertencer à mesma conta da AWS ou contas diferentes. O objeto pode ser replicado em um único bucket de destino ou em vários intervalos de destino. Os buckets de destino podem estar em diferentes regiões da AWS ou na mesma região que o bucket de origem.

Esta cópia para outra região permite uma recuperação próxima a zero em tempo (RTO=0) e com um dígito de segundos de diferença (RPO <10 segundos) mesmo com a falha de uma região inteira.

O Amazon Redshift também pode ser configurado para copiar automaticamente snapshots para outra região da AWS, você especifica a região da AWS de destino para a qual copiar os snapshots. Para snapshots automatizados, você também pode especificar o período de retenção para mantê-los na região da AWS de destino. Depois que um snapshot automatizado é copiado para a região da AWS de destino e atingir o período de tempo de retenção lá, ele será excluído da região da AWS de destino.

Para alcançar os níveis mais altos de disponibilidade, além dos serviços de replicação de dados entre regiões, a automação de infraestrutura como código com o AWS CloudFormation é muito utilizada. Pode-se criar a mesma infraestrutura de uma região em outra, permitindo uma consistência e uniformidade nas configurações e tamanhos de cada serviço, como Redshift e EMR.

Para criar uma infraestrutura espelho em outra região a partir de um template de Clouformation com EMR e Redshift leva de 10 a 15 minutos, se não houver estes componentes o tempo é abaixo de 5 minutos.

O Amazon Route 53, serviço de DNS global, pode ser usado para apontar nomes globais como failover entre regiões para APIs baseado em disponibilidade ou latência.

O Amazon Redshift pode ter a resiliência aumentada, através de uma arquitetura multi-cluster, com uso do Route 53 e carga em duplicada em paralelo.

Usando uma técnica de “dual load” e o Route 53 para acesso via DNS, é possível criar um ambiente de Redshift ativo-ativo, reduzindo a próximo de zero o RPO e RTO no caso de falha de uma AZ inteira.

A recuperação da AZ que falhou é feita a partir de um snapshot e aplicando as cargas das últimas duas horas, lembrando que os dados no Redshift via de regra são carregados e mantidos no S3, estando totalmente disponíveis para uma nova carga.

Resumo

A resiliência do Amazon S3 traz como base um ambiente com durabilidade muito alta 99.999999999%, disponibilidade de 99.99%, e RPOs e RTOs próximos a zero para os dados do Amazon S3, e por consequência para as aplicações que os consomem.

O armazenamento usando Amazon Redshift nativamente atende a maioria dos ambientes analíticos, porém quando necessário um RTO e RPO muito baixos é possível trabalhar com ambientes ativo-ativo, com dual-load. Porém indicamos estes ambientes somente para cargas de trabalho muito críticas, e dados que realmente tenham impacto no negócio em caso de perda ou tempo de recuperação de 15 minutos.

Pensando em um ambiente de continuidade de negócios, a cópia automatizada de dados Multi-região permite uma recuperação total do ambiente com RTO de segundos.

Sobre os autores

Carolina Ferreira é arquiteta de soluções na AWS para clientes de vários segmentos, com área de aprofundamento em Analytics.

Hugo Rozestraten é arquiteto de soluções especialista em Analytics na AWS e atua com os clientes da América Latina.

Referências:

https://d1.awsstatic.com/Industries/Financial%20Services/Overview/Resilient%20Applications%20on%20AWS%20for%20Financial%20Services.pdf

https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/wellarchitected-reliability-pillar.pdf#s-99.99-scenario

https://aws.amazon.com/blogs/big-data/building-multi-az-or-multi-region-amazon-redshift-clusters/

Use seus dados para impulsionar o crescimento do negócio. Inove continuamente usando o data flywheel.