Esegui il deployment dello strumento Autoscaler nelle funzioni Cloud Run

Lo strumento di scalabilità automatica è progettato per garantire flessibilità e può adattarsi alla suddivisione esistente delle responsabilità tra i team di operazioni e di applicazioni. La responsabilità di configurare la scalabilità automatica delle istanze Spanner può essere centralizzata in un unico team operativo o distribuita ai team più vicini alle applicazioni servite da queste istanze Spanner.

Questo documento fa parte di una serie che include anche:

Questa serie è rivolta ai team IT, Operations e Site Reliability Engineering (SRE) che vogliono ridurre l'overhead operativo e ottimizzare il costo degli implementazioni di Spanner.

Questa pagina illustra tre modi per eseguire il deployment di Autoscaler in Cloud Run Functions, in base ai tuoi requisiti:

  • Una topologia di deployment per progetto. L'infrastruttura di Autoscaler viene dispiata nello stesso progetto di Spanner che deve essere sottoposto a scalabilità automatica. Consigliamo questa topologia per i team indipendenti che vogliono gestire la propria configurazione e infrastruttura di Autoscaler. Una topologia di deployment per progetto è anche un buon punto di partenza per testare le funzionalità dell'Autoscaler.
  • Una topologia di deployment centralizzata. Lo strumento Autoscaler viene implementato in un progetto e gestisce una o più istanze Spanner in progetti diversi. Consigliamo questa topologia per i team che gestiscono la configurazione e l'infrastruttura di una o più istanze Spanner, mantenendo al contempo i componenti e la configurazione di Autoscaler in un unico posto. Nella topology centralizzata, oltre a un progetto Autoscaler, devi configurare un secondo progetto, denominato in questo tutorial Progetto applicazione. Il progetto dell'applicazione contiene le risorse dell'applicazione, incluso Spanner.
  • Una topologia di deployment distribuita. La maggior parte dell'infrastruttura di Autoscaler viene dispiattata in un progetto, ma alcuni componenti dell'infrastruttura vengono dispiattati con la scalabilità automatica delle istanze Spanner in progetti diversi. Consigliamo questa topologia per le organizzazioni con più team, in cui i team che possiedono le istanze Spanner vogliono gestire solo i parametri di configurazione del gestore della scalabilità automatica per le proprie istanze, mentre il resto dell'infrastruttura del gestore della scalabilità automatica è gestito da un team centrale.

Serverless per facilitare il deployment e la gestione

In questo modello, lo strumento Autoscaler viene creato utilizzando solo strumenti serverless e a bassa gestione Google Cloud , come le funzioni Cloud Run, Pub/Sub, Cloud Scheduler e Firestore. Questo approccio riduce al minimo il costo e l'overhead operativo dell'esecuzione dello strumento Autoscaler.

Utilizzando gli strumenti Google Cloud integrati, lo strumento Autoscaler può sfruttare al meglio Identity and Access Management (IAM) per l'autenticazione e l'autorizzazione.

Configurazione

Lo strumento Autoscaler gestisce le istanze Spanner tramite la configurazione definita in Cloud Scheduler. Se è necessario eseguire il polling di più istanze Spanner con lo stesso intervallo, ti consigliamo di configurarle nello stesso job Cloud Scheduler. La configurazione di ogni istanza è rappresentata come oggetto JSON. Di seguito è riportato un esempio di configurazione in cui due istanze Spanner vengono gestite con un job Cloud Scheduler:

[
  {
    "projectId": "my-spanner-project",
    "instanceId": "my-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "NODES",
    "minSize": 1,
    "maxSize": 3
  },
  {
    "projectId": "different-project",
    "instanceId": "another-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "PROCESSING_UNITS",
    "minSize": 500,
    "maxSize": 3000,
    "scalingMethod": "DIRECT"
  }
]

Le istanze Spanner possono avere più configurazioni su diversi job Cloud Scheduler. Ad esempio, un'istanza può avere una configurazione di Autoscaler con il metodo lineare per le normali operazioni, ma anche un'altra configurazione di Autoscaler con il metodo diretto per i carichi di lavoro batch pianificati.

Quando il job Cloud Scheduler viene eseguito, invia un messaggio Pub/Sub all'argomento Pub/Sub di polling. Il payload di questo messaggio è l'array JSON degli oggetti di configurazione per tutte le istanze configurate nello stesso job. Consulta l'elenco completo delle opzioni di configurazione nel file README del poller.

