Panoramica dei gruppi di endpoint di rete serverless

Un gruppo di endpoint di rete (NEG) specifica un gruppo di endpoint di backend per un bilanciatore del carico. Un NEG serverless è un backend che punta a un servizio Cloud Run, App Engine, Cloud Functions o Gateway API.

Un NEG serverless può rappresentare uno dei seguenti:

  • Un servizio Cloud Run o un gruppo di servizi.
  • Una funzione Cloud Functions o un gruppo di funzioni.
  • Un'app App Engine (Standard o Flex), un servizio specifico all'interno di un'app, una versione specifica di un'app o un gruppo di servizi.
  • Un API Gateway che fornisce l'accesso ai tuoi servizi tramite un'API REST coerente per tutti i servizi, indipendentemente dall'implementazione. Questa funzionalità è in Anteprima.

Casi d'uso

I NEG serverless sono supportati con i seguenti bilanciatori del carico:

  • Application Load Balancer esterno globale e l'Application Load Balancer classico: sono supportati Cloud Run, App Engine e Cloud Functions.
  • Application Load Balancer esterno regionale: è supportato solo Cloud Run.
  • Application Load Balancer interno: è supportato solo Cloud Run. Tieni presente che gli Application Load Balancer interni tra regioni sono limitati a un solo servizio Cloud Run per servizio di backend.

Quando il bilanciatore del carico è abilitato per le app serverless, puoi:

  • Configura la tua app serverless in modo che utilizzi un indirizzo IP IPv4 dedicato non condiviso con altri servizi.
  • Mappa un singolo URL a più funzioni o servizi serverless nello stesso dominio. In questo documento, consulta la sezione Mascherine URL.
  • Condividi lo spazio URL con altre piattaforme di computing Google Cloud. Utilizzando più servizi di backend, un singolo bilanciatore del carico può inviare traffico a più tipi di backend. Il bilanciatore del carico seleziona il servizio di backend corretto in base all'host o al percorso dell'URL della richiesta.
  • Riutilizza gli stessi certificati SSL e le stesse chiavi private che utilizzi per Compute Engine, Google Kubernetes Engine e Cloud Storage. Il riutilizzo degli stessi certificati elimina la necessità di gestire certificati separati per le app serverless.

Application Load Balancer esterno globale e Application Load Balancer classico

La configurazione di un Application Load Balancer esterno globale o di un Application Load Balancer classico consente alle tue app serverless di integrarsi con i servizi cloud esistenti. Ecco cosa puoi fare:

  • Proteggi il tuo servizio con Google Cloud Armor, un prodotto per la sicurezza WAF/per la difesa DDoS perimetrale disponibile per tutti i servizi a cui si accede tramite un Application Load Balancer esterno. Esistono alcune limitazioni associate a questa funzionalità, in particolare per Cloud Run e App Engine.
  • Abilita il tuo servizio per ottimizzare la distribuzione utilizzando Cloud CDN. Cloud CDN memorizza i contenuti nella cache vicino ai tuoi utenti. Cloud CDN offre funzionalità come l'annullamento della convalida della cache e gli URL firmati di Cloud CDN.
  • Utilizza l'infrastruttura perimetrale di Google per terminare le connessioni HTTP(S) dell'utente più vicine all'utente, riducendo così la latenza.

Per scoprire come configurare un bilanciatore del carico con un backend di serverless computing, consulta la documentazione seguente:

L'integrazione di un Application Load Balancer esterno con API Gateway consente ai backend serverless di sfruttare tutte le funzionalità offerte da Cloud Load Balancing. Per ulteriori informazioni, vedi External Application Load Balancer for API Gateway. Per configurare un Application Load Balancer esterno in modo da instradare il traffico a un API Gateway, consulta la Guida introduttiva all'utilizzo di un Application Load Balancer esterno per API Gateway. Questa funzionalità è in Anteprima.

Application Load Balancer esterno regionale

L'utilizzo di un Application Load Balancer esterno regionale consente di eseguire carichi di lavoro con requisiti normativi o di conformità sui backend Cloud Run. Ad esempio, se richiedi che le configurazioni di rete e la terminazione del traffico della tua applicazione si trovino in una regione specifica, un Application Load Balancer esterno regionale è spesso l'opzione preferita per soddisfare i controlli giurisdizionali necessari.

Per informazioni su come configurare un Application Load Balancer esterno regionale con un backend di serverless computing, consulta Configurare un Application Load Balancer esterno regionale con Cloud Run.

