Panoramica dello strumento di scalabilità automatica

Questa pagina introduce lo strumento Autoscaler per Spanner (Autoscaler), un strumento open source che puoi utilizzare come strumento complementare a Spanner. Questo strumento consente di aumentare o ridurre automaticamente la capacità di calcolo in una o più istanze Spanner in base alla quantità di capacità in uso.

Per ulteriori informazioni sulla scalabilità in Spanner, consulta Spanner con scalabilità automatica. Per informazioni sul deployment dello strumento Autoscaler, consulta quanto segue:

Questa pagina presenta le funzionalità, l'architettura, la configurazione e le topia di deployment del gestore della scalabilità automatica. Gli argomenti che seguono questa serie ti guidano nel deployment di Autoscaler in ciascuna delle diverse topologie.

Gestore della scalabilità automatica

Lo strumento Autoscaler è utile per gestire l'utilizzo e le prestazioni dei deployment di Spanner. Per aiutarti a bilanciare il controllo dei costi con le esigenze di prestazioni, lo strumento di scalabilità automatica monitora le istanze e aggiunge o rimuove automaticamente nodi o unità di elaborazione per garantire che rimangano nei seguenti parametri:

I deployment di Spanner con scalabilità automatica consentono all'infrastruttura di adattarsi e scalare automaticamente per soddisfare i requisiti di carico con poca o nessuna intervento. La scalabilità automatica ottimizza anche le dimensioni dell'infrastruttura di cui è stato eseguito il provisioning, il che può aiutarti a ridurre i costi.

Architettura

Questa sezione descrive in modo più dettagliato i componenti di Autoscaler e i relativi scopi.

L'architettura dello strumento di scalabilità automatica è composta da Cloud Scheduler, due argomenti Pub/Sub, due funzioni Cloud Run e Firestore. L'API Cloud Monitoring viene utilizzata per ottenere le metriche di utilizzo della CPU e dello spazio di archiviazione per le istanze Spanner.

Cloud Scheduler

Con Cloud Scheduler, puoi definire la frequenza con cui lo strumento Autoscaler verifica le soglie delle metriche di scalabilità delle istanze Spanner. Un job Cloud Scheduler può controllare una o più istanze contemporaneamente. Puoi definire tutte le pianificazioni dei job di cui hai bisogno.

Funzione Cloud Run del poller

La funzione Cloud Run del poller si occupa di raccogliere ed elaborare le metriche delle serie temporali per una o più istanze Spanner. Il Polling pre-elabora i dati delle metriche per ogni istanza Spanner in modo che solo i punti dati più pertinenti vengano valutati e inviati alla funzione Scaler Cloud Run. La preelaborazione eseguita dalla funzione Poller Cloud Run semplifica anche il processo di valutazione delle soglie per le istanze Spanner a livello di regione, a due regioni e a più regioni.

Funzione Cloud Run per lo scalare

La funzione Cloud Run Scaler valuta i punti dati ricevuti dalla funzione Cloud Run Poller e determina se è necessario modificare il numero di nodi o unità di elaborazione e, in caso affermativo, di quanto. La funzione Cloud Run confronta i valori delle metriche con la soglia, più o meno un margine consentito, e regola il numero di nodi o unità di elaborazione in base al metodo di scalabilità configurato. Per ulteriori dettagli sui metodi di scalabilità, consulta Funzionalità del gestore della scalabilità automatica.

Flusso operativo

Questa sezione descrive in dettaglio il modello operativo dello strumento Autoscaler, come mostrato nel seguente diagramma di architettura.

Modello operativo di Autoscaler.

  1. Puoi definire la pianificazione, l'ora e la frequenza dei job di scalabilità automatica in Cloud Scheduler.
  2. Nella pianificazione che definisci, Cloud Scheduler invia un messaggio contenente un payload JSON con i parametri di configurazione dello strumento di scalabilità automatica per una o più istanze Spanner nell'argomento Pub/Sub di polling.
  3. Quando il messaggio viene pubblicato nell'argomento di polling, viene creata un'istanza della funzione Cloud Run del Polling per gestirlo.
  4. La funzione Cloud Run del poller legge il payload del messaggio ed esegue query sull'API Cloud Monitoring per recuperare le metriche di utilizzo per ogni istanza Spanner.
  5. Per ogni istanza Spanner enumerata nel messaggio, la funzione Poller invia un messaggio all'argomento Pub/Sub Scaling, contenente le metriche e i parametri di configurazione da valutare per l'istanza Spanner specifica.

  6. Per ogni messaggio inviato nell'argomento Scaler, la funzione Cloud Run di Scaler esegue le seguenti operazioni:

    1. Confronta le metriche delle istanze Spanner con le soglie configurate, più o meno un margine configurabile.

    Puoi configurare il margine autonomamente o utilizzare il valore predefinito. 1. Determina se l'istanza deve essere scalata. 1. Calcola il numero di nodi o unità di elaborazione a cui deve essere eseguita la scalabilità dell'istanza in base al metodo di scalabilità scelto.

  7. La funzione Scaler Cloud Run recupera l'ora dell'ultimo ridimensionamento dell'istanza da Firestore e la confronta con l'ora corrente per determinare se è consentito il ridimensionamento verso l'alto o verso il basso in base ai periodi di attesa.

  8. Se il periodo di attesa configurato è terminato, la funzione Scaler Cloud Run invia una richiesta all'istanza Spanner per eseguire lo scale up o lo scale down.

