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 elementi:

  • 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 gateway API che fornisce l'accesso ai tuoi servizi tramite un'API REST coerente tra tutti i servizi, indipendentemente dall'implementazione del servizio. Questa funzionalità è in Anteprima.

Bilanciatori del carico supportati

La seguente tabella elenca i prodotti serverless supportati da ciascun bilanciatore del carico delle applicazioni. I NEG serverless non sono supportati dai bilanciatori del carico di rete proxy e dai bilanciatori del carico di rete passthrough.

Piattaforma serverless Bilanciatori del carico delle applicazioni
Interno
regionale		 Interno
tra regioni		 Esterno
globale		 Classico Esterno
regionale
Cloud Run
App Engine
Cloud Functions

Casi d'uso

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

  • Configura l'app serverless in modo che venga pubblicata da un indirizzo IP IPv4 dedicato non condiviso con altri servizi.
  • Mappare un singolo URL a più funzioni o servizi serverless che operano nello stesso dominio. In questo documento, consulta le maschere degli URL.
  • Condividi 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 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.

Bilanciatore del carico delle applicazioni esterno globale e bilanciatore del carico delle applicazioni classico

La configurazione di un bilanciatore del carico delle applicazioni esterno globale o di un bilanciatore del carico delle applicazioni classico consente alle app serverless di integrarsi con i servizi cloud esistenti. Puoi:

  • Proteggi il tuo servizio con Google Cloud Armor, un prodotto per la difesa dagli attacchi DDoS perimetrale e la sicurezza WAF disponibile per tutti i servizi a cui si accede tramite un bilanciatore del carico delle applicazioni 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 nella cache i contenuti vicini ai tuoi utenti. e offre funzionalità come l'annullamento della convalida della cache e gli URL firmati.
  • 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 seguente documentazione:

L'integrazione di un bilanciatore del carico delle applicazioni esterno con API Gateway consente ai tuoi backend serverless di sfruttare tutte le funzionalità offerte da Cloud Load Balancing. Per saperne di più, vedi Bilanciatore del carico delle applicazioni esterno per API Gateway. Per configurare un bilanciatore del carico delle applicazioni esterno per instradare il traffico a un API Gateway, consulta la guida introduttiva all'utilizzo di un bilanciatore del carico delle applicazioni esterno per API Gateway. Questa funzionalità è in Anteprima.

Bilanciatore del carico delle applicazioni esterno regionale

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

Per scoprire come configurare un Application Load Balancer esterno regionale con un backend di serverless computing, consulta Configurare un bilanciatore del carico delle applicazioni esterno regionale con Cloud Run.

Bilanciatore del carico delle applicazioni interno regionale e bilanciatore del carico delle applicazioni interno tra regioni

Quando un bilanciatore del carico delle applicazioni interno è configurato con i backend Cloud Run, puoi:

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

Per scoprire come configurare un Application Load Balancer interno regionale con un backend di serverless computing, consulta Configurare un bilanciatore del carico delle applicazioni interno regionale con Cloud Run.

Il resto di questa pagina illustra come utilizzare i NEG serverless con i bilanciatori del carico delle applicazioni. Per ulteriori informazioni sugli 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, API Gateway o Cloud Functions esistente che si trova nella stessa regione del NEG.

Quando crei un NEG serverless, specifichi il nome di dominio completo (FQDN) del servizio Cloud Run, App Engine, API Gateway 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 URL. Il bilanciatore del carico funge da frontend per l'applicazione di serverless computing e 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 nella regione più vicina per ridurre al minimo la latenza delle richieste.

Livello di rete

Per i bilanciatori del carico delle applicazioni esterni globali, puoi utilizzare un NEG serverless in un bilanciatore del carico utilizzando il livello Standard o Premium di Network Service Tiers. Il livello Premium è necessario solo se vuoi configurare NEG serverless in più regioni.

I bilanciatori del carico delle applicazioni esterni regionali sono sempre di livello Standard.

I bilanciatori del carico delle applicazioni interni tra regioni e i bilanciatori del carico delle applicazioni interni regionali sono sempre di livello Premium.

Componenti di bilanciamento del carico

Un bilanciatore del carico che utilizza un backend NEG serverless richiede una configurazione speciale solo per il servizio di backend. La configurazione frontend è uguale a qualsiasi altro bilanciatore del carico Google Cloud basato su proxy. Inoltre, i bilanciatori del carico delle applicazioni interni richiedono una subnet solo proxy per eseguire i proxy Envoy per tuo conto.

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

Esterno globale

Questo diagramma mostra il modo in cui un NEG serverless si inserisce in un'architettura del bilanciatore del carico delle applicazioni esterno globale.

Bilanciatore del carico delle applicazioni esterno globale per app serverless.
Bilanciatore del carico delle applicazioni esterno globale per app serverless (fai clic per ingrandire).

Esterno regionale

Questo diagramma mostra il modo in cui un NEG serverless si inserisce in un'architettura del bilanciatore del carico delle applicazioni esterno regionale.

