Panoramica dello strumento del gestore della scalabilità automatica

Questa pagina presenta lo strumento del gestore della scalabilità automatica per Spanner, uno 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 di Spanner in base alla quantità di capacità in uso.

Per saperne di più sulla scalabilità in Spanner, consulta Scalabilità automatica di Spanner. Per informazioni sul deployment dello strumento del gestore della scalabilità automatica, consulta quanto segue:

Questa pagina presenta le funzionalità, l'architettura, la configurazione e le topologie di deployment del gestore della scalabilità automatica. Gli argomenti che continuano in questa serie illustrano il deployment del gestore della scalabilità automatica in ciascuna delle diverse topologie.

Gestore della scalabilità automatica

Lo strumento del gestore della scalabilità automatica è 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 del gestore della scalabilità automatica monitora le istanze e aggiunge o rimuove automaticamente nodi o unità di elaborazione per garantire che rimangano entro i seguenti parametri:

La scalabilità automatica dei deployment di Spanner consente all'infrastruttura di adattarsi e scalare automaticamente per soddisfare i requisiti di carico con un intervento minimo o nullo. La scalabilità automatica definisce le dimensioni giuste dell'infrastruttura di cui hai eseguito il provisioning, il che può aiutarti a ridurre i costi.

Architettura

In questa sezione vengono descritti in maggiore dettaglio i componenti del gestore della scalabilità automatica e le rispettive finalità.

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

Cloud Scheduler

Con Cloud Scheduler, puoi definire la frequenza con cui lo strumento del gestore della scalabilità automatica 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 che vuoi.

Funzione Cloud Functions Functions Poller

La funzione Poller Cloud Functions è responsabile della raccolta e dell'elaborazione delle metriche delle serie temporali per una o più istanze Spanner. Il sondaggio pre-elabora i dati delle metriche per ogni istanza di Spanner in modo che solo i punti dati più rilevanti vengano valutati e inviati alla funzione Cloud Functions Scaler. La pre-elaborazione eseguita dalla funzione Cloud Functions Poller semplifica anche il processo di valutazione delle soglie per le istanze Spanner a livello di una o più regioni.

Funzione Cloud Functions Functions Scaler

La funzione Cloud Functions Scaler valuta i punti dati ricevuti dalla funzione Cloud Functions Poller e determina se è necessario regolare il numero di nodi o unità di elaborazione e, in tal caso, di quanto. La funzione Cloud Functions confronta i valori della metrica 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 del gestore della scalabilità automatica, come mostrato nel seguente diagramma dell'architettura.

modello operativo del gestore della scalabilità automatica.

  1. Sei tu a definire la pianificazione, l'orario e la frequenza dei job di scalabilità automatica in Cloud Scheduler.
  2. In base alla pianificazione definita, Cloud Scheduler esegue il push di un messaggio contenente un payload JSON con i parametri di configurazione dello strumento della scalabilità automatica per una o più istanze Spanner nell'argomento Polling Pub/Sub.
  3. Quando il messaggio viene pubblicato nell'argomento Polling, viene creata un'istanza della funzione Cloud Functions Polling per gestire il messaggio.
  4. La funzione Poller Cloud Functions legge il payload del messaggio ed esegue una query sull'API Cloud Monitoring per recuperare le metriche di utilizzo per ogni istanza Spanner.
  5. Per ogni istanza di Spanner enumerata nel messaggio, la funzione poller esegue il push di un messaggio nell'argomento Pub/Sub per la scalabilità, contenente le metriche e i parametri di configurazione da valutare per la specifica istanza di Spanner.

  6. Per ogni messaggio di cui è stato eseguito il push nell'argomento Scaler, la Cloud Function Scaler esegue quanto segue:

    1. Confronta le metriche dell'istanza Spanner con le soglie configurate, più o meno un margine configurabile.

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

  7. La funzione Cloud Functions Scaler recupera quando è stata eseguita l'ultima scalabilità dell'istanza da Firestore e la confronta con il momento attuale, per determinare se lo scale up o lo scale down è consentito in base ai periodi di attesa.

  8. Se è trascorso il periodo di attesa configurato, la Cloud Function Scaler invia una richiesta all'istanza Spanner di scale up o scale down.