Durante il flusso, lo strumento Autoscaler scrive un riepilogo dei suoi consigli e delle sue azioni in Cloud Logging per il monitoraggio e il controllo.

Indipendentemente dalla topologia di deployment che scegli, il funzionamento complessivo dello strumento di scalabilità automatica rimane invariato.

Funzionalità del gestore della scalabilità automatica

Questa sezione descrive le funzionalità principali dello strumento Autoscaler.

Gestire più istanze

Lo strumento Autoscaler è in grado di gestire più istanze Spanner in più progetti. Le istanze multiregionali, a doppia regione e regionali hanno tutte diverse soglie di utilizzo che vengono utilizzate durante il ridimensionamento. Ad esempio, i deployment multiregionali e a due regioni vengono scalati in base a un utilizzo della CPU ad alta priorità del 45%, mentre i deployment regionali vengono scalati in base a un utilizzo della CPU ad alta priorità del 65%, entrambi con un margine consentito. Per ulteriori informazioni sulle diverse soglie per la scalabilità, consulta Avvisi per utilizzo elevato della CPU.

Parametri di configurazione indipendenti

Ogni istanza Spanner con scalabilità automatica può avere una o più pianificazioni di polling. Ogni pianificazione del polling ha un proprio insieme di parametri di configurazione.

Questi parametri determinano i seguenti fattori:

  • Il numero minimo e massimo di nodi o unità di elaborazione che controllano quanto può essere piccola o grande l'istanza, aiutandoti a controllare i costi.
  • Il metodo di scalabilità utilizzato per regolare l'istanza Spanner in base al tuo carico di lavoro.
  • I periodi di attesa per consentire a Spanner di gestire le suddivisioni dei dati.

Diversi metodi di scalabilità per carichi di lavoro diversi

Lo strumento Autoscaler fornisce tre diversi metodi di scalabilità per aumentare e diminuire le istanze Spanner: graduale, lineare e diretto. Ogni metodo è progettato per supportare diversi tipi di carichi di lavoro. Puoi applicare uno o più metodi a ogni istanza Spanner sottoposto ad autoscaling quando crei pianificazioni di polling indipendenti.

Gradualmente

La scalabilità graduale è utile per i carichi di lavoro con picchi piccoli o multipli. Provisiona la capacità per appianare tutto con un singolo evento di scalabilità automatica.

Il seguente grafico mostra un pattern di caricamento con più plateau o livelli di carico, dove ogni livello presenta più picchi di piccole dimensioni. Questo pattern è adatto al metodo graduale.

Modello di caricamento con più passaggi.

Quando viene superata la soglia di carico, questo metodo esegue il provisioning e la rimozione di nodi o unità di elaborazione utilizzando un numero fisso, ma configurabile. Ad esempio, vengono aggiunti o rimossi tre nodi per ogni azione di ridimensionamento. Modificando la configurazione, puoi consentire l'aggiunta o la rimozione di incrementi di capacità più elevati in qualsiasi momento.

Lineare

La scalabilità lineare è ideale per i pattern di carico che cambiano in modo più graduale o che hanno alcuni picchi elevati. Il metodo calcola il numero minimo di nodi o unità di elaborazione necessarie per mantenere l'utilizzo al di sotto della soglia di scalabilità. Il numero di nodi o unità di elaborazione aggiunti o rimossi in ogni evento di scalabilità non è limitato a un valore di incremento fisso.

Il pattern di caricamento di esempio nel grafico seguente mostra aumenti e diminuzioni improvvisi più elevati del carico. Queste fluttuazioni non sono raggruppate in passaggi distinguibili come nel grafico precedente. Questo modello è più facile da gestire utilizzando la scala lineare.

Carica il pattern con fluttuazioni.

