Best practice per il networking di App Engine

Questa pagina descrive le best practice per la configurazione delle opzioni di networking per le risorse App Engine. Ti consigliamo di esaminare tutte le sezioni di questa pagina per comprendere le opzioni di networking supportate da App Engine e le relative implicazioni.

Best practice:

Gestione degli indirizzi IP.
Monitora l'utilizzo degli indirizzi IP.
Utilizza indirizzi IP non RFC 1918.
Utilizza subnet IPv4 e IPv6 (dual stack).
Utilizza il pool di connessioni e riutilizza le connessioni.
Utilizza i runtime supportati.
Velocità effettiva esterna più elevata verso internet.
Velocità effettiva interna più elevata per un'API di Google.

Gestione IP

Devi gestire i tuoi indirizzi IP perché ogni istanza del tuo servizio App Engine utilizza indirizzi IP della tua subnet. Utilizza le seguenti strategie per gestire i tuoi indirizzi IP:

  • Allocazione IP alternativa: alloca intervalli privati standard o intervalli IP alternativi per mitigare l'esaurimento degli indirizzi IP. Consulta le strategie di esaurimento degli indirizzi IP.

  • Dimensionamento della subnet: assicurati che l'intervallo di indirizzi IPv4 della subnet sia /26 o superiore per fornire indirizzi IP sufficienti per la scalabilità.

  • Esegui l'overprovisioning degli indirizzi IP: ti consigliamo di eseguire l'overprovisioning del numero di indirizzi IP disponibili nella subnet per evitare l'esaurimento. Come per altri servizi App Engine, in genere devi utilizzare un numero di indirizzi IP quattro volte superiore (2 volte per lo stato stabile e altre 2 volte durante il deployment) rispetto al numero di istanze in esecuzione per facilitare lo scale up e gli aggiornamenti.

Monitora l'utilizzo degli indirizzi IP

Se utilizzi il traffico VPC diretto in uscita, assicurati di avere allocato un numero sufficiente di indirizzi IP per la tua subnet. Il numero di indirizzi IP che utilizzi dipende dal numero di istanze su cui vengono eseguiti i workload, pertanto ti consigliamo di monitorare l'utilizzo degli indirizzi IP. Assicurati che l'utilizzo degli IP nel tempo rimanga entro i limiti supportati dalla subnet.

Per stimare l'utilizzo degli indirizzi IP:

  1. Nella console Google Cloud , vai alla pagina Metrics Explorer:

    Vai a Esplora metriche

  2. Cerca al volo il numero di istanze nel tuo progetto utilizzando il tipo di metrica appengine.googleapis.com/system/instance_count. Questa metrica conteggia tutte le istanze App Engine nel progetto. Per le versioni configurate con il traffico VPC diretto in uscita, filtra in base all'etichetta module_id, che identifica il servizio, o in base all'etichetta version_id. Cloud Monitoring ti consente di visualizzare il valore di questa metrica nel tempo.

  3. Moltiplica per 2 il valore della metrica del conteggio delle istanze per ottenere una stima del numero di indirizzi IP in uso.

Strategie per l'esaurimento degli indirizzi IP

La presenza di un numero elevato di workload App Engine può causare problemi di esaurimento degli IP quando si utilizza lo spazio di indirizzi IP privati RFC 1918 con l'accesso VPC diretto. Le seguenti strategie possono aiutarti a gestire l'esaurimento degli indirizzi IP utilizzando intervalli di indirizzi IP alternativi.

Utilizza indirizzi IPv4 non RFC 1918

Oltre agli intervalli di indirizzi IPv4 RFC 1918, App Engine supporta anche gli intervalli RFC 6598 e Classe E/RFC 5735. Tutti i servizi e le funzionalità diGoogle Cloud funzionano con questi intervalli non RFC 1918, tra cui le reti VPC, Cloud Load Balancing e Private Service Connect.

Per la massima compatibilità, ti consigliamo di iniziare con l'intervallo RFC 6598 (100.64.0.0/10). Se utilizzi già questo intervallo altrove, valuta la possibilità di utilizzare la classe E/RFC 5735 (240.0.0.0/4). La classe E è uno spazio enorme con oltre 268 milioni di indirizzi IP disponibili, quindi supporterà la tua crescita per molto tempo. Tuttavia, la classe E presenta alcune limitazioni. Ad esempio, non è supportata su Windows e su alcuni hardware on-premise. Scopri di più su come sfruttare lo spazio degli indirizzi IPv4 di classe E per mitigare i problemi di esaurimento degli indirizzi IPv4 in GKE.

Utilizza Cloud NAT o Private Service Connect

Se il tuo workload App Engine si trova in un intervallo non RFC 1918 e deve raggiungere una destinazione on-premise che accetta solo RFC 1918, scegli una delle seguenti soluzioni:

  • Utilizza Hybrid NAT per eseguire la traduzione degli indirizzi e il traffico in uscita tramite un intervallo RFC 1918 ridotto.
  • Esponi il servizio on-premise come servizio ibrido Private Service Connect.

Utilizza subnet IPv4 e IPv6 (dual stack)

Anche se non ridurrà l'esaurimento degli indirizzi IPv4, valuta la possibilità di spostare le tue app su IPv6. Per evitare problemi di esaurimento degli indirizzi IPv4 in futuro, configura le risorse a doppio stack.

Strategie di riduzione dell'esaurimento delle porte

La sezione seguente descrive le strategie per ridurre l'esaurimento delle porte con App Engine.

Utilizza il pool di connessioni e riutilizza le connessioni

Quando invii un numero elevato di richieste dalla tua app App Engine a un singolo indirizzo IP di destinazione, utilizza il pooling delle connessioni per mantenere e riutilizzare le connessioni alla destinazione. Frequenze di connessione elevate a un singolo indirizzo IP possono esaurire le porte in uscita e causare errori di connessione rifiutata.

Strategie di prestazioni e throughput

Questa sezione illustra le opzioni scalabili per migliorare le prestazioni e il throughput della rete verso internet e i servizi Google.

Utilizza i runtime supportati

Il VPC diretto in uscita è supportato solo sui runtime di seconda generazione standard. I runtime supportati eseguono implementazioni di linguaggi standard, supportano integrazioni di librerie moderne e offrono prestazioni di networking più rapide e solide.

Utilizza VPC diretto in uscita per una velocità effettiva di traffico di rete in uscita più elevata

Per ottenere una velocità effettiva più elevata nelle connessioni di rete in uscita, utilizza il VPC diretto per il traffico in uscita per instradare il traffico attraverso la tua rete VPC.

Esempio 1: traffico esterno verso internet

Se invii traffico esterno alla rete internet pubblica, instrada tutto il traffico attraverso la rete VPC impostando il campo vpc_egress su all-traffic nel file app.yaml. Con questo approccio, devi configurare Cloud NAT per raggiungere la rete internet pubblica.

Per configurare Cloud NAT per il tuo servizio App Engine, consulta Configura un indirizzo IP in uscita statico. Per le impostazioni del gateway Cloud NAT da utilizzare con l'accesso VPC diretto per Public NAT o Private NAT, consulta Interazioni dell'accesso VPC diretto di Cloud NAT.

Esempio 2: traffico interno verso un'API di Google

Se utilizzi il traffico in uscita VPC diretto per inviare traffico a un'API di Google, ad esempio Cloud Storage, scegli una delle seguenti opzioni:

  • Specifica private-ranges-only (predefinito) con Accesso privato Google:
    1. Imposta vpc_egress: private-ranges-only nel file app.yaml.
    2. Abilita l'accesso privato Google.
    3. Configura il DNS per l'accesso privato Google. Assicurati che il dominio di destinazione (ad esempio storage.googleapis.com) sia mappato a uno dei seguenti intervalli di indirizzi IP interni:
      • 199.36.153.8/30
      • 199.36.153.4/30
  • Specifica all-traffic con l'accesso privato Google:
    1. Imposta vpc_egress: all-traffic nel file app.yaml.
    2. Abilita l'accesso privato Google.

Utilizza l'impostazione MTU predefinita per App Engine

Non modificare l'impostazione dell'unità massima di trasmissione (MTU) di una rete VPC quando la utilizzi con App Engine. Utilizza invece la MTU predefinita di 1460 byte.

Considerazioni sui costi

Quando configuri le opzioni di networking per le tue risorse, tieni presente quanto segue:

  • Colloca le risorse: prova a eseguire il deployment delle risorse App Engine nella stessa regione dei database di backend, ad esempio Cloud SQL, Firestore e i bucket Cloud Storage. Il trasferimento di dati tra risorse Google Cloud all'interno della stessa regione è senza costi.
  • Passa al VPC diretto in uscita: se instradi il traffico in modo sicuro alle risorse di rete VPC interne, valuta la possibilità di passare al VPC diretto in uscita dai connettori di accesso VPC serverless. Il VPC diretto in uscita non comporta addebiti per il computing di base, eliminando l'overhead di computing di base e i costi di inattività associati alle istanze del connettore.
  • Utilizza Cloud CDN: esegui l'offload degli asset statici e dei contenuti altamente memorizzabili nella cache posizionando Cloud CDN davanti alle risorse App Engine. La pubblicazione dei dati dall'edge è molto più economica rispetto al pagamento del traffico in uscita verso internet standard direttamente da App Engine. Non puoi abilitare Cloud CDN direttamente sull'URL appspot.com predefinito. Invece, instrada le richieste tramite un bilanciatore del carico delle applicazioni esterno con un backend del gruppo di endpoint di rete (NEG) serverless. Per saperne di più, consulta Configura un bilanciatore del carico delle applicazioni esterno globale con App Engine.
  • Monitora il traffico in uscita verso internet: il traffico in uscita che attraversa i confini della regione o va verso la rete internet pubblica comporta addebiti standard. Concentra le tue attività di monitoraggio sul traffico in uscita che attraversa i confini della regione.

Per saperne di più, consulta i prezzi di App Engine o stima i costi con il Calcolatore prezzi.

Passaggi successivi