Bilanciamento del carico per API Gateway

L'integrazione del supporto del bilanciatore del carico delle applicazioni esterno globale e dell'Application Load Balancer classico per API Gateway consente ai backend serverless di sfruttare tutte le funzionalità fornite da Cloud Load Balancing. Combinando API Gateway con un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico utilizzando un gruppo di endpoint di rete serverless (NEG serverless), puoi:

  • Gateway host con domini con brand personalizzati
  • Configurare TLS per i gateway utilizzando certificati emessi da un'autorità di certificazione preferita
  • Crea un punto di ingresso comune per il routing di un gateway a più backend
  • Esegui il deployment dei gateway in più regioni geografiche per una disponibilità elevata senza gestire gli URL per ogni regione
  • Proteggi i gateway con Cloud Armor
  • Migliora il tempo di risposta del gateway sfruttando Cloud CDN

Utilizzo di un NEG serverless per API Gateway

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 backend serverless ospitato da Google come Cloud Run, App Engine o API Gateway. Un backend NEG serverless per API Gateway può rappresentare:

  • Un'istanza API Gateway
  • Un gruppo di gateway configurati con la stessa configurazione API

La figura seguente mostra come i NEG serverless possono essere utilizzati nel modello di Cloud Load Balancing:

diagramma della negazione serverless come backend per i gateway multiregionali

Come illustrato in un esempio precedente, un servizio di backend può essere gestito da diversi NEG serverless. Ogni NEG serverless può contenere una singola istanza di API Gateway o utilizzare una maschera URL per puntare a più gateway. Poiché tutti i NEG che agiscono come servizio di backend vengono utilizzati per il bilanciamento del carico, devono rappresentare deployment di gateway equivalenti dal punto di vista funzionale. Ad esempio, per tutti i NEG deve essere stato eseguito il deployment della stessa configurazione API su ciascun gateway in regioni diverse. Se un servizio di backend contiene diversi NEG, il bilanciatore del carico bilancia il traffico tra questi NEG riducendo al minimo la latenza delle richieste.

Limitazioni sui NEG serverless e su API Gateway

È necessario considerare alcune limitazioni quando si utilizzano NEG serverless per integrare Cloud Load Balancing per API Gateway. In particolare:

  • Ai NEG serverless non possono essere collegati endpoint di rete, ad esempio indirizzi IP o porte.
  • I NEG serverless possono puntare solo alle istanze API Gateway che si trovano nella stessa regione in cui viene creato il NEG.
  • I NEG serverless possono puntare solo alle istanze del gateway API create nello stesso progetto del bilanciatore del carico utilizzando il backend NEG serverless.
  • API Gateway non supporta le impostazioni di controllo Ingress. Di conseguenza, non è possibile disabilitare l'accesso a API Gateway utilizzando un URL gateway generato dal servizio e garantire che tutto il traffico sia gestito dal bilanciatore del carico.

Per ulteriori informazioni sulle limitazioni relative ai NEG serverless e ai servizi di backend in generale, consulta Limitazioni.

Limitazioni sui NEG serverless nelle configurazioni dei servizio di backend

Un servizio di backend definisce il modo in cui Cloud Load Balancing distribuisce il traffico. La configurazione del servizio di backend contiene un insieme di valori, ad esempio il protocollo utilizzato per la connessione ai backend, varie impostazioni di distribuzione e sessione, controlli di integrità e timeout. Per i NEG serverless utilizzati come servizio di backend per API Gateway, queste impostazioni forniscono un controllo granulare sul comportamento del bilanciatore del carico.

La definizione della risorsa di un servizio di backend ha le seguenti implicazioni per la progettazione del bilanciamento del carico:

  • I NEG serverless non possono essere utilizzati con altri tipi di NEG nello stesso servizio di backend. Ad esempio, non puoi eseguire il routing a un cluster GKE e a un'istanza API Gateway dallo stesso servizio di backend.
  • Tutti i NEG serverless combinati in un servizio di backend devono utilizzare lo stesso tipo di backend. Ciò significa che i NEG serverless di API Gateway possono essere combinati solo con altri NEG serverless di API Gateway. I NEG serverless di App Engine possono essere combinati solo con i NEG serverless di App Engine.
  • Un servizio di backend può contenere solo un NEG serverless per regione.

Quando definisci una configurazione del servizio di backend che instrada a un NEG serverless, si applicano le seguenti limitazioni di campo:

  • Impossibile specificare balancingMode
  • Il campo healthCheck deve essere vuoto e non può essere specificato
  • Impossibile specificare le porte
  • Sono supportati solo i protocolli HTTP e HTTPS.
  • I valori specificati nei campi correlati a utilization o connection non sono supportati.

I campi IAP, cdnPolicy e securityPolicy della configurazione del servizio di backend sono validi per i NEG serverless. Questi campi possono essere utilizzati per configurare rispettivamente Identity-Aware Proxy, Cloud CDN e Cloud Armor con il tuo servizio API Gateway.

Che cosa succede dopo?