Compartilhar via

Dados para cargas de trabalho de SaaS no Azure

  • Artigo

Trate os dados como o ativo mais valioso da sua solução. Como um fornecedor independente de software (ISV), você é responsável por gerenciar os dados de seus clientes. Sua estratégia de design de dados e a escolha do armazenamento de dados podem afetar significativamente seus clientes.

Este artigo fornece diretrizes sobre como garantir a integridade e a confidencialidade dos dados para seus clientes e, ao mesmo tempo, atender aos requisitos de desempenho dos negócios. Ele destaca as principais considerações para ajudá-lo a atingir essas metas de forma eficaz.

Selecionar um armazenamento de dados

O armazenamento de dados em uma solução de software como serviço (SaaS) afeta sua arquitetura, desempenho, confiabilidade e complexidade transacional. Compare os recursos dos serviços gerenciados do Azure com ofertas semelhantes que não são da Microsoft. Em algumas situações, você também pode considerar a execução de produtos de software livre em máquinas virtuais.

Considerações sobre o design

  • Diferencie entre suas operações transacionais e analíticas. Os armazenamentos de dados transacionais são projetados para dar suporte aos seus aplicativos, e os armazenamentos de dados analíticos são usados para relatórios e tarefas como aprendizado de máquina. Essas lojas são criadas com produtos especializados e têm necessidades exclusivas de desempenho, padrões de acesso, esquemas e casos de uso.

    Este guia se concentra em armazenamentos de dados transacionais.

  • Entenda suas necessidades de dados. Estime o volume, a frequência com que ele pode mudar e o tipo de dados que você precisa armazenar.

    Espere que os dados cresçam significativamente ao longo do tempo. Para soluções SaaS, o crescimento ocorre em várias dimensões. Antecipe aumentos no volume e nos tipos de dados à medida que o número de clientes cresce. Certifique-se de planejar esse crescimento e investir em tecnologias que possam apoiá-lo.

    Decida entre uma plataforma de dados relacional ou não relacional com base na natureza de seus dados. Para muitas cargas de trabalho transacionais, um banco de dados relacional é uma boa opção para modelar entidades de aplicativo como tabelas discretas. Essa abordagem permite que as consultas operem no modelo de dados relacional. Como alternativa, se seus dados se ajustarem naturalmente a um modelo de documento ou seguirem uma estrutura de gráfico, uma abordagem não relacional poderá ser mais adequada.

    Para obter mais informações, consulte SQL versus plataformas de dados NoSQL.

  • Minimize os tipos de armazenamentos de dados. Armazenar diferentes tipos de dados em vários armazenamentos de dados distintos pode ser benéfico para organizações maduras que têm experiência em várias plataformas de dados. No entanto, essa abordagem geralmente introduz complexidade desnecessária para startups e organizações menores. É mais eficaz se concentrar em um ou em um pequeno número de armazenamentos de dados.

    Se você não tiver a justificativa comercial para usar vários armazenamentos de dados, concentre seus esforços em um ou em um pequeno número de armazenamentos de dados.

  • Use o que você sabe e invista nisso. Se sua equipe já tem experiência com um armazenamento de dados específico, geralmente é melhor usar esse armazenamento de dados em vez de investir no aprendizado de novas habilidades. Os armazenamentos de dados e as plataformas são complexos e as decisões de design podem ser difíceis de reverter.

    No entanto, tenha em mente o crescimento potencial. Se o armazenamento de dados atual não atender mais aos seus requisitos, escolha um armazenamento de dados que possa aprimorar o desempenho, a resiliência, a segurança e a eficiência operacional da solução. Também deve ajudar sua equipe a aprofundar seus conhecimentos.

Recomendações de design

Recomendação Benefício
Separe os armazenamentos de dados transacionais para operações diárias dos armazenamentos de dados analíticos e de relatórios. Misturar a intenção de seus armazenamentos de dados pode levar a uma complexidade desnecessária. A segmentação de dados aumenta a eficiência operacional e maximiza a utilização de cada armazenamento de dados.
Escolha entre uma estrutura de dados relacional ou não relacional com base em seus requisitos. Comece com um ou um pequeno número de armazenamentos de dados.

