Multi-tenancy modello a silo

Alcuni ambienti SaaS multi-tenant potrebbero richiedere l'implementazione dei dati dei tenant su risorse completamente separate a causa di requisiti di conformità e normativi. In alcuni casi, i clienti di grandi dimensioni richiedono cluster dedicati per ridurre l'impatto sulla rumorosità dei vicini. In tali situazioni, è possibile applicare il modello a silo.

Nel modello a silo, l'archiviazione dei dati del tenant è completamente isolata da qualsiasi altro dato del tenant. Tutti i costrutti utilizzati per rappresentare i dati del tenant sono considerati fisicamente unici per quel client, il che significa che ogni tenant avrà generalmente storage, monitoraggio e gestione distinti. Ogni tenant avrà anche una chiave separata AWS Key Management Service (AWS KMS) per la crittografia. In Amazon Neptune, un silo è un cluster per tenant.

Cluster per tenant

È possibile implementare un modello di silo con Neptune disponendo di un tenant per cluster. Il diagramma seguente mostra tre tenant che accedono a un microservizio applicativo in un cloud privato virtuale (VPC), con un cluster separato per ogni tenant.

Ogni cluster dispone di un endpoint individuale che contribuisce a garantire punti di accesso distinti per un'interazione e una gestione efficienti dei dati. Inserendo ogni tenant nel proprio cluster, si crea un confine ben definito tra i tenant, garantendo ai clienti che i loro dati vengano isolati con successo dai dati degli altri tenant. Questo isolamento è interessante anche per le soluzioni SaaS che hanno rigidi vincoli normativi e di sicurezza. Inoltre, se ogni tenant dispone di un proprio cluster, non c'è da preoccuparsi dei rumorosi vicini, in cui un inquilino impone un carico che potrebbe influire negativamente sull'esperienza degli altri inquilini.

Il modello a cluster-per-tenant silo presenta dei vantaggi, ma introduce anche sfide di gestione e agilità. La natura distribuita di questo modello rende più difficile l'aggregazione e la valutazione dell'attività degli inquilini e dello stato operativo tra tutti gli inquilini. L'implementazione diventa inoltre più impegnativa perché la configurazione di un nuovo tenant richiede ora il provisioning di un cluster separato. L'aggiornamento diventa più difficile in ambienti con un livello client condiviso quando gli aggiornamenti e le versioni dei client sono strettamente associati all'aggiornamento del database.

Neptune supporta sia i cluster serverless che quelli con provisioning. Valuta se il carico di lavoro delle tue applicazioni è gestito meglio da istanze serverless o con provisioning. In generale, se il carico di lavoro presenta un livello costante di domanda, le istanze fornite saranno più convenienti. Serverless è ottimizzato per carichi di lavoro impegnativi e altamente variabili con un utilizzo intensivo del database per brevi periodi di tempo seguiti da lunghi periodi di attività leggera o inesistente.

Quando si utilizza un cluster con provisioning di Neptune per tenant, è necessario selezionare una dimensione dell'istanza che si avvicini al carico massimo della domanda del tenant. Questa dipendenza da un server ha anche un impatto a cascata sull'efficienza di scalabilità e sui costi dell'ambiente SaaS. Sebbene l'obiettivo del SaaS sia quello di dimensionare dinamicamente in base al carico effettivo del tenant, un cluster con provisioning di Neptune richiede un provisioning eccessivo per tenere conto dei periodi di utilizzo più intensi e dei picchi di carico. L'over-provisioning aumenta il costo per tenant. Inoltre, poiché l'utilizzo del tenant cambia nel tempo, la scalabilità verso l'alto o verso il basso del cluster deve essere applicata separatamente per ciascun tenant.

Il team di Neptune generalmente sconsiglia un modello a silo a causa dei costi più elevati sostenuti dalle risorse inattive e delle complessità operative aggiuntive. Tuttavia, per carichi di lavoro altamente regolamentati o sensibili che richiedono questo isolamento aggiuntivo, i clienti potrebbero essere disposti a pagare il costo aggiuntivo.

Linee guida all'implementazione per il modello a silo

Per implementare un modello di cluster-per-tenant isolamento dei silos, crea policy di accesso ai dati AWS Identity and Access Management (IAM). Queste policy controllano l'accesso ai cluster Neptune dei tenant assicurando che i tenant possano accedere solo al cluster Neptune contenente i propri dati. Associa la policy IAM per ogni tenant a un ruolo IAM. Il microservizio dell'applicazione utilizza quindi il ruolo IAM per generare credenziali temporanee granulari utilizzando il metodo di (). AssumeRole AWS Security Token Service AWS STS Queste credenziali, che hanno accesso solo al cluster Neptune per quel tenant, vengono utilizzate per connettersi al cluster Neptune del tenant.

Il seguente frammento di codice mostra un esempio di policy IAM basata sui dati:

{
  "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"
        }      
      }
    }
  ]
}

Il codice fornisce a un tenant di esempio l'tenant-1accesso alle query di lettura e scrittura ai rispettivi cluster Neptune. L'Conditionelemento garantisce che solo l'entità chiamante (la principale), che ha assunto il ruolo tentant-1 IAM (tenant-role-1), sia autorizzata ad accedere al cluster Neptune tenant-1 di Neptune.