Armazenando dados relacionais no Azure

Os dados estruturados possuem uma estrutura bem definida. Geralmente, são armazenados em tabelas de bancos de dados que contêm linhas, colunas e chaves. E que de certa forma estão relacionados, os chamados dados relacionais. Esse tipo de dado é constantemente utilizado por aplicações, como sites de vendas on-line por exemplo.

A seguir serão apresentados recursos voltados para o armazenamento de dados estruturados no Azure.

Banco de dados SQL 

É uma opção PaaS, recomendada para criação de aplicativos baseados em nuvem. Oferece dimensionamento automático, além de permitir o uso um banco de dados individual ou um conjunto auto escalável. Suporta até 100 TB de dados, possui SLA de 99,995%, RPO de 5 segundos e RTO de 30 segundos. 

Há dois modelos de compra:

DTU (Database Transaction Unit): é uma medida combinada dos recursos de computação, armazenamento e Entrada/Saída. É uma opção pré-configurada. Não está disponível na instância gerenciada do SQL. 

vCores: são núcleos virtuais de processamento. É possível escolher a quantidade de vCores de acordo com as necessidades dos recursos a serem implantados. Esse modelo é recomendado por permitir selecionar, de forma independente, os recursos de computação e armazenamento. 

O Banco de Dados SQL do Azure oferece três camadas de serviço: 

Uso geral: oferece opções balanceadas de computação e armazenamento.

Comercialmente crítica:  destinada para aplicativos que exigem baixa latência e maior resiliência.

Hiper escala: indicado para cenários que exigem armazenamento altamente escalonável e alta performance de leitura.

Instância gerenciada SQL 

Opção PaaS, a maioria dos recursos do SQL Server estão disponíveis. Ideal para cenários onde há migração para o Azure sem a necessidade de recriar as aplicações. 

Utiliza o modo vCores, permitindo o cliente definir o máximo de núcleos e o máximo de armazenamento alocado para a instância. Além de oferecer vários outros benefícios: 

• Atualizações automáticas
• Backup automatizado
• Alta disponibilidade
• Menor sobrecarga de gerenciamento 

SQL em VMs do Azure 

É uma versão do SQL Server executada em uma VM do Azure. Nessa opção, ainda que o Azure possa ajudar a automatizar backups e patchs de segurança o cliente fica responsável por atualizar e aplicar patches no sistema operacional e no SQL Server. É recomendada para aplicativos que requerem acesso no nível do sistema operacional. 

Escalabilidade

O Banco de Dados SQL do Azure pode ser facilmente escalado. Há dois tipos de escalonamento que podem ser implementados:

Vertical: permite aumentar ou diminuir os recursos de computação de um banco de dados individual. Pode ser usado em cenários onde a demanda de uso é imprevisível ou variável. Os conjuntos são dimensionados automaticamente conforme a necessidade de uso. Há três opções de conjunto auto escalável:

• Basic: permite o dimensionamento automático de até 5 eDTUs por banco de dados.
• Standard: permite o dimensionamento automático de até 100 eDTUs por banco de dados.
• Premium: permite o dimensionamento automático de até 1000 eDTUs por banco de dados.

 Horizontal: é a adição ou remoção de instâncias de bancos de dados para ajustar a capacidade ou o desempenho de forma geral. Há dois tipos de escala horizontal:

• Expansão de leitura: é possível isolar carga de trabalho somente leitura da carga de leitura e gravação. Instâncias somente leitura são criadas, e é feito o balanceamento de carga de forma a melhorar a performance das instâncias de leitura e gravação. Esse tipo de recurso pode ser utilizado, por exemplo, em sistemas de transações bancárias. 
• Fragmentação: usada em cenários onde há a necessidade de distribuir a cargas de trabalho. Os fragmentos de dados são distribuídos entre as instâncias. Dentre os contextos aplicáveis temos:

1. A necessidade de isolar fisicamente dados de diferentes clientes.
2. Atender requisitos de conformidade.
3. Aplicativos que fazem grandes quantidades de solicitações de transações ao ponto de saturar o banco de dados.

