Considerações sobre a plataforma de dados para cargas de trabalho críticas no Azure

A seleção de uma plataforma de dados de aplicativos eficaz é outra área de decisão crucial, que tem implicações de longo alcance em outras áreas de design. Em última análise, o Azure oferece uma infinidade de plataformas de dados relacionais, não relacionais e analíticas, que diferem muito em capacidade. Portanto, é essencial que os principais requisitos não funcionais sejam totalmente considerados juntamente com outros fatores de decisão, como consistência, operabilidade, custo e complexidade. Por exemplo, a capacidade de operar em uma configuração de gravação multirregional terá uma influência crítica na adequação de uma plataforma disponível globalmente.

Essa área de design expande o design do aplicativo, fornecendo considerações e recomendações importantes para informar a seleção de uma plataforma de dados ideal.

Importante

Este artigo faz parte da série de carga de trabalho crítica do Azure Well-Architected. Se você não estiver familiarizado com esta série, recomendamos que comece com o que é uma carga de trabalho crítica?

Os Quatro Vs do Big Data

Os 'Quatro Vs de Big Data' fornecem uma estrutura para entender melhor as características necessárias para uma plataforma de dados altamente disponível e como os dados podem ser usados para maximizar o valor comercial. Esta seção, portanto, explorará como as características de Volume, Velocidade, Variedade e Veracidade podem ser aplicadas em um nível conceitual para ajudar a projetar uma plataforma de dados usando tecnologias de dados apropriadas.

• Quantidadede dados que está chegando para informar a capacidade de armazenamento e os requisitos de camadas - esse é o tamanho do conjunto de dados.
• Velocidade: a velocidade com que os dados são processados, seja em lotes ou fluxos contínuos - ou seja, a taxa de fluxo.
• Ambiente: a organização e o formato dos dados, capturando formatos estruturados, semiestruturados e não estruturados, ou seja, dados em vários armazenamentos ou tipos.
• Veracidade: inclui a proveniência e curadoria de conjuntos de dados considerados para governança e garantia de qualidade de dados - ou seja, precisão dos dados.

Considerações de criação

Volume

• Volumes de dados existentes (se houver) e futuros esperados com base nas taxas de crescimento de dados previstas alinhadas com os objetivos e planos de negócios.

  • O volume de dados deve abranger os próprios dados e índices, logs, telemetria e outros conjuntos de dados aplicáveis.
  • Normalmente, os aplicativos comercialmente críticos e críticos geram e armazenam grandes volumes (GB e TB) diariamente.
  • Pode haver implicações de custo significativas associadas à expansão de dados.

• O volume de dados poderá flutuar devido à mudança das circunstâncias comerciais ou dos procedimentos de manutenção.

• O volume de dados pode ter um impacto profundo no desempenho da consulta da plataforma de dados.

• Pode haver um impacto profundo associado ao alcance dos limites de volume da plataforma de dados.

  • Isso resultará em tempo de inatividade? e se sim, por quanto tempo?
  • Quais são os procedimentos de mitigação? E a mitigação exigirá alterações no aplicativo?
  • Haverá risco de perda de dados?

• Recursos como TTL (vida útil) podem ser usados para gerenciar o crescimento dos dados excluindo registros automaticamente após um tempo decorrido, por meio da criação ou da modificação do registro.

  • Por exemplo, o Azure Cosmos DB fornece uma funcionalidade TTL interna.

Velocidade

• A velocidade com que os dados são emitidos de vários componentes do aplicativo e os requisitos de taxa de transferência para a rapidez com que os dados precisam ser confirmados e recuperados são essenciais para determinar uma tecnologia de dados ideal para os principais cenários de carga de trabalho.

  • A natureza dos requisitos de taxa de transferência será diferente de acordo com o cenário de carga de trabalho, como aqueles que são de leitura pesada ou gravação.
    • Por exemplo, as cargas de trabalho analíticas normalmente precisam atender a uma grande taxa de transferência de leitura.
  • Qual é a taxa de transferência necessária? E como se espera que a produtividade cresça?
  • Quais são os requisitos de latência de dados em P50/P99 sob níveis de carga de referência?

• Recursos como suporte a um design sem bloqueio, ajuste de índice e políticas de consistência são essenciais para obter alta taxa de transferência.

  • A otimização da configuração para alta taxa de transferência incorre em compensações, que devem ser totalmente compreendidas.
  • A persistência de nivelamento de carga e os padrões de mensagens, como CQRS e Event Sourcing, podem ser usados para otimizar ainda mais a taxa de transferência.

• Os níveis de carga naturalmente flutuarão para muitos cenários de aplicativo, com picos naturais que exigem um grau suficiente de elasticidade para lidar com a demanda variável, mantendo a taxa de transferência e a latência.

  • A escalabilidade Agile é fundamental para dar suporte efetivo aos níveis de taxa de transferência e de carga variáveis sem os níveis de capacidade de superprovisionamento.
    • A taxa de transferência de leitura e gravação precisa ser escalada de acordo com os requisitos e a carga do aplicativo.
    • As operações de escala vertical e horizontal podem ser aplicadas em resposta à alteração nos níveis de carga.

• O impacto das quedas de taxa de transferência pode variar de acordo com o cenário de carga de trabalho.

  • Haverá interrupção da conectividade?
  • As operações individuais retornarão códigos de falha enquanto o plano de controle continuar a operar?
  • A plataforma de dados ativará a limitação e, em caso afirmativo, por quanto tempo?

• A recomendação fundamental de design de aplicativo para usar uma distribuição geográfica ativa-ativa apresenta desafios em torno da consistência dos dados.

  • Há uma compensação entre consistência e desempenho em relação à semântica transacional ACID completa e ao comportamento de bloqueio tradicional.
    • Minimizar a latência de gravação terá o custo da consistência dos dados.

• Em uma configuração de gravação de várias regiões, as alterações precisarão ser sincronizadas e mescladas entre todas as réplicas, com resolução de conflitos quando necessário, e isso pode afetar os níveis de desempenho e a escalabilidade.

• As réplicas somente leitura (intrarregião e inter-região) podem ser usadas para minimizar a latência de ida e volta e distribuir o tráfego para aumentar o desempenho, a taxa de transferência, a disponibilidade e a escalabilidade.

• Uma camada de cache pode ser usada para aumentar a taxa de transferência de leitura para melhorar a experiência do usuário e os tempos de resposta do cliente de ponta a ponta.

  • Os tempos e as políticas de expiração do cache precisam ser considerados para otimizar a atualidade dos dados.

Variedade

• O modelo de dados, os tipos de dados, as relações de dados e o modelo de consulta pretendido afetarão fortemente as decisões sobre a plataforma de dados.

  • O aplicativo requer um modelo de dados relacional ou pode dar suporte a um modelo de dados de esquema variável ou não relacional?
  • Como o aplicativo consultará os dados? E as consultas dependerão de conceitos de camada de banco de dados, como junções relacionais? Ou o aplicativo fornece essa semântica?

• A natureza dos conjuntos de dados considerados pelo aplicativo pode ser variada, desde conteúdo não estruturado, como imagens e vídeos, ou arquivos mais estruturados, como CSV e Parquet.

  • Normalmente, as cargas de trabalho de aplicativos compostos terão conjuntos de dados distintos e requisitos associados.

• Além das plataformas de dados relacionais ou não relacionais, as plataformas de dados de grafo ou chave-valor também podem ser adequadas para determinadas cargas de trabalho de dados.

  • Algumas tecnologias atendem a modelos de dados de esquema variável, em que os itens de dados são semanticamente semelhantes e/ou armazenados e consultados juntos, mas diferem estruturalmente.

• Em uma arquitetura de microsserviço, os serviços de aplicativos individuais podem ser criados com repositórios de dados otimizados para cenários distintos, em vez de depender de um único repositório de dados monolítico.

  • Padrões de design como SAGA podem ser aplicados para gerenciar consistência e dependências entre diferentes repositórios de dados.
    • As consultas diretas entre bancos de dados podem impor restrições de colocalização.
  • O uso de várias tecnologias de dados adicionará um grau de sobrecarga de gerenciamento para manter as tecnologias englobadas.

• Os conjuntos de recursos para cada serviço do Azure diferem entre linguagens, SDKs e APIs, o que pode afetar muito o nível de ajuste de configuração que pode ser aplicado.

• Os recursos para alinhamento otimizado com o modelo de dados e os tipos de dados englobados influenciarão fortemente as decisões da plataforma de dados.

  • Camadas de consulta, como procedimentos armazenados e mapeadores relacionais de objeto.
  • Recurso de consulta neutro em idioma, como uma camada de API REST segura.
  • Recursos de continuidade de negócios, como backup e restauração.

• Os repositórios de dados analíticos normalmente oferecem suporte ao armazenamento poliglota para vários tipos de estruturas de dados.

  • Ambientes de tempo de execução analíticos, como o Apache Spark, podem ter restrições de integração para analisar estruturas de dados poliglotas.

• Em um contexto empresarial, o uso de processos e ferramentas existentes e a continuidade das habilidades podem ter uma influência significativa no design da plataforma de dados e na seleção de tecnologias de dados.

Veracidade

• Vários fatores precisam ser considerados para validar a precisão dos dados em um aplicativo, e o gerenciamento desses fatores pode ter uma influência significativa no design da plataforma de dados.

  • Consistência de dados.
  • Recursos de segurança da plataforma.
  • Governança de dados.
  • Gerenciamento de mudanças e evolução do esquema.
  • Dependências entre conjuntos de dados.

