Questa pagina fornisce le best practice per la creazione di un'architettura multi-tenant per ospitare codice non attendibile con Cloud Run. In qualità di cliente Google Cloud , un "tenant" è definito come uno dei tuoi clienti e il "codice non attendibile" è il codice fornito da questi tenant per essere eseguito sulla tua piattaforma.
Casi d'uso
I casi d'uso di queste architetture includono:
- App Hosting: fornisci una piattaforma in cui i tuoi clienti eseguono il deployment del loro codice. Ad esempio, una piattaforma di hosting web (i clienti forniscono un server web) o una piattaforma Functions as a Service (i clienti forniscono una funzione).
- Piattaforme di hosting degli agenti: i tuoi clienti utilizzano gli SDK per creare agenti AI, la tua piattaforma li esegue in background.
- Piattaforme di modelli ottimizzati: offri la possibilità di personalizzare i modelli di AI in base al cliente. La tua piattaforma li esegue on demand sfruttando le GPU.
- Funzioni definite dall'utente: il tuo software consente ai clienti di definire una logica personalizzata utilizzando il codice. Ad esempio, se fornisci un motore di analisi e vuoi consentire ai clienti di scrivere funzioni personalizzate o se fornisci un gateway API e vuoi consentire ai clienti di filtrare o modificare le richieste in base alla loro logica personalizzata.
- Estendibilità del Software as a Service (SaaS): potresti offrire un SaaS e voler consentire ai clienti di estenderne le funzionalità utilizzando le estensioni. Queste estensioni potrebbero essere scritte da clienti o partner.
I clientiGoogle Cloud utilizzano con successo Cloud Run in produzione per questi casi d'uso.
Sfide delle piattaforme multi-tenant
Le sfide tipiche della creazione di un'architettura di questo tipo includono:
- Sicurezza: è impossibile scansionare o sanificare il codice fornito. Il codice non attendibile può includere azioni dannose o dipendenze vulnerabili. Se non adeguatamente isolato, il codice non attendibile potrebbe potenzialmente accedere a dati sensibili appartenenti ad altri tenant. Il semplice pacchettizzazione del codice in un container non è un confine di sicurezza sufficientemente forte. Inoltre, il codice deve essere limitato nelle sue azioni applicando il principio del privilegio minimo.
- Efficienza dei costi: questa architettura può diventare costosa se ogni tenant comporta costi fissi per la tua piattaforma.
- Gestione dei tenant: la gestione di centinaia di migliaia di tenant può essere difficile, in particolare per quanto riguarda l'eliminazione dei dati.
Vantaggi di Cloud Run
Un'architettura basata su Cloud Run offre una soluzione per le sfide comuni con molti vantaggi, come sicurezza, efficienza dei costi e gestione dei tenant.
Sicurezza
Cloud Run fornisce le funzionalità di sicurezza pronte all'uso pertinenti per questa architettura:
- Isolamento del computing: Cloud Run garantisce un isolamento rigoroso tra le istanze di container, che si tratti dello stesso servizio o di servizi diversi di progetti diversi. Per saperne di più sulla sicurezza dei container e sugli ambienti di esecuzione, consulta la Panoramica della progettazione della sicurezza.
- Aggiornamenti della sicurezza: gli aggiornamenti automatici della sicurezza delle immagini di base possono essere abilitati per mantenere aggiornati e con patch il sistema operativo e il runtime dei workload di cui è stato eseguito il deployment, senza richiedere nuovi deployment su larga scala.
- Isolamento della rete: Cloud Run non solo esegue il sandboxing dei container, ma fornisce anche uno stack di networking multi-tenant.
- Identità di servizio: i workload di Cloud Run possono essere configurati in modo da avere identità dedicate con autorizzazioni limitate.
Efficienza in termini di costi
- Scale down fino a zero e pagamento a consumo: le istanze di Cloud Run eseguono automaticamente lo scale down fino a zero quando non sono in uso, garantendo che i workload ospitati vengano addebitati solo quando devono essere eseguiti. Ciò si traduce in un utilizzo molto efficiente delle risorse rispetto alle architetture che sfruttano macchine virtuali "sempre attive".
- Fatturazione per richiesta: oltre allo scale to zero, puoi usufruire di un modello di fatturazione ancora più granulare che addebita i costi solo quando le richieste vengono elaborate, offrendo un'efficienza in termini di costi ancora maggiore.
- On demand e avvio rapido: dopo aver fatto lo scale down, i servizi Cloud Run possono eseguire rapidamente lo scale up, con una latenza minima percepita dall'utente finale dell'applicazione di cui è stato eseguito il deployment.
- Etichettatura automatica dei costi: tutti i costi registrati da Cloud Run sono etichettati, consentendoti di automatizzare l'attribuzione e il monitoraggio dei costi dei tuoi tenant.
- Impegni per ridurre i costi aggregati: a livello di account di fatturazione, puoi utilizzare gli sconti per impegno di utilizzo flessibile per ottimizzare la spesa per qualsiasi utilizzo di base di Cloud Run.
Gestione tenant
A causa della sua natura on demand, i costi di Cloud Run non sono più elevati quando utilizzi più progetti Google Cloud , consentendo la gestione dei tenant come descritto in Organizza i tuoi progetti Google Cloud .
Architettura di destinazione per piattaforme multi-tenant
A livello generale, l'architettura consigliata è la seguente:
Organizzazione dei progetti Google Cloud
Devi configurare un'organizzazione Google Cloud , la fatturazione offline e contattare il team dedicato al tuo account per comunicare che stai agendo come account rivenditore.Google Cloud potrebbe collaborare con te per garantire che vengano messi in atto canali di comunicazione adeguati per la mitigazione degli abusi.
Devi utilizzare le cartelle per organizzare i tuoi progetti Google Cloud , in particolare è essenziale inserire in cartelle diverse i progetti che eseguono il tuo codice proprietario da quelli che eseguono il codice non attendibile dei tuoi tenant. Devi automatizzare l'onboarding dei tenant in modo che la creazione dei progetti e delle risorse di un tenant non richieda l'intervento human-in-the-loop.
Google consiglia di utilizzare un progetto Google Cloud per tenant. È anche possibile ospitare più tenant nello stesso progetto, ma questo comporta limitazioni aggiuntive:
Tenant singolo per progetto Google Cloud (consigliato)
In questa architettura, ogni tenant della tua piattaforma è ospitato in un progettoGoogle Cloud dedicato, il che offre molti vantaggi:
- Sicurezza più semplice: il progetto Google Cloud è un confine rigido per tutte le risorse che contiene. Ciò significa che se un tenant deve accedere a più risorseGoogle Cloud , ad esempio più servizi Cloud Run, un bucket Cloud Storage, puoi utilizzare il progetto come perimetro sicuro.
- Meno limitato:
- Il numero di risorse in un determinato progetto è limitato. Ad esempio, Cloud Run consente di creare solo 1000 servizi per regione in un progetto. Esistono limiti simili per il numero di service account e altre risorse correlate.
- Il numero di progetti è di per sé una quota e può essere aumentato. Non esistono limiti a questo numero per un'organizzazione Google Cloud . Esiste un limite flessibile di 100.000 progetti per account di fatturazione, che può essere moltiplicato contattando Google. La tua organizzazione può anche creare molti account di fatturazione e raggrupparli in un "gruppo di account" (attualmente in anteprima privata).
- Monitoraggio e gestione più semplici:
- L'utilizzo di un progetto per tenant semplifica i processi di eliminazione dei dati, in cui l'eliminazione dei dati per un tenant si riduce all'eliminazione del rispettivo progetto.
- Google Cloud Monitoring e Logging funzionano su più progetti e ti consentono di monitorare l'intero parco risorse.
- Le quote a livello di progetto ti consentono di limitare l'utilizzo delle risorse Cloud Run per un determinato tenant, allineando potenzialmente i limiti ai tuoi livelli di prezzo.
- Le policy dell'organizzazione personalizzate ti consentono di applicare a tutti i progetti di una cartella restrizioni specifiche, come le regioni disponibili o l'allocazione massima di CPU/memoria.
La creazione di un progetto Google Cloud e l'inizializzazione di API e risorse possono presentare latenza, pertanto Google consiglia di utilizzare un pool di progetti pre-creati da assegnare ai tenant quando necessario.
Più tenant per progetto Google Cloud (non consigliato)
È possibile ospitare più tenant nello stesso progetto Google Cloud, ma Google sconsiglia questa architettura.
Molti servizi Google Cloud hanno limiti di risorse per progetto. Ad esempio, Cloud Run ha un limite non modificabile di 1000 servizi Cloud Run per regione in un progetto. Di conseguenza, l'hosting di più tenant per progetto richiederà comunque la gestione di un parco risorse di progetti Google Cloud , il che aumenterà complessivamente la complessità della gestione dei tenant. Dal punto di vista della sicurezza, i progettiGoogle Cloud sono progettati come un confine di sicurezza, quindi l'hosting di due tenant distinti negli stessi progetti richiede una maggiore attenzione in termini di sicurezza. Ad esempio, utilizzando service account dedicati e autorizzazioni granulari.
Deployment in più regioni
Per l'affidabilità e la scalabilità, Google consiglia di distribuire i deployment dei tenant su più regioniGoogle Cloud . Il deployment di ogni applicazione tenant viene eseguito in una singola regione, ma puoi utilizzare regioni diverse per tenant diversi. La selezione della regione può essere casuale o può tenere conto della località del tenant per ottimizzare la latenza.
Routing delle richieste e domini personalizzati
Se vuoi esporre i servizi Cloud Run del tuo tenant agli utenti finali, devi aggiungere il tuo dominio e utilizzare la tua logica di routing. Ad esempio, per mappare un sottodominio al progetto Google Cloud Project Hosting che ospita il servizio del tenant.
Puoi implementare il tuo servizio di routing personalizzato, ma Google consiglia di utilizzare un bilanciatore del carico delle applicazioni esterno globale con Service Extensions per la logica di routing. Le estensioni di servizio possono essere implementate come plug-in (dove la logica viene eseguita in linea con l'elaborazione delle richieste) o callout (la logica di routing viene delegata a un servizio Cloud Run separato che può chiamare uno dei database multiregionali scalabili diGoogle Cloudcome Spanner).
L'utilizzo di un bilanciatore del carico delle applicazioni ti consentirà anche di aggiungere un livello di memorizzazione nella cache sfruttando Cloud CDN e una protezione aggiuntiva dagli attacchi DDoS (Distributed Denial of Service) alla tua piattaforma utilizzando Cloud Armor.
Reputazione e abuso
Qualsiasi piattaforma di hosting autorizzata a eseguire codice non attendibile sarà soggetta ad abusi.
Ti consigliamo di utilizzare un account di fatturazione Cloud diverso per ogni livello di reputazione che offri. Ad esempio, i tenant del Livello senza costi non devono essere collegati allo stesso account di fatturazione dei clienti paganti di fascia alta. Google può considerare questi account di fatturazione a diversi livelli di reputazione.
Come descritto in Organizza i progetti Google Cloud , oltre a separare gli account di fatturazione, devi utilizzare le cartelle per organizzare i progetti. Google può aiutarti a impostare quote a livello di cartella per garantire che tutte le risorse all'interno di una cartella non consumino mai più di un massimo impostato, consentendoti di gestire meglio i costi della tua piattaforma.
Per impostazione predefinita, Google rimuove automaticamente i workload illeciti in base ai Termini di servizio diGoogle Cloud . Google può anche registrare gli eventi di rilevamento di attività illecite in Cloud Logging, in modo che tu possa intervenire.