Disponibilidade 

Na camada de serviço de Uso Geral os bancos de dados e as instâncias gerenciadas possuem a mesma arquitetura de disponibilidade. Considere a imagem a seguir para a explicação.

Ao fazer uma requisição, a aplicação se conecta ao gateway que direciona a solicitação para o servidor. A réplica primária utiliza um SSD atachado localmente. Os arquivos de dados e os logs são mantidos no armazenamento Premium com redundância local. Os arquivos de backup são mantidos no armazenamento Standard, que tem suporte ao RA-GRS por padrão.

O Banco de Dados SQL é integrado ao Azure Service Fabric. Caso o Service Fabric identifique que o nó primário está indisponível, o alocador de serviço procura um nó com capacidade disponível e cria uma nova instância de SQL Server. Os arquivos são anexados e os gateways são atualizados para direcionar as requisições para o novo nó. 

Na camada Comercialmente Crítica, a implantação é similar à de um Grupo de Disponibilidade Always On. A figura a seguir ilustra seu funcionamento.

Os arquivos de dados e logs são executados diretamente no disco, isso reduz consideravelmente a latência. Existem três réplicas secundárias, uma delas pode ser usada como ponto de extremidade somente leitura (sem custo adicional). Essa expansão de leitura dá suporte à persistência de sessão. Com isso, se a sessão somente leitura for interrompida por indisponibilidade da réplica, ela pode ser redirecionada para outra réplica secundária. No entanto, se o aplicativo estiver usando a réplica primária e for redirecionado para uma sessão somente leitura poderá não conseguir visualizar imediatamente as atualizações. Isso devido à latência de replicação assíncrona do log de transações. 

A camada de Hiper escala possui uma arquitetura diferente, pois faz utilização de cache e paginação para um desempenho melhor. O uso de servidores em paralelo, permite dimensionar os recursos horizontalmente. Dando suporte a banco de dados de até 100 TB. É possível criar snapshots independentemente do tamanho, e a restauração pode ser feita em minutos. 

Nessa abordagem o serviço de log é usado para alimentar as réplicas e os servidores de paginação. As transações podem ser confirmadas quando o log é armazenado na área de persistência de dados. Diferente das outras camadas é possível definir se serão usadas réplicas juntamente com o nó primário. Há suporte para até 4 réplicas secundárias, que podem ser utilizadas para expansão de leitura. 

A existência de réplicas impacta no tempo de recuperação. Caso não tenha réplicas o cenário será semelhante ao da camada de serviço de Uso Geral. Se existirem réplicas a recuperação será mais rápida, similar à camada de serviço Comercialmente Crítica. 

A camada Comercialmente Crítica oferece alto desempenho e disponibilidade para cargas de trabalho com pequenas gravações de log que exigem baixa latência. Em contrapartida a camada de serviço de Hiper escala dá suporte a taxa de transferência de registro maior em termos de MB/s, bancos de dados maiores e até quatro réplicas para elevar a escala de leitura. Com isso, é preciso levar em conta a carga de trabalho na hora de escolher entre as duas abordagens. 

Proteção de dados 

O armazenamento de dados implica na implementação de soluções para que tais dados não sejam acessados de forma indevida. 

Uma das formas de gerenciar a integridade dos dados é fazendo sua classificação de forma a implementar medidas de proteção de acordo com a sensibilidade da informação. Dentre rótulos de classificação temos: 

• Público
• Confidencial
• Restritos 

Existem três estados básicos para os dados: 

• Dados inativos
• Dados em movimento
• Dados em processo 

Cada estado permite a implementação de métodos de criptografia diferentes. A tabela a seguir relaciona os estados a esses métodos.

Proteção de dados inativos 

A TDE (Transparent Data Encryption) faz a proteção do Bancos de Dados SQL do Azure, das Instâncias Gerenciadas SQL e do Azure Synapse Analytics (serviço de análise dados). Os dados são criptografados e descriptografados em tempo real sem a necessidade de alterações no aplicativo. Por padrão, a TDE vem habilitada em todos bancos de dados SQL do Azure desde fevereiro de 2019.

