Modello di distribuzione delle applicazioni multi-tenant su OCI

Nel mondo odierno incentrato sul cloud, le aziende e i fornitori di software indipendenti (ISV) stanno trasformando sempre più le applicazioni tradizionali in offerte software-as-a-service (SaaS). Un componente fondamentale di questa trasformazione è il modello di implementazione multi-tenant, che consente a più clienti di condividere la stessa applicazione garantendo al contempo sicurezza, prestazioni ed efficienza dei costi. Oracle Cloud Infrastructure (OCI) offre un solido set di servizi che semplifica la fornitura di applicazioni SaaS utilizzando tenancy condivisa e approcci ibridi.

Informazioni sulle tenancy

È importante non confondere la tenancy OCI con il concetto di tenant in un'applicazione SaaS.

Tenancy OCI: questo è l'account che si riceve quando ci si iscrive ai servizi OCI. Rappresenta l'account root e funge da partizione sicura e isolata in cui si organizzano e gestiscono le risorse OCI.

Un tenant (in un contesto SaaS): si supponga che un ISV crei una piattaforma SaaS su OCI. Quando l'ISV mette a disposizione i propri clienti nella piattaforma, ciascuno di questi clienti è considerato un inquilino. Un tenant in questo senso rappresenta un'organizzazione cliente e a ogni tenant possono essere associati più utenti.

In breve, una tenancy OCI fa riferimento all'account OCI stesso, mentre un tenant si riferisce a un'organizzazione (ad esempio un cliente SaaS) che utilizza un'applicazione ospitata su OCI da un'altra entità, come un ISV.

Architettura

Questa architettura rappresenta un modello di distribuzione di applicazioni multi-tenant su OCI, a livello avanzato.

Il seguente diagramma illustra questa architettura di riferimento:


Segue la descrizione dell'immagine cldtenant-app-oci.png
Descrizione dell'illustrazione multi-tenant-app-oci.png

multi-tenant-app-oci-oracle.zip

Questa architettura flessibile è organizzata in tre livelli:

Layer Scopo Azione chiave
Autenticazione iniziale (IAM OCI) Verifica identità globale Emetti token Web JSON (JWT) dopo la convalida delle credenziali
Middleware di autenticazione Verifica identità per ogni richiesta Estrai contesto tenant e utente da JWT
Hook Data Access Layer o ORM Applica l'isolamento dei dati Filtra automaticamente tutte le query in base a tenant_id

Ogni livello è descritto di seguito:

Autenticazione iniziale e istituzione contesto tenant

  • Servizio di autenticazione: l'utente esegue il login, in genere utilizzando un URL specifico del tenant (ad esempio mycompany.app.com) o selezionando un tenant durante il login.
  • OCI Identity and Access Management (OCI IAM) come provider di identità: IAM OCI (in particolare, un dominio di Identity dedicato) convalida le credenziali dell'utente. Fondamentalmente, conferma che l'utente non è solo valido, ma è anche un membro del gruppo di inquilini specifico (ad esempio, mycompany-users) a cui sta tentando di accedere.
  • Emissione JWT: al completamento dell'autenticazione, il dominio di Identity OCI IAM emette un token Web JSON firmato (JWT). Questo token include le seguenti affermazioni critiche:
    • sotto: identificativo univoco dell'utente.
    • gruppi: array di OCID per i gruppi IAM a cui appartiene l'utente. Questa è la chiave per identificare il tenant.
    • È possibile aggiungere una richiesta personalizzata, ad esempio tenant_id o tenant_name, utilizzando attributi personalizzati in IAM OCI. (Facoltativo)

Middleware di autenticazione – livello "Chi"

Il backend deve essere progettato per estrarre e propagare il contesto del tenant in modo sicuro. Questa architettura supporta l'utilizzo di OCI API Gateway o OCI Load Balancer per eseguire l'autenticazione per ogni richiesta e la propagazione del contesto del tenant.

  • Gateway API OCI: questo è il punto di ingresso consigliato. Può eseguire la convalida JWT stessa, scaricando questa responsabilità dal codice dell'applicazione. La si configura per convalidare la firma sull'endpoint JWKS del dominio di Identity IAM OCI.
  • OCI Load Balancer: è in grado di gestire l'interruzione e l'instradamento SSL, ma passerebbe il JWT al middleware di autenticazione per la convalida.