• Em qualquer aplicativo distribuído com várias réplicas de dados, há uma compensação entre consistência e latência, conforme expresso nos teoremas CAP e PACELC .

  • Quando os leitores e gravadores são distribuídos de forma distinta, um aplicativo deve optar por retornar a versão mais rápida disponível de um item de dados, mesmo que esteja desatualizada em comparação com uma gravação (atualização) recém-concluída desse item de dados em outra réplica, ou a versão mais atualizada do item de dados, que pode incorrer em latência adicional para determinar e obter o estado mais recente.
  • A consistência e a disponibilidade podem ser configuradas no nível da plataforma ou no nível da solicitação de dados individual.
  • Qual é a experiência do usuário se os dados forem fornecidos de uma réplica mais próxima do usuário que não reflita o estado mais recente de uma réplica diferente? ou seja, o aplicativo pode suportar a possibilidade de fornecer dados desatualizados?

• Em um contexto de gravação de várias regiões, quando o mesmo item de dados é alterado em duas réplicas de gravação separadas antes que qualquer alteração possa ser replicada, é criado um conflito que deve ser resolvido.

  • Políticas padronizadas de resolução de conflitos, como "Last Write Wins", ou uma estratégia personalizada com lógica personalizada podem ser aplicadas.

• A implementação de requisitos de segurança pode afetar negativamente a taxa de transferência ou o desempenho.

• A criptografia em repouso pode ser implementada na camada de aplicativo usando criptografia do lado do cliente e/ou na camada de dados usando criptografia do lado do servidor, se necessário.

• O Azure dá suporte a vários modelos de criptografia, incluindo criptografia do lado do servidor que usa chaves gerenciadas pelo serviço, chaves gerenciadas pelo cliente no Key Vault ou chaves gerenciadas pelo cliente em hardware controlado pelo cliente.

  • Com a criptografia do lado do cliente, as chaves podem ser gerenciadas no Key Vault ou em outro local seguro.

• A criptografia de link de dados MACsec (IEEE 802.1AE MAC) é usada para proteger todo o tráfego que se move entre datacenters do Azure na rede de backbone da Microsoft.

  • Os pacotes são criptografados e descriptografados nos dispositivos antes de serem enviados, evitando ataques físicos de 'man-in-the-middle' ou espionagem/escuta telefônica.

• Autenticação e autorização para o plano de dados e o plano de controle.

  • Como a plataforma de dados autenticará e autorizará o acesso ao aplicativo e o acesso operacional?

• Observabilidade por meio do monitoramento da integridade da plataforma e do acesso aos dados.

  • Como o alerta será aplicado para condições fora dos limites operacionais aceitáveis?

Recomendações de design

Volume

• Certifique-se de que os volumes de dados futuros associados ao crescimento orgânico não excedam os recursos da plataforma de dados.

  • Preveja as taxas de crescimento de dados alinhadas aos planos de negócios e use as taxas estabelecidas para informar os requisitos contínuos de capacidade.
  • Compare os volumes de registro agregado e por dados com os limites da plataforma de dados.
  • Se houver um risco de limites serem atingidos em circunstâncias excepcionais, verifique se as mitigações operacionais estão em vigor para evitar tempo de inatividade e perda de dados.

• Monitore o volume de dados e valide-o em relação a um modelo de capacidade, considerando os limites de escala e as taxas de crescimento de dados esperadas.

  • Certifique-se de que as operações de escala estejam alinhadas com os requisitos de armazenamento, desempenho e consistência.
  • Quando uma nova unidade de escala é introduzida, os dados subjacentes podem precisar ser replicados, o que levará tempo e provavelmente introduzirá uma penalidade de desempenho enquanto a replicação ocorre. Portanto, certifique-se de que essas operações sejam realizadas fora do horário comercial crítico, se possível.

• Defina camadas de dados do aplicativo para classificar conjuntos de dados com base no uso e na criticidade para facilitar a remoção ou o descarregamento de dados mais antigos.

  • Considere classificar conjuntos de dados em camadas 'quentes', 'mornas' e 'frias' ('arquivo').
    • Por exemplo, as implementações de referência fundamentais usam o Azure Cosmos DB para armazenar dados "quentes" que são usados ativamente pelo aplicativo, enquanto o Armazenamento do Azure é usado para dados de operações "frios" para fins analíticos.

• Configure procedimentos de manutenção para otimizar o crescimento de dados e impulsionar a eficiência de dados, como desempenho de consulta e gerenciamento de expansão de dados.

  • Configure a expiração de vida útil (TTL) para dados que não são mais necessários e não têm valor analítico de longo prazo.
    • Valide se os dados antigos podem ser colocados em camadas com segurança no armazenamento secundário ou excluídos imediatamente, sem um impacto adverso no aplicativo.
  • Descarregue dados não críticos para o armazenamento frio secundário, mas mantenha-os para valor analítico e para atender aos requisitos de auditoria.
  • Colete estatísticas de telemetria e uso da plataforma de dados para permitir que as equipes de DevOps avaliem continuamente os requisitos de manutenção e os armazenamentos de dados do "tamanho certo".

• Em linha com um design de aplicativo de microsserviço, considere o uso de várias tecnologias de dados diferentes em paralelo, com soluções de dados otimizadas para cenários de carga de trabalho específicos e requisitos de volume.

  • Evite criar um só armazenamento de dados monolítico em que o volume de dados da expansão possa ser difícil de ser gerenciado.

Velocidade

• A plataforma de dados deve ser inerentemente projetada e configurada para dar suporte a alta taxa de transferência, com cargas de trabalho separadas em diferentes contextos para maximizar o desempenho usando soluções de dados otimizadas para cenários.

  • Verifique se a taxa de transferência de leitura e gravação para cada cenário de dados pode ser escalada de acordo com os padrões de carga esperados, com tolerância suficiente para variação inesperada.
  • Separe diferentes cargas de trabalho de dados, como operações transacionais e analíticas, em contextos de desempenho distintos.

• Nível de carga por meio do uso de mensagens assíncronas sem bloqueio, por exemplo, usando os padrões CQRS ou Event Sourcing .

  • Pode haver latência entre as solicitações de gravação e quando novos dados ficam disponíveis para leitura, o que pode ter um impacto na experiência do usuário.
    • Esse impacto deve ser compreendido e aceitável no contexto dos principais requisitos de negócios.

• Garanta escalabilidade ágil para oferecer suporte a níveis variáveis de taxa de transferência e carga.

  • Se os níveis de carga forem altamente voláteis, considere o excesso de níveis de capacidade de provisionamento para garantir que a taxa de transferência e o desempenho sejam mantidos.
  • Teste e valide o impacto nas cargas de trabalho do aplicativo composto quando a taxa de transferência não puder ser mantida.

• Priorize os serviços de dados nativos do Azure com operações de escala automatizadas para facilitar uma resposta rápida à volatilidade no nível da carga.

  • Configure o dimensionamento automático com base nos limites internos do serviço e do conjunto de aplicativos.
  • O dimensionamento deve ser iniciado e concluído em prazos consistentes com os requisitos de negócios.
  • Para os cenários em que a interação manual é necessária, estabeleça 'guias estratégicos' operacionais automatizados que possam ser disparados em vez de realizar ações operacionais manuais.
    • Considere se os gatilhos automatizados podem ser aplicados como parte de investimentos de engenharia subsequentes.

• Monitore a taxa de transferência de leitura e gravação de dados do aplicativo em relação aos requisitos de latência P50/P99 e alinhe-se a um modelo de capacidade do aplicativo.

• O excesso de taxa de transferência deve ser tratado normalmente pela plataforma de dados ou camada de aplicativo e capturado pelo modelo de integridade para representação operacional.

• Implemente o cache para cenários de dados "quentes" para minimizar os tempos de resposta.

  • Aplique políticas apropriadas para expiração de cache e manutenção para evitar o crescimento descontrolado de dados.
    • Expirar itens de cache quando os dados de backup forem alterados.
    • Se a expiração do cache for estritamente baseada em TTL (vida útil), o impacto e a experiência do cliente de fornecer dados desatualizados precisam ser compreendidos.

Variedade

• Em alinhamento com o princípio de um design nativo da nuvem e do Azure, é altamente recomendável priorizar os serviços gerenciados do Azure para reduzir a complexidade operacional e de gerenciamento e aproveitar os futuros investimentos em plataforma da Microsoft.

• Em alinhamento com o princípio de design de aplicativo de arquiteturas de microsserviço fracamente acopladas, permita que serviços individuais usem armazenamentos de dados distintos e tecnologias de dados otimizadas para cenário.

  • Identifique os tipos de estrutura de dados que o aplicativo processará para cenários específicos de carga de trabalho.
  • Evite criar uma dependência de um só armazenamento de dados monolítico.
    • Considere o padrão de design SAGA em que existem dependências entre repositórios de dados.

• Valide se as funcionalidades necessárias estão disponíveis para as tecnologias de dados selecionadas.

  • Garanta o suporte para os idiomas necessários e os recursos do SDK. Nem todos os recursos estão disponíveis para todas as linguagens/SDKs da mesma maneira.

Veracidade

• Adote um design de plataforma de dados de várias regiões e distribua as réplicas entre regiões para obter a máxima confiabilidade, disponibilidade e desempenho, aproximando os dados dos pontos de extremidade do aplicativo.

  • Distribua réplicas de dados entre zonas de disponibilidade (AZs) em uma região (ou use camadas de serviço com redundância de zona) para maximizar a disponibilidade dentro da região.