Durante il flusso, lo strumento del gestore della scalabilità automatica scrive un riepilogo dei suggerimenti e delle azioni in Cloud Logging a scopo di monitoraggio e controllo.

Indipendentemente dalla topologia di deployment scelta, il funzionamento complessivo dello strumento del gestore della scalabilità automatica rimane invariato.

Funzionalità del gestore della scalabilità automatica

In questa sezione vengono descritte le funzionalità principali dello strumento Gestore della scalabilità automatica.

Gestisci più istanze

Il gestore della scalabilità automatica è in grado di gestire più istanze Spanner su più progetti. Le istanze multiregionali e regionali hanno soglie di utilizzo diverse utilizzate per la scalabilità. Ad esempio, i deployment multiregionali vengono scalati con un utilizzo della CPU ad alta priorità del 45%, mentre i deployment a livello di regione vengono scalati al 65% di utilizzo della CPU ad alta priorità, più o meno un margine consentito. Per saperne di più sulle diverse soglie di 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 di polling ha il proprio set 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, in modo da tenere sotto controllo i costi.
  • Il metodo di scalabilità utilizzato per regolare l'istanza Spanner in modo specifico per il 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 Gestore della scalabilità automatica offre tre diversi metodi di scalabilità per l'aumento e la riduzione della scalabilità delle istanze Spanner: a livello, lineare e diretto. Ogni metodo è progettato per supportare diversi tipi di carichi di lavoro. Puoi applicare uno o più metodi a ogni istanza Spanner con scalabilità automatica quando crei pianificazioni di polling indipendenti.

Passo a passo

La scalabilità graduale è utile per i carichi di lavoro con picchi piccoli o multipli. Esegue il provisioning della capacità per renderle più fluide con un singolo evento di scalabilità automatica.

Il seguente grafico mostra un modello di carico con più piani di carico o passaggi, in cui ogni passaggio presenta più piccoli picchi. Questo pattern è adatto per il metodo a gradini.

Carica il pattern con più passaggi.

Quando la soglia di carico viene superata, questo metodo esegue il provisioning e rimuove nodi o unità di elaborazione utilizzando un numero fisso ma configurabile. Ad esempio, vengono aggiunti o rimossi tre nodi per ogni azione di scalabilità. Modificando la configurazione, puoi aggiungere o rimuovere incrementi di capacità maggiori in qualsiasi momento.

Lineare

La scalabilità lineare è ideale per l'uso con modelli di carico che cambiano in modo più graduale o hanno alcuni picchi significativi. Il metodo calcola il numero minimo di nodi o unità di elaborazione necessari per mantenere l'utilizzo al di sotto della soglia di scalabilità. Il numero di nodi o di unità di elaborazione aggiunti o rimossi in ogni evento di scalabilità non è limitato a un numero di passaggi fisso.

Il pattern di caricamento di esempio nel grafico seguente mostra aumenti e diminuzioni improvvise maggiori del carico. Queste fluttuazioni non sono raggruppate in passaggi distinguibili come nel grafico precedente. Questo pattern è gestito più facilmente con la scalabilità lineare.

Pattern di caricamento con fluttuazioni.

Lo strumento della scalabilità automatica usa il rapporto tra l'utilizzo osservato rispetto alla soglia di utilizzo per calcolare se aggiungere o sottrarre nodi o unità di elaborazione dal numero totale attuale.

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

newSize = currentSize * currentUtilization / utilizationThreshold

Diretta

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

Il seguente grafico mostra l'ampio aumento pianificato del carico, per cui il gestore della scalabilità automatica ha eseguito il pre-provisioning della capacità per l'utilizzo del metodo diretto.

Pattern di caricamento con scalabilità diretta pre-provisioning.

Dopo che il carico di lavoro batch è stato completato e l'utilizzo torna a livelli normali, a seconda della configurazione, viene applicata la scalabilità lineare o graduale per fare automaticamente la scalabilità dell'istanza.

Metodi di deployment

Il deployment dello strumento del gestore della scalabilità automatica può essere eseguito in un singolo progetto o insieme alle istanze Spanner che gestisce. Lo strumento del gestore della scalabilità automatica è progettato per offrire flessibilità e soddisfare la separazione delle responsabilità esistenti tra i team operativi e quelli delle applicazioni. La responsabilità di configurare la scalabilità automatica delle istanze Spanner può essere centralizzata con un singolo team operativo oppure può essere distribuita ai team più vicini alle applicazioni gestite da queste istanze Spanner.

I diversi modelli di deployment sono discussi in modo più dettagliato in Topologie di deployment.

Serverless per deployment e gestione semplici

Il gestore della scalabilità automatica è stato creato utilizzando solo strumenti Google Cloud serverless e a bassa gestione, come Cloud Functions, Pub/Sub, Cloud Scheduler e Firestore. Questo approccio riduce al minimo i costi e l'overhead operativo dell'esecuzione dello strumento del gestore della scalabilità automatica.

Utilizzando gli strumenti integrati di Google Cloud, lo strumento del gestore della scalabilità automatica può sfruttare appieno IAM (IAM) per l'autenticazione e l'autorizzazione.

Configurazione

Lo strumento del gestore della scalabilità automatica offre diverse opzioni di configurazione che puoi utilizzare per gestire la scalabilità dei deployment Spanner. Le sezioni successive descrivono le opzioni di configurazione di base e più avanzate.

Configurazione di base

Lo strumento Gestore della scalabilità automatica gestisce le istanze Spanner tramite la configurazione definita in Cloud Scheduler. Se più istanze Spanner devono essere sottoposte a polling con lo stesso intervallo, ti consigliamo di configurarle nello stesso job Cloud Scheduler. La configurazione di ogni istanza è rappresentata come un 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 del gestore della scalabilità automatica con il metodo lineare per le normali operazioni, ma anche un'altra configurazione del gestore della scalabilità automatica con il metodo diretto per i carichi di lavoro batch pianificati.

Durante l'esecuzione del job Cloud Scheduler, viene inviato un messaggio Pub/Sub all'argomento Polling Pub/Sub. 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 poller README.

Configurazione avanzata

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

Soglie personalizzate

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

  • CPU ad alta priorità
  • Media mobile di 24 ore della CPU
  • Utilizzo archiviazione

Ti consigliamo di utilizzare le soglie predefinite come descritto in Creazione di avvisi per le metriche Spanner. Tuttavia, in alcuni casi potresti voler modificare le soglie utilizzate dallo strumento del gestore della scalabilità automatica. Ad esempio, potresti utilizzare soglie più basse per far reagire lo strumento del gestore della scalabilità automatica più rapidamente rispetto a soglie più alte. Questa modifica consente di impedire l'attivazione di avvisi a soglie più elevate.

Metriche personalizzate

Sebbene le metriche predefinite nello strumento del gestore della scalabilità automatica tengano conto della maggior parte degli scenari di prestazioni e scalabilità, in alcuni casi potrebbe essere necessario specificare le tue metriche personalizzate per determinare quando fare lo scale in e lo scale out. In questi scenari, puoi definire metriche personalizzate nella configurazione utilizzando la proprietà metrics.

Margini

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

L'obiettivo di questo parametro è evitare che vengano attivati eventi di scalabilità automatica per piccole fluttuazioni dei carichi di lavoro intorno alla soglia, riducendo la quantità di fluttuazione delle azioni del gestore della scalabilità automatica. La soglia e il margine definiscono insieme il seguente intervallo, in base al valore che vuoi assegnare alla metrica: 

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

L'indicazione di un parametro di margine per una metrica è facoltativa e il valore predefinito è cinque punti percentuali sia prima che sotto il parametro.

Topologie di deployment

Per eseguire il deployment dello strumento del gestore della scalabilità automatica, decidi quale delle seguenti topologie è quella più adatta alle tue esigenze tecniche e operative:

  • Topologia per progetto: il deployment dell'infrastruttura del gestore della scalabilità automatica viene eseguito nello stesso progetto di Spanner per il quale è necessario scalare automaticamente.
  • Topologia centralizzata: il deployment dello strumento del gestore della scalabilità automatica viene eseguito in un progetto e gestisce una o più istanze Spanner in progetti diversi.
  • Topologia distribuita: il deployment della maggior parte dell'infrastruttura del gestore della scalabilità automatica viene eseguito in un singolo progetto, mentre il deployment di alcuni componenti dell'infrastruttura viene eseguito con la scalabilità automatica delle istanze di Spanner in progetti diversi.

Topologia per progetto

In un deployment della topologia per progetto, ogni progetto con un'istanza Spanner che deve essere scalata automaticamente dispone anche del proprio deployment indipendente dei componenti del gestore della scalabilità automatica. Consigliamo questa topologia ai team indipendenti che vogliono gestire la propria infrastruttura e la configurazione del gestore della scalabilità automatica. È anche un buon punto di partenza per testare le funzionalità dello strumento del gestore della scalabilità automatica.

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

Deployment concettuale per progetto.

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

  • Due applicazioni, Applicazione 1 e Applicazione 2, utilizzano ciascuna le proprie istanze di Spanner.
  • Le istanze Spanner (A) risiedono nei rispettivi progetti dell'Applicazione 1 e dell'Applicazione 2.
  • In ogni progetto viene eseguito il deployment di un gestore della scalabilità automatica (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 vantaggi e gli svantaggi seguenti.

Vantaggi:

  • Design più semplice: la topologia per progetto è la progettazione più semplice delle tre topologie, poiché il deployment di tutti i componenti del gestore della scalabilità automatica viene eseguito insieme alle istanze Spanner di cui viene scalata automaticamente.
  • Configurazione: il controllo sui parametri dello scheduler appartiene al team proprietario dell'istanza Spanner, che offre al team maggiore libertà di adattare lo strumento del gestore della scalabilità automatica alle sue esigenze rispetto a una topologia centralizzata o distribuita.
  • Confine chiaro di responsabilità dell'infrastruttura: la progettazione di una topologia per progetto stabilisce un chiaro confine di responsabilità e sicurezza sull'infrastruttura del gestore della scalabilità automatica, in quanto il proprietario del team delle istanze Spanner è anche il proprietario dell'infrastruttura del gestore della scalabilità automatica.

Svantaggi:

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

Per scoprire come configurare il gestore della scalabilità automatica utilizzando una topologia per progetto, consulta Eseguire il deployment di uno strumento di scalabilità automatica per progetto o centralizzato per Spanner.

Topologia centralizzata

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

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

Deployment concettuale dei progetti centralizzato.

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

  • Due applicazioni, Applicazione 1 e Applicazione 2, utilizzano ciascuna le proprie istanze di Spanner.
  • Le istanze Spanner (A) si trovano nei rispettivi progetti dell'Applicazione 1 e dell'Applicazione 2.
  • Viene eseguito il deployment del gestore della scalabilità automatica (B) in un progetto separato per controllare la scalabilità automatica delle istanze Spanner nei progetti dell'Applicazione 1 e dell'Applicazione 2.

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

Un deployment centralizzato presenta i vantaggi e gli svantaggi riportati di seguito.

Vantaggi:

  • Configurazione e infrastruttura centralizzate: un unico team controlla i parametri dello scheduler e l'infrastruttura del gestore della scalabilità automatica. Questo approccio può essere utile nei settori più regolamentati,
  • Minore manutenzione complessiva: la manutenzione e la configurazione richiedono in genere un minore sforzo da gestire rispetto a un deployment per progetto.
  • Criteri e audit centralizzati: le best practice per i vari team potrebbero essere più semplici da specificare e mettere in atto. Potrebbe essere più facile eseguire i controlli.

Svantaggi:

  • Configurazione centralizzata: qualsiasi modifica ai parametri del gestore della scalabilità automatica deve essere attribuita al team centralizzato, anche se il team che richiede la modifica è il proprietario dell'istanza Spanner.
  • Potenziale rischio aggiuntivo: il team centralizzato potrebbe diventare un single point of failure, anche se l'infrastruttura del gestore della scalabilità automatica è progettata pensando all'alta disponibilità.

Per un tutorial dettagliato sulla configurazione dello strumento del gestore della scalabilità automatica utilizzando questa opzione, consulta Eseguire il deployment di uno strumento del gestore della scalabilità automatica centralizzato per progetto o per Spanner.

Topologia distribuita

In un deployment di topologia distribuita, le istanze Cloud Scheduler e di Spanner per cui è richiesta la scalabilità automatica risiedono nello stesso progetto. I restanti componenti dello strumento del gestore della scalabilità automatica risiedono in un progetto gestito centralmente. Questo deployment è ibrido. I team che possiedono le istanze Spanner gestiscono solo i parametri di configurazione del gestore della scalabilità automatica per le proprie istanze, mentre un team centrale gestisce l'infrastruttura del gestore della scalabilità automatica rimanente.

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

Deployment concettuale di progetti distribuiti.

Il deployment ibrido illustrato nel diagramma precedente ha le seguenti caratteristiche:

  • Due applicazioni, Applicazione 1 e Applicazione 2, utilizzano le proprie istanze di Spanner.
  • Le istanze Spanner (A) si trovano nei progetti dell'Applicazione 1 e dell'Applicazione 2.
  • Viene eseguito il deployment di un componente (C) indipendente di Cloud Scheduler in ciascun progetto: Applicazione 1 e Applicazione 2.
  • Il deployment dei restanti componenti del gestore della scalabilità automatica (B) viene eseguito in un progetto separato.
  • Lo strumento Gestore della scalabilità automatica scala automaticamente le istanze Spanner nei progetti dell'Applicazione 1 e dell'Applicazione 2 utilizzando le configurazioni inviate dai componenti indipendenti di Cloud Scheduler in ogni progetto.

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

Un deployment distribuito presenta i vantaggi e gli svantaggi seguenti.

Vantaggi:

  • I team delle applicazioni controllano la configurazione e le pianificazioni: il deployment di Cloud Scheduler viene eseguito insieme alle istanze Spanner in fase di scalabilità automatica, offrendo ai team delle applicazioni un maggiore controllo sulla configurazione e sulla pianificazione.
  • Il team operativo controlla l'infrastruttura: i componenti principali dello strumento del gestore della scalabilità automatica vengono distribuiti centralmente, dando ai team operativi il controllo dell'infrastruttura del gestore della scalabilità automatica.
  • Manutenzione centralizzata: l'infrastruttura di scalabilità automatica è centralizzata, riducendo i costi generali.

Svantaggi:

  • Configurazione più complessa: i team delle applicazioni devono fornire account di servizio per scrivere nell'argomento di polling.
  • Potenziale rischio aggiuntivo: l'infrastruttura condivisa potrebbe diventare un single point of failure anche se è stata progettata per l'alta disponibilità.

Per scoprire come configurare lo strumento del gestore della scalabilità automatica in un deployment distribuito, consulta Eseguire il deployment di uno strumento del gestore della scalabilità automatica distribuito per Spanner.

Suddivisione dei dati

Spanner assegna intervalli di dati denominati segmenti ai nodi o alle suddivisioni di un nodo chiamato unità di elaborazione. Il nodo o le unità di elaborazione gestiscono e pubblicano in modo indipendente i dati nelle suddivisioni distribuite. Le suddivisioni dei dati vengono create in base a diversi fattori, tra cui il volume dei dati e i pattern di accesso. Per ulteriori dettagli, consulta Spanner - Schema e modello dei dati.

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

Lo strumento Gestore della scalabilità automatica 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 concede all'istanza il tempo necessario per riorganizzare le relazioni tra note di computing o unità di elaborazione e suddivisioni dei dati. Per impostazione predefinita, i periodi di attesa per lo scale up e lo scale down sono impostati sui seguenti valori minimi:

  • Valore di scale up: 5 minuti
  • Valore di scale down: 30 minuti

Per saperne di più sui suggerimenti sulla scalabilità e sui periodi di attesa, consulta Scalabilità delle istanze Spanner.

Costi

Il consumo di risorse dello strumento della scalabilità automatica è minimo, quindi nella maggior parte dei casi d'uso i costi sono trascurabili. Non è previsto alcun costo quando viene utilizzato il gestore della scalabilità automatica su Google Cloud. Ad esempio, è disponibile senza costi l'esecuzione di uno strumento del gestore della scalabilità automatica per gestire tre 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 500 ms di Cloud Function
  • 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