SaaS Factory (A série) — Particionamento de dados: Estratégias de Armazenamento em SaaS (Parte 3/3)

Neste post, continuaremos falando sobre arquiteturas de particionamento de dados: estratégias de armazenamento em SaaS.

Híbrido: O compromisso com o negócio

Para muitas organizações, a escolha de uma estratégia não é tão simples quanto selecionar o modelo de Silo, Bridge ou Pool. Seus inquilinos e sua empresa terão uma influência significativa em como você aborda a seleção de uma estratégia de armazenamento. Em alguns casos, uma equipe pode identificar uma pequena coleção de seus inquilinos que requer o modelo de Silo ou Bridge. Depois de tomarem essa decisão, suponha que eles tenham que implementar todo o armazenamento com esse modelo. Isso limita artificialmente sua capacidade de abraçar os inquilinos que podem estar abertos a um modelo Pool. Na verdade, pode adicionar custo ou complexidade para uma camada de inquilinos que não estão exigindo os atributos do modelo de Silo ou Bridge. Um possível compromisso é construir uma solução que dê suporte total ao armazenamento “pooled” como sua base. Então, você pode criar um banco de dados separado para os inquilinos que exigem uma solução de armazenamento em Silos. A figura a seguir fornece um exemplo dessa abordagem em ação.

Aqui, temos dois inquilinos (Inquilino 1 e Inquilino 2) que estão aproveitando um modelo Silo e os locatários restantes estão em execução em um modelo de armazenamento em pool. Isso é abstraído por uma camada de acesso a dados que esconde os desenvolvedores do armazenamento subjacente do inquilino. Embora isso possa adicionar um nível de complexidade à sua camada de acesso a dados e perfil de gerenciamento, ele também pode oferecer a sua empresa uma maneira de escalonar sua oferta para representam o melhor dos dois mundos.

Migração de Dados

A migração de dados é uma daquelas áreas que muitas vezes é deixada de fora da avaliação de modelos de armazenamento SaaS. No entanto, com SaaS, considere como suas escolhas arquiteturais influenciarão sua capacidade de implantar continuamente novos recursos e capacidades. Embora o desempenho e a experiência geral do locatário são importantes de enfatizar, também é essencial considerar como seu armazenamento solução irá acomodar mudanças contínuas na representação subjacente de seus dados.

Migração e Multitenancy

Cada um dos modelos de armazenamento multilocatário requer sua própria abordagem única para lidar com a migração de dados. Nos modelos de silo e bridge, você pode migrar dados em locatário por locatário. Sua organização pode achar isso atraente porque permite que você migre cuidadosamente cada locatário SaaS sem expor todos os locatários a a possibilidade de um erro de migração. No entanto, esta abordagem pode apresentar mais complexidade na orquestração geral do seu ciclo de vida de implantação. A migração de dados no modelo de pool pode ser atraente e desafiadora. A migração em um modelo de pool fornece um único ponto que, uma vez migrado, todos os inquilinos fizeram a transição com sucesso para seu novo modelo de dados. No outro, por outro lado, qualquer problema introduzido durante a migração de um pool pode afetar todos os seus inquilinos. Desde o início, você deve pensar em como a migração de dados se encaixa em seu estratégia SaaS multitenant geral. Se você preparar esta orquestração de migração em seu pipeline de entrega mais cedo, você tende a alcançar um maior grau de agilidade em seu processo de liberação.

Considerações de segurança

A segurança dos dados deve ser uma prioridade para os provedores de SaaS. Ao adotar um estratégia multilocatária, sua organização precisa de uma estratégia de segurança robusta para garantir que os dados do inquilino sejam protegidos de forma eficaz contra acesso não autorizado. Protegendo esses dados e transmitindo que seu sistema empregou o medidas de segurança adequadas são essenciais para ganhar a confiança do seu SaaS clientes. As estratégias de armazenamento que você escolher provavelmente usarão padrões de segurança comuns compatível com AWS. Criptografar dados em repouso, por exemplo, é uma estratégia horizontal que pode ser aplicado universalmente em qualquer um dos modelos. Isso fornece um nível básico de segurança que garante que — mesmo que haja dados não autorizados acesso aos dados — seria inútil sem as chaves necessárias para descriptografar a informação.

Multitenancy no DynamoDB

A natureza de como os dados são definidos e gerenciados pelo DynamoDB adiciona alguns novos mudanças em como você aborda a multilocação. Embora alguns serviços de armazenamento se alinhem bem com as estratégias tradicionais de particionamento de dados, o DynamoDB tem um mapeamento um pouco menos direto para os modelos de Silo, Bridge e Pool. Com o DynamoDB, você tem que considerar alguns fatores adicionais ao selecionar sua estratégia de multilocatário. As seções a seguir exploram os mecanismos AWS que são comumente usados para realizar cada um dos esquemas de particionamento multilocatário no DynamoDB.

