Panoramica dello strumento del gestore della scalabilità automatica

Questa pagina introduce lo strumento del gestore della scalabilità automatica per Spanner (scalatore automatico), 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 proseguono questa serie ti guidano nel 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 alla tua infrastruttura di adattarsi e scalare automaticamente per soddisfare i requisiti di carico con un intervento minimo o nullo. Anche la scalabilità automatica ridimensiona correttamente l'infrastruttura di cui è stato eseguito il provisioning,

Architettura

Questa sezione descrive in maggiore dettaglio i componenti del gestore della scalabilità automatica e i rispettivi scopi.

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

Utilizzando 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 ti servono.

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 Spanner in modo che solo i punti dati più pertinenti vengano valutati e inviati alla funzione Cloud Functions di Scaler. La pre-elaborazione eseguita dalla funzione Cloud Functions di Poller semplifica inoltre il processo di valutazione delle soglie per le istanze di Spanner a livello di regione, di due regioni e di più regioni.

Funzione Cloud Functions Functions dello scaler

La funzione Cloud Functions di scaler valuta i punti dati ricevuti dalla funzione Cloud Functions di polling 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'ora 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 di Poller per gestire il messaggio.
  4. La funzione Poller Cloud Functions legge il payload dei messaggi ed esegue una 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 esegue il push di un messaggio nell'argomento Pub/Sub Scalabilità, contenente le metriche e i parametri di configurazione da valutare per l'istanza Spanner specifica.

  6. Per ogni messaggio inviato tramite push nell'argomento Scaler, la Cloud Function Scaler esegue le operazioni seguenti:

    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 in base al quale deve essere scalata l'istanza in base al metodo di scalabilità scelto.

  7. La funzione Cloud Functions dello scaler recupera l'ora dell'ultima scalabilità dell'istanza da Firestore e la confronta con l'ora attuale per determinare se è consentito lo scale up o lo scale down in base ai periodi di attesa.

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

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

Indipendentemente dalla topologia di deployment che scegli, il funzionamento complessivo dello strumento del gestore della scalabilità automatica rimane le stesse.

Funzionalità del gestore della scalabilità automatica

Questa sezione descrive le funzionalità principali dello strumento del gestore della scalabilità automatica.

Gestisci più istanze

Lo strumento del gestore della scalabilità automatica è in grado di gestire più istanze Spanner su più progetti. Le istanze multiregionali, a due regioni e a livello di regione hanno tutte soglie di utilizzo diverse che vengono utilizzate per la scalabilità. Ad esempio, i deployment multiregionali e a due regioni vengono scalati al 45% di utilizzo della CPU ad alta priorità, mentre i deployment a livello regionale vengono scalati al 65% di utilizzo della CPU ad alta priorità, più o meno un margine consentito. Per maggiori informazioni sulle diverse soglie di scalabilità, consulta Avvisi per l'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 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 le dimensioni dell'istanza, contribuendo a controllare i costi.
  • Il metodo di scalabilità utilizzato per regolare l'istanza Spanner in base al carico di lavoro.
  • I periodi di attesa per consentire a Spanner di gestire le suddivisioni dei dati.

Diversi metodi di scalabilità per diversi carichi di lavoro

Lo strumento del gestore della scalabilità automatica offre tre diversi metodi di scalabilità per lo scale up e lo scale down delle 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 di cui viene scalata automaticamente la scalabilità automatica quando crei pianificazioni di polling indipendenti.

A passo

La scalabilità graduale è utile per carichi di lavoro con picchi ridotti o multipli. Fornisce la capacità per agevolarle tutte 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 ha più picchi di piccole dimensioni. Questo pattern è particolarmente adatto per il metodo stepwise.

Carica la sequenza con più passaggi.

Quando la soglia di carico viene superata, questo metodo esegue il provisioning e rimuove i nodi o le 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 consentire l'aggiunta o la rimozione di incrementi di capacità maggiori in qualsiasi momento.

Lineare

La scalabilità lineare è particolarmente adatta a pattern di carico che cambiano in modo più graduale o presentano alcuni picchi elevati. 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 unità di elaborazione aggiunti o rimossi in ogni evento di scalabilità non è limitato a una quantità di passaggi fissa.

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

Pattern di caricamento con fluttuazioni.

Lo strumento del gestore della scalabilità automatica utilizza il rapporto dell'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 fornisce un aumento immediato della capacità. Questo metodo è destinato a supportare carichi di lavoro batch in cui è richiesto periodicamente un numero di nodi più alto predeterminato in una pianificazione con un'ora di inizio nota. Questo metodo scala l'istanza fino al numero massimo di nodi o unità di elaborazione specificati nella pianificazione ed è destinato a essere utilizzato in aggiunta a un metodo lineare o graduale.