Priorize armazenamentos de dados gerenciados. As opções comuns incluem Azure Cosmos DB, SQL do Azure, MySQL, MongoDB e PostgreSQL.		 Essa abordagem ajuda a minimizar a complexidade e garante que você use o produto certo para maximizar a eficiência. Os armazenamentos de dados gerenciados fornecem flexibilidade no gerenciamento de recursos e custos de forma elástica e dimensionam de acordo com suas necessidades. O uso de armazenamentos de dados gerenciados cria menos carga de gerenciamento do que implantar seu próprio armazenamento de dados em sua própria infraestrutura.
Invista no aprendizado da tecnologia escolhida. Equipe sua equipe para gerenciar os requisitos de alta escalabilidade e outras complexidades das soluções SaaS. Saiba mais sobre as ferramentas que você usa e seu ecossistema mais amplo para que você possa usar sua plataforma de dados com eficiência à medida que escala.
Adote flexibilidade em seu design de dados. À medida que sua solução SaaS cresce ou seus requisitos mudam, você pode se adaptar adicionando ou alterando armazenamentos de dados. Essa flexibilidade permite que você comece com um armazenamento de dados e evolua ao longo do tempo para atender às suas necessidades.

Modelo de locação e estratégia de banco de dados

Um aspecto fundamental do design de dados é a decisão de hospedar recursos em nome de seus clientes ou hospedar recursos em seu ambiente. A maioria dos provedores de SaaS hospeda recursos para todos os clientes, o que oferece flexibilidade no gerenciamento de banco de dados. Se você hospedar recursos no ambiente do cliente, considere como acessar e gerenciar esses recursos.

Considerações sobre o design

  • Planeje a segmentação do banco de dados. Em soluções SaaS business-to-business (B2B), recomendamos que você crie bancos de dados dedicados para cada cliente. Essa abordagem aprimora a segurança dos dados, mantendo um isolamento estrito entre os clientes, o que reduz o risco de combinação de dados e oferece suporte a chaves de criptografia gerenciadas pelo cliente. Ele também ajuda você a atender aos requisitos de conformidade regulatória para alguns clientes.

    Separar os dados do cliente em bancos de dados individuais pode melhorar o desempenho, minimizando os problemas de vizinhos barulhentos. Alguns armazenamentos de dados gerenciados incluem controles de alocação de recursos para mitigar esses problemas, fornecer eficiência de custos e incorporar ferramentas para gerenciar vários bancos de dados em escala.

    Em alguns casos, é apropriado armazenar os dados de vários clientes em um único armazenamento de dados. Por exemplo, em soluções B2C (business-to-consumer), você pode salvar dados em um único repositório com particionamento lógico com base na ID do cliente. Em soluções B2B que compartilham componentes, você pode usar um único armazenamento de dados para partes específicas, como um armazenamento de eventos, garantindo a inclusão de IDs de cliente em cada evento.

  • Colocar armazenamentos de dados com componentes de aplicativo. Se você hospedar recursos em nome do cliente, implante na mesma região do Azure para evitar encargos de largura de banda de saída e latência. Ao hospedar aplicativos e armazenamentos de dados no ambiente de um cliente, implante-os juntos no mesmo ambiente para evitar complexidades entre ambientes.

  • Padronize o gerenciamento do armazenamento de dados o máximo possível. A uniformidade é fundamental para gerenciar dados entre os clientes. À medida que sua empresa cresce, as diferenças entre os clientes aumentam o risco e a complexidade. Essas diferenças também podem tornar as interrupções de produção mais prováveis e a solução de problemas mais difícil.

    Evite mudanças pontuais em sua gestão para oferecer suporte a clientes individuais. Por exemplo, para dar suporte a metadados gerenciados pelo cliente, evite alterações de esquema, como adicionar colunas extras ao banco de dados. Em vez disso, crie funcionalidades para que os clientes adicionem seus próprios metadados. Da mesma forma, se você precisar fornecer diferentes níveis de desempenho de banco de dados para diferentes clientes, crie um único processo que possa ser usado para aplicar diferentes configurações a diferentes camadas de clientes.