Modelo Silo

Se você implementar um modelo de silo no DynamoDB, terá que encontrar uma maneira de criar um agrupamento de uma ou mais tabelas associadas a um inquilino. A abordagem também deve criar uma visão segura e controlada dessas tabelas para satisfazer os requisitos de segurança dos clientes do silo, evitando qualquer possibilidade de acesso de dados entre inquilinos.

Modelo Bridge

Para Bridge, a única questão seria se você pode relaxar um pouco do requisitos de isolamento descritos com o modelo de silo. Você pode conseguir isso por eliminando a introdução de quaisquer políticas de IAM em nível de tabela. Assumindo o seu inquilinos não exigem isolamento total, você pode argumentar que a remoção do IAM políticas podem simplificar seu esquema de provisionamento. No entanto, mesmo no modelo Bridge, há méritos no isolamento. Portanto, embora a eliminação do isolamento IAM possa ser atraente, ainda é uma boa prática de SaaS alavancar construções e políticas que pode restringir o acesso entre inquilinos.

Modelo Pool

Implementar o modelo de pool no DynamoDB requer que você dê um passo atrás e considere como o serviço gerencia os dados. Como os dados são armazenados no DynamoDB, o o serviço deve avaliar e particionar continuamente os dados para obter escala. E se o perfil de seus dados é distribuído uniformemente, você pode simplesmente confiar neste esquema de particionamento subjacente para otimizar o desempenho e o perfil de custo de seus inquilinos SaaS.

Vejamos um exemplo de como você pode dar vida a essa solução. Primeiro, você precisa de uma tabela separada, que chamaremos de “tabela de pesquisa de locatário”, para capturar e gerenciar o mapeamento de inquilinos para seus correspondentes DynamoDB chaves de partição. A figura a seguir representa um exemplo de como você pode estruturar seu tabela de pesquisa de inquilino.

Multitenancy no RDS

A construção e representação de dados em RDS é muito mais uma extensão de ambientes relacionais não gerenciados. Os mecanismos básicos que estão disponíveis no MySQL, por exemplo, também estão disponíveis no RDS. Isso torna o realização de multilocação em todos os sabores RDS relativamente simples. As seções a seguir descrevem as várias estratégias que são comumente empregado para realizar os modelos de particionamento em RDS.

Modelo Silo

Você pode alcançar o padrão de silo na AWS de várias maneiras. No entanto, a abordagem comum e mais simples para alcançar o isolamento é criar instâncias de banco de dados para cada locatário. Por meio de instâncias, você pode atingir um nível de separação que normalmente satisfaz as necessidades de conformidade dos clientes sem as despesas gerais de provisionamento de contas totalmente separadas.

Modelo Bridge

O modelo da ponte oferece a oportunidade de ter inquilinos com diferentes esquemas e alguma flexibilidade ao migrar dados do locatário. Você poderia, por exemplo, ter diferentes locatários executando diferentes versões do produto em um determinado momento e migre gradualmente as alterações de esquema em uma base de locatário por locatário. A figura a seguir fornece um exemplo de uma maneira de implementar o modelo de Bridge em RDS. Neste diagrama, você tem uma única instância de banco de dados RDS que contém tabelas de clientes separadas para Tenant1 e Tenant2.

Outra opção aqui seria introduzir a noção de bancos de dados separados para cada inquilino em uma instância. A terminologia varia para cada sabor de RDS. Alguns contêineres de armazenamento RDS se referem a isso como banco de dados; outros o rotulam como um esquema.

Modelo Pool

O modelo de pool para RDS depende de esquemas tradicionais de indexação relacional para particionar dados do locatário. Como parte da movimentação de todos os dados do locatário para um modelo de infraestrutura, você armazena os dados do locatário em uma única instância RDS e o os inquilinos compartilham mesas comuns. Essas tabelas são indexadas com um locatário exclusivo identificador que é usado para acessar e gerenciar os dados de cada locatário

Conclusões

Embora não haja uma estratégia única que se adapte universalmente a todos os ambientes, é claro que alguns modelos se alinham melhor com os princípios básicos da entrega do modelo SaaS. Em geral, as abordagens baseadas em pool para armazenamento, alinham-se bem com a necessidade de uma abordagem unificada para gerenciar e operar em um ambiente multilocatário. Ter todos os seus inquilinos compartilhando repositórios e representações simplifica e unifica sua abordagem operacional e de implantação, permitindo visões de saúde entre locatários e performance.

Nos próximos posts, falaremos sobre Identidade e Acesso: os segredos de controle de Identidade e Acesso em SaaS.

SaaS Factory (A série) — Como construir soluções de Software como Serviço na AWS

Até lá! =)