Application Load Balancer interno

Quando un Application Load Balancer interno è configurato con i backend Cloud Run, puoi fare quanto segue:

  • Abilita le funzionalità avanzate di gestione del traffico come l'iniezione di errori, le riscritture delle intestazioni, i reindirizzamenti, la suddivisione del traffico e altro ancora, per i tuoi servizi Cloud Run.
  • Esegui facilmente la migrazione dei servizi legacy da Compute Engine, GKE o on-premise a Cloud Run e sfrutta la suddivisione del traffico in base al peso per spostare gradualmente il traffico su Cloud Run senza tempi di inattività.
  • Proteggi i tuoi servizi Cloud Run con i Controlli di servizio VPC.
  • Stabilisci un singolo punto di ingresso interno che applichi criteri per i servizi in esecuzione in Cloud Run, Compute Engine e GKE.

Per informazioni su come configurare un Application Load Balancer interno con un backend di serverless computing, consulta Configurare un Application Load Balancer interno regionale con Cloud Run.

Il resto di questa pagina illustra come utilizzare NEG serverless con i bilanciatori del carico delle applicazioni. Per ulteriori informazioni su altri tipi di NEG, consulta Panoramica dei gruppi di endpoint di rete.

Tipi di endpoint

I NEG serverless non hanno endpoint di rete come porte o indirizzi IP. Possono puntare solo a un servizio Cloud Run, App Engine, gateway API o Cloud Functions esistente che risiede nella stessa regione del NEG.

Quando crei un NEG serverless, devi specificare il nome di dominio completo (FQDN) del servizio Cloud Run, App Engine, Gateway API o Cloud Functions. L'endpoint è di tipo SERVERLESS. Altri tipi di endpoint non sono supportati in un NEG serverless.

Un NEG serverless non può avere più di un endpoint. L'endpoint rimanda a un'applicazione serverless o a una maschera di URL. Il bilanciatore del carico funge da frontend per l'applicazione di serverless computing e funge da proxy del traffico all'endpoint specificato. Tuttavia, se il servizio di backend contiene più NEG serverless in regioni diverse, il bilanciatore del carico invia il traffico al NEG nell'area geografica più vicina per ridurre al minimo la latenza delle richieste.

Livello di rete

Per gli Application Load Balancer esterni globali, puoi utilizzare un NEG serverless in un bilanciatore del carico utilizzando livelli di servizi di rete Standard o Premium. Il livello Premium è necessario solo se vuoi configurare NEG serverless in più regioni.

Gli Application Load Balancer esterni regionali sono sempre di livello Standard.

Gli Application Load Balancer interni tra regioni e gli Application Load Balancer interni regionali sono sempre di livello Premium.

Componenti di bilanciamento del carico

Un bilanciatore del carico che utilizza un backend di NEG serverless richiede una configurazione speciale solo per il servizio di backend. La configurazione di frontend è la stessa di qualsiasi altro bilanciatore del carico Google Cloud basato su proxy. Inoltre, gli Application Load Balancer interni richiedono una subnet solo proxy per eseguire i proxy di Envoy per tuo conto.

I seguenti diagrammi mostrano un deployment di NEG serverless di esempio.

Esterno globale

Questo diagramma mostra come un NEG serverless si inserisce in un'architettura di Application Load Balancer esterno globale.

Application Load Balancer esterno globale per app serverless
Application Load Balancer esterno globale per app serverless

Esterno a livello di regione

Questo diagramma mostra come un NEG serverless si inserisce in un'architettura dell'Application Load Balancer esterno regionale.

Application Load Balancer esterno regionale per app serverless
Application Load Balancer esterno regionale per app serverless

Interno a livello di regione

Questo diagramma mostra come un NEG serverless si inserisce nel modello dell'Application Load Balancer interno regionale.

Application Load Balancer interno regionale per app serverless
Application Load Balancer interno regionale per app serverless

Componenti frontend

Non è richiesta alcuna configurazione di frontend speciale per il bilanciamento del carico con backend NEG serverless. Le regole di forwarding vengono utilizzate per instradare il traffico in base a indirizzo IP, porta e protocollo a un proxy di destinazione. Il proxy di destinazione termina quindi le connessioni dai client.

Le mappe URL vengono utilizzate dagli Application Load Balancer per configurare il routing basato su URL delle richieste ai servizi di backend appropriati.