Topologia per progetto

In un deployment della topologia per progetto, ogni progetto con un'istanza Spanner che deve essere sottoposta a scalabilità automatica ha anche il proprio deployment indipendente dei componenti Autoscaler. Consigliamo questa topologia per i team indipendenti che vogliono gestire la propria configurazione e infrastruttura di Autoscaler. È anche un buon punto di partenza per testare le funzionalità dello strumento di scalabilità automatica.

Il seguente diagramma mostra una visione concettuale di alto livello di un deployment per progetto.

Deployment concettuale per progetto.

I deployment per progetto mostrati nel diagramma precedente hanno le seguenti caratteristiche:

  • Due applicazioni, Applicazione 1 e Applicazione 2, utilizzano ciascuna le proprie istanze Spanner.
  • Le istanze Spanner (A) si trovano nei rispettivi progetti Application 1 e Application 2.
  • In ogni progetto viene implementato un Autoscaler (B) indipendente per controllare la scalabilità automatica delle istanze all'interno di un progetto.

Un deployment per progetto presenta i seguenti vantaggi e svantaggi.

Vantaggi:

  • Design più semplice: la topologia per progetto è il design più semplice delle tre topologie, poiché tutti i componenti di Autoscaler vengono di cui vengono eseguiti il deployment insieme alle istanze Spanner di cui viene eseguita la scalabilità automatica.
  • Configurazione: il controllo dei parametri di pianificazione appartiene al team che possiede l'istanza Spanner, il che offre al team maggiore libertà di adattare lo strumento di scalabilità automatica alle proprie esigenze rispetto a una topologia centralizzata o distribuita.
  • Demarcazione chiara della responsabilità dell'infrastruttura: la progettazione di una topologia per progetto stabilisce un confine chiaro di responsabilità e sicurezza per l'infrastruttura di Autopilot, perché il proprietario del team delle istanze Spanner è anche il proprietario dell'infrastruttura di Autopilot.

Svantaggi:

  • Maggiore manutenzione complessiva: ogni team è responsabile della configurazione e dell'infrastruttura di Autoscaler, pertanto potrebbe essere difficile assicurarsi che tutti gli strumenti di Autoscaler dell'azienda seguano le stesse linee guida di aggiornamento.
  • Controllo più complesso: poiché ogni team ha un elevato livello di controllo, un controllo centralizzato può diventare più complesso.

Per scoprire come configurare l'autoscalabilità utilizzando una topologia per progetto, consulta la guida passo passo all'implementazione per progetto.

Topologia centralizzata

Come nella topologia per progetto, in un deployment con topologia centralizzata tutti i componenti dello strumento di scalabilità automatica si trovano nello stesso progetto. Tuttavia, le istanze Spanner si trovano in progetti diversi. Questo deployment è adatto a un team che gestisce la configurazione e l'infrastruttura di diverse istanze Spanner da un unico deployment dello strumento di scalabilità automatica in un'unica posizione.

Il seguente diagramma mostra una visione concettuale di alto livello di un deployment di progetto centralizzato:

Implementazione di un progetto centralizzato concettuale.

Il deployment centralizzato mostrato nel diagramma precedente presenta le seguenti caratteristiche:

  • Due applicazioni, Applicazione 1 e Applicazione 2, utilizzano ciascuna le proprie istanze Spanner.
  • Le istanze Spanner (A) si trovano nei rispettivi progetti Application 1 e Application 2.
  • L'autoscalabilità (B) viene eseguita in un progetto separato per controllare l'autoscalabilità delle istanze Spanner sia nei progetti Application 1 sia in quelli Application 2.

Un deployment centralizzato presenta i seguenti vantaggi e svantaggi.

Vantaggi:

  • Infrastruttura e configurazione centralizzate: un unico team controlla i parametri dello scheduler e l'infrastruttura di Autoscaler. Questo approccio può essere utile in settori fortemente regolamentati.
  • Meno manutenzione complessiva: la manutenzione e la configurazione richiedono in genere meno impegno rispetto a un deployment per progetto.
  • Criteri e controllo centralizzati: le best practice per i vari team potrebbero essere più facili da specificare e applicare. I controlli potrebbero essere più facili da eseguire.