Para obter mais informações sobre como seu modelo de locação afeta sua estratégia de dados, consulte.

Recomendações de design

Recomendação Benefício
Avalie se deseja compartilhar bancos de dados entre vários clientes ou fornecer uma plataforma de dados compartilhada.

Implante um único banco de dados para os dados de cada cliente, quando apropriado. Relaxe essa estratégia se o isolamento estrito não for um requisito, como em soluções B2C.		 Essa abordagem minimiza os problemas de vizinhos barulhentos e pode oferecer suporte aos requisitos de conformidade para alguns clientes.
Implante aplicativos e seus bancos de dados na mesma região. Essa abordagem otimiza o custo da largura de banda e a latência incorridos pelo acesso ao banco de dados entre regiões.
Projete uma abordagem padronizada para armazenar dados ou metadados definidos pelo cliente. Evite alterar o esquema para clientes individuais ou fazer com que os ambientes do cliente sejam diferentes. Essa abordagem ajuda a evitar a carga operacional de gerenciar inconsistências entre bancos de dados para cada cliente.
Planeje as operações de manutenção de rotina no ambiente implantado pelo cliente.

Planeje como acessar o banco de dados para atualizações, alterações de esquema, manutenção e outras operações.		 Essa abordagem proativa minimiza os problemas de falta de manutenção e reduz o risco de tempo de inatividade e problemas de desempenho.

Planejar a capacidade

O planejamento de capacidade refere-se ao gerenciamento da utilização de recursos, com foco em operações de CPU, memória, armazenamento e disco, como operações de entrada e saída por segundo (IOPS). Alguns armazenamentos de dados combinam esses recursos em uma métrica de consumo de recursos simples e sintética, como uma DTU (unidade de taxa de transferência) de banco de dados no SQL do Azure ou uma RU (unidade de solicitação) no Azure Cosmos DB. Os armazenamentos de dados gerenciados fornecem flexibilidade no gerenciamento de recursos, o que permite alterações ao longo do tempo. É crucial estabelecer um plano inicial e iterar à medida que suas necessidades evoluem.

Considerações sobre o design

  • Entenda seus requisitos de alocação de recursos. Diferentes clientes em soluções SaaS podem ter necessidades de recursos variadas. Clientes menores podem exigir recursos mínimos e clientes maiores podem precisar de mais. Clientes maiores geralmente pagam mais, o que justifica uma maior alocação de recursos. Usando bancos de dados separados para cada cliente, você pode ajustar a alocação de recursos com base em seu tamanho e necessidades.

  • Entenda os diferentes modelos de capacidade que as plataformas de dados oferecem. As plataformas de dados baseadas em nuvem geralmente fornecem vários modelos de recursos. Por exemplo, alguns serviços do Azure, como o Azure Cosmos DB, fornecem modelos provisionados baseados em taxa de transferência e modelos sem servidor. O Banco de Dados SQL do Azure também fornece pools elásticos.

    A taxa de transferência provisionada requer alocação de recursos predeterminada, seja de um único banco de dados ou de um grupo de bancos de dados. Os pools elásticos permitem o compartilhamento de recursos entre vários bancos de dados. Os pools elásticos são comumente usados em soluções SaaS.

    Embora a taxa de transferência provisionada exija que você aloque recursos com antecedência, serviços como o Azure Cosmos DB fornecem taxa de transferência de dimensionamento automático. Você pode definir regras para adicionar ou remover recursos dinamicamente com base em gatilhos especificados.

    Os modelos de recursos sem servidor são dimensionados automaticamente com base na demanda. Essa funcionalidade os torna um bom ponto de partida se você não puder prever seus requisitos de capacidade com antecedência. No entanto, eles podem oferecer suporte a menos recursos e se tornar ineficientes em termos de custo à medida que você cresce. Os modelos sem servidor estão disponíveis no Banco de Dados SQL do Azure e no Azure Cosmos DB.