Lo strumento Autoscaler utilizza il rapporto tra l'utilizzo osservato e la soglia di utilizzo per calcolare se aggiungere o sottrarre nodi o unità di elaborazione dal numero totale corrente.

La formula per calcolare il nuovo numero di nodi o unità di elaborazione è la seguente:

newSize = currentSize * currentUtilization / utilizationThreshold

Diretto

La scalabilità diretta consente un aumento immediato della capacità. Questo metodo è pensato per supportare i carichi di lavoro batch in cui è richiesto periodicamente un numero di nodi più elevato predeterminato in base a una pianificazione con un'ora di inizio nota. Questo metodo scala l'istanza fino al numero massimo di nodi o unità di elaborazione specificato nella pianificazione ed è progettato per essere utilizzato insieme a un metodo lineare o graduale.

Il seguente grafico mostra l'elevato aumento pianificato del carico, per il quale il gestore della scalabilità automatica ha preprovisionato la capacità per l'utilizzo del metodo diretto.

Modello di caricamento con scalabilità diretta pre-provisionata.

Una volta completato il carico di lavoro batch e l'utilizzo è tornato ai livelli normali, a seconda della configurazione, viene applicato il ridimensionamento lineare o graduale per ridurre automaticamente l'istanza.

Metodi di deployment

Lo strumento Autoscaler può essere implementato in un singolo progetto o insieme alle istanze Spanner che gestisce. Lo strumento di ridimensionamento automatico è progettato per consentire flessibilità e può adattarsi alla separazione esistente delle responsabilità tra i team di operazioni e di applicazione. 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.

I diversi modelli di implementazione sono descritti più nel dettaglio in Topologie di implementazione.

Serverless per facilitare il deployment e la gestione

Lo strumento Autoscaler viene creato utilizzando solo strumenti Google Cloud serverless e a bassa gestione, 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 integrati di Google Cloud , lo strumento di scalabilità automatica può sfruttare appieno IAM (Identity Access Management) per l'autenticazione e l'autorizzazione.

Configurazione

Lo strumento di gestione della scalabilità automatica offre diverse opzioni di configurazione che puoi utilizzare per gestire la scalabilità dei deployment di Spanner. Le sezioni seguenti descriveranno le opzioni di configurazione di base e quelle più avanzate.

Configurazione di base