Per ulteriori dettagli su ciascuno di questi componenti, consulta le sezioni relative all'architettura delle panoramiche specifiche del bilanciatore del carico:

Servizio di backend

I servizi di backend forniscono informazioni di configurazione al bilanciatore del carico. I bilanciatori del carico utilizzano le informazioni in un servizio di backend per indirizzare il traffico in entrata a uno o più backend collegati. I NEG serverless possono essere utilizzati come backend per determinati bilanciatori del carico.

A seconda del tipo di bilanciatore del carico, si applicano le seguenti restrizioni:

  • A un servizio di backend globale utilizzato da Application Load Balancer esterni globali possono essere collegati diversi NEG serverless, ma un solo NEG serverless per regione.
  • Un servizio di backend globale utilizzato dagli Application Load Balancer interni tra regioni può avere un solo NEG serverless per bilanciatore del carico.
  • Un servizio di backend regionale utilizzato dagli Application Load Balancer interni regionali e dagli Application Load Balancer esterni regionali può avere un solo NEG serverless collegato.

Ogni NEG serverless può puntare a uno dei seguenti elementi:

  • Il nome di dominio completo di una singola funzione o servizio
  • Una maschera URL che rimanda a più funzioni o servizi che operano nello stesso dominio.

Una maschera URL è un modello di schema URL che indica al backend NEG serverless come mappare la richiesta utente al servizio corretto. Le maschere URL sono utili se utilizzi un dominio personalizzato per la tua applicazione serverless e hai più servizi utilizzati nello stesso dominio. Invece di creare un NEG serverless separato per ogni funzione o servizio, puoi creare il NEG con una maschera URL generica per il dominio personalizzato. Per ulteriori informazioni ed esempi, consulta l'articolo Mascherine URL.

Per ulteriori limitazioni quando si aggiunge un NEG serverless come backend, consulta le Limitazioni.

Rilevamento outlier per NEG serverless

Il rilevamento outlier è una configurazione facoltativa che può essere abilitata su un servizio di backend globale a cui sono collegati NEG serverless. L'analisi del rilevamento di outlier è disponibile solo per un Application Load Balancer esterno globale e non per un Application Load Balancer classico. L'analisi per il rilevamento di outlier identifica i NEG serverless in stato non integro in base ai rispettivi pattern di risposta HTTP e riduce la percentuale di errori eseguendo il routing di alcune nuove richieste da servizi in stato non integro a servizi in stato integro.

Ad esempio, supponiamo che esista un servizio di backend a cui sono collegati due NEG serverless, uno nell'area geografica us-central1 e un altro nell'area geografica europe-west1. Se il NEG serverless che funge da backend per un Application Load Balancer esterno globale nella regione us-central1 non risponde, il rilevamento outlier identifica il NEG serverless come non integro. In base all'analisi del rilevamento di outlier, alcune delle nuove richieste vengono inviate al NEG serverless nella regione europe-west1.

In base al tipo di errore del server che si è verificato, puoi utilizzare uno dei seguenti metodi di rilevamento di outlier per abilitare il rilevamento di outlier:

  • Errori 5xx consecutivi. Un codice di stato HTTP della serie 5xx è considerato un errore.
  • Errori consecutivi del gateway. Solo i codici di stato HTTP 502, 503 e 504 sono idonei come errore.

Tieni presente che, anche dopo aver abilitato il rilevamento di outlier, è probabile che alcune richieste vengano inviate al servizio in stato non integro, con la conseguente restituzione di errori 5XX ai client. Questo perché i risultati dell'algoritmo di rilevamento di outlier (esclusione degli endpoint dal pool di bilanciamento del carico e restituzione al pool) vengono eseguiti in modo indipendente da ogni istanza proxy del bilanciatore del carico. Nella maggior parte dei casi, più di un'istanza proxy gestisce il traffico ricevuto da un servizio di backend. Pertanto, è possibile che un endpoint in stato non integro venga rilevato ed espulso solo da alcuni proxy e, mentre ciò accade, altri proxy possono continuare a inviare richieste allo stesso endpoint in stato non integro. Per ridurre ulteriormente il tasso di errore, puoi configurare parametri di rilevamento outlier più aggressivi. Per ulteriori informazioni, consulta outlierDetection nella documentazione relativa all'API del servizio di backend globale.

I seguenti campi outlierDetection non sono supportati quando al servizio di backend è collegato un NEG serverless:

  • outlierDetection.enforcingSuccessRate

  • outlierDetection.successRateMinimumHosts

  • outlierDetection.successRateRequestVolume

  • outlierDetection.successRateStdevFactor