Svantaggi:

  • Configurazione centralizzata: qualsiasi modifica ai parametri di Autoscaler deve essere approvata dal team centralizzato, anche se il team che richiede la modifica è proprietario dell'istanza Spanner.
  • Possibile rischio aggiuntivo: il team centralizzato stesso potrebbe diventare un singolo punto di errore anche se l'infrastruttura di Autoscaler è progettata in funzione dell'alta disponibilità.

Per scoprire come configurare l'autoscalabilità utilizzando una topologia centralizzata, consulta la guida passo passo al deployment centralizzato.

Topologia distribuita

In un deployment di topologia distribuita, le istanze Cloud Scheduler e Spanner che devono essere sottoposte a scalabilità automatica si trovano nello stesso progetto. I restanti componenti dello strumento di scalabilità automatica si trovano in un progetto gestito centralmente. Questo deployment è ibrido. I team che possiedono le istanze Spanner gestiscono solo i parametri di configurazione di Autopilot per le loro istanze e un team centrale gestisce l'infrastruttura rimanente di Autopilot.

Il seguente diagramma mostra una visione concettuale di alto livello di un deployment di progetto distribuito.

Deployment concettuale di progetti distribuiti.

Il deployment ibrido rappresentato nel diagramma precedente presenta le seguenti caratteristiche:

  • Due applicazioni, Applicazione 1 e Applicazione 2, utilizzano le proprie istanze Spanner.
  • Le istanze Spanner (A) si trovano sia nel progetto Application 1 sia nel progetto Application 2.
  • In ogni progetto viene eseguito il deployment di un componente Cloud Scheduler indipendente (C): applicazione 1 e applicazione 2.
  • I restanti componenti di Autoscaler (B) vengono di cui vengono eseguiti il deployment in un progetto distinto.
  • Lo strumento Autoscaler esegue il ridimensionamento automatico delle istanze Spanner sia nel progetto Application 1 sia nel progetto Application 2 utilizzando le configurazioni inviate dai componenti Cloud Scheduler indipendenti in ogni progetto.

Funzione di inoltro

Cloud Scheduler può pubblicare messaggi solo negli argomenti dello stesso progetto, pertanto per la topologia distribuita è necessario un componente intermedio chiamato funzione di inoltro.

La funzione Forwarder prende i messaggi pubblicati su Pub/Sub da Cloud Scheduler, controlla la loro sintassi JSON e li inoltra all'argomento Pub/Sub Poller. L'argomento può appartenere a un progetto distinto da Cloud Scheduler.

Il seguente diagramma mostra i componenti utilizzati per il meccanismo di inoltro:

Meccanismo di inoltro.

Come mostrato nel diagramma precedente, le istanze Spanner si trovano nei progetti Application 1 e Application 2:

  1. Cloud Scheduler è lo stesso progetto delle istanze Spanner.

  2. (2a) Cloud Scheduler pubblica i suoi messaggi nell'argomento Forwarder nei progetti Application 1 e Application 2.

    (2b) La funzione Forwarder legge i messaggi dall'argomento Forwarder.

    (2c) La funzione Forwarder inoltra i messaggi allo argomento Polling nel progetto Autoscaler.

  3. La funzione Poller legge i messaggi dall'argomento di polling e il processo continua, come descritto nella sezione Poller.

Un deployment distribuito presenta i seguenti vantaggi e svantaggi.

Vantaggi:

  • I team di applicazioni controllano la configurazione e le pianificazioni: Cloud Scheduler viene implementato insieme alle istanze Spanner che vengono sottoposte a scalabilità automatica, offrendo ai team di applicazioni un maggiore controllo sulla configurazione e sulla pianificazione.
  • Il team operativo controlla l'infrastruttura: i componenti principali dello strumento Autoscaler vengono implementati centralmente, dando ai team operativi il controllo sull'infrastruttura di Autoscaler.
  • Manutenzione centralizzata: l'infrastruttura di Scaler è centralizzata, il che riduce il carico.

Svantaggi:

  • Configurazione più complessa: i team di applicazioni devono fornire account di servizio per scrivere nell'argomento di polling.
  • Possibile rischio aggiuntivo: l'infrastruttura condivisa potrebbe diventare un singolo punto di errore anche se è progettata per garantire un'elevata disponibilità.

Per scoprire come configurare l'autoscalabilità utilizzando una topologia distribuita, consulta la guida dettagliata all'implementazione distribuita.

Passaggi successivi