Recomendações de design

Recomendação Benefício
Modele seus requisitos de banco de dados para cada cliente. Determine se você deve ter muitos bancos de dados pequenos, menos bancos de dados grandes ou uma mistura dos dois.

Use um exercício de dimensionamento de camisetas para categorizar os clientes em baldes pequenos, médios e grandes.		 Essa abordagem fornece uma estimativa aproximada dos recursos necessários por cliente e ajuda a mapear os clientes para seu modelo de cobrança.
Segmente pools de recursos com base no tamanho dos bancos de dados do cliente que os utilizam.

Use a capacidade provisionada a seu favor. Por exemplo, você pode criar um pool elástico SQL compartilhado para clientes menores, um pool separado para clientes médios e recursos dedicados para clientes grandes.		 Ao segmentar pools de recursos com base no tamanho do banco de dados de seus clientes, você pode otimizar a alocação de recursos e a eficiência de custos.
Aproveite os recursos de dimensionamento internos que os serviços gerenciados fornecem. Você pode transferir responsabilidades de escalabilidade para a plataforma. Recursos como pools elásticos e dimensionamento automático podem ajudar a otimizar o uso de recursos.
Revise regularmente os armazenamentos de dados sem servidor para garantir que eles continuem atendendo às suas necessidades. Você pode garantir que o armazenamento de dados permaneça eficaz com suas necessidades em evolução. Otimize o desempenho e a economia à medida que seus requisitos mudam.

Alta disponibilidade e recuperação de desastre

Os clientes de soluções SaaS geralmente têm grandes expectativas de alta disponibilidade (HA) e recuperação de desastres (DR). Se seus clientes operam em setores regulamentados ou confiam em sua solução para operações diárias, seus requisitos podem ser ainda mais rigorosos.

HA e DR não são soluções únicas para todos e dependem de vários fatores. Tenha uma compreensão clara das opções disponíveis que são aplicáveis a você e aos requisitos de seus clientes para tomar decisões informadas sobre a mitigação de diferentes riscos.

Compensação: confiabilidade, custo e desempenho: a resiliência para serviços de dados geralmente requer a distribuição de réplicas ou cópias de seus dados em uma área geográfica mais ampla para reduzir os riscos. No entanto, existem compensações. Quanto maior a distância que os dados precisam percorrer, mais proteção você tem contra falhas localizadas. Mas, copiar dados em distâncias maiores aumenta a latência e geralmente custa mais. Muitos armazenamentos de dados gerenciados fornecem replicação de dados automatizada, mas podem impor limites aos tipos de replicação que você pode executar em diferentes distâncias para manter o desempenho.

Considerações sobre o design

  • Quantifique a resiliência. Meça os requisitos de resiliência usando SLOs (objetivos de nível de serviço), que incluem métricas como tempo de atividade, tempo de recuperação e ponto de recuperação. Essas métricas são orientadas por seus requisitos de negócios e de seus clientes, que podem ter necessidades variadas. Se você armazena grandes quantidades de dados em nome de seus clientes, sua solução de HA e DR pode precisar ser mais complexa para atender a requisitos rigorosos.

    Para obter mais informações sobre métricas de resiliência, consulte Recomendações RE:04 para definir metas de confiabilidade.

  • Use os recursos da plataforma. O Azure fornece recursos para resiliência em um datacenter, em uma região usando zonas de disponibilidade e em uma área geográfica mais ampla usando várias regiões. Combine estratégias como zonas de disponibilidade, backup entre regiões e implantações multirregionais para alcançar o nível certo de resiliência para sua solução. Para requisitos de alta resiliência, considere uma arquitetura multirregional, ativa-passiva com replicação de dados assíncrona entre regiões. Essa abordagem pode resultar em alguma perda de dados durante uma interrupção catastrófica.

    Compensação: designs multirregionais ativos-ativos com replicação são os mais resilientes, mas são complexos de construir e testar. Para a maioria das soluções ativas-ativas, você precisa criar uma abordagem de resolução de conflitos que leve em conta os atrasos na sincronização de dados. A maioria das soluções não precisa desse grau de resiliência.

    Consulte RE :05 Recomendações para usar zonas e regiões de disponibilidade.

  • Use carimbos de implantação para isolar o raio de explosão dos componentes. O padrão de selos de implantação é amplamente usado em soluções SaaS porque oferece benefícios para implantação, gerenciamento, desempenho e resiliência. Por exemplo, a implantação de um selo nos Estados Unidos e outro na Europa garante que os clientes em uma região sejam isolados de interrupções na outra região e possam operar de forma independente.