Per informazioni su come configurare il rilevamento di outlier, consulta Configurare un Application Load Balancer esterno globale con backend serverless: abilitare il rilevamento di outlier.

Maschere URL

Un backend NEG serverless può puntare a un singolo servizio Cloud Run (o App Engine o Cloud Functions, se applicabile) oppure a una maschera URL che rimanda a più servizi. Una maschera URL è un modello dello schema di URL. Il NEG serverless utilizza questo modello per mappare la richiesta al servizio appropriato.

Le maschere URL sono una funzionalità facoltativa che semplifica la configurazione di NEG serverless quando l'applicazione serverless è composta da più servizi Cloud Run, Cloud Functions o App Engine. I NEG serverless utilizzati con Application Load Balancer interni possono utilizzare solo una maschera URL che punta ai servizi Cloud Run.

Le maschere URL sono utili se la tua app serverless è mappata a un dominio personalizzato anziché all'indirizzo predefinito fornito da Google Cloud. Con un dominio personalizzato come example.com, potresti eseguire il deployment di più servizi in sottodomini o percorsi diversi sullo stesso dominio. In questi casi, invece di creare un backend di NEG serverless separato per ogni servizio, puoi creare un singolo NEG serverless con una maschera URL generica per il dominio personalizzato (ad esempio example.com/<service>). Il NEG estrae il nome del servizio dall'URL della richiesta.

L'illustrazione seguente mostra un Application Load Balancer esterno con un singolo servizio di backend e NEG serverless, che utilizza una maschera URL per mappare le richieste degli utenti a servizi diversi.

Distribuzione del traffico alle applicazioni serverless (fai clic per ingrandire)
Utilizzo di una maschera URL per distribuire il traffico a servizi diversi

Le maschere URL funzionano al meglio quando i servizi della tua applicazione utilizzano uno schema URL prevedibile. Il vantaggio di utilizzare una maschera URL anziché una mappa URL è che non è necessario creare NEG serverless separati per i servizi login e search. Inoltre, non è necessario modificare la configurazione del bilanciatore del carico ogni volta che aggiungi un nuovo servizio all'applicazione.

Limitazioni

  • Un NEG serverless non può avere endpoint di rete come un indirizzo IP o una porta.
  • I NEG serverless possono puntare solo ad applicazioni serverless che si trovano nella stessa regione in cui è stato creato.
  • Per un bilanciatore del carico che utilizza un backend di NEG serverless, il NEG serverless deve essere creato nello stesso progetto dei servizi Cloud Run, App Engine, gateway API o Cloud Functions a cui fa riferimento il NEG. Potresti notare che le richieste non vanno a buon fine se connetti un servizio che non si trova nello stesso progetto del NEG serverless.
  • Un bilanciatore del carico configurato con un NEG serverless non è in grado di rilevare se l'app o il servizio serverless sottostante funziona come previsto. Ciò significa che, anche se il servizio restituisce errori, il bilanciatore del carico continua a indirizzare il traffico a questo servizio. Assicurati di testare accuratamente le nuove versioni dei servizi prima di indirizzare il traffico degli utenti a queste ultime.

Limitazioni con i servizi di backend