A TDE criptografa e descriptografa os dados no nível de paginação. À medida que são gravados nas páginas, os dados são criptografados e quando as páginas são lidas na memória os dados são descriptografados. A criptografia é feita utilizando uma chave simétrica, DEK (Data Encryption Key). 

O gerenciamento da TDE pode ser feito pelo serviço através de um certificado de servidor integrado que é armazenado no Azure Key Vault. Ou pelo cliente, que fornece o protetor de TDE e gerencia as chaves em um sistema próprio, implementando o Bring Your Own Key. 

Ao usar o TDE em Grupos de Disponibilidade Always On, o certificado usado na criptografia deve ser copiado em backup e restaurado nos outros servidores que hospedam as cópias do banco de dados. 

Proteção de dados em trânsito 

É feita com a utilização dos protocolos SSL (Secure Socket Layer) e TLS (Transport Layer Security), todas as conexões são criptografadas. A seguir temos cenários e as respectivas soluções para permitir conexões seguras. 

Cenário 1: conectar várias estações de trabalho locais a uma rede virtual do Azure. 

Solução: criar VPN site a site.

Cenário 2: conectar uma estação de trabalho local a uma rede virtual do Azure. 

Solução: criar VPN ponto a site.

Cenário 3: mover grandes conjuntos de dados através de um link WAN dedicado de alta velocidade. 

Solução: Usar Azure ExpressRoute. 

Cenário 4: administrar serviços de armazenamento via Portal Azure. 

Solução: todas as transações serão via HTTPS. É possível ainda usar a API REST para os serviços de armazenamento e Banco de Dados SQL. 

Proteção de dados em uso 

Há situações em que dados sensíveis precisam ser acessados por terceiros, mas esses dados não podem ser expostos completamente. Por exemplo, um serviço de atendimento ao cliente precisa verificar os usuários para quem estão ligando, mas não podem ver o número completo. Uma forma de resolver esse problema é o mascaramento de dados dinâmicos. 

A Máscara de Dados Dinâmicos é um recurso de segurança que, através de políticas, permite ocultar partes de dados sensíveis no resultado de uma consulta. A quantidade de dados a serem revelados pode ser definida de modo a causar o mínimo de impacto na camada de aplicativo. 

No portal do Azure é possível configurar a política de mascaramento apenas do Banco de Dados SQL. Para o mascaramento de dados dinâmicos podem ser usados cmdlets do PowerShell e a API REST. 

A tabela a seguir exemplifica o mascaramento de caracteres de acordo com tipo de dado.

É importante ressaltar que o mascaramento dinâmico de dados afeta apenas o resultado na camada de apresentação, os administradores do banco de dados sempre conseguirão ver os dados sem máscaras. 

Existe, ainda, uma opção para proteção de dados inativos e em trânsito, o Always Encrypted. Com esse recurso os dados sempre são criptografados, sendo descriptografados apenas para o processamento por parte dos aplicativos.

A figura a seguir ilustra o funcionamento do Always Encrypted.

São usados dois tipos de chave, chave de criptografia de coluna e chave mestra de coluna. A primeira é usada para criptografar as colunas, a segunda para criptografar uma ou mais chaves de coluna. O mecanismo de banco de dados guarda apenas os valores criptografados das chaves de criptografia de coluna e as informações sobre onde estão as chaves mestras. As chaves mestras podem ser guardadas no Azure Key Vault ou no repositório de certificados do Windows.

Para acessar os dados armazenados em uma coluna criptografada, o aplicativo deve usar um driver cliente com suporte ao Always Encrypted. A criptografia e descriptografia ocorre através do driver.  

O Always Encrypted não funciona com o mascaramento de dados dinâmicos. É preciso entender qual funcionalidade melhor atende a cada contexto. Cenários onde a administração do banco de dados é feita por terceiros o Always Encrypted é a melhor forma de proteger os dados. 

Azure SQL Edge 