• Onde os requisitos de consistência permitirem, use um design de plataforma de dados de gravação multirregional para maximizar a disponibilidade e a confiabilidade globais gerais.

  • Considere os requisitos de negócios para resolução de conflitos quando o mesmo item de dados é alterado em duas réplicas de gravação separadas antes que qualquer alteração possa ser replicada e, portanto, criar um conflito.
    • Use políticas padronizadas de resolução de conflitos, como "O último vence" sempre que possível
      • Se uma estratégia personalizada com lógica personalizada for necessária, verifique se as práticas de DevOps de CI/CD são aplicadas para gerenciar a lógica personalizada.

• Teste e valide recursos de backup e restauração e operações de failover por meio de testes de caos em processos de entrega contínua.

• Execute benchmarks de desempenho para garantir que os requisitos de taxa de transferência e desempenho não sejam afetados pela inclusão de recursos de segurança necessários, como criptografia.

  • Certifique-se de que os processos de entrega contínua considerem o teste de carga em relação a benchmarks de desempenho conhecidos.

• Durante a aplicação da criptografia, é altamente recomendável usar chaves de criptografia gerenciadas pelo serviço como uma forma de reduzir a complexidade do gerenciamento.

  • Se houver um requisito de segurança específico para as chaves gerenciadas pelo cliente, verifique se os procedimentos de gerenciamento de chaves apropriados são aplicados para garantir a disponibilidade, o backup e a rotação de todas as chaves consideradas.

Observação

Ao integrar com uma implementação organizacional mais ampla, é fundamental que uma abordagem centrada no aplicativo seja aplicada para o provisionamento e a operação de componentes da plataforma de dados em um design de aplicativo.

Mais especificamente, para maximizar a confiabilidade, é fundamental que os componentes individuais da plataforma de dados respondam adequadamente à integridade do aplicativo por meio de ações operacionais que podem incluir outros componentes do aplicativo. Por exemplo, em um cenário em que recursos adicionais da plataforma de dados são necessários, provavelmente será necessário dimensionar a plataforma de dados junto com outros componentes do aplicativo de acordo com um modelo de capacidade, potencialmente por meio do fornecimento de unidades de escala adicionais. Essa abordagem será restrita se houver uma forte dependência de uma equipe de operações centralizada para resolver problemas relacionados à plataforma de dados isoladamente.

Em última análise, o uso de serviços de dados centralizados (ou seja, DBaaS de TI Central) introduz gargalos operacionais que prejudicam significativamente a agilidade por meio de uma experiência de gerenciamento amplamente descontextualizada e devem ser evitados em um contexto de missão crítica ou de negócios.

Referências adicionais

Diretrizes adicionais de plataforma de dados estão disponíveis no Guia de Arquitetura de Aplicativos do Azure.

• Árvore de Decisão do Armazenamento de Dados do Azure
• Critérios para escolher um armazenamento de dados
• Armazenamentos de dados não relacionais
• Armazenamentos de dados OLTP relacionais

Armazenamento de dados de gravação multirregional distribuído globalmente

Para acomodar totalmente as aspirações ativo-ativo distribuídas globalmente de um design de aplicativo, é altamente recomendável considerar uma plataforma de dados de gravação multirregional distribuída, em que as alterações em réplicas graváveis separadas são sincronizadas e mescladas entre todas as réplicas, com resolução de conflitos quando necessário.

Importante

Os microsserviços podem não exigir um armazenamento de dados de gravação multirregional distribuído, portanto, deve-se considerar o contexto arquitetônico e os requisitos de negócios de cada cenário de carga de trabalho.

O Azure Cosmos DB fornece um armazenamento de dados NoSQL distribuído globalmente e altamente disponível, oferecendo gravações em várias regiões e consistência ajustável pronta para uso. As considerações e recomendações de design nesta seção se concentrarão, portanto, no uso ideal do Azure Cosmos DB.

Considerações sobre o design

Azure Cosmos DB

• O Azure Cosmos DB armazena dados em contêineres, que são repositórios transacionais indexados baseados em linha projetados para permitir leituras e gravações transacionais rápidas com tempos de resposta da ordem de milissegundos.

• O Azure Cosmos DB dá suporte a várias APIs diferentes com conjuntos de recursos diferentes, como SQL, Cassandra e MongoDB.

  • O Azure Cosmos DB for NoSQL primário fornece o conjunto de recursos mais avançado e normalmente é a API em que os novos recursos serão disponibilizados primeiro.

• O Azure Cosmos DB dá suporte aos modos de conectividade Gateway e Direto, em que o Direct facilita a conectividade por TCP para nós de réplica do Azure Cosmos DB de back-end para melhorar o desempenho com menos saltos de rede, enquanto o Gateway fornece conectividade HTTPS para nós de gateway de front-end.

  • O modo direto só está disponível ao usar o Azure Cosmos DB for NoSQL e atualmente só tem suporte em plataformas .NET e Java SDK.

• Nas regiões habilitadas para Zona de Disponibilidade, o Azure Cosmos DB oferece suporte à redundância da AZ (Zona de Disponibilidade) para alta disponibilidade e resiliência a falhas zonais em uma região.

• O Azure Cosmos DB mantém quatro réplicas de dados em uma única região e, quando a redundância da AZ (zona de disponibilidade) está habilitada, o Azure Cosmos DB garante que as réplicas de dados sejam colocadas em várias AZs para proteger contra falhas zonais.

  • O protocolo de consenso Paxos é aplicado para atingir quorum entre réplicas dentro de uma região.

• Uma conta do Azure Cosmos DB pode ser facilmente configurada para replicar dados em várias regiões para reduzir o risco de uma única região ficar indisponível.

  • A replicação pode ser configurada com gravações de região única ou gravações de várias regiões.
    • Com gravações de região única, uma região de 'hub' primária é usada para atender a todas as gravações e, se essa região de 'hub' ficar indisponível, uma operação de failover deverá ocorrer para promover outra região como gravável.
    • Com gravações de várias regiões, os aplicativos podem gravar em qualquer região de implantação configurada, o que replicará as alterações entre todas as outras regiões. Se uma região não estiver disponível, as regiões restantes serão usadas para atender ao tráfego de gravação.

• Em uma configuração de gravação de várias regiões, podem ocorrer conflitos de atualização (inserir, substituir, excluir) em que os gravadores atualizam simultaneamente o mesmo item em várias regiões.

• O Azure Cosmos DB fornece duas políticas de resolução de conflitos, que podem ser aplicadas para resolver conflitos automaticamente.

  • O LWW (Last Write Wins) aplica um protocolo de relógio de sincronização de tempo usando uma propriedade de carimbo de data/hora _ts definida pelo sistema como o caminho de resolução de conflitos. Se de um conflito o item com o valor mais alto para o caminho de resolução de conflitos se tornar o vencedor e, se vários itens tiverem o mesmo valor numérico, o sistema selecionará um vencedor para que todas as regiões possam convergir para a mesma versão do item confirmado.
    • Com conflitos de exclusão, a versão excluída sempre vence os conflitos de inserção ou substituição, independentemente do valor do caminho de resolução de conflitos.
    • O Last Writer Wins é o modo de resolução de conflitos padrão.
    • Ao usar o Azure Cosmos DB for NoSQL, uma propriedade numérica personalizada, como uma definição de carimbo de data/hora personalizada, pode ser usada para resolução de conflitos.
  • As políticas de resolução personalizadas permitem que a semântica definida pelo aplicativo reconcilie conflitos usando um procedimento armazenado de mesclagem registrado que é invocado automaticamente quando conflitos são detectados.
    • O sistema fornece exatamente uma garantia para a execução de um procedimento de mesclagem como parte do protocolo de confirmação.
    • Uma política de resolução de conflitos personalizada só está disponível com o Azure Cosmos DB for NoSQL e só pode ser definida no momento da criação do contêiner.

• Em uma configuração de gravação de várias regiões, há uma dependência de uma única região de 'hub' do Azure Cosmos DB para executar todas as resoluções de conflitos, com o protocolo de consenso Paxos aplicado para obter quorum entre réplicas dentro da região do hub.

  • A plataforma fornece um buffer de mensagens para conflitos de gravação na região do hub para carregar o nível e fornecer redundância para falhas transitórias.
    • O buffer é capaz de armazenar alguns minutos de atualizações de gravação que exigem consenso.

A direção estratégica da plataforma Azure Cosmos DB é remover essa dependência de região única para resolução de conflitos em uma configuração de gravação de várias regiões, utilizando uma abordagem Paxos de 2 fases para atingir o quorum em nível global e dentro de uma região.

• A região do 'hub' primária é determinada pela primeira região em que o Azure Cosmos DB está configurado.

  • Uma ordem de prioridade é configurada para regiões de implantação de satélite adicionais para fins de failover.

• O modelo de dados e o particionamento entre partições lógicas e físicas desempenham um papel importante na obtenção de desempenho e disponibilidade ideais.

• Quando implantado com uma única região de gravação, o Azure Cosmos DB pode ser configurado para failover automático com base em uma prioridade de failover definida, considerando todas as réplicas da região de leitura.

• O RTO fornecido pela plataforma do Azure Cosmos DB é de ~10 a 15 minutos, capturando o tempo decorrido para executar um failover regional do serviço do Azure Cosmos DB se um desastre catastrófico afetar a região do hub.

  • Esse RTO também é relevante em um contexto de gravação multirregional, dada a dependência de uma única região de 'hub' para resolução de conflitos.
    • Se a região 'hub' ficar indisponível, as gravações feitas em outras regiões falharão depois que o buffer de mensagens for preenchido, pois a resolução de conflitos não poderá ocorrer até que o serviço faça failover e uma nova região de hub seja estabelecida.

A direção estratégica da plataforma Azure Cosmos DB é reduzir o RTO para ~5 minutos, permitindo failovers no nível da partição.

