Panoramica dello strumento di gestione della scalabilità automatica

Questa pagina presenta 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 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 illustra le funzionalità, l'architettura, la configurazione e le topia di deployment dell'Autoscaler. Gli argomenti che seguono questa serie ti guidano nel deployment di Autoscaler in ciascuna delle diverse topologie.

Gestore della scalabilità automatica

Lo strumento del gestore della scalabilità automatica è utile per gestire l'utilizzo e le prestazioni deployment 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:

La scalabilità automatica dei deployment di Spanner consente alla tua infrastruttura si adattano automaticamente e scalano per soddisfare i requisiti di carico con una minima o nessuna dell'intervento. Inoltre, la scalabilità automatica ridimensiona correttamente l'infrastruttura di cui è stato eseguito il provisioning, può aiutarti a ridurre i costi.

Architettura

Questa sezione descrive i componenti del gestore della scalabilità automatica e le relative gli scopi più in dettaglio.

L'architettura dello strumento del gestore della scalabilità automatica è composta da Cloud Scheduler , due Pub/Sub argomenti, due Funzioni di Cloud Run e Firestore di Google. La API Cloud Monitoring viene utilizzato per ottenere le metriche di utilizzo della CPU e di archiviazione per Spanner di Compute Engine.

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 quanti più job di pianificazione in base alle tue esigenze.

Funzione Cloud Run del poller

La funzione Poller Cloud Run è responsabile della raccolta e dell'elaborazione delle metriche delle serie temporali per uno o più istanze Spanner. Il sondaggio pre-elabora i dati delle metriche per per ogni istanza Spanner, in modo che solo i punti dati più pertinenti vengano viene valutato e inviato alla funzione Cloud Run di Scaler. La pre-elaborazione eseguita dalla funzione Poller Cloud Run, semplifica anche il processo di valutazione delle soglie per a livello di singola regione, due regioni e più regioni Istanze Spanner.

Funzione Cloud Run dello scaler

Lo Scaler Funzione Cloud Run valuta i punti dati ricevuti dalla funzione Poller Cloud Run e determina se devi regolare il numero di nodi o unità di elaborazione e, in tal caso, 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 le 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 Polling, viene eseguita un'istanza del metodo Viene creata la funzione Cloud Run Poller per gestire il messaggio.
  4. La funzione Poller Cloud Run legge il payload dei messaggi ed esegue una query all'API Cloud Monitoring per recuperare di utilizzo delle metriche 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 all'argomento Scaler, lo scaler La funzione Cloud Run esegue queste operazioni:

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

    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 Cloud Run dello scaler recupera l'ora in cui l'istanza è stata ridimensionato per l'ultima volta da Firestore e lo confronta con per determinare se è consentito lo scale up o lo scale down in base al tempo di attesa cicli.

  8. Se il periodo di assestamento configurato è trascorso, lo scaler La funzione Cloud Run invia una richiesta a Spanner Istanza di cui fare 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 generale dello strumento del gestore della scalabilità automatica rimane invariato.

Funzionalità del gestore della scalabilità automatica

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

Gestisci 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 più o meno. 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 come può essere piccola o grande la tua 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 diversi carichi di lavoro

Lo strumento del gestore della scalabilità automatica offre tre diversi metodi di scalabilità verticale la scalabilità delle istanze Spanner: graduale, lineare e diretta. Ciascuna è progettato per supportare diversi tipi di carichi di lavoro. Puoi applicare uno o più la scalabilità automatica di ogni istanza Spanner quando crei seminari elettorali indipendenti.

A passo

La scalabilità graduale è utile per carichi di lavoro con picchi ridotti o multipli. it esegue il provisioning della capacità per agevolarli tutti con un singolo evento di scalabilità automatica.

Il seguente grafico mostra un pattern di carico con più piani di carico o passaggi: in cui ogni passo ha diversi piccoli picchi. Questo pattern è adatto al metodo graduale.

Modello di caricamento con più passaggi.

Quando la soglia di carico viene superata, questo metodo esegue il provisioning e rimuove i nodi o che utilizzano un numero fisso ma configurabile. Ad esempio, per ogni azione di ridimensionamento vengono aggiunti o rimossi tre nodi. 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 hanno alcuni picchi elevati. Il metodo calcola il numero minimo di nodi necessarie per mantenere l'utilizzo al di sotto della soglia di scalabilità. La di nodi o 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 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.

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 di unità di elaborazione dal numero totale attuale.

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

newSize = currentSize * currentUtilization / utilizationThreshold

Diretto