Recomendações de design

Recomendação Benefício
Concentre-se nos requisitos de resiliência enquanto pensa nos requisitos gerais de dados para você e seus clientes. Ao fundamentar suas decisões de projeto nesses requisitos, você pode garantir que fará as compensações apropriadas e evitar a subengenharia ou o excesso de engenharia para suas necessidades.
Reflita níveis variados de resiliência em seu modelo de cobrança.

Defina expectativas com seus clientes. Perda zero de dados durante interrupções catastróficas ou 100% de tempo de atividade pode ser irreal.		 Os modelos de cobrança podem ajudar seus clientes a entender quanta resiliência garantida eles estão assinando. Por exemplo, com um nível inferior, os clientes obtêm garantias mínimas. Em uma camada mais alta, os clientes recebem mais resiliência porque você pode replicar seus recursos em várias regiões.
Use zonas de disponibilidade do Azure para soluções de produção. Quando possível, use armazenamentos de dados com redundância de zona. As zonas de disponibilidade fornecem resiliência contra interrupções do datacenter, sem aumentar significativamente o custo, a latência ou a complexidade da sua solução.
Mantenha backups de seus armazenamentos de dados em um formato globalmente redundante usando a replicação entre regiões, quando disponível. Os backups de dados entre regiões adicionam um nível extra de resiliência.
Use selos de implantação para criar instâncias separadas de sua solução em locais distribuídos geograficamente. Usando carimbos de implantação para criar instâncias separadas de sua solução em locais distribuídos geograficamente, você pode aumentar a resiliência e fornecer mais benefícios, como gerenciamento de operações mais fácil.
Avalie se você precisa de implantação multirregional e se precisa de um design ativo-ativo para atender aos requisitos.

Considere as compensações envolvidas. Os componentes sem estado são mais fáceis de replicar do que os componentes com estado, como um armazenamento de dados.		 A distribuição de sua solução ou selos entre regiões fornece níveis mais altos de resiliência replicando dados entre regiões.

Segurança e conformidade

Você é responsável por garantir a confidencialidade e a integridade dos dados de seus clientes. Ao criar uma linha de base de segurança, considere seus requisitos e promessas de segurança. Planeje atender às necessidades de conformidade de seus clientes, incluindo retenção de dados.

Considerações sobre o design

  • Rede: considere quem acessará seu armazenamento de dados. Normalmente, apenas seu aplicativo precisa de comunicação direta, portanto, configure-o para rede somente privada.

  • Identidade: considere como seus armazenamentos de dados serão acessados. Muitas soluções SaaS usam uma única identidade de aplicativo para todos os armazenamentos de dados, com a camada de aplicativo impondo isolamento e autorização. Para segurança em nível de linha ou autorização em nível de banco de dados, talvez seja necessário propagar a identidade do usuário para o armazenamento de dados, o que é complexo em um ambiente multilocatário.

  • Retenção de dados: planeje suas políticas de retenção de dados com antecedência. Manter mais dados aumenta os custos de armazenamento e a complexidade do gerenciamento. Por exemplo, grandes quantidades de dados em um banco de dados transacional podem complicar os processos de consulta e truncamento.

    Para retenção de dados de longo prazo, como para conformidade ou análises futuras, considere realocar os dados para um repositório adequado para retenção de longo prazo.