• Os objetivos de ponto de recuperação (RPO) e os objetivos de tempo de recuperação (RTO) são configuráveis por meio de níveis de consistência, com uma compensação entre a durabilidade dos dados e a taxa de transferência.

  • O Azure Cosmos DB fornece um RTO mínimo de 0 para um nível de consistência relaxado com gravações de várias regiões ou um RPO de 0 para consistência forte com região de gravação única.

• O Azure Cosmos DB oferece um SLA de 99,999% para disponibilidade de leitura e gravação para contas de banco de dados configuradas com várias regiões do Azure como graváveis.

  • O SLA é representado pela Porcentagem de Tempo de Atividade Mensal, que é calculada como 100% - Taxa de Erro Média.
  • A Taxa Média de Erros é definida como a soma das Taxas de Erros para cada hora no mês de cobrança dividida pelo número total de horas no mês de cobrança, em que a Taxa de Erros é o número total de Solicitações com Falha dividido pelo Total de Solicitações durante um determinado intervalo de uma hora.

• O Azure Cosmos DB oferece um SLA de 99,99% para taxa de transferência, consistência, disponibilidade e latência para contas de banco de dados com escopo para uma única região do Azure quando configuradas com qualquer um dos cinco níveis de consistência.

  • Um SLA de 99,99% também se aplica a contas de banco de dados que abrangem várias regiões do Azure configuradas com qualquer um dos quatro níveis de consistência relaxados.

• Há dois tipos de taxa de transferência que podem ser provisionados no Azure Cosmos DB, standard e dimensionamento automático, que são medidos usando RU/s (Unidades de Solicitação por segundo).

  • A taxa de transferência padrão aloca os recursos necessários para garantir um valor de RU/s especificado.
    • O Standard é cobrado por hora pela taxa de transferência provisionada.
  • O dimensionamento automático define um valor máximo de taxa de transferência e o Azure Cosmos DB aumentará ou diminuirá automaticamente dependendo da carga do aplicativo, entre o valor máximo da taxa de transferência e um mínimo de 10% do valor máximo da taxa de transferência.
    • O dimensionamento automático é cobrado por hora pela taxa de transferência máxima consumida.

• A taxa de transferência provisionada estática com uma carga de trabalho variável pode resultar em erros de limitação, o que afetará a disponibilidade percebida do aplicativo.

  • O dimensionamento automático protege contra erros de limitação permitindo que o Azure Cosmos DB seja escalado verticalmente conforme necessário, mantendo a proteção de custo reduzindo verticalmente quando a carga diminuir.

• Quando o Azure Cosmos DB é replicado em várias regiões, as RUs (Unidades de Solicitação) provisionadas são cobradas por região.

• Há um delta de custo significativo entre uma configuração de gravação de várias regiões e uma configuração de gravação de região única que, em muitos casos, pode tornar o custo de uma plataforma de dados do Azure Cosmos DB de vários mestres proibitivo.

Leitura/gravação de região única	Gravação de região única - Leitura de região dupla	Leitura/gravação de região dupla
1 RU	2 RU	4 RU

O delta entre gravação de região única e gravação de várias regiões é, na verdade, menor que a proporção de 1:2 refletida na tabela acima. Mais especificamente, há uma cobrança de transferência de dados entre regiões associada a atualizações de gravação em uma configuração de gravação única, que não é capturada nos custos de RU como acontece com a configuração de gravação de várias regiões.

• O armazenamento consumido é cobrado como uma taxa fixa para a quantidade total de armazenamento (GB) consumida para hospedar dados e índices por uma determinada hora.

• Sessioné o nível de consistência padrão e mais amplamente usado, pois os dados são recebidos na mesma ordem que as gravações.

• O Azure Cosmos DB dá suporte à autenticação por meio de uma identidade do Microsoft Entra ou chaves e tokens de recurso do Azure Cosmos DB, que fornecem recursos sobrepostos.

• É possível desabilitar operações de gerenciamento de recursos usando chaves ou tokens de recurso para limitar chaves e tokens de recurso apenas a operações de dados, permitindo o controle de acesso a recursos refinado usando o RBAC (controle de acesso baseado em função) do Microsoft Entra.

  • Restringir o acesso ao painel de controle por meio de chaves ou tokens de recurso desabilitará as operações do painel de controle para clientes que usam SDKs do Azure Cosmos DB e, portanto, deve ser completamente avaliado e testado.
  • A disableKeyBasedMetadataWriteAccess configuração pode ser definida por meio de definições de IaC do Modelo do ARM ou por meio de um Azure Policy Interno.

• O suporte ao RBAC do Microsoft Entra no Azure Cosmos DB se aplica a operações de gerenciamento de painel de controle de conta e recurso.

  • Os administradores de aplicativos podem criar atribuições de função para usuários, grupos, entidades de serviço ou identidades gerenciadas para conceder ou negar acesso a recursos e operações em recursos do Azure Cosmos DB.
  • Há várias funções RBAC internas disponíveis para atribuição de função, e funções RBAC personalizadas também podem ser usadas para formar combinações de privilégios específicas.
    • O Leitor de Conta do Cosmos DB permite o acesso somente leitura ao recurso do Azure Cosmos DB.
    • O Colaborador de Conta do Banco de Dados de Documentos permite o gerenciamento de contas do Azure Cosmos DB, incluindo chaves e atribuições de função, mas não habilita o acesso ao plano de dados.
    • Operador do Cosmos DB, que é semelhante ao Colaborador da Conta do Banco de Dados de Documentos, mas não fornece a capacidade de gerenciar chaves ou atribuições de função.

• Os recursos do Azure Cosmos DB (contas, bancos de dados e contêineres) podem ser protegidos contra modificação ou exclusão incorreta usando Bloqueios de Recursos.

  • Os bloqueios de recursos podem ser definidos no nível da conta, do banco de dados ou do contêiner.
  • Um Bloqueio de Recursos definido em um recurso será herdado por todos os recursos filho. Por exemplo, um Bloqueio de Recursos definido na conta do Azure Cosmos DB será herdado por todos os bancos de dados e contêineres dentro da conta.
  • Os bloqueios de recursos se aplicam apenas a operações do plano de controle e não impedem operações do plano de dados, como criar, alterar ou excluir dados.
  • Se o acesso ao plano de controle não for restrito com disableKeyBasedMetadataWriteAccesso , os clientes poderão executar operações do painel de controle usando chaves de conta.

• O feed de alterações do Azure Cosmos DB fornece um feed ordenado por tempo de alterações nos dados em um contêiner do Azure Cosmos DB.

  • O feed de alterações inclui apenas operações de inserção e atualização para o contêiner de origem do Azure Cosmos DB; não inclui exclusões.

• O feed de alterações pode ser usado para manter um armazenamento de dados separado do contêiner primário usado pelo aplicativo, com atualizações contínuas no armazenamento de dados de destino alimentado pelo feed de alterações do contêiner de origem.

  • O feed de alterações pode ser usado para preencher um repositório secundário para redundância adicional da plataforma de dados ou para cenários analíticos subsequentes.

• Se as operações de exclusão afetarem rotineiramente os dados no contêiner de origem, o repositório alimentado pelo feed de alterações será impreciso e não refletirá os dados excluídos.

  • Um padrão de exclusão reversível pode ser implementado para que os registros de dados sejam incluídos no feed de alterações.
    • Em vez de excluir explicitamente os registros de dados, os registros de dados são atualizados definindo um sinalizador (por exemplo, IsDeleted) para indicar que o item é considerado excluído.
    • Qualquer armazenamento de dados de destino alimentado pelo feed de alterações precisará detectar e processar itens com um sinalizador excluído definido como True; Em vez de armazenar registros de dados excluídos de forma reversível, a versão existente do registro de dados no repositório de destino precisará ser excluída.
  • Um TTL (Time-To-Live) curto normalmente é usado com o padrão de exclusão reversível para que o Azure Cosmos DB exclua automaticamente os dados expirados, mas somente depois que eles forem refletidos no feed de alterações com o sinalizador excluído definido como True.
    • Realiza a intenção de exclusão original enquanto também propaga a exclusão por meio do feed de alterações.

• O Azure Cosmos DB pode ser configurado como um repositório analítico, que aplica um formato de coluna para consultas analíticas otimizadas para resolver os desafios de complexidade e latência que ocorrem com os pipelines ETL tradicionais.

• O Azure Cosmos DB faz backup automático dos dados em intervalos regulares sem afetar o desempenho ou a disponibilidade e sem consumir RU/s.