É um banco de dados voltado para IoT (Internet of Things). Dispõe de funcionalidades para criação de uma camada de processamento e armazenamento de dados de alto desempenho para aplicações e soluções de IoT. Com ele é possível transmitir, processar e analisar dados relacionais e não relacionais, como JSON, grafos e séries temporais. 

O Azure SQL Edge está disponível em duas versões: 

Azure SQL Edge Developer: apenas para desenvolvimento, cada container de desenvolvimento é limitado a 4 núcleos e 32 GB de memória.

Azure SQL Edge: usado em produção. Cada container pode ter até 8 núcleos e 64 GB de memória. 

Há dois modos de implantação do Azure SQL Edge: 

Conectado: o Azure SQL Edge pode ser encontrado no Azure Marketplace e implantando como um módulo do Azure IoT Edge.

Desconectado: feita por meio de imagens de container do Azure SQL Edge que podem ser obtidas através de pull request no Docker Hub e implantadas como container autônomo do Docker ou em um cluster Kubernetes. 

O Azure SQL Edge é um aplicativo Linux em containers. Necessita de menos de 500 MB para inicialização. Com isso é possível executar aplicativos na maioria dos dispositivos IoT. Através dele é possível capturar dados contínuos em tempo real e integrar dados em soluções de dados organizacionais. 

Com os dados de IoT é possível obter diversos insights. O Azure SQL Edge possui um mecanismo de streaming interno para dar apoio. Esse mecanismo permite a transformação, agregação em janelas, detecção de anomalias simples, classificação de fluxos de dados de entrada. Há, também, um mecanismo de armazenamento de série temporal para armazenamento de dados indexados no tempo. 

O Azure SQL Edge é baseado na tecnologia do SQL Server. Com isso, possui os mesmos recursos de segurança do SQL Server Enterprise. As políticas e práticas de segurança são aplicáveis da nuvem para a borda. 

A segurança deve ser abordada em todos os aspectos da implantação: 

Plataforma e sistema: inclui o host físico do Docker, o sistema operacional e os elementos de rede que conectam dispositivos físicos a aplicativos e clientes.

Restrição de acesso: garantir que apenas pessoa autorizadas possam acessar, processo autenticação. E atribuir somente as permissões necessárias aos usuários autenticados, processo de autorização.

Banco de dados: aprimorar a segurança implementando a criptografia dos dados. Enquanto a TDE permite a conformidade com várias normas de segurança, O Always Encrypted faz a separação entre os usuários que detêm os dados e os que gerenciam os dados.

Aplicativos: permitir que apenas aplicativos a gravação de aplicativos cliente seguros, por exemplo. 

O Azure SQL Edge dá suporte a uma série de requisitos: 

Conectividade limitada: suporta soluções que funcionam com ou sem conexão com a rede. Além de possuir um banco de dados local que dispensa a necessidade de enviar todos os dados para um banco de dados baseado em nuvem, eliminando problemas com latência.

Privacidade e segurança de dados: implementa RBAC (Role-Based Access Control) e ABAC (Attribute Based Access Control), criptografia e classificação de dados. Permitindo maior proteção e controle de acesso aos dados.

Sincronização e conectividade: é possível trocar dados com outros sistemas de forma fácil. Como Azure SQL Server, SQL Server e Cosmos DB.

Familiaridade: possui a mesma base de código do SQL Server. Logo, desenvolveres habituados ao SQL Server podem reutilizar seus códigos. 

Azure Cosmos DB 

É um banco de dados NoSQL totalmente gerenciado. As atualizações, aplicações de patch e o gerenciamento de capacidade são feitos pelo Azure. Dentre os recursos oferecido temos: 

• Escalabilidade automática
• Alta disponibilidade, SLA de 99,999%
• APIs e SDKs de código aberto para linguagens mais populares
• Criação rápida sem análise de ETL sobre dados operacionais
• Distribuição de dados em várias regiões 

Os dados no Azure Cosmo DB são armazenados no formato ARS (atom-record-sequence). 

Diferenças Azure Table Storage e Azure Cosmos DB 