Recomendações de design

Recomendação Benefício
Configure seus armazenamentos de dados para usar pontos de extremidade privados e desabilite pontos de extremidade públicos. Essa abordagem aumenta a segurança restringindo o acesso à sua rede interna. Ao restringir o acesso, você pode reduzir o risco de acesso não autorizado e possíveis violações de dados.
Use identidades gerenciadas e a ID do Microsoft Entra para autenticação. Evite o uso de chaves ou credenciais de banco de dados. As identidades gerenciadas eliminam a necessidade de chaves ou credenciais de banco de dados, o que reduz o risco de roubo de credenciais e simplifica o gerenciamento de acesso.
Ao trabalhar com armazenamentos de dados compartilhados, certifique-se de que o aplicativo defina o escopo de todas as solicitações para um único locatário incluindo o identificador de locatário nas WHERE cláusulas. Esse processo ajuda a reduzir o risco de vazamento ou representação de dados entre locatários.
Planeje sua estratégia de retenção de dados com base na conformidade e nas necessidades de negócios. Evite manter dados históricos desnecessários. Para retenção de longo prazo, mova os dados dos repositórios primários para o armazenamento de arquivamento. Ao evitar retenção desnecessária, você mantém uma área de superfície menor.
Use recursos de armazenamento de dados para dar suporte às suas necessidades de ciclo de vida de dados.

No Azure Cosmos DB, defina a vida útil dos documentos. No SQL do Azure, implemente uma estratégia de janela deslizante usando o particionamento de tabela para minimizar o impacto do processo de arquivamento no banco de dados.		 Essas abordagens garantem o gerenciamento eficiente do ciclo de vida dos dados, otimizam o armazenamento arquivando ou excluindo dados desatualizados e reduzem a intervenção manual quando possível.

Operações

As soluções SaaS geralmente incluem um grande número de bancos de dados ou outros armazenamentos. É importante planejar a manutenção de rotina em sua frota e explorar opções de automação para gerenciar essas tarefas com eficiência.

Considerações sobre o design

  • Entenda as capacidades da sua equipe. Se você não tiver grandes equipes de administradores de banco de dados que possam realizar análises detalhadas nos bancos de dados de clientes individuais, tenha um plano para executar operações em escala e use ferramentas de plataforma sempre que possível.

  • Planeje seus procedimentos regulares de manutenção. Liste as operações regulares de manutenção necessárias e sua frequência. As operações específicas variam de acordo com o tipo de armazenamento de dados que você usa. Por exemplo:

    • Monitore a quantidade total de dados e dados localizados em entidades específicas, como tabelas importantes.
    • Recompilar índices.
    • Crie ou remova índices com base na alteração de padrões de consulta.
    • Rebalancear partições.

    Explore os recursos da plataforma que podem ajudá-lo a realizar manutenção regular e procurar proativamente novos problemas. Por exemplo, o Assistente do Banco de Dados SQL no Banco de Dados SQL do Azure monitora problemas.

  • Design para automação. As operações automatizadas são essenciais para que uma solução SaaS seja dimensionada de forma eficaz. Identifique tarefas regulares e ocasionais e crie manuais ou scripts de automação para elas. Para tarefas que você não pode automatizar imediatamente, documente minuciosamente os processos para garantir consistência e clareza.

Recomendações de design

Recomendação Benefício
Esforce-se para obter consistência entre os armazenamentos de dados dos clientes quando possível.

Se um cliente precisar de acomodações especiais, integre-as a um processo geral em vez de personalizar a configuração para esse cliente. Por exemplo, use o mesmo esquema para cada banco de dados e use os mesmos processos para implantar e gerenciar seus recursos.		 A consistência facilita a realização de alterações em escala e minimiza o risco de problemas acidentais durante implantações ou procedimentos de manutenção.
Implante recursos limitados com cuidado e busque oportunidades para simplificar as operações. Você pode evitar pequenas eficiências e ter melhor utilização de recursos e desempenho geral.
Crie automação para tarefas repetitivas. Opte por comprar ferramentas automatizadas em vez de criar uma solução personalizada.