• O Azure Cosmos DB pode ser configurado de acordo com dois modos de backup distintos.

  • Periódico é o modo de backup padrão para todas as contas, em que os backups são feitos em intervalos periódicos e os dados são restaurados criando uma solicitação com a equipe de suporte.
    • O período de retenção de backup periódico padrão é de oito horas e o intervalo de backup padrão é de quatro horas, o que significa que apenas os dois backups mais recentes são armazenados por padrão.
    • O intervalo de backup e o período de retenção são configuráveis na conta.
      • O período máximo de retenção se estende a um mês com um intervalo mínimo de backup de uma hora.
      • Uma atribuição de função para a "Função de Leitor de Conta do Cosmos DB" do Azure é necessária para configurar a redundância de armazenamento de backup.
    • Duas cópias de backup estão incluídas sem custo adicional, mas backups adicionais incorrem em custos adicionais.
    • Por padrão, os backups periódicos são armazenados em GRS (Armazenamento com Redundância Geográfica) separado que não pode ser acessado diretamente.
      • O armazenamento de backup existe na região principal do 'hub' e é replicado para a região emparelhada por meio da replicação de armazenamento subjacente.
      • A configuração de redundância da conta de armazenamento de backup subjacente é configurável para Armazenamento com Redundância de Zona ou Armazenamento com Redundância Local.
    • A execução de uma operação de restauração requer uma solicitação de suporte, pois os clientes não podem executar uma restauração diretamente.
      • Antes de abrir um tíquete de suporte, o período de retenção de backup deve ser aumentado para pelo menos sete dias dentro de oito horas após o evento de perda de dados.
    • Uma operação de restauração cria uma nova conta do Azure Cosmos DB em que os dados são recuperados.
      • Uma conta existente do Azure Cosmos DB não pode ser usada para restauração
      • Por padrão, uma nova conta do Azure Cosmos DB nomeada <Azure_Cosmos_account_original_name>-restored<n> será usada.
        • Esse nome pode ser ajustado, por exemplo, reutilizando o nome existente se a conta original foi excluída.
    • Se a taxa de transferência for provisionada no nível do banco de dados, o backup e a restauração ocorrerão no nível do banco de dados
      • Não é possível selecionar um subconjunto de contêineres para restaurar.
  • O modo de backup contínuo permite uma restauração para qualquer ponto no tempo nos últimos 30 dias.
    • As operações de restauração podem ser executadas para retornar a um ponto específico no tempo (PITR) com uma granularidade de um segundo.
    • A janela disponível para operações de restauração é de até 30 dias.
      • Também é possível restaurar para o estado de instanciação do recurso.
    • Os backups contínuos são feitos em todas as regiões do Azure em que existe a conta do Azure Cosmos DB.
      • Os backups contínuos são armazenados na mesma região do Azure que cada réplica do Azure Cosmos DB, usando LRS (Armazenamento com Redundância Local) ou ZRS (Armazenamento com Redundância de Zona) em regiões que dão suporte a Zonas de Disponibilidade.
    • Uma restauração de autoatendimento pode ser executada usando o portal do Azure ou artefatos de IaC, como modelos do ARM.
    • Há várias limitações com o backup contínuo.
      • O modo de backup contínuo não está disponível atualmente em uma configuração de gravação de várias regiões.
      • Somente o Azure Cosmos DB for NoSQL e o Azure Cosmos DB for MongoDB podem ser configurados para backup contínuo no momento.
      • Se um contêiner tiver TTL configurado, os dados restaurados que excederam seu TTL poderão ser excluídos imediatamente
    • Uma operação de restauração cria uma nova conta do Azure Cosmos DB para a restauração pontual.
    • Há um custo de armazenamento adicional para backups contínuos e operações de restauração.

• As contas existentes do Azure Cosmos DB podem ser migradas de Periódicas para Contínuas, mas não de Contínuas para Periódicas; A migração é unidirecional e não reversível.

• Cada backup do Azure Cosmos DB é composto pelos próprios dados e detalhes de configuração para taxa de transferência provisionada, políticas de indexação, regiões de implantação e configurações de TTL do contêiner.

  • Os backups não contêm configurações de firewall, listas de controle de acesso à rede virtual, configurações de ponto de extremidade privado, configurações de consistência (uma conta é restaurada com consistência de sessão), procedimentos armazenados, gatilhos, UDFs ou configurações de várias regiões.
    • Os clientes são responsáveis por reimplantar recursos e definições de configuração. Eles não são restaurados por meio do backup do Azure Cosmos DB.
  • Os dados do repositório analítico do Link do Azure Synapse também não estão incluídos nos backups do Azure Cosmos DB.

• É possível implementar um recurso personalizado de backup e restauração para cenários em que as abordagens periódicas e contínuas não são adequadas.

  • Uma abordagem personalizada introduz custos significativos e sobrecarga administrativa adicional, que deve ser compreendida e cuidadosamente avaliada.
    • Cenários comuns de restauração devem ser modelados, como a corrupção ou exclusão de uma conta, banco de dados, contêiner, item de dados.
    • Procedimentos de manutenção devem ser implementados para evitar a expansão de backup.
  • O Armazenamento do Azure ou uma tecnologia de dados alternativa pode ser usada, como um contêiner alternativo do Azure Cosmos DB.
    • O Armazenamento do Azure e o Azure Cosmos DB fornecem integrações nativas com serviços do Azure, como o Azure Functions e o Azure Data Factory.

• A documentação do Azure Cosmos DB indica duas opções potenciais para implementar backups personalizados.

  • Feed de alterações do Azure Cosmos DB para gravar dados em um recurso de armazenamento separado.
    • Uma função do Azure ou processo de aplicativo equivalente usa o processador do feed de alterações para associar ao feed de alterações e processar itens no armazenamento.
  • Backups personalizados contínuos ou periódicos (em lote) podem ser implementados usando o feed de alterações.
  • O feed de alterações do Azure Cosmos DB ainda não reflete exclusões, portanto, um padrão de exclusão reversível deve ser aplicado usando uma propriedade booliana e TTL.
    • Esse padrão não será necessário quando o feed de alterações fornecer atualizações de fidelidade total.
  • Conector do Azure Data Factory para Azure Cosmos DB (conectores de API do Azure Cosmos DB for NoSQL ou MongoDB) para copiar dados.
    • O Azure Data Factory (ADF) dá suporte à execução manual e ao agendamento, à janela em cascata e aos gatilhos baseados em eventos.
      • Fornece suporte para Armazenamento e Grade de Eventos.
    • O ADF é adequado principalmente para implementações de backup personalizadas periódicas devido à sua orquestração orientada a lotes.
      • É menos adequado para implementações de backup contínuo com eventos frequentes devido à sobrecarga de execução de orquestração.
    • O ADF dá suporte ao Link Privado do Azure para cenários de alta segurança de rede

O Azure Cosmos DB é usado no design de muitos serviços do Azure, portanto, uma interrupção regional significativa para o Azure Cosmos DB terá um efeito em cascata em vários serviços do Azure nessa região. O impacto preciso em um serviço específico dependerá muito de como o design de serviço subjacente usa o Azure Cosmos DB.

Recomendações de design

Azure Cosmos DB

• Use o Azure Cosmos DB como a plataforma de dados primária quando os requisitos permitirem.

• Para cenários de carga de trabalho críticos, configure o Azure Cosmos DB com uma réplica de gravação dentro de cada região de implantação para reduzir a latência e fornecer redundância máxima.

  • Configure o aplicativo para priorizar o uso da réplica local do Azure Cosmos DB para gravações e leituras para otimizar a carga do aplicativo, o desempenho e o consumo regional de RU/s.
  • A configuração de gravação multirregional tem um custo significativo e deve ser priorizada apenas para cenários de carga de trabalho que exigem confiabilidade máxima.

• Para cenários de carga de trabalho menos críticos, priorize o uso da configuração de gravação de região única (ao usar zonas de disponibilidade) com réplicas de leitura distribuídas globalmente, pois isso oferece um alto nível de confiabilidade da plataforma de dados (SLA de 99,999% para operações de leitura, SLA de 99,995% para operações de gravação) a um preço mais atraente.

  • Configure o aplicativo para usar a réplica de leitura local do Azure Cosmos DB para otimizar o desempenho de leitura.

• Selecione uma região de implantação de 'hub' ideal em que a resolução de conflitos ocorrerá em uma configuração de gravação de várias regiões e todas as gravações serão executadas em uma configuração de gravação de região única.

  • Considere a distância em relação a outras regiões de implantação e a latência associada na seleção de uma região primária e os recursos necessários, como suporte a Zonas de Disponibilidade.

• Configure o Azure Cosmos DB com redundância de AZ (zona de disponibilidade) em todas as regiões de implantação com suporte a AZ para garantir a resiliência a falhas zonais em uma região.

• Use o Azure Cosmos DB for NoSQL, pois ele oferece o conjunto de recursos mais abrangente, especialmente no que diz respeito ao ajuste de desempenho.

  • APIs alternativas devem ser consideradas principalmente para cenários de migração ou compatibilidade.
    • Ao usar APIs alternativas, valide se os recursos necessários estão disponíveis com a linguagem e o SDK selecionados para garantir a configuração e o desempenho ideais.

• Use o modo de conexão direta para otimizar o desempenho da rede por meio da conectividade TCP direta para nós de back-end do Azure Cosmos DB, com um número reduzido de 'saltos' de rede.

O SLA do Azure Cosmos DB é calculado pela média de solicitações com falha, que podem não estar diretamente alinhadas com um orçamento de erro de camada de confiabilidade de 99,999%. Ao projetar para SLO de 99,999%, é vital planejar a indisponibilidade de gravação regional e multirregional do Azure Cosmos DB, garantindo que uma tecnologia de armazenamento de fallback seja posicionada em caso de falha, como uma fila de mensagens persistente para repetição subsequente.

• Defina uma estratégia de particionamento entre partições lógicas e físicas para otimizar a distribuição de dados de acordo com o modelo de dados.

  • Minimizar consultas entre partições.
  • Teste e valide iterativamente a estratégia de particionamento para garantir o desempenho ideal.

• Selecione uma chave de partição ideal.

  • A chave de partição não pode ser alterada depois de criada na coleção.
  • A chave de partição deve ser um valor de propriedade que não é alterado.
  • Selecione uma chave de partição que tenha uma cardinalidade alta, com uma ampla gama de valores possíveis.
  • A chave de partição deve distribuir o consumo de RU e o armazenamento de dados uniformemente em todas as partições lógicas para garantir até mesmo o consumo de RU e a distribuição de armazenamento entre partições físicas.
  • Execute consultas de leitura na coluna particionada para reduzir o consumo e a latência de RU.

• A indexação também é crucial para o desempenho, portanto, certifique-se de que as exclusões de índice sejam usadas para reduzir os requisitos de RU/s e armazenamento.

  • Indexe apenas os campos necessários para filtrar nas consultas; índices de design para os predicados mais usados.

