Multilocação em modelo de silo

Alguns ambientes SaaS multilocatários podem exigir que os dados dos locatários sejam implantados em recursos totalmente separados devido aos requisitos regulatórios e de conformidade. Em alguns casos, grandes clientes precisam de clusters dedicados para reduzir o impacto de vizinhos ruidosos. Nessas situações, você pode aplicar o modelo de silo.

No modelo de silo, o armazenamento dos dados do inquilino é totalmente isolado de qualquer outro dado do inquilino. Todas as construções usadas para representar os dados do inquilino são consideradas fisicamente exclusivas desse cliente, o que significa que cada inquilino geralmente terá armazenamento, monitoramento e gerenciamento distintos. Cada inquilino também terá uma chave AWS Key Management Service (AWS KMS) separada para criptografia. No Amazon Neptune, um silo é um cluster por inquilino.

Cluster por inquilino

Você pode implementar um modelo de silo com o Neptune tendo um inquilino por cluster. O diagrama a seguir mostra três locatários acessando um microsserviço de aplicativo em uma nuvem privada virtual (VPC), com um cluster separado para cada inquilino.

Cada cluster tem seu endpoint individual para ajudar a garantir pontos de acesso distintos para interação e gerenciamento eficientes de dados. Ao colocar cada inquilino em seu próprio cluster, você cria um limite bem definido entre os locatários, garantindo aos clientes que seus dados sejam isolados com sucesso dos dados de outros locatários. Esse isolamento também é atraente para soluções SaaS que têm restrições regulatórias e de segurança rígidas. Além disso, quando cada inquilino tem seu próprio cluster, você não precisa se preocupar com vizinhos barulhentos, onde um inquilino impõe uma carga que pode afetar adversamente a experiência de outros inquilinos.

Embora o modelo de cluster-per-tenant silo tenha vantagens, ele também apresenta desafios de gerenciamento e agilidade. A natureza distribuída desse modelo torna mais difícil agregar e avaliar a atividade dos inquilinos e a integridade operacional de todos os inquilinos. A implantação também se torna mais desafiadora porque a configuração de um novo inquilino agora exige o provisionamento de um cluster separado. A atualização se torna mais desafiadora em ambientes com uma camada de cliente compartilhada quando as atualizações e versões do cliente estão fortemente acopladas à atualização do banco de dados.

O Neptune oferece suporte a clusters provisionados e sem servidor. Avalie se a carga de trabalho do seu aplicativo é melhor gerenciada por instâncias provisionadas ou sem servidor. Em geral, se sua carga de trabalho tiver um nível constante de demanda, as instâncias provisionadas serão mais econômicas. O Serverless é otimizado para cargas de trabalho exigentes e altamente variáveis, com uso intenso do banco de dados por curtos períodos de tempo seguidos por longos períodos de atividade leve ou nenhuma atividade.

Ao usar um cluster provisionado pelo Neptune por locatário, você deve selecionar um tamanho de instância que se aproxime da carga máxima da demanda do seu locatário. Essa dependência de um servidor também tem um impacto em cascata na eficiência de escalabilidade e no custo do seu ambiente SaaS. Embora a meta do SaaS seja dimensionar dinamicamente com base na carga real do inquilino, um cluster provisionado pelo Neptune exige que você provisione em excesso para compensar períodos mais pesados de uso e picos nas cargas. O provisionamento excessivo aumenta o custo por inquilino. Além disso, à medida que o uso do inquilino muda com o tempo, a ampliação ou redução do cluster deve ser aplicada separadamente para cada inquilino.

A equipe do Neptune geralmente desaconselha um modelo de silo devido ao maior custo incorrido por recursos ociosos e às complexidades operacionais adicionais. No entanto, se cargas de trabalho altamente regulamentadas ou sensíveis exigirem esse isolamento adicional, os clientes podem estar dispostos a pagar o custo adicional.

Orientação de implementação para o modelo de silo

Para implementar um modelo de cluster-per-tenant isolamento de silos, crie políticas de acesso a dados AWS Identity and Access Management (IAM). Essas políticas controlam o acesso aos clusters Neptune dos inquilinos, garantindo que os inquilinos possam acessar somente o cluster Neptune contendo seus próprios dados. Vincule a política do IAM de cada inquilino a uma função do IAM. O microsserviço do aplicativo então usa a função do IAM para gerar credenciais temporárias refinadas usando o AssumeRole método de (). AWS Security Token Service AWS STS Essas credenciais, que têm acesso somente ao cluster Neptune desse inquilino, são usadas para se conectar ao cluster Neptune do inquilino.

O trecho de código a seguir mostra um exemplo de política do IAM baseada em dados:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "neptune-db:ReadDataViaQuery",
        "neptune-db:WriteDataViaQuery"
      ],
      "Resource": "arn:aws:neptune-db:us-east-1:123456789012:tenant-1-cluster/*",
      "Condition": {
        "ArnEquals": {
          "aws:PrincipalArn": "arn:aws:iam::123456789012:role/tenant-role-1"
        }      
      }
    }
  ]
}

O código fornece um exemplo de inquilino,tenant-1, com acesso de consulta de leitura e gravação ao respectivo cluster Neptune. O Condition elemento garante que somente a entidade chamadora (a principal), que assumiu a função do tentant-1 IAM (tenant-role-1), tenha permissão para acessar o cluster tenant-1 Neptune.