Explore as opções que a plataforma e os fornecedores que não são da Microsoft fornecem.		 Ao investir em automação de qualidade, você pode usar repetidamente esses ativos e reduzir tarefas manuais que geralmente são propensas a erros. As ferramentas automatizadas são valiosas se você não for um especialista no armazenamento de dados que está usando ou se não tiver certeza sobre as tarefas de manutenção necessárias.
Implante a capacidade de administração de banco de dados da sua equipe com cuidado. Reserve administradores de banco de dados humanos para as atividades mais impactantes, como lidar com grandes clientes ou prediais Ao priorizar funções valiosas, você pode maximizar a eficiência.

Acesso do cliente aos dados

Alguns de seus clientes podem solicitar acesso direto aos dados deles para relatórios ou análises personalizados. Considere cuidadosamente como os clientes podem acessar dados em sua solução e se devem atender a essas solicitações ou fornecer métodos alternativos para atender às suas necessidades.

Considerações sobre o design

  • Justifique os motivos do acesso direto. Entenda por que os clientes precisam de acesso a dados brutos, obtendo informações sobre seu problema de negócios. Colabore para encontrar uma solução que atenda às suas necessidades sem introduzir riscos em sua plataforma.

    Encontre maneiras alternativas de atender aos requisitos em vez de fornecer acesso direto. Se o acesso for necessário para fins de relatório, as abordagens de camada de aplicativo serão preferíveis. Por exemplo, você pode criar relatórios para eles usando o Microsoft Power BI ou exportar um subconjunto de seus dados para um arquivo fornecido a eles. Você também pode criar APIs que eles podem usar para acessar seus dados.

  • Avalie as implicações de segurança e isolamento. Fornecer acesso direto a um armazenamento de dados apresenta riscos de segurança significativos. Evite expor recursos internos a partes externas, incluindo clientes. Em um ambiente SaaS que tem muitos clientes compartilhando uma solução, os riscos são ainda maiores porque o ambiente pode ser explorado para acessar os dados de outros clientes.

    Considere fornecer aos clientes acesso aos seus dados de maneira segura e isolada que não afete seu sistema de produção e permita que você faça alterações no design do banco de dados interno sem interromper as consultas dos clientes.

  • Considere o efeito no desempenho. Permitir acesso direto ao seu armazenamento de dados transacional pode levar a problemas de desempenho para seu aplicativo principal. Por exemplo, um cliente pode executar uma consulta com uso intensivo de recursos que interrompe a funcionalidade do aplicativo.

Recomendações de design

Recomendação Benefício
Evite dar acesso direto aos seus armazenamentos de dados.

Se você precisar conceder acesso direto, forneça acesso a uma réplica somente leitura, se a plataforma de dados der suporte a ela.		 As abordagens de camada de aplicativo oferecem controle sobre como os clientes usam seus dados. Se não for possível criar constructos de camada de aplicativo, o acesso por meio de réplicas somente leitura reduzirá a tensão das consultas do cliente em suas operações.
Evite expor detalhes de implementação interna. Ao controlar o acesso às suas estruturas de dados, você impede que os clientes façam suposições sobre a funcionalidade do esquema de banco de dados. Essa flexibilidade permite que você evolua e otimize sua estrutura de banco de dados ao longo do tempo, sem as restrições de ferramentas criadas pelo cliente ou suposições imprecisas.

Recursos adicionais

A multilocação é uma metodologia de negócios central para projetar cargas de trabalho SaaS. Estes artigos fornecem mais informações sobre considerações de design de dados:

Próxima etapa

Saiba mais sobre as considerações de DevOps para cargas de trabalho de SaaS, incluindo gerenciamento eficiente do ciclo de vida do cliente e práticas de implantação seguras.

Área de design: práticas de DevOps para cargas de trabalho SaaS no Azure