Le seguenti limitazioni si applicano ai servizi di backend che hanno un backend NEG serverless:

  • Un servizio di backend globale utilizzato dagli Application Load Balancer esterni globali può avere un solo NEG serverless per regione. Per combinare più NEG serverless in un singolo servizio di backend, tutti i NEG devono rappresentare deployment equivalenti dal punto di vista funzionale in regioni diverse. Ad esempio, i NEG possono puntare allo stesso servizio Cloud Run, App Engine o Cloud Functions di cui è stato eseguito il deployment in regioni diverse.
  • Un servizio di backend globale utilizzato dagli Application Load Balancer interni tra regioni può avere un solo NEG serverless per bilanciatore del carico.
  • A un servizio di backend regionale può essere collegato un solo NEG serverless.
  • Il servizio di backend deve essere creato nello stesso progetto del NEG serverless e del servizio Cloud Run, App Engine, API Gateway o Cloud Functions di supporto. Se stai configurando un deployment VPC condiviso con riferimento a servizio tra progetti, i componenti frontend del bilanciatore del carico (indirizzo IP, regola di forwarding, proxy di destinazione e mappa URL) possono essere creati in un progetto diverso.
  • L'impostazione di timeout del servizio di backend non si applica ai servizi di backend con backend NEG serverless. Il tentativo di modificare la proprietà resource.timeoutSec del servizio di backend genera il seguente errore: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    Per i servizi di backend con backend NEG serverless, il timeout predefinito è di 60 minuti. Questo timeout non è configurabile. Se la tua applicazione ha bisogno di connessioni a lunga esecuzione, configura i client in modo che riprovino le richieste in caso di errore.
  • Anche tutti i NEG serverless combinati in un servizio di backend devono utilizzare lo stesso tipo di backend. Ciò significa che i NEG serverless di Cloud Run possono essere combinati solo con altri NEG serverless di Cloud Run, i NEG serverless di App Engine possono essere combinati solo con i NEG serverless di App Engine e così via.
  • Non puoi combinare NEG serverless con altri tipi di NEG nello stesso servizio di backend. Ad esempio, non puoi eseguire il routing a un cluster GKE e a un servizio Cloud Run dallo stesso servizio di backend.
  • Durante la configurazione dei servizi di backend che instradano a NEG serverless, alcuni campi sono limitati:
    • Non puoi specificare una modalità di bilanciamento. In altre parole, i valori RATE, UTILIZATION e CONNECTION non hanno effetto sulla distribuzione del traffico del bilanciatore del carico.
    • I controlli di integrità non sono supportati per i backend serverless. Pertanto, i servizi di backend che contengono backend di NEG serverless non possono essere configurati con controlli di integrità. Tuttavia, puoi facoltativamente abilitare il rilevamento di outlier per identificare i servizi serverless in stato non integro e instradare le nuove richieste a un servizio serverless integro.
  • Non puoi utilizzare il comando gcloud compute backend-services edit per modificare un servizio di backend con un backend NEG serverless. Come soluzione alternativa, utilizza il comando gcloud compute backend-services update.

Si applicano limitazioni aggiuntive a seconda del tipo di bilanciatore del carico e del backend serverless.

Limitazioni degli Application Load Balancer interni e degli Application Load Balancer esterni regionali

  • I NEG serverless utilizzati con Application Load Balancer interni tra regioni, Application Load Balancer interni regionali o Application Load Balancer esterni regionali possono puntare solo ai servizi Cloud Run.
  • Per i progetti che utilizzano NEG serverless, il limite di query al secondo (QPS) è pari a 5000 QPS per progetto per il traffico inviato a qualsiasi NEG serverless configurato con Application Load Balancer esterni regionali o Application Load Balancer interni regionali. Questo limite viene aggregato tra tutti gli Application Load Balancer esterni regionali e gli Application Load Balancer interni regionali nel progetto. Non è un limite per bilanciatore del carico.

Limitazioni degli Application Load Balancer esterni globali

Limitazioni di App Engine

  • Gli Application Load Balancer esterni globali con backend dell'ambiente flessibile di App Engine non supportano l'utilizzo del riferimento al servizio tra progetti. L'ambiente standard di App Engine è supportato.

Limitazioni di Cloud Run

  • Un Application Load Balancer esterno con NEG serverless non supporta Cloud Run for Anthos.
  • Gli Application Load Balancer esterni non supportano le richieste autenticate ai servizi Cloud Run.

Limitazioni di Cloud Functions

  • IAP non funziona con Cloud Functions.

Limitazioni di App Engine

  • Il bilanciamento del carico in più regioni non è supportato con App Engine. Questo perché App Engine richiede una regione per progetto.
  • È consentito un solo criterio IAP nel percorso di richiesta. Ad esempio, se hai già impostato un criterio IAP nel servizio di backend, non devi impostare un altro criterio IAP nell'app App Engine.
  • Ti consigliamo di utilizzare i controlli in entrata in modo che la tua app riceva solo le richieste inviate dal bilanciatore del carico (e dal VPC, se lo utilizzi). In caso contrario, gli utenti possono utilizzare l'URL App Engine della tua app per bypassare il bilanciatore del carico, i criteri di sicurezza di Google Cloud Armor, i certificati SSL e le chiavi private che vengono trasmesse attraverso il bilanciatore del carico.

Limitazioni di API Gateway

Per saperne di più, consulta Limitazioni sui NEG serverless e API Gateway.

Prezzi

Per informazioni sui prezzi dei bilanciatori del carico con NEG serverless, vedi Tutti i prezzi di networking: Cloud Load Balancing.

Passaggi successivi