O Azure Table Storage é usado para o armazenamento de dados estruturados não relacionais na nuvem, onde chaves e atributos são armazenados sem um esquema definido. O que facilita a adaptação dos dados conforme as necessidades do aplicativo. Permite armazenar um grande volume de dados estruturados. É possível armazenar qualquer quantidade de entidades em uma tabela, até o limite da capacidade da conta de armazenamento. O Table Storage armazena conjuntos de valores que não necessitam de junções complexas, chaves estrangeiras ou procedimentos armazenados. Como, aplicativos Web, catálogos de endereço, informações de dispositivos. Além de permitir consultar dados de forma rápida utilizando um índice clusterizado, tipo de índice que determina a ordem em que as linhas de uma tabela são armazenadas no disco. 

Existem algumas diferenças entre o Azure Cosmos DB e o Azure Table Storage que precisam ser consideradas em um cenário de migração afim de evitar problemas. 

• A cobrança de uma tabela no Cosmos DB é feita de acordo com sua capacidade no momento de sua criação, mesmo que essa capacidade não seja usada em sua totalidade. Isso ocorre devido ao Cosmos DB usar um modelo de capacidade reservada, o que garante melhor desempenho. No Azure Table Storage a cobrança é com base na capacidade utilizada, em contrapartida a leitura de dados é mais lenta.
• O retorno das consultas do Cosmos DB não é classificado pela ordem da chave de partição e da chave de linha como no Table Storage.
• As chaves de linha no Cosmos DB são limitadas a 255 bytes.
• As operações em lote são limitadas a 2 MB.
• O Cosmos DB suporte CORS (Cross-origin Resource Sharing)
• No Cosmos DB letras maiúsculas são diferenciadas de letras minúsculas. Ao contrário do Table Storage. 

As aplicações que utilizam o Table Storage pode ser migradas para o Cosmos DB com poucas alterações de código. A API de tabelas do Cosmos DB e do Table Storage utilizam o mesmo modelo de dados de tabela e suportam as mesmas operações de criar, excluir, atualizar e consultar através de SDKs. 

O Cosmos DB dá suporte a várias APIs: 

Core (SQL): Possui latência de milissegundo com um único dígito para leitura e gravação. Banco de dados globalmente distribuído com failover automático. SLA para leitura e gravação de 99,999%. Taxa de transferência provisionada ou dimensionamento automático. Recomendado para cenários onde são usados armazenamento de dados em cache, repositórios de gerenciamento de sessão, gerenciamento de perfis e usuários. 

MongoDB: suporta o dimensionamento automático de forma instantânea. Faz o gerenciamento automático da infraestrutura, a fragmentação é automática e transparente. Possui SLA de até 99,999%. Suporta o modo sem servidor, a cobrança é feita por operação não havendo taxas quando o banco de dados está sem uso. As atualizações de API são rápidas e não ocasionam inatividade. Possui capacidade para realizar consultas complexas em tempo real, pois não há pipelines de ETL. 

Cassandra: faz uso de recursos, ferramentas e ecossistemas nativos do Apache Cassandra. Faz o gerenciamento automático dos recursos (sistema operacional, VM Java, nós, clusters...). Suporta gravação de múltiplas regiões.

Gremlin: baseada no Apache TinkerPop, estrutura de computação de grafo que usa linguagem de consulta Gremlin. Grafo é uma estrutura formada por vértices e bordas. Os vértices representam objetos e as bordas denotam as relações entre vértices. É possível armazenar grafos com bilhões de vértices e bordas. Os dados são distribuídos automaticamente através do particionamento de grafo. A consulta dos grafos é de milissegundos. Também dá suporte ao Apache Spark e ao GraphFrames para cenários de grafos analíticos complexos. Permite replicação em múltiplas regiões. Dentre os cenários de utilização tempo sistemas de detecção de fraudes, grafos de mídia social e IoT. No momento, a API do Gremlin oferece suporte apenas para OLTP (Online Transaction Processing).

É importante definir os requisitos das aplicações para escolher o recurso de armazenamento mais adequado. O planejamento é fundamental para obter o melhor custo benefício alinhado à segurança.