• Aproveite os recursos internos de tratamento de erros, repetição e confiabilidade mais ampla do SDK do Azure Cosmos DB.

  • Implemente a lógica de repetição no SDK em clientes.

• Use chaves de criptografia gerenciadas pelo serviço para reduzir a complexidade do gerenciamento.

  • Se houver um requisito de segurança específico para chaves gerenciadas pelo cliente, verifique se os procedimentos de gerenciamento de chaves apropriados são aplicados, como backup e rotação.

• Desabilite o acesso de gravação de metadados baseados em chave do Azure Cosmos DB aplicando o Azure Policy interno.

• Habilite o Azure Monitor para coletar as principais métricas e logs de diagnóstico, como RU/s (taxa de transferência provisionada).

  • Encaminhe os dados operacionais do Azure Monitor para um workspace do Log Analytics dedicado ao Azure Cosmos DB e outros recursos globais no design do aplicativo.
  • Use métricas do Azure Monitor para determinar se os padrões de tráfego do aplicativo são adequados para dimensionamento automático.

• Avalie os padrões de tráfego do aplicativo para selecionar uma opção ideal para tipos de taxa de transferência provisionada.

  • Considere a taxa de transferência provisionada de dimensionamento automático para nivelar automaticamente a demanda de carga de trabalho.

• Avalie as dicas de desempenho da Microsoft para o Azure Cosmos DB para otimizar a configuração do lado do cliente e do lado do servidor para melhorar a latência e a taxa de transferência.

• Ao usar o AKS como a plataforma de computação: para cargas de trabalho com uso intensivo de consulta, selecione um SKU de nó do AKS que tenha a rede acelerada habilitada para reduzir a latência e o nervosismo da CPU.

• Para implantações de região de gravação única, é altamente recomendável configurar o Azure Cosmos DB para failover automático.

• Nível de carga por meio do uso de mensagens assíncronas sem bloqueio em fluxos do sistema, que gravam atualizações no Azure Cosmos DB.

  • Considere padrões como Comando e Consulta, Segregação de Responsabilidade e Fornecimento de Eventos.

• Configure a conta do Azure Cosmos DB para backups contínuos para obter uma granularidade fina de pontos de recuperação nos últimos 30 dias.

  • Considere o uso de backups do Azure Cosmos DB em cenários em que os dados contidos ou a conta do Azure Cosmos DB são excluídos ou corrompidos.
  • Evite o uso de uma abordagem de backup personalizada, a menos que seja absolutamente necessário.

• É altamente recomendável praticar procedimentos de recuperação em recursos e dados que não são de produção, como parte da preparação padrão da operação de continuidade de negócios.

• Defina artefatos de IaC para restabelecer as definições de configuração e os recursos de uma restauração de backup do Azure Cosmos DB.

• Avalie e aplique as diretrizes de controle da Linha de Base de Segurança do Azure para Backup e Recuperação do Azure Cosmos DB.

  • BR-1: Garanta backups automatizados regulares
  • BR-3: Valide todos os backups, incluindo chaves gerenciadas pelo cliente
  • BR-4, Reduza o risco de perda de chaves

• Para cargas de trabalho analíticas que exigem disponibilidade de várias regiões, use o Repositório Analítico do Azure Cosmos DB, que aplica um formato de coluna para consultas analíticas otimizadas.

Tecnologias de dados relacionais

Para cenários com um modelo de dados altamente relacional ou dependências em tecnologias relacionais existentes, o uso do Azure Cosmos DB em uma configuração de gravação de várias regiões pode não ser diretamente aplicável. Nesses casos, é essencial que as tecnologias relacionais usadas sejam projetadas e configuradas para manter as aspirações ativa-ativa de várias regiões de um design de aplicativo.

O Azure fornece muitas plataformas de dados relacionais gerenciados, incluindo o Banco de Dados SQL do Azure e o Banco de Dados do Azure para soluções relacionais OSS comuns, incluindo MySQL, PostgreSQL e MariaDB. As considerações e recomendações de design nesta seção se concentrarão, portanto, no uso ideal dos tipos de OSS do Banco de Dados SQL do Azure e do Banco de Dados do Azure para maximizar a confiabilidade e a disponibilidade global.

Considerações sobre o design

• Embora as tecnologias de dados relacionais possam ser configuradas para dimensionar facilmente as operações de leitura, as gravações normalmente são restritas a passar por uma única instância primária, o que coloca uma restrição significativa na escalabilidade e no desempenho.

• A fragmentação pode ser aplicada para distribuir dados e processamento em vários bancos de dados estruturados idênticos, particionando bancos de dados horizontalmente para navegar pelas restrições da plataforma.

  • Por exemplo, a fragmentação geralmente é aplicada em plataformas de SaaS multilocatário para isolar grupos de locatários em constructos distintos da plataforma de dados.

Banco de Dados SQL do Azure

• O Banco de Dados SQL do Azure fornece um mecanismo de banco de dados totalmente gerenciado que está sempre em execução na última versão estável do mecanismo de banco de dados do SQL Server e do sistema operacional subjacente.

  • Fornece recursos inteligentes, como ajuste de desempenho, monitoramento de ameaças e avaliações de vulnerabilidade.

• O Banco de Dados SQL do Azure fornece alta disponibilidade regional interna e replicação geográfica pronta para uso para distribuir réplicas de leitura entre regiões do Azure.

  • Com a replicação geográfica, as réplicas de banco de dados secundárias permanecem somente leitura até que um failover seja iniciado.
  • Até quatro secundários são suportados na mesma região ou em regiões diferentes.
  • As réplicas secundárias também podem ser usadas para acesso de consulta somente leitura para otimizar o desempenho de leitura.
  • O failover deve ser iniciado manualmente, mas pode ser encapsulado em procedimentos operacionais automatizados.

• O Banco de Dados SQL do Azure fornece Grupos de Failover Automático, que replicam bancos de dados para um servidor secundário e permitem failover transparente em caso de falha.

  • Os grupos de failover automático dão suporte à replicação geográfica de todos os bancos de dados no grupo para apenas um servidor secundário ou uma instância em uma região diferente.
  • No momento, não há suporte para grupos de failover automático na camada de serviço de Hiperescala.
  • Bancos de dados secundários podem ser usados para descarregar o tráfego de leitura.

• As réplicas de banco de dados da camada de serviço Premium ou Comercialmente Crítico podem ser distribuídas entre Zonas de Disponibilidade sem custo adicional.

  • O anel de controle também é duplicado em várias zonas como três anéis de gateway (GW).
    • O roteamento para um anel de gateway específico é controlado pelo Gerenciador de Tráfego do Azure.
  • Ao usar o nível Comercialmente Crítico, a configuração com redundância de zona só estará disponível quando o hardware de computação Gen5 for selecionado.

• O Banco de Dados SQL do Azure oferece um SLA de disponibilidade de linha de base de 99,99% em todas as suas camadas de serviço, mas fornece um SLA mais alto de 99,995% para as camadas Comercialmente Crítico ou Premium em regiões que dão suporte a zonas de disponibilidade.

  • As camadas Comercialmente Crítico ou Premium do Banco de Dados SQL do Azure não configuradas para implantações com redundância de zona têm um SLA de disponibilidade de 99,99%.

• Quando configurada com replicação geográfica, a camada Comercialmente Crítico do Banco de Dados SQL do Azure fornece um RTO (Objetivo de Tempo de Recuperação) de 30 segundos para 100% das horas implantadas.

• Quando configurada com replicação geográfica, a camada Comercialmente Crítico do Banco de Dados SQL do Azure tem um RPO (Objetivo de Ponto de Recuperação) de 5 segundos para 100% das horas implantadas.

• A camada de Hiperescala do Banco de Dados SQL do Azure, quando configurada com pelo menos duas réplicas, tem um SLA de disponibilidade de 99,99%.

• Os custos de computação associados ao Banco de Dados SQL do Azure podem ser reduzidos usando um Desconto de Reserva.

  • Não é possível aplicar capacidade reservada para bancos de dados baseados em DTU.

• A restauração pontual pode ser usada para retornar um banco de dados e dados contidos para um ponto anterior no tempo.

• A restauração geográfica pode ser usada para recuperar um banco de dados de um backup com redundância geográfica.

Banco de Dados do Azure para PostgreSQL

• O Banco de Dados do Azure para PostgreSQL é oferecido em três opções de implantação diferentes:

  • Servidor único, SLA 99,99%
  • Servidor flexível, que oferece redundância de zona de disponibilidade, SLA de 99,99%
  • Hiperescala (Citus), SLA de 99,95% quando o modo de alta disponibilidade está habilitado.

• A Hiperescala (Citus) fornece escalabilidade dinâmica por meio de fragmentação sem alterações no aplicativo.

  • A distribuição de linhas de tabela em vários servidores PostgreSQL é fundamental para garantir consultas escalonáveis em Hiperescala (Citus).
  • Vários nós podem armazenar coletivamente mais dados do que um banco de dados tradicional e, em muitos casos, podem usar CPUs de trabalho em paralelo para otimizar custos.

• O dimensionamento automático pode ser configurado por meio da automação de runbook para garantir a elasticidade em resposta às mudanças nos padrões de tráfego.

• O servidor flexível fornece eficiência de custos para cargas de trabalho de não produção por meio da capacidade de parar/iniciar o servidor e uma camada de computação expansível adequada para cargas de trabalho que não exigem capacidade de computação contínua.

• Não há custo adicional para armazenamento de backup de até 100% do armazenamento total do servidor provisionado.

  • O consumo adicional de armazenamento de backup é cobrado de acordo com o GB/mês consumido.