Azione: OCI API Gateway convalida la firma e la scadenza di JWT. Se non valida, la richiesta viene rifiutata immediatamente. Se valido, inoltra la richiesta al servizio a monte, passando spesso il token convalidato o le richieste estratte nelle intestazioni (ad esempio, X-USER-ID, X-TENANT-ID).

Se si utilizza OCI Load Balancer anziché OCI API Gateway, il primo componente del backend dell'applicazione deve essere il middleware di autenticazione.

Azione: estrarre il file JWT dall'intestazione Authorization: Bearer <token>, verificarne la firma utilizzando le chiavi pubbliche di IAM OCI, decodificare le richieste e inserire user_id e tenant_id (derivati dalla richiesta dei gruppi) nel contesto della richiesta per tutti i livelli successivi da utilizzare.

hook ORM (Data Access Layer) o ORM (Object-Relational Mapper) - layer "What"

Questo layer inserisce automaticamente l'ID tenant in ogni query SQL.

  • Esempio: una chiamata a getAllInvoices() viene trasformata in SELECT * FROM invoices WHERE tenant_id = :tenant_id.
  • Applicazione: questa operazione viene applicata in modo ottimale da un livello di accesso ai dati centralizzato o da un hook ORM (ad esempio Hibernate) o da un connection pool "tenant-aware" per evitare errori umani.
  • Hok ORM: meccanismo che consente l'isolamento implicito dei tenant mediante l'intercettazione e la modifica delle operazioni del database a livello di framework dell'applicazione.

Strategie di isolamento dei dati dei tenant:

Questa architettura supporta due opzioni per isolare e proteggere i dati dei tenant:

Opzione 1: Livello applicazione

Ganci/scopi ORM: framework quali Hibernate (Java), Django ORM (Python) o Eloquent (PHP) consentono di definire ambiti globali che aggiungono automaticamente il filtro tenant a tutte le query per un modello specifico.

o

Opzione 2: livello database

È possibile utilizzare una colonna discriminatore, uno schema separato per tenant o un database separato per tenant:

  • Colonna discriminatore (più comune):

    A ogni tabella o documento specifico del tenant viene aggiunta una colonna tenant_id.

    Il Data Access Layer (DAL) o ORM dell'applicazione è responsabile dell'aggiunta automatica della clausola WHERE tenant_id = ? a ogni query. Ciò si ottiene attraverso:

    • Pattern repository: tutti i flussi di accesso al database tramite una classe centrale o un set di classi. Questo repository aggiunge automaticamente il filtro tenant a ogni operazione SELECT, INSERT, UPDATE e DELETE basata su tenant_id nel contesto della richiesta corrente.
    • Contesto di connessione: per alcuni database SQL (ad esempio Oracle HeatWave MySQL), l'applicazione può impostare una variabile di sessione (ad esempio, SET @tenant_id = 'mycompany123';) e quindi utilizzarla nelle viste o nelle stored procedure. Tuttavia, il livello dell'applicazione è ancora responsabile dell'impostazione di questo valore per connessione.
  • Schema per tenant:

    Ogni tenant dispone di uno schema di database dedicato all'interno della stessa istanza di database.

    La logica dell'applicazione, basata sull'ID tenant, deve cambiare lo schema corrente della connessione al database.

    • Connection pool per tenant: gestire un connection pool separato per ogni tenant, in cui ogni connessione è preconfigurata per utilizzare lo schema del tenant (ad esempio, USE tenant_mycompany;).
    • Cambio di connessione dinamico: utilizzare un connection pool che imposta lo schema sul checkout in base al tenant_id corrente, ad esempio utilizzando un comando SET search_path TO tenant_mycompany; per PostgreSQL.
  • Database per tenant:

    Ogni tenant dispone di un'istanza di database separata fisicamente con la cifratura Bring Your Own Keys per le aziende.

    L'applicazione richiede un servizio di ricerca dati tenant per mappare un tenant_id alla stringa di connessione al database corretta.

    • L'applicazione contiene connection pool a più database.
    • DAL utilizza l'ID tenant del contesto di richiesta per ottenere la connessione corretta DAL pool ed eseguire la query sul database tenant dedicato.

    Questa opzione presenta vantaggi e svantaggi:

    • Pros: il massimo isolamento, sicurezza e prestazioni. I tenant possono anche trovarsi su versioni di database o tipi di motore diversi.
    • Cons: maggiori costi generali, costi e complessità operativi. Le migrazioni e le patch del database devono essere eseguite su ogni database tenant.