Il grafico seguente illustra il grande 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.

Una volta completato il carico di lavoro batch e l'utilizzo torna ai livelli normali, a seconda della configurazione, viene applicata la scalabilità lineare o graduale per ridurre automaticamente l'istanza.

Metodi di deployment

Lo strumento del gestore della scalabilità automatica può essere implementato in un singolo progetto o insieme alle istanze Spanner che gestisce. Lo strumento del gestore della scalabilità automatica è progettato per garantire flessibilità e può soddisfare la separazione esistente delle responsabilità 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 distribuita ai team più vicini alle applicazioni gestite da queste istanze Spanner.

I diversi modelli di deployment sono descritti in modo più dettagliato nella sezione Topologie di deployment.

Serverless per facilità di deployment e gestione

Lo strumento della scalabilità automatica è 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 associato all'esecuzione dello strumento del gestore della scalabilità automatica.

Grazie agli 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 di Spanner. Le sezioni successive descrivono le opzioni di configurazione di base e le opzioni di configurazione più avanzate.

Configurazione di base

Lo strumento del gestore 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 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 operazioni normali, ma anche un'altra configurazione del gestore della scalabilità automatica con il metodo diretto per i carichi di lavoro batch pianificati.

Quando viene eseguito, il job Cloud Scheduler 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 Poller README.

Configurazione avanzata

Lo strumento del gestore della scalabilità automatica offre opzioni di configurazione avanzate che consentono di controllare in modo più preciso quando e come vengono gestite le istanze Spanner. Le sezioni seguenti 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 di Spanner consigliate per le seguenti metriche di carico:

  • CPU ad alta priorità
  • Media mobile di 24 ore
  • 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 sì che lo strumento del gestore della scalabilità automatica reagisca più rapidamente rispetto a soglie più alte. Questa modifica contribuisce a impedire l'attivazione di avvisi a soglie più alte.

Metriche personalizzate

Sebbene le metriche predefinite dello strumento del gestore della scalabilità automatica rispondano alla maggior parte degli scenari di prestazioni e scalabilità, in alcuni casi potrebbe essere necessario specificare le proprie metriche utilizzate per determinare quando fare lo scale in e lo scale out. Per questi scenari, definisci le metriche personalizzate nella configurazione utilizzando la proprietà metrics.

Margini

Un margine definisce un limite massimo 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 del carico di lavoro intorno alla soglia, riducendo la quantità di fluttuazione nelle azioni del gestore della scalabilità automatica. La soglia e il margine definiscono insieme il seguente intervallo, in base al valore che vuoi della 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.

Specificare un parametro di margine per una metrica è facoltativo e il valore predefinito è di cinque punti percentuali prima e sotto il parametro.

Topologie di deployment

Per eseguire il deployment dello strumento del gestore della scalabilità automatica, decidi quale delle seguenti topologie è 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, il quale deve essere scalato automaticamente.
  • Topologia centralizzata: lo 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 progetto, mentre per alcuni componenti dell'infrastruttura viene eseguito il deployment delle istanze di Spanner vengono scalate automaticamente in progetti diversi.

Topologia per progetto

In un deployment della topologia a livello di progetto, ogni progetto con un'istanza di Spanner che deve essere scalata automaticamente dispone anche di un deployment indipendente dei componenti del gestore della scalabilità automatica. Consigliamo questa topologia ai team indipendenti che vogliono gestire la configurazione e l'infrastruttura 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 generale di un deployment per progetto.

Deployment concettuale per singolo progetto.

I deployment per progetto descritti 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 Applicazione 1 e 2.
  • In ciascun 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 riportati di seguito.

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 per le quali viene eseguita la scalabilità automatica.
  • Configurazione: il controllo sui parametri dello scheduler appartiene al team proprietario dell'istanza Spanner, che offre al team più libertà di adattare lo strumento del gestore della scalabilità automatica alle proprie esigenze rispetto a una topologia centralizzata o distribuita.
  • Limite chiaro della responsabilità dell'infrastruttura: la progettazione di una topologia per progetto stabilisce un chiaro confine di responsabilità e sicurezza nell'infrastruttura del gestore della scalabilità automatica, in quanto il proprietario del team delle istanze di 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, perciò potrebbe diventare difficile garantire che tutti gli strumenti del gestore della scalabilità automatica presenti nell'azienda seguano le stesse linee guida per l'aggiornamento.
  • Controllo più complesso: dato che ogni team ha un elevato livello di controllo, un controllo centralizzato potrebbe diventare più complesso.

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