• Os custos de computação associados ao Banco de Dados do Azure para PostgreSQL podem ser reduzidos usando um Desconto de Reserva de Servidor Único ou um Desconto de Reserva de Hiperescala (Citus).

Recomendações de design

• Considere a fragmentação para particionar os bancos de dados relacionais com base em diferentes contextos de dados e aplicativos, ajudando a superar as restrições da plataforma, maximizar a escalabilidade e a disponibilidade e o isolamento de falhas.

  • Essa recomendação é particularmente prevalente quando o design do aplicativo considera três ou mais regiões do Azure, pois as restrições de tecnologia relacional podem prejudicar significativamente as plataformas de dados distribuídas globalmente.
  • A fragmentação não é apropriada para todos os cenários de aplicativo e, portanto, uma avaliação contextualizada é necessária.

• Priorize o uso do Banco de Dados SQL do Azure quando houver requisitos relacionais devido à maturidade na plataforma Azure e uma ampla gama de funcionalidades de confiabilidade.

Banco de Dados SQL do Azure

• Use a camada de serviço Comercialmente crítico para maximizar a confiabilidade e a disponibilidade, incluindo o acesso a funcionalidades críticas de resiliência.

• Use o modelo de consumo baseado em vCore para facilitar a seleção independente de recursos de computação e armazenamento, adaptados aos requisitos de volume e taxa de transferência da carga de trabalho.

  • Certifique-se de que um modelo de capacidade definido seja aplicado para informar os requisitos de recursos de computação e armazenamento.
    • Considere a capacidade reservada para fornecer possíveis otimizações de custo.

• Configure o modelo de implantação com redundância de zona para distribuir réplicas de banco de dados comercialmente críticas dentro da mesma região entre zonas de disponibilidade.

• Use a Replicação Geográfica Ativa para implantar réplicas legíveis em todas as regiões de implantação (até quatro).

• Use grupos de failover automático para fornecer failover transparente para uma região secundária, com replicação geográfica aplicada para fornecer replicação para regiões de implantação adicionais para otimização de leitura e redundância de banco de dados.

  • Para os cenários de aplicativo limitados a apenas duas regiões de implantação, o uso de grupos de failover automático deve ser priorizado.

• Considere gatilhos operacionais automatizados, com base em alertas alinhados ao modelo de integridade do aplicativo, para realizar failovers para instâncias replicadas geograficamente se houver uma falha que afete o primário e o secundário no Grupo de Failover Automático.

Importante

Para aplicativos que consideram mais de quatro regiões de implantação, deve-se considerar seriamente a fragmentação no escopo do aplicativo ou a refatoração do aplicativo para dar suporte a tecnologias de gravação de várias regiões, como o Azure Cosmos DB. No entanto, se isso não for viável no cenário de carga de trabalho do aplicativo, é recomendável elevar uma região dentro de uma única geografia para um status primário que abrange uma instância replicada geograficamente para acesso de leitura distribuído de maneira mais uniforme.

• Configure o aplicativo para consultar instâncias de réplica para consultas de leitura a fim de otimizar o desempenho de leitura.

• Use o Azure Monitor e a Análise de SQL do Azure para obter insights operacionais quase em tempo real no Banco de Dados SQL do Azure para a detecção de incidentes de confiabilidade.

• Use o Azure Monitor para avaliar o uso de todos os bancos de dados para determinar se eles foram escalados de acordo.

  • Verifique se os pipelines de CD consideram o teste de carga em níveis de carga representativos para validar o comportamento apropriado da plataforma de dados.

• Calcule uma métrica de integridade para componentes de banco de dados para observar a integridade em relação aos requisitos de negócios e à utilização de recursos, usando monitoramento e alertas para conduzir ações operacionais automatizadas quando apropriado.

  • Certifique-se de que as principais métricas de desempenho da consulta sejam incorporadas para que uma ação rápida possa ser tomada quando ocorrer degradação do serviço.

• Otimize consultas, tabelas e bancos de dados usando o Query Performance Insights e recomendações comuns de desempenho fornecidas pela Microsoft.

• Implemente a lógica de repetição usando o SDK para atenuar erros transitórios que afetam a conectividade do Banco de Dados SQL do Azure.

• Priorize o uso de chaves gerenciadas pelo serviço ao aplicar a TDE (Transparent Data Encryption) do lado do servidor para criptografia em repouso.

  • Se for necessária a criptografia de chaves gerenciadas pelo cliente ou do lado do cliente (AlwaysEncrypted), verifique se as chaves são adequadamente resilientes com backups e recursos de rotação automatizada.

• Considere o uso da restauração pontual como um guia estratégico operacional para se recuperar de erros graves de configuração.

Banco de Dados do Azure para PostgreSQL

• O Servidor Flexível é recomendado para usá-lo para cargas de trabalho críticas para os negócios devido ao suporte à Zona de Disponibilidade.

• Ao usar a Hiperescala (Citus) para cargas de trabalho críticas para os negócios, habilite o modo de Alta Disponibilidade para receber a garantia de SLA de 99,95%.

• Use a configuração do servidor de Hiperescala (Citus) para maximizar a disponibilidade em vários nós.

• Defina um modelo de capacidade para o aplicativo para informar os requisitos de recursos de computação e armazenamento na plataforma de dados.

  • Considere o Desconto de Reserva de Hiperescala (Citus) para fornecer possíveis otimizações de custo.

Armazenamento em cache para dados de nível frequente

Uma camada de cache na memória pode ser aplicada para aprimorar uma plataforma de dados, aumentando significativamente a taxa de transferência de leitura e melhorando os tempos de resposta do cliente de ponta a ponta para cenários de dados de camada quente.

O Azure fornece vários serviços com recursos aplicáveis para armazenar em cache as principais estruturas de dados, com o Cache do Azure para Redis posicionado para abstrair e otimizar o acesso de leitura da plataforma de dados. Esta seção, portanto, se concentrará no uso ideal do Cache do Azure para Redis em cenários em que o desempenho de leitura adicional e a durabilidade do acesso a dados são necessários.

Considerações de criação

• Uma camada de cache fornece durabilidade adicional de acesso a dados, pois mesmo que uma interrupção afete as tecnologias de dados subjacentes, um instantâneo de dados do aplicativo ainda pode ser acessado por meio da camada de cache.

• Em determinados cenários de carga de trabalho, o cache na memória pode ser implementado na própria plataforma do aplicativo.

Cache Redis do Azure

• O cache Redis é um sistema de armazenamento na memória de chave-valor NoSQL de código aberto.

• As camadas Enterprise e Enterprise Flash podem ser implantadas em uma configuração ativa-ativa em Zonas de Disponibilidade dentro de uma região e diferentes regiões do Azure por meio da replicação geográfica.

  • Quando implantado em pelo menos três regiões do Azure e três ou mais Zonas de Disponibilidade em cada região, com a replicação geográfica ativa habilitada para todas as instâncias de Cache, o Cache do Azure para Redis fornece um SLA de 99,999% para conectividade com um ponto de extremidade de cache regional.
  • Quando implantado em três Zonas de Disponibilidade em uma única região do Azure, um SLA de conectividade de 99,99% é fornecido.

• A camada Enterprise Flash é executada em uma combinação de RAM e armazenamento de memória flash não volátil e, embora isso introduza uma pequena penalidade de desempenho, também permite tamanhos de cache muito grandes, de até 13 TB com clustering.

• Com a replicação geográfica, as cobranças pela transferência de dados entre regiões também serão aplicáveis, além dos custos diretos associados às instâncias de cache.

• O recurso Atualizações Agendadas não inclui atualizações do Azure ou atualizações aplicadas ao sistema operacional da VM subjacente.

• Haverá um aumento na utilização da CPU durante uma operação de expansão enquanto os dados são migrados para novas instâncias.

Recomendações de design

• Considere uma camada de cache otimizada para cenários de dados 'quentes' para aumentar a taxa de transferência de leitura e aprimorar os tempos de resposta.

• Aplique políticas apropriadas para expiração de cache e limpeza a fim de evitar o crescimento descontrolado dos dados.

  • Considere a expiração de itens de cache quando os dados de backup forem alterados.

Cache Redis do Azure

• Use o SKU Premium ou Enterprise para maximizar a confiabilidade e o desempenho.

  • Para os cenários com volumes de dados extremamente grandes, a camada Enterprise Flash deve ser considerada.
  • Para os cenários em que apenas a replicação geográfica passiva é necessária, a camada Premium também pode ser considerada.

• Implante instâncias de réplica usando a replicação geográfica em uma configuração ativa em todas as regiões de implantação consideradas.

• Verifique se as instâncias de réplica são implantadas em Zonas de Disponibilidade em cada região do Azure considerada.

• Use o Azure Monitor para avaliar o Cache do Azure para Redis.

  • Calcule uma pontuação de integridade para componentes de cache regionais para observar a integridade em relação aos requisitos de negócios e à utilização de recursos.
  • Observe e alerte sobre as principais métricas, como alta CPU, alto uso de memória, alta carga do servidor e chaves removidas para obter insights sobre quando dimensionar o cache.

• Otimize a resiliência da conexão implementando lógica de repetição, tempos limite e usando uma implementação singleton do multiplexador de conexão Redis.

• Configure as atualizações agendadas para prescrever os dias e horários em que as atualizações do Redis Server são aplicadas ao cache.

Cenários analíticos

É cada vez mais comum que aplicativos de missão crítica considerem cenários analíticos como um meio de gerar valor adicional de fluxos de dados englobados. Os cenários analíticos de aplicativos e operacionais (AIOps), portanto, formam um aspecto crucial da plataforma de dados altamente confiável.