Questa architettura implementa i seguenti componenti:

  • Tenancy

    Una tenancy è una partizione sicura e isolata impostata da Oracle all'interno di Oracle Cloud al momento dell'iscrizione a OCI. È possibile creare, organizzare e amministrare le risorse su OCI all'interno della tenancy. Una tenancy è sinonimo di azienda o organizzazione. In genere, un'azienda disporrà di una singola tenancy, all'interno della quali rifletterà la propria struttura organizzativa. Una singola tenancy viene in genere associata a una singola sottoscrizione e una singola sottoscrizione di solito ha una sola tenancy.

  • OCI Identity and Access Management

    Oracle Cloud Infrastructure Identity and Access Management (IAM) fornisce il controllo dell'accesso degli utenti per OCI e Oracle Cloud Applications. L'interfaccia API IAM e l'interfaccia utente consentono di gestire i domini di Identity e le risorse al loro interno. Ogni dominio di Identity OCI IAM rappresenta una soluzione standalone di gestione accessi e identità oppure una popolazione di utenti diversa.

  • Load balancer

    Oracle Cloud Infrastructure Load Balancer fornisce una distribuzione automatica del traffico da un singolo punto di accesso a più server.

  • OCI API Gateway

    Oracle Cloud Infrastructure API Gateway ti consente di pubblicare API con endpoint privati accessibili dall'interno della tua rete e che puoi esporre alla rete Internet pubblica, se necessario. Gli endpoint supportano la convalida dell'API, la trasformazione di richieste e risposte, CORS, autenticazione e autorizzazione e limitazione delle richieste.

  • Oracle Key Management Cloud Service

    OCI Key Management Service Oracle Cloud Infrastructure (OCI) Key Management Service (KMS) è un servizio basato su cloud che fornisce gestione e controllo centralizzati delle chiavi di cifratura per i dati memorizzati in OCI. OCI KMS è una cifratura gestita dal cliente e offre OCI Vault (sia Virtual Vault che Private Vault), OCI Dedicated KMS e servizi OCI External KMS.

  • Computazione OCI

    Con Oracle Cloud Infrastructure Compute, puoi eseguire il provisioning e gestire gli host di computazione nel cloud. Puoi avviare istanze di computazione con forme che soddisfano i requisiti delle risorse per CPU, memoria, larghezza di banda della rete e storage. Dopo aver creato un'istanza di computazione, puoi accedervi in modo sicuro, riavviarla, collegare e scollegare i volumi e interromperla quando non ne hai più bisogno.

  • Funzioni OCI

    Oracle Cloud Infrastructure Functions è una piattaforma completamente gestita, multitenant, altamente scalabile, on-demand, Functions-as-a-Service (FaaS). È alimentato dal motore open source di Fn Project. Le funzioni OCI consentono di distribuire il codice e di chiamarlo direttamente o attivarlo in risposta agli eventi. OCI Functions utilizza container Docker ospitati in Oracle Cloud Infrastructure Registry.

  • Motore Kubernetes OCI

    Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine o OKE) è un servizio completamente gestito, scalabile e ad alta disponibile da utilizzare per distribuire le applicazioni containerizzate nel cloud. È possibile specificare le risorse di computazione richieste dalle applicazioni e OKE le esegue il provisioning su OCI in una tenancy esistente. OKE utilizza Kubernetes per automatizzare l'implementazione, il ridimensionamento e la gestione di applicazioni containerizzate tra cluster di host.

  • MySQL Oracle HeatWave

    Oracle MySQL Database Service è un servizio di database completamente gestito che consente agli sviluppatori di sviluppare e distribuire rapidamente applicazioni sicure e native nel cloud utilizzando il database open source più diffuso al mondo. Oracle HeatWave MySQL è un nuovo acceleratore di query in-memory, integrato, ad alte prestazioni per Oracle MySQL Database Service che accelera le prestazioni di MySQL per analytics e query transazionali.

  • Oracle NoSQL Database Cloud Service

    Oracle NoSQL Database Cloud Service semplifica la creazione di applicazioni utilizzando modelli di database documentali, a schema fisso e a valore chiave, offrendo tempi di risposta prevedibili in millisecondi a singola cifra con replica dei dati per l'alta disponibilità. Il servizio offre replica regionale attiva-attiva, transazioni ACID, scalabilità serverless, sicurezza completa e prezzi bassi pay-per-use sia per le modalità di capacità on-demand che quelle di cui è stato eseguito il provisioning, inclusa la compatibilità al 100% con Oracle NoSQL Database on-premise.

  • Memorizzazione degli oggetti OCI

    Lo storage degli oggetti OCI fornisce l'accesso a grandi quantità di dati strutturati e non strutturati di qualsiasi tipo di contenuto, inclusi backup del database, dati analitici e contenuti avanzati come immagini e video. Puoi memorizzare in tutta sicurezza i dati direttamente dalle applicazioni o dall'interno della piattaforma cloud. È possibile ridimensionare lo storage senza subire alcun deterioramento a livello di prestazioni o affidabilità del servizio.

    Utilizza lo storage standard per lo storage "caldo" a cui devi accedere in modo rapido, immediato e frequente. Utilizzare lo storage di archivio per lo storage "a freddo" che si conserva per lunghi periodi di tempo e a cui si accede raramente o raramente.

  • Oracle Autonomous Database Serverless

    Oracle Autonomous Database Serverless è un Oracle Autonomous Database. Hai un database completamente elastico in cui Oracle gestisce in modo autonomo tutti gli aspetti del ciclo di vita del database, dal posizionamento del database al backup e agli aggiornamenti.

  • Cifratura dei dati trasparente

    Transparent Data Encryption (TDE) cifra in modo trasparente i dati archiviati in un Oracle AI Database. TDE è completamente integrato con Oracle AI Database e può cifrare interi backup del database (RMAN), esportazioni di Data Pump, intere tablespace di applicazioni o colonne riservate specifiche. I dati cifrati rimangono cifrati nel database, indipendentemente dal fatto che si trovino nei file di storage delle tablespace, nelle tablespace temporanee, nelle tablespace di undo o in altri file, ad esempio i redo log. Ciò impedisce i tentativi non autorizzati di accedere ai dati del database senza influire sul modo in cui le applicazioni accedono ai dati utilizzando SQL.