Bilanciatore del carico delle applicazioni esterno regionale per le app serverless.
Bilanciatore del carico delle applicazioni esterno regionale per le app serverless (fai clic per ingrandire).

Interno a livello di regione

Questo diagramma mostra come un NEG serverless si inserisce nel modello di bilanciatore del carico delle applicazioni interno regionale.

Bilanciatore del carico delle applicazioni interno regionale per le app serverless.
Bilanciatore del carico delle applicazioni interno regionale per app serverless (fai clic per ingrandire).

Tra regioni

Questo diagramma mostra come un NEG serverless si inserisce nel modello di bilanciatore del carico delle applicazioni interno tra regioni.

Bilanciatore del carico delle applicazioni interno tra regioni con deployment di Cloud Run.
Bilanciatore del carico delle applicazioni interno tra regioni con deployment di Cloud Run (fai clic per ingrandire).

Componenti del frontend

Non è richiesta alcuna configurazione frontend speciale per il bilanciamento del carico con backend NEG serverless. Le regole di forwarding vengono utilizzate per instradare il traffico per 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 dai bilanciatori del carico delle applicazioni per configurare il routing delle richieste basato su URL ai servizi di backend appropriati.

Per ulteriori dettagli su ciascuno di questi componenti, fai riferimento alle sezioni sull'architettura delle panoramiche specifiche sui bilanciatori del carico:

Servizio di backend

I servizi di backend forniscono informazioni di configurazione al bilanciatore del carico. I bilanciatori di 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 usati come backend per determinati bilanciatori del carico.

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

  • A un servizio di backend globale utilizzato dai bilanciatori del carico delle applicazioni esterni globali possono essere collegati diversi NEG serverless, ma un solo NEG serverless per regione.
  • A un servizio di backend regionale utilizzato dai bilanciatori del carico delle applicazioni interni regionali e dai bilanciatori del carico delle applicazioni esterni regionali può essere associato un solo NEG serverless.
  • A un servizio di backend globale utilizzato dai bilanciatori del carico delle applicazioni interni tra regioni possono essere collegati solo servizi Cloud Run.

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

  • Il nome di dominio completo per una singola funzione o un singolo servizio
  • Una maschera URL che punta a più funzioni o servizi pubblicati sullo stesso dominio.

Una maschera URL è un modello di schema URL che indica al backend NEG serverless come mappare la richiesta dell'utente al servizio corretto. Le maschere URL sono utili se utilizzi un dominio personalizzato per la tua applicazione serverless e la tua applicazione serverless gestisce più servizi nello stesso dominio. Anziché 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 Maschere URL.

Per ulteriori limitazioni quando aggiungi un NEG serverless come backend, consulta 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 outlier è disponibile solo per un bilanciatore del carico delle applicazioni interno tra regioni, per il bilanciatore del carico delle applicazioni esterno globale e non per un bilanciatore del carico delle applicazioni classico. L'analisi del rilevamento degli outlier identifica i NEG serverless non integri in base ai pattern di risposta HTTP e riduce la percentuale di errori instradando la maggior parte delle nuove richieste da servizi non integri a servizi integri. Per scoprire come funziona l'algoritmo di rilevamento di outlier e comprenderne i limiti, guarda l'esempio seguente.

Supponiamo che esista un servizio di backend con due NEG serverless collegati, uno nella regione REGION_A e un altro nella regione REGION_B. Se il NEG serverless che funge da backend per un bilanciatore del carico delle applicazioni esterno globale nella regione REGION_A non è reattivo, il rilevamento dell'outlier identifica il NEG serverless come non integro. In base all'analisi del rilevamento degli outlier, alcune delle nuove richieste vengono quindi inviate al NEG serverless nella regione REGION_B.

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

  • Errori 5xx consecutivi. Un codice di stato HTTP della serie 5xx viene classificato come errore.
  • Errori consecutivi del gateway. Solo i codici di stato HTTP 502, 503 e 504 possono essere considerati errori.

Tieni presente che anche dopo aver abilitato il rilevamento outlier, è probabile che alcune richieste vengano inviate al servizio in stato non integro e che quindi restituiscano errori 5XX ai client. Ciò è dovuto al fatto che i risultati dell'algoritmo di rilevamento degli outlier (espulsione degli endpoint dal pool di bilanciamento del carico e restituiti al pool) vengono eseguiti in modo indipendente da ciascuna 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, anche se ciò accade, altri proxy potrebbero continuare a inviare richieste allo stesso endpoint in stato non integro.