Lo strumento di gestione della scalabilità automatica 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": "spanner1",
        "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
        "units": "NODES", "minSize": 1, "maxSize": 3
     },
     {
        "projectId":
        "different-project", "instanceId": "another-spanner1", "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.

Configurazione avanzata

Lo strumento di scalabilità automatica offre opzioni di configurazione avanzate che ti consentono di controllare con maggiore precisione quando e come vengono gestite le istanze Spanner. Le sezioni seguenti illustrano una selezione di questi controlli.

Soglie personalizzate

Lo strumento di scalabilità automatica determina il numero di nodi o unità di elaborazione da aggiungere o sottrarre a un'istanza utilizzando le soglie di Spanner consigliate per le seguenti metriche di carico:

  • CPU ad alta priorità
  • CPU media mobile su 24 ore
  • Utilizzo archiviazione

Ti consigliamo di utilizzare le soglie predefinite descritte in Creare avvisi per le metriche di Spanner. Tuttavia, in alcuni casi potresti voler modificare le soglie utilizzate dall'elaboratore automatico. Ad esempio, puoi utilizzare soglie più basse per fare in modo che lo strumento Autoscaler reagisca più rapidamente rispetto alle soglie più alte. Questa modifica contribuisce a evitare l'attivazione degli avvisi a soglie più elevate.

Metriche personalizzate

Sebbene le metriche predefinite nello strumento Autoscaler affrontino la maggior parte degli scenari di rendimento e scalabilità, in alcuni casi potrebbe essere necessario specificare le tue metriche utilizzate per determinare quando eseguire fare lo scale in e lo scale down. Per questi scenari, definisci le metriche personalizzate nella configurazione utilizzando la proprietà metrics.

Margini

Un margine definisce un limite superiore e uno inferiore rispetto alla soglia. Lo strumento Autoscaler attiva un evento di scalabilità automatica solo se il valore della metrica è superiore al limite superiore o inferiore al limite inferiore.

Lo scopo di questo parametro è evitare l'attivazione di eventi di scalabilità automatica per piccole fluttuazioni del carico di lavoro intorno alla soglia, riducendo la quantità di fluttuazione nelle azioni del gestore della scalabilità automatica. La soglia e il margine insieme definiscono il seguente intervallo, in base al valore che vuoi assegnare alla metrica: 

[threshold - margin, threshold + margin]
. Maggiore è il margine, più ristretto è l'intervallo, con una maggiore probabilità di attivazione di un evento di scalabilità automatica.

La specifica di un parametro di margine per una metrica è facoltativa e il valore predefinito è di cinque punti percentuali prima e sotto il parametro.

Topologie di deployment

Per eseguire il deployment dello strumento Autoscaler, decidi quale delle seguenti topologie è la migliore per soddisfare le tue esigenze tecniche e operative:

  • Topologia per progetto: l'infrastruttura di Autoscaler viene dispiattata nello stesso progetto di Spanner che deve essere sottoposto a scalabilità automatica.
  • Topologia centralizzata: lo strumento Autoscaler viene implementato in un progetto e gestisce una o più istanze Spanner in progetti diversi.
  • Topologia distribuita: la maggior parte dell'infrastruttura di Autoscaler viene dispiattata in un progetto, ma alcuni componenti dell'infrastruttura vengono dispiattati con le istanze Spanner sottoposte a scalabilità automatica in progetti diversi.

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.

Per un diagramma più dettagliato di un deployment per progetto, consulta la sezione Architettura.

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 Autoscaler utilizzando una topologia per progetto, consulta Eseguire il deployment di uno strumento Autoscaler per progetto o centralizzato per Spanner.

Topologia centralizzata

Come nella topologia per progetto, in un deployment di topologia centralizzata tutti i componenti dello strumento Autoscaler 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.

Per un diagramma più dettagliato di un deployment di progetto centralizzato, consulta Eseguire il deployment di uno strumento di gestione della scalabilità automatica per progetto o centralizzato per Spanner.

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 un tutorial passo passo sulla configurazione dello strumento Autoscaler utilizzando questa opzione, consulta Eseguire il deployment di uno strumento Autoscaler per progetto o centralizzato per Spanner.

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 Autoscaler 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.

Per un diagramma più dettagliato del deployment del progetto centralizzato, consulta Eseguire il deployment di uno strumento di gestione della scalabilità automatica distribuita per Spanner.

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 lo strumento Autoscaler in un deployment distribuito, consulta Eseguire il deployment di uno strumento Autoscaler distribuito per Spanner.

Suddivisioni dei dati

Spanner assegna intervalli di dati chiamati split a nodi o suddivisioni di un nodo chiamate unità di elaborazione. Il nodo o le unità di elaborazione gestiscono e pubblicano in modo indipendente i dati nelle suddivisioni ripartite. Le suddivisioni dei dati vengono create in base a diversi fattori, tra cui il volume di dati e i pattern di accesso. Per maggiori dettagli, consulta Spanner - schema e modello dei dati.

I dati sono organizzati in suddivisioni e Spanner gestisce automaticamente le suddivisioni. Pertanto, quando lo strumento Autoscaler aggiunge o rimuove nodi o unità di elaborazione, deve concedere al backend di Spanner tempo sufficiente per riassegnare e riorganizzare le suddivisioni man mano che viene aggiunta o rimossa nuova capacità dalle istanze.

Lo strumento Autoscaler utilizza periodi di attesa sia per gli eventi di scale up che per quelli di scale down per controllare la velocità con cui può aggiungere o rimuovere nodi o unità di elaborazione da un'istanza. Questo metodo consente all'istanza il tempo necessario per riorganizzare le relazioni tra note di calcolo o unità di elaborazione e le suddivisioni dei dati. Per impostazione predefinita, i periodi di attesa per l'aumento e la riduzione della scala sono impostati sui seguenti valori minimi:

  • Valore di scalabilità: 5 minuti
  • Valore di riduzione: 30 minuti

Per ulteriori informazioni sui suggerimenti per la scalabilità e sui periodi di attesa, consulta Scalare le istanze Spanner.

Costi

Il consumo di risorse dello strumento Autoscaler è minimo, quindi per la maggior parte dei casi d'uso i costi sono trascurabili. L'utilizzo di Autoscaler su Google Cloudnon comporta costi. Ad esempio, è disponibile senza costi aggiuntivi l'esecuzione di uno strumento di scalabilità automatica per gestire 3 istanze Spanner con un intervallo di polling di 5 minuti per ogni istanza. Questa stima include quanto segue:

  • 3 job Cloud Scheduler
  • 0,15 GB di messaggi Pub/Sub
  • 51840 chiamate di funzioni Cloud Run di 500 ms
  • Meno di 10 MB di dati in Firestore

La stima non include i costi delle operazioni del database Spanner. Utilizza il Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.

Passaggi successivi