Suggerimenti

Utilizzare i suggerimenti riportati di seguito come punto di partenza per progettare l'architettura. I requisiti potrebbero essere diversi dall'architettura descritta qui.
  • VCN

    Quando crei una VCN, determina il numero di blocchi CIDR necessari e la dimensione di ciascun blocco in base al numero di risorse che prevedi di collegare alle subnet nella VCN. Utilizzare blocchi CIDR che si trovano all'interno dello spazio degli indirizzi IP privati standard.

    Seleziona blocchi CIDR che non si sovrappongono a nessun'altra rete (in Oracle Cloud Infrastructure, nel tuo data center on-premise o in un altro provider cloud) a cui intendi impostare connessioni private.

    Dopo aver creato una VCN, è possibile modificare, aggiungere e rimuovere i relativi blocchi CIDR.

    Quando si progettano le subnet, considerare il flusso di traffico e i requisiti di sicurezza. Collegare tutte le risorse all'interno di un livello o ruolo specifico alla stessa subnet, che può fungere da limite di sicurezza.

  • Liste di sicurezza

    Utilizza le liste di sicurezza per definire le regole di entrata e uscita che si applicano all'intera subnet.

  • Gruppi di sicurezza di rete (NSG)

    Puoi utilizzare i gruppi NSG per definire un set di regole di entrata e uscita che si applicano a VNIC specifiche. Si consiglia di utilizzare i gruppi NSG anziché le liste di sicurezza, poiché i gruppi NSG consentono di separare l'architettura della subnet della VCN dai requisiti di sicurezza dell'applicazione.

  • Cloud Guard

    Duplica e personalizza le recipe predefinite fornite da Oracle per creare recipe personalizzate del rilevatore e del rispondente. Queste recipe consentono di specificare il tipo di violazioni della sicurezza che generano un'avvertenza e le azioni che possono essere eseguite su di esse. Ad esempio, potresti voler rilevare bucket di OCI Object Storage con visibilità impostata su pubblico.

    Applica Oracle Cloud Guard a livello di tenancy per coprire l'ambito più ampio e ridurre l'onere amministrativo della gestione di più configurazioni.

    È inoltre possibile utilizzare la funzione Elenco gestito per applicare determinate configurazioni ai rilevatori.

  • Zone di sicurezza

    Per le risorse che richiedono la massima sicurezza, Oracle consiglia di utilizzare le zone di sicurezza. Una zona di sicurezza è un compartimento associato a una recipe dei criteri di sicurezza definita da Oracle basata sulle procedure ottimali. Ad esempio, le risorse in una zona di sicurezza non devono essere accessibili dalla rete Internet pubblica e devono essere cifrate utilizzando chiavi gestite dal cliente. Quando crei e aggiorni le risorse in una zona di sicurezza, OCI convalida le operazioni in base ai criteri nella recipe e impedisce le operazioni che violano uno qualsiasi dei criteri.