Per ridurre ulteriormente i tassi di errore, puoi configurare parametri di rilevamento outlier più aggressivi. Ti consigliamo di configurare valori più elevati per le soglie di esclusione (outlierDetection.baseEjectionTime). Ad esempio, i nostri test mostrano che impostare outlierDetection.baseEjectionTime su 180 secondi con un QPS sostenuto superiore a 100 si traduce in tassi di errore osservati inferiori al 5%. Per scoprire di più sull'API di rilevamento degli outlier, consulta outlierDetection nella documentazione dell'API globale del servizio di backend.

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 scoprire come configurare il rilevamento degli outlier, consulta Configurare un bilanciatore del carico delle applicazioni esterno globale con un 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 punta a più servizi. Una maschera URL è un modello dello schema 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 dei NEG serverless quando l'applicazione serverless è composta da più servizi Cloud Run, Cloud Functions o App Engine. I NEG serverless utilizzati con i bilanciatori del carico delle applicazioni interni possono usare 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, è possibile che più servizi vengano distribuiti in sottodomini o percorsi diversi sullo stesso dominio. In questi casi, invece di creare un backend 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 bilanciatore del carico delle applicazioni 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 app serverless.
Utilizzo di una maschera URL per distribuire il traffico a servizi diversi (fai clic per ingrandire).

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 devi 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 indirizzo IP o porta.
  • I NEG serverless possono puntare solo ad applicazioni serverless che risiedono nella stessa regione in cui viene creato il NEG.
  • Per un bilanciatore del carico che utilizza un backend NEG serverless, il NEG serverless deve essere creato nello stesso progetto dei servizi Cloud Run, App Engine, Gateway API o Cloud Functions di supporto a cui punta 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 indirizzarvi il traffico. Assicurati di testare accuratamente le nuove versioni dei tuoi servizi prima di instradare loro il traffico degli utenti.

Limitazioni con i servizi di backend

Le seguenti limitazioni si applicano ai servizi di backend con backend di NEG serverless:

  • Un servizio di backend globale utilizzato da bilanciatori del carico delle applicazioni 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 diverse regioni. Ad esempio, i NEG possono puntare allo stesso servizio Cloud Run, App Engine o Cloud Functions di cui è stato eseguito il deployment in diverse regioni.
  • A un servizio di backend globale utilizzato dai bilanciatori del carico delle applicazioni interni tra regioni può essere collegato un solo servizio Cloud Run.
  • A un servizio di backend regionale può essere collegato un solo NEG serverless.
  • I riferimenti di servizi tra progetti in un deployment VPC condiviso sono supportati con configurazioni che contengono un NEG serverless. Per utilizzare questa funzionalità, devi creare i componenti frontend del bilanciatore del carico (indirizzo IP, regola di forwarding, proxy di destinazione e mappa URL) in un progetto diverso dai componenti backend del bilanciatore del carico (servizio di backend e NEG serverless). Tieni presente che il servizio di backend, i NEG serverless associati e il servizio serverless di supporto (Cloud Run, App Engine, API Gateway o Cloud Functions) devono essere sempre creati nello stesso progetto.
  • 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 è 60 minuti. Questo timeout non è configurabile. Se la tua applicazione ha bisogno di connessioni a lunga esecuzione, configura i client in modo da riprovare 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 e i NEG serverless di App Engine possono essere combinati solo con i NEG serverless di App Engine.
  • 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 di servizi di backend che eseguono l'instradamento a NEG serverless, alcuni campi sono limitati:
    • Non puoi specificare una modalità di bilanciamento. In altre parole, i valori RATE, UTILIZATION e CONNECTION non influiscono 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 outlier per identificare i servizi serverless non integri e indirizzare 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 ulteriori limitazioni a seconda del tipo di bilanciatore del carico e del backend serverless.

Limitazioni relative ai bilanciatori del carico delle applicazioni interni regionali e agli Application Load Balancer esterni regionali

  • I NEG serverless utilizzati con bilanciatori del carico delle applicazioni interni regionali o bilanciatori del carico delle applicazioni esterni regionali possono puntare solo ai servizi Cloud Run.
  • Per i progetti che utilizzano NEG serverless, il limite di query al secondo (QPS) è di 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 è aggregato per tutti i bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni interni regionali nel progetto. Non si tratta di un limite per bilanciatore del carico.

Limitazioni con i bilanciatori del carico delle applicazioni interni tra regioni

  • I NEG serverless utilizzati con bilanciatori del carico delle applicazioni interni tra regioni possono puntare solo ai servizi Cloud Run.

Limitazioni con i bilanciatori del carico delle applicazioni esterni globali

Questa sezione elenca le limitazioni che incontrerai durante la configurazione dei NEG serverless con bilanciatori del carico delle applicazioni esterni globali.

Limitazioni con App Engine

  • I bilanciatori del carico delle applicazioni esterni globali con backend dell'ambiente flessibile di App Engine non supportano l'utilizzo dei riferimenti ai servizi tra progetti. L'ambiente standard di App Engine è supportato.

Limitazioni con Cloud Run

  • Un bilanciatore del carico delle applicazioni esterno con NEG serverless non supporta Knative serving.
  • I bilanciatori del carico delle applicazioni esterni non supportano le richieste autenticate ai servizi Cloud Run.

Limitazioni con Cloud Functions

  • IAP non funziona con Cloud Functions.

Limitazioni con App Engine

  • Il bilanciamento del carico multiregionale non è supportato con App Engine. Questo perché App Engine richiede 1 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 di App Engine dell'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 tramite il bilanciatore del carico.

Limitazioni con API Gateway

Per maggiori informazioni, consulta Limitazioni relative ai NEG serverless e ad API Gateway.

Prezzi

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

Passaggi successivi