La scalabilità diretta consente un aumento immediato della capacità. Questo metodo è il cui scopo è supportare carichi di lavoro batch in cui un numero di nodi predeterminato più elevato è periodicamente richiesti 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 specificati nella pianificazione ed è progettato per essere utilizzato insieme a un metodo lineare o graduale.

Il seguente grafico illustra il grande aumento pianificato del carico, che il gestore della scalabilità automatica della capacità di pre-provisioning 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 del gestore della scalabilità automatica è progettato consente flessibilità e può supportare la separazione esistente le responsabilità tra i team operativi e quelli delle 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.

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 del gestore della scalabilità automatica può vantaggio di IAM (IAM) per l'autenticazione e l'autorizzazione.

Configurazione

Lo strumento del gestore della scalabilità automatica offre diverse opzioni di configurazione gestire la scalabilità dei tuoi deployment Spanner. Le sezioni successive descrivere le opzioni di configurazione di base e quelle più avanzate.

Configurazione di base

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 è rappresentato come un oggetto JSON. Di seguito è riportato un esempio di configurazione in cui due istanze Spanner vengono gestite 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 un gestore della scalabilità automatica con il metodo lineare per le operazioni normali, ma hanno anche un'altra configurazione del gestore della scalabilità automatica con il metodo diretto per il batch pianificato carichi di lavoro con scale out impegnativi.

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 nella File poller README:

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 del gestore della scalabilità automatica determina il numero di nodi o unità di elaborazione da aggiunta o sottratta a un'istanza utilizzando 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 aiuta a evitare l'attivazione di avvisi a soglie più alte.

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 lo scale up e lo scale down. In questi scenari, devi definire metriche personalizzate nella configurazione utilizzando metrics proprietà.

Margini

Un margine definisce un limite massimo e uno inferiore intorno alla soglia. Gestore della scalabilità automatica attiva un evento di scalabilità automatica solo se il valore della metrica è superiore a il 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]
 Più basso è il margine, più ristretto l'intervallo, con conseguente probabilità che venga attivato un evento di scalabilità automatica.

Specificare un parametro di margine per una metrica è facoltativo e il suo valore predefinito è cinque punti percentuali precedenti e inferiori al parametro.

Topologie di deployment

Per eseguire il deployment dello strumento del gestore della scalabilità automatica, decidi quale tra le seguenti topologie è la migliore per soddisfare le tue esigenze tecniche e operative:

  • Topologia per progetto: il deployment dell'infrastruttura del gestore della scalabilità automatica viene eseguito lo stesso progetto di Spanner che deve essere scalato automaticamente.
  • Topologia centralizzata: il deployment dello strumento del gestore della scalabilità automatica viene eseguito in un solo progetto gestisce una o più istanze Spanner in progetti diversi.
  • Topologia distribuita:: viene eseguito il deployment della maggior parte dell'infrastruttura del gestore della scalabilità automatica in un progetto, ma il deployment di alcuni componenti dell'infrastruttura viene eseguito Istanze Spanner con 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 ai team indipendenti che vogliono e gestire la configurazione e l'infrastruttura del gestore della scalabilità automatica. È anche un un buon punto di partenza per testare le funzionalità dello strumento del gestore della scalabilità automatica.

Il seguente diagramma mostra una visione concettuale di alto livello di un e deployment continuo.

Deployment concettuale per progetto.

I deployment per progetto descritti nel diagramma precedente hanno questi caratteristiche:

  • Due applicazioni, Applicazione 1 e Applicazione 2, ciascuna utilizza la propria Istanze Spanner.
  • Le istanze Spanner (A) risiedono nelle rispettive applicazioni 1 e Progetti dell'applicazione 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 Architettura .

Un deployment per progetto presenta i seguenti vantaggi e svantaggi.

Vantaggi:

  • Design più semplice: la topologia per progetto è la progettazione più semplice tre topologie poiché tutti i componenti del gestore della scalabilità automatica vengono delle istanze Spanner per le quali viene applicata la scalabilità automatica.
  • Configurazione: il controllo sui parametri dello scheduler appartiene al team proprietario dell'istanza Spanner, che offre al team più la libertà di adattare lo strumento del gestore della scalabilità automatica alle sue esigenze rispetto a un una topologia 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 del gestore della scalabilità automatica configurazione e infrastruttura, perciò potrebbe essere difficile che tutti gli strumenti del gestore della scalabilità automatica in tutta l'azienda seguano lo stesso aggiornamento linee guida.
  • Controllo più complesso: dato che ogni team ha un elevato livello di controllo, l'audit 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 ed è adatto a un team che gestisce la configurazione e l'infrastruttura diverse istanze Spanner da un singolo deployment 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:

Implementazione concettuale centralizzata del progetto.

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

  • Due applicazioni, Applicazione 1 e Applicazione 2, ciascuna utilizza la propria Istanze Spanner.
  • Le istanze Spanner (A) si trovano nelle rispettive applicazioni 1 Progetti dell'applicazione 2.
  • Il deployment del gestore della scalabilità automatica (B) viene eseguito in un progetto separato per controllare delle istanze Spanner sia nella piattaforma Application 1 che Progetti dell'applicazione 2.

Per un diagramma più dettagliato di un deployment centralizzato a un progetto, consulta Esegui 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 la i parametri dello scheduler e l'infrastruttura del gestore della scalabilità automatica. Questo approccio può essere utile nei settori con normative molto severe.
  • Meno manutenzione complessiva: la manutenzione e la configurazione richiedono in genere meno impegno rispetto a un deployment per progetto.
  • Criteri e controlli centralizzati: le best practice per i vari team potrebbero essere più facili da specificare e applicare. Potrebbe essere più facile eseguire i controlli.

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.
  • Potenziale rischio aggiuntivo: il team centralizzato stesso potrebbe diventare un single point of failure anche se l'infrastruttura del gestore della scalabilità automatica è progettata tenendo presente l'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 scalate automaticamente si trovano nello stesso progetto. I componenti rimanenti dello strumento del gestore della scalabilità automatica risiedono in una posizione progetto gestito. Questo deployment è ibrido. I team che possiedono Le istanze Spanner gestiscono solo la configurazione del gestore della scalabilità automatica parametri per le proprie istanze, mentre un team centrale gestisce i restanti dell'infrastruttura del gestore della scalabilità automatica.

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

Deployment concettuale di progetti distribuiti.

Il deployment ibrido descritto nel diagramma precedente ha quanto segue caratteristiche:

  • Due applicazioni, Applicazione 1 e Applicazione 2, usano la propria Istanze Spanner.
  • Le istanze Spanner (A) si trovano sia nell'Applicazione 1 Progetti dell'applicazione 2.
  • In ogni progetto viene eseguito il deployment di un componente (C) indipendente di Cloud Scheduler progetto: Applicazione 1 e Applicazione 2.
  • Il deployment dei componenti del gestore della scalabilità automatica rimanenti (B) viene eseguito progetto.
  • Lo strumento del gestore della scalabilità automatica scala automaticamente le istanze Spanner sia I progetti dell'applicazione 1 e 2 che utilizzano le configurazioni inviate i componenti indipendenti di Cloud Scheduler 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 vantaggi e gli svantaggi riportati di seguito.

Vantaggi:

  • I team di applicazioni controllano la configurazione e le pianificazioni: Cloud Scheduler viene implementato insieme alle istanze Spanner che vengono scalate automaticamente, offrendo ai team di applicazioni un maggiore controllo sulla configurazione e sulla pianificazione.
  • Il team operativo controlla l'infrastruttura: i componenti fondamentali del Lo strumento di scalabilità automatica viene implementato centralmente per consentire ai team operativi di controllare dell'infrastruttura del gestore della scalabilità automatica.
  • Manutenzione centralizzata: l'infrastruttura di Scaler è centralizzata, il che riduce il carico.

Svantaggi:

  • Configurazione più complessa: i team delle applicazioni devono fornire i propri servizi di scrittura nell'argomento polling.
  • Potenziale di rischio aggiuntivo: l'infrastruttura condivisa potrebbe diventare un il single point of failure anche se l'infrastruttura è progettata con la disponibilità del servizio.

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

Suddivisione dei dati

Spanner assegna intervalli di dati denominati split a nodi o suddivisioni di un nodo chiamato unità di elaborazione. Il nodo o le unità di elaborazione in modo indipendente gestire e pubblicare i dati nelle suddivisioni distribuite. 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 suddivisioni. Quindi, quando lo strumento della scalabilità automatica aggiunge o rimuove nodi deve concedere al backend Spanner tempo sufficiente per riassegnare riorganizzare le suddivisioni man mano che la nuova capacità viene aggiunta o rimossa 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 dell'automazione sono impostati sui seguenti valori minimi:

  • Valore di scalabilità: 5 minuti
  • Valore di riduzione: 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 per la maggior parte dei casi d'uso, sono trascurabili. Non è previsto alcun costo quando Autoscaler viene utilizzato su Google Cloud. Ad esempio , eseguendo uno strumento del gestore della scalabilità automatica per gestire tre istanze Spanner con un di 5 minuti per ogni istanza è disponibile senza costi aggiuntivi. Questa stima include quanto segue:

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

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

Passaggi successivi