Considerazioni

Quando si distribuisce questa architettura, prendere in considerazione queste opzioni.

  • Prestazioni:
    • Imposta la limitazione di frequenza basata sui tenant sulle API
    • Utilizza le quote di risorse Kubernetes per spazio di nomi in OKE per limitare pod, CPU e memoria per tenant
    • Sfrutta pool di nodi dedicati per tenant ad alta richiesta
    • Impostare una dimensione pool per tenant sulla connessione al database
  • Sicurezza:
    • I gruppi IAM OCI controllano il tenant a cui un utente può accedere. Questo viene applicato dal JWT.
    • Consenti a Oracle Cloud Guard di rilevare configurazioni errate
  • Costo:

    Valuta in base alle tue esigenze aziendali se hai bisogno di un livello di tabella, di uno schema o di un database dedicato per i clienti a livello aziendale. Ad esempio:

    • Livello 1: Standard (colonna discriminatore): i tenant condividono le stesse tabelle/schema.
    • Livello 2: Premium (schema per tenant): i tenant ottengono uno schema dedicato all'interno dello stesso database.
    • Livello 3: Enterprise (database per tenant): i tenant ottengono un'istanza di database dedicata.
  • Applicazione di patch e aggiornamenti delle applicazioni

    In un'architettura SaaS a istanza singola e multi-tenant, non è possibile applicare patch a un tenant senza applicarle tutte. Tutti i tuoi clienti condividono la stessa applicazione codebase, runtime e infrastruttura. Questa realtà crea una sfida significativa: come implementare gli aggiornamenti in modo sicuro, efficiente e senza causare tempi di inattività dirompenti per l'intera base di utenti? La risposta risiede nelle moderne strategie di distribuzione DevOps progettate appositamente per questo scopo: utilizzare strategie di distribuzione senza tempi di inattività per consentire transizioni senza interruzioni tra le versioni senza forzare gli utenti offline.

    • Distribuzione blu-verde: si tratta di mantenere due ambienti di produzione identici: uno "blu" (in esecuzione della versione corrente) e uno "verde" (in esecuzione della nuova versione). Dopo aver implementato e testato la nuova versione in verde, puoi passare senza problemi tutto il traffico da blu a verde. Se qualcosa va storto, si torna immediatamente indietro, rendendo il rollback un non evento. Il vecchio ambiente blu viene quindi disattivato.
    • Distribuzione canaria: questa strategia riduce i rischi eseguendo un rollout graduale. La nuova versione viene distribuita a un piccolo sottoinsieme controllato di utenti (i "canari"). Monitorare attentamente questo gruppo per individuare eventuali errori o problemi relativi alle prestazioni. Se le metriche sembrano buone, l'aggiornamento viene gradualmente distribuito a più utenti fino a quando tutti non sono nella nuova versione.

    Comunicare agli utenti la finestra di upgrade obbligatoria (ad esempio, "Se non viene specificata alcuna data di upgrade, l'upgrade si svolgerà automaticamente alle 12:00 di domenica, mm/dd/yyyy"). Dopo la finestra, si interrompono le sessioni per la vecchia versione e si reindirizza tutto il traffico alla nuova versione. Il vecchio codice dell'applicazione viene quindi completamente chiuso.

  • Considerazioni sul database

    Impossibile cambiare lo schema di database nel momento esatto in cui si cambia la versione dell'applicazione. La maggior parte delle aziende SaaS evita questo utilizzando:

    • Modifiche allo schema di database compatibili con le versioni precedenti
    • Flag funzione/toggle
    • Controllo della versione basato sui metadati del tenant

    Ciò consente al nuovo codice di operare in modo sicuro rispetto alle vecchie versioni dello schema durante il rollout, consentendo migrazioni senza tempi di inattività e rollback immediato.

Scopri di più

Ulteriori informazioni sulla distribuzione delle applicazioni multi-tenant.

Esaminare le seguenti risorse aggiuntive:

Conferme

  • Autore: Gururaj Mohan, Enterprise Cloud Architect
  • Collaboratori: Joshua Stanley