As cargas de trabalho analíticas e transacionais exigem diferentes recursos e otimizações de plataforma de dados para um desempenho aceitável em seus respectivos contextos.

Descrição	Analítico	Transacional
Caso de uso	Analisar volumes muito grandes de dados ("big data")	Processar volumes muito grandes de transações individuais
Otimizado para	Ler consultas e agregações em muitos registros	Consultas CRUD (Criar/Ler/Atualizar/Excluir) quase em tempo real em poucos registros
Principais características	- Consolide a partir de fontes de dados de registro - Armazenamento baseado em colunas - Armazenamento distribuído - Processamento paralelo -Desnormalizada - Leituras e gravações de baixa simultaneidade - Otimize o volume de armazenamento com compactação	- Fonte de dados de registro para aplicação - Armazenamento baseado em linha - Armazenamento contíguo - Processamento simétrico -Normalizado - Leituras e gravações de alta simultaneidade, atualizações de índice - Otimize para acesso rápido aos dados com armazenamento na memória

O Azure Synapse fornece uma plataforma analítica empresarial que reúne dados relacionais e não relacionais com tecnologias Spark, usando a integração interna com serviços do Azure, como o Azure Cosmos DB, para facilitar a análise de Big Data. As considerações e recomendações de design nesta seção se concentrarão, portanto, no uso ideal do Azure Synapse e do Azure Cosmos DB para cenários analíticos.

Considerações de criação

• Tradicionalmente, os cenários analíticos em larga escala são facilitados pela extração de dados em uma plataforma de dados separada otimizada para consultas analíticas posteriores.
  • Os pipelines de ETL (extração, transformação e carregamento) são usados para extrair dados que consumirão a taxa de transferência e afetarão o desempenho da carga de trabalho transacional.
  • A execução de pipelines de ETL com pouca frequência para reduzir a taxa de transferência e os impactos no desempenho resultará em dados analíticos menos atualizados.
  • A sobrecarga de desenvolvimento e manutenção do pipeline ETL aumenta à medida que as transformações de dados se tornam mais complexas.
    • Por exemplo, se os dados de origem forem alterados ou excluídos com frequência, os pipelines de ETL deverão considerar essas alterações nos dados de destino para consultas analíticas por meio de uma abordagem aditiva/com controle de versão, despejo e recarregamento ou alterações in-loco nos dados analíticos. Cada uma dessas abordagens terá impacto derivado, como recriação ou atualização de índices.

Azure Cosmos DB

• As consultas analíticas executadas em dados transacionais do Azure Cosmos DB normalmente serão agregadas em partições em grandes volumes de dados, consumindo uma taxa de transferência significativa de RU (Unidade de Solicitação), o que pode afetar o desempenho das cargas de trabalho transacionais circundantes.

• O Repositório Analítico do Azure Cosmos DB fornece um armazenamento de dados orientado a colunas esquematizado e totalmente isolado que permite a análise em larga escala de dados do Azure Cosmos DB do Azure Synapse sem impacto nas cargas de trabalho transacionais do Azure Cosmos DB.

  • Quando um Contêiner do Azure Cosmos DB é habilitado como um Repositório Analítico, um novo repositório de colunas é criado internamente a partir dos dados operacionais no Contêiner. Esse repositório de colunas é mantido separadamente do repositório de transações orientado a linhas para o contêiner.
  • As operações de criação, atualização e exclusão nos dados operacionais são sincronizadas automaticamente com o repositório analítico, portanto, nenhum feed de alterações ou processamento de ETL é necessário.
  • A sincronização de dados do repositório operacional para o repositório analítico não consome RUs (Unidades de Solicitação) de taxa de transferência provisionadas no Contêiner ou no Banco de Dados. Não há impacto no desempenho das cargas de trabalho transacionais. O Repositório Analítico não requer a alocação de RUs adicionais em um Banco de Dados ou Contêiner do Azure Cosmos DB.
  • A Sincronização Automática é o processo em que as alterações de dados operacionais são sincronizadas automaticamente com o Repositório Analítico. A latência da sincronização automática geralmente é inferior a dois (2) minutos.
    • A latência da Sincronização Automática pode ser de até cinco (5) minutos para um Banco de Dados com taxa de transferência compartilhada e um grande número de Contêineres.
    • Assim que a Sincronização Automática for concluída, os dados mais recentes poderão ser consultados no Azure Synapse.
  • O armazenamento do Repositório Analítico usa um modelo de preços baseado em consumo que cobra pelo volume de dados e pelo número de operações de leitura e gravação. O preço da loja analítica é separado do preço da loja transacional.

• Usando o Link do Azure Synapse, o Repositório Analítico do Azure Cosmos DB pode ser consultado diretamente do Azure Synapse. Isso permite o HTAP (Processamento Analítico Transacional Híbrido) sem ETL do Synapse, para que os dados do Azure Cosmos DB possam ser consultados junto com outras cargas de trabalho analíticas do Synapse quase em tempo real.

• O Repositório Analítico do Azure Cosmos DB não é particionado por padrão.

  • Para determinados cenários de consulta, o desempenho melhorará particionando dados do Repositório Analítico usando chaves que são usadas com frequência em predicados de consulta.
  • O particionamento é disparado por um trabalho no Azure Synapse que executa um notebook do Spark usando o Link do Synapse, que carrega os dados do Repositório Analítico do Azure Cosmos DB e os grava no repositório particionado do Synapse na conta de armazenamento primária do workspace do Synapse.

• Os pools do SQL Serverless do Azure Synapse Analytics podem consultar o Repositório Analítico por meio de exibições atualizadas automaticamente ou por meio de SELECT / OPENROWSET comandos.

• Os pools do Spark do Azure Synapse Analytics podem consultar o Repositório Analítico por meio de tabelas do Spark atualizadas automaticamente ou do spark.read comando.

• Os dados também podem ser copiados do Repositório Analítico do Azure Cosmos DB para um pool de SQL do Synapse dedicado usando o Spark, para que os recursos provisionados do pool de SQL do Azure Synapse possam ser usados.

• Os dados do Repositório Analítico do Azure Cosmos DB podem ser consultados com o Azure Synapse Spark.

  • Os notebooks do Spark permitem combinações de dataframe do Spark para agregar e transformar dados analíticos do Azure Cosmos DB com outros conjuntos de dados e usar outras funcionalidades avançadas do Synapse Spark, incluindo a gravação de dados transformados em outros repositórios ou o treinamento de modelos de aprendizado de máquina de AIOps.

• O feed de alterações do Azure Cosmos DB também pode ser usado para manter um armazenamento de dados secundário separado para cenários analíticos.

Azure Synapse

• O Azure Synapse reúne recursos de análise, incluindo data warehouse SQL, Big Data do Spark e Data Explorer para análise de log e série temporal.

  • O Azure Synapse usa serviços vinculados para definir conexões com outros serviços, como o Armazenamento do Azure.
  • Os dados podem ser ingeridos no Synapse Analytics por meio da atividade Copiar de fontes com suporte. Isso permite a análise de dados no Synapse sem afetar o armazenamento de dados de origem, mas adiciona tempo, custo e sobrecarga de latência devido à transferência de dados.
  • Os dados também podem ser consultados in-loco em repositórios externos com suporte, evitando a sobrecarga de ingestão e movimentação de dados. O Armazenamento do Azure com Data Lake Gen2 é um repositório com suporte para Synapse e os dados exportados do Log Analytics podem ser consultados por meio do Synapse Spark.

• O Azure Synapse Studio une tarefas de ingestão e consulta.

  • Os dados de origem, incluindo dados do Repositório Analítico do Azure Cosmos DB e dados de exportação do Log Analytics, são consultados e processados para dar suporte à business intelligence e outros casos de uso analíticos agregados.

Recomendações de design

• Verifique se as cargas de trabalho analíticas não afetam as cargas de trabalho de aplicativos transacionais para manter o desempenho transacional.

Análise de aplicativos

• Use o Link do Azure Synapse com o Repositório Analítico do Azure Cosmos DB para executar análises em dados operacionais do Azure Cosmos DB criando um armazenamento de dados otimizado, que não afetará o desempenho transacional.

  • Habilite o Link do Azure Synapse em contas do Azure Cosmos DB.
  • Crie um contêiner habilitado para o Repositório Analítico ou habilite um Contêiner existente para o Repositório Analítico.
  • Conecte o workspace do Azure Synapse ao Repositório Analítico do Azure Cosmos DB para permitir que cargas de trabalho analíticas no Azure Synapse consultem dados do Azure Cosmos DB. Use uma cadeia de conexão com uma chave somente leitura do Azure Cosmos DB.

• Priorize o Repositório Analítico do Azure Cosmos DB com o Link do Azure Synapse em vez de usar o feed de alterações do Azure Cosmos DB para manter um armazenamento de dados analíticos.

  • O feed de alterações do Azure Cosmos DB pode ser adequado para cenários analíticos muito simples.

AIOps e análise operacional

• Crie um único workspace do Azure Synapse com serviços vinculados e conjuntos de dados para cada conta de armazenamento do Azure de origem para a qual os dados operacionais dos recursos são enviados.

• Crie uma conta de Armazenamento do Azure dedicada e use-a como a conta de armazenamento primária do workspace para armazenar os dados e metadados do catálogo do workspace do Synapse. Configure-o com namespace hierárquico para habilitar o Azure Data Lake Gen2.

  • Mantenha a separação entre os dados analíticos de origem e os dados e metadados do workspace do Synapse.
    • Não use uma das contas regionais ou globais do Armazenamento do Azure para as quais os dados operacionais são enviados.

Próxima etapa

Revise as considerações para considerações de rede.

Rede e conectividade