Topologia centralizzata

Come per la topologia per progetto, in un deployment centralizzato di topologia 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 a un team che gestisce la configurazione e l'infrastruttura di diverse istanze Spanner da un unico deployment dello strumento Autoscaler in una posizione centrale.

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

Implementazione concettuale centralizzata del progetto.

Il deployment centralizzato illustrato 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 Applicazione 1 e 2.
  • Il deployment del gestore della scalabilità automatica (B) viene eseguito in un progetto separato per controllare la scalabilità automatica delle istanze Spanner nei progetti Applicazione 1 e Applicazione 2.

Per un diagramma più dettagliato di un deployment centralizzato a un progetto, consulta Eseguire il deployment di uno strumento della 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 singolo team controlla i parametri del scheduler e l'infrastruttura del gestore della scalabilità automatica. Questo approccio può essere utile in settori soggetti a regolamentazioni severe.
  • Minore manutenzione complessiva: manutenzione e configurazione di solito richiedono meno impegno rispetto a un deployment per singolo progetto.
  • Criteri e controlli centralizzati: le best practice per i vari team potrebbero essere più semplici da specificare e applicare. Potrebbe essere più semplice eseguire i controlli.

Svantaggi:

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

Per un tutorial dettagliato su come configurare lo strumento del gestore della scalabilità automatica utilizzando questa opzione, consulta Eseguire il deployment di uno strumento della scalabilità automatica per progetto o centralizzato per Spanner.

Topologia distribuita

In un deployment di topologia distribuita, le istanze Cloud Scheduler e di Spanner che devono essere scalate automaticamente risiedono nello stesso progetto. I componenti rimanenti dello strumento del gestore della scalabilità automatica risiedono in un progetto gestito centralmente. Questo deployment è ibrido. I team proprietari delle istanze di Spanner gestiscono solo i parametri di configurazione del gestore della scalabilità automatica per le proprie istanze, mentre un team centrale gestisce la restante infrastruttura del gestore della scalabilità automatica.

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

Deployment concettuale di progetti distribuiti.

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

  • Due applicazioni, Applicazione 1 e Applicazione 2, utilizzano le proprie istanze di Spanner.
  • Le istanze di Spanner (A) si trovano nei progetti dell'Applicazione 1 e dell'Applicazione 2.
  • In ciascun progetto viene eseguito il deployment di un componente (C) indipendente di Cloud Scheduler: Applicazione 1 e Applicazione 2.
  • Per i restanti componenti del gestore della scalabilità automatica (B) viene eseguito il deployment in un progetto separato.
  • Lo strumento del 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 di ciascun progetto.

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

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

Vantaggi:

  • I team delle applicazioni controllano la configurazione e le pianificazioni: il deployment di Cloud Scheduler viene eseguito insieme alle istanze di 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: il deployment dei componenti principali dello strumento del gestore della scalabilità automatica viene eseguito a livello centrale, in modo che i team operativi abbiano il controllo sull'infrastruttura del gestore della scalabilità automatica.
  • Manutenzione centralizzata: l'infrastruttura dello scaler è centralizzata e riduce i costi generali.

Svantaggi:

  • Configurazione più complessa: i team delle applicazioni devono fornire account di servizio per scrivere nell'argomento del polling.
  • Potenziale rischio aggiuntivo: l'infrastruttura condivisa potrebbe diventare un single point of failure anche se è stata progettata in funzione dell'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 split ai nodi o alle suddivisioni di un nodo chiamato unità di elaborazione. Il nodo o le unità di elaborazione gestiscono e pubblicano i dati in modo indipendente nelle suddivisioni distribuite. Le suddivisioni dei dati vengono create in base a diversi fattori, tra cui volume di dati e pattern di accesso. Per ulteriori dettagli, consulta Spanner: schema e modello dei dati.

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

Lo strumento del 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 le note di calcolo o le unità di elaborazione e le 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 scale down: 30 minuti

Per ulteriori informazioni sui suggerimenti di scalabilità e sui periodi di attesa, consulta Scalabilità delle istanze Spanner.

Costi

Il consumo di risorse dello strumento del gestore della scalabilità automatica è minimo, quindi nella maggior parte dei casi d'uso i costi sono trascurabili. Non sono previsti costi se il gestore della scalabilità automatica viene utilizzato su Google Cloud. Ad esempio, è disponibile senza costi l'esecuzione di uno strumento del gestore della 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
  • Chiamate da 500 ms per la funzione Cloud Function
  • Meno di 10 MB di dati in Firestore

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

Passaggi successivi