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 da eseguire sulla tua piattaforma.
Casi d'uso
I casi d'uso per queste architetture includono:
- Piattaforme di hosting di app: fornisci una piattaforma in cui i tuoi clienti implementano il loro codice. Ad esempio, una piattaforma di web hosting (i clienti forniscono un web server) o una piattaforma Functions-as-a-Service (i clienti forniscono una funzione).
- Piattaforme di hosting di agenti: i tuoi clienti utilizzano gli SDK per creare agenti AI e 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 piattaforma li esegue poi 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, fornisci un motore di analisi e vuoi consentire ai clienti di scrivere funzioni personalizzate oppure fornisci un gateway API e vuoi consentire ai clienti di filtrare o modificare le richieste in base alla loro logica personalizzata.
- Estensibilità 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 clienti diGoogle Cloud utilizzano Cloud Run in produzione per questi casi d'uso.
Sfide delle piattaforme multi-tenant
Le sfide tipiche della creazione di questa architettura 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 inserimento del codice in un container non è un limite di sicurezza sufficientemente solido. Il codice deve anche essere limitato in ciò che può fare applicando il principio delle autorizzazioni con privilegi minimi.
- Efficienza dei costi: questa architettura può diventare costosa se ogni tenant sostiene costi fissi per la tua piattaforma.
- Gestione dei tenant: la gestione di centinaia di migliaia di tenant può essere difficile, soprattutto quando si tratta di eliminare i 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 predefinite pertinenti per questa architettura:
- Isolamento del calcolo: Cloud Run garantisce un rigoroso isolamento tra le istanze 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 patchati il sistema operativo e il runtime dei carichi di lavoro di cui è stato eseguito il deployment senza richiedere nuovi deployment su larga scala.
- Isolamento di rete: Cloud Run non solo esegue il sandboxing dei container, ma fornisce anche uno stack di rete multi-tenant.
- Identità di servizio: i workload Cloud Run possono essere configurati in modo da avere identità dedicate con autorizzazioni limitate.
Efficienza in termini di costi
- Scale-to-zero e pagamento a consumo: le istanze Cloud Run vengono scalate automaticamente fino a zero quando non sono in uso, garantendo che i workload ospitati vengano addebitati solo quando devono essere eseguiti. con conseguente utilizzo molto efficiente delle risorse rispetto alle architetture che sfruttano macchine virtuali "always-on".
- Fatturazione per richiesta: oltre allo scale-to-zero, puoi usufruire di un modello di fatturazione ancora più granulare che addebita solo l'elaborazione delle richieste, offrendo un'efficienza dei costi ancora maggiore.
- Avvio rapido e on demand: quando vengono ridimensionati, i servizi Cloud Run possono essere scalati rapidamente, con una latenza minima percepita dall'utente finale dell'applicazione di cui è stato eseguito il deployment.
- Etichettatura automatica dei costi: tutti i costi segnalati 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 Organizzare i progetti Google Cloud .
Architettura di destinazione per piattaforme multi-tenant
A livello generale, ecco l'architettura consigliata:
Organizzare i progetti Google Cloud
Devi configurare un'organizzazione, la fatturazione offline e contattare il team dell'account per comunicare che agisci in qualità di account rivenditore.Google Cloud potrebbe collaborare con te per garantire che vengano implementati canali di comunicazione adeguati per la mitigazione degli abusi. Google Cloud
Devi utilizzare le cartelle per organizzare i tuoi Google Cloud progetti, in particolare è essenziale inserire in cartelle diverse i progetti che eseguono il codice proprietario dai progetti 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 umano.
Google consiglia di utilizzare un progetto Google Cloud per tenant. È anche possibile ospitare più tenant nello stesso progetto, ma ciò comporta ulteriori limitazioni:
Un singolo tenant 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 limite rigoroso per tutte le risorse che contiene. Ciò significa che se un tenant ha bisogno di accedere a più risorseGoogle Cloud , come 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 al numero di service account e altre risorse correlate.
- Il numero di progetti è una quota e può essere aumentato. Non ci sono 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 le procedure di eliminazione dei dati, in quanto l'eliminazione dei dati per un tenant si riduce all'eliminazione del progetto corrispondente.
- Google Cloud Monitoring e Logging funzionano su più progetti e possono consentirti 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 regioni disponibili o allocazione massima di CPU/memoria.
La creazione di un progetto e l'inizializzazione di API e risorse possono comportare latenza. Google consiglia di utilizzare un pool di progetti pre-creati da assegnare ai tenant quando necessario. Google Cloud
Più tenant per Google Cloud progetto (non consigliato)
È possibile ospitare più tenant nello stesso progetto Google Cloud, ma Google non consiglia 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 di Google Cloud progetti, 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. Ospitare due tenant distinti nello stesso progetto richiede maggiore attenzione in termini di sicurezza. Ad esempio, utilizzando service account dedicati e autorizzazioni granulari.
Routing delle richieste e domini personalizzati
Se vuoi esporre i servizi Cloud Run del tuo tenant agli utenti finali, ti consigliamo di aggiungere il tuo dominio e utilizzare la tua logica di routing. Ad esempio, per mappare un sottodominio al progetto Google Cloud 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 Cloud, come 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 ciascuno dei livelli di reputazione che offri. Ad esempio, i tenant del livello senza costi non devono essere collegati allo stesso account di fatturazione dei clienti che pagano di più. Google può considerare questi account di fatturazione a diversi livelli di reputazione.
Come descritto in Organizzare i progetti, oltre a separarli per account di fatturazione, devi utilizzare le cartelle per organizzare i progetti. Google Cloud 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 prestabilito, consentendoti di gestire meglio i costi della piattaforma.
Per impostazione predefinita, Google rimuove automaticamente i carichi di lavoro illeciti in base ai Google Cloud termini di servizio. Google può anche registrare gli eventi di rilevamento di abusi in Cloud Logging, su cui puoi intervenire.