Questa pagina è stata tradotta dall'API Cloud Translation.

Creazione di deployment in più regioni per API Gateway

Questo tutorial mostra come configurare un bilanciatore del carico HTTP(S) per abilitare i deployment multiregione per API Gateway.

La creazione di un bilanciatore del carico HTTP(S) per supportare gli implementazioni multi-regione di API Gateway può migliorare la disponibilità e ridurre la latenza del servizio pubblicandolo da più di una regione. Puoi ridurre ulteriormente la latenza e massimizzare il tempo di attività con il routing tra regioni, che serve le richieste dalla regione disponibile più vicina all'utente.

Ai fini di questo tutorial, configurerai un singolo schema URL non regionale che funzioni in qualsiasi parte del mondo, ma che gestisca le richieste degli utenti dal deployment di API Gateway più vicino. Con questa configurazione, le richieste vengono indirizzate idealmente alla regione che offre una latenza minima all'utente. Se la regione più vicina non è disponibile o ha superato la capacità, la richiesta viene inoltrata a una regione diversa per garantire la disponibilità.

Prima di iniziare

Prima di configurare il deployment multiregione, segui la guida rapida di API Gateway per eseguire il deployment di un servizio Cloud Run e creare un gateway che rimandi a quel servizio.

Per questo tutorial, esegui il deployment del servizio in due regioni diverse. Ad esempio, puoi eseguire il deployment di due istanze API Gateway:

my-gateway-eu a una regione in Europa
my-gateway-us a una regione degli Stati Uniti

Configura autorizzazioni

In questo tutorial, creerai un gruppo di endpoint di rete (NEG) serverless e un bilanciatore del carico HTTP(S) esterno in un progetto Cloud. Per farlo, devi disporre del ruolo Proprietario o Editor del progetto oppure dei seguenti ruoli IAM di Compute Engine:

Attività	Ruolo richiesto
Crea componenti di bilanciamento del carico e di rete	Amministratore di rete
Creare e modificare i NEG	Amministratore istanze Compute
Crea e modifica i certificati SSL	Amministratore della sicurezza

Crea una risorsa del certificato SSL

Per creare un bilanciatore del carico HTTPS, è necessario aggiungere una risorsa del certificato SSL al frontend del bilanciatore del carico. Crea una risorsa del certificato SSL utilizzando un certificato SSL gestito da Google o un certificato SSL con gestione indipendente.

Certificati gestiti da Google. Ti consigliamo di utilizzare i certificati gestiti da Google perché Google Cloud li ottiene, li gestisce e li rinnova automaticamente. Per creare un certificato gestito da Google, devi disporre di un dominio e dei relativi record DNS per poter eseguire il provisioning del certificato. Se non hai ancora un dominio, puoi acquistarne uno da Google Domains. Inoltre, dovrai aggiornare il record DNS A del dominio in modo che indichi l'indirizzo IP del bilanciatore del carico creato in un passaggio successivo. Per istruzioni dettagliate, vedi Utilizzare i certificati gestiti da Google.
Certificati autofirmati. Se al momento non vuoi configurare un dominio, puoi utilizzare un certificato SSL autofirmato per i test.

Questo tutorial presuppone che tu abbia già creato una risorsa del certificato SSL.

Se vuoi testare questa procedura senza creare una risorsa del certificato SSL (o un dominio come richiesto dai certificati gestiti da Google), puoi comunque utilizzare le istruzioni riportate in questa pagina per configurare un bilanciatore del carico HTTP.

Crea il bilanciatore del carico HTTP(S)

Crea un NEG serverless per ogni istanza 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 servizio come API Gateway, come mostrato nella figura seguente:

Per creare un NEG serverless per ogni istanza di gateway, esegui il seguente comando, dove:
- SERVERLESS_NEG_NAME è il nome del NEG serverless da creare.
- GATEWAY_ID specifica il nome del gateway.
- REGION_ID è la regione di deployment del NEG serverless (deve corrispondere alla regione del gateway).
```
gcloud beta compute network-endpoint-groups create SERVERLESS_NEG_NAME \
  --region=REGION_ID \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=GATEWAY_ID
```
Ad esempio:
```
gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg-eu \
  --region=europe-west1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway-eu
```
Ripeti questo comando per creare un NEG serverless per la successiva istanza di gateway, utilizzando i valori appropriati per la seconda istanza di gateway, ad esempio api-gateway-serverless-neg-us per my-gateway-us nella regione us-central1.
Crea un servizio di backend per definire la modalità di distribuzione del traffico da parte di Cloud Load Balancing.

La configurazione del servizio di backend contiene un insieme di valori, ad esempio il protocollo utilizzato per connettersi ai backend, varie impostazioni di distribuzione e sessione, controlli di integrità e timeout, come mostrato nella figura seguente:

Per creare un servizio di backend e aggiungere il NEG serverless come backend al servizio di backend, esegui i seguenti comandi, dove:
- BACKEND_SERVICE_NAME è il nome del servizio di backend.
- SERVERLESS_NEG_NAME è il nome del gruppo di elenchi di negazioni serverless creato nel passaggio precedente.
- REGION_ID è la regione di deployment del NEG serverless (deve corrispondere alla regione del gateway).
```
gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --global \ 
```
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \ 
  --network-endpoint-group=SERVERLESS_NEG_NAME \
  --network-endpoint-group-region=REGION_ID
```
Ad esempio:
```
gcloud compute backend-services add-backend api-gateway-backend-service \
  --global \
  --network-endpoint-group=api-gateway-serverless-neg-eu \
  --network-endpoint-group-region=europe-west1
```
Ripeti questo comando per aggiungere il secondo NEG serverless al servizio di backend, utilizzando i valori appropriati per il secondo NEG serverless, ad esempio api-gateway-serverless-neg-us per my-gateway-us nella regione us-central1.
Crea una mappa URL per instradare le richieste in entrata al servizio di backend, come mostrato nella figura seguente:

Per creare la mappa di URL, esegui il seguente comando, dove:
- URL_MAP_NAME è il nome della mappa URL da creare.
- BACKEND_SERVICE_NAME è il nome del servizio di backend.
```
gcloud compute url-maps create URL_MAP_NAME \
  --default-service BACKEND_SERVICE_NAME
```
Ad esempio:
```
gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service
```
Questa mappa URL di esempio ha come target un solo servizio di backend che rappresenta un singolo gateway, pertanto non sono necessarie regole host o corrispondenze di percorso. Se hai più di un servizio di backend, puoi utilizzare le regole host per indirizzare le richieste a servizi diversi in base al nome host. Utilizza i corrispondenti dei percorsi per indirizzare le richieste a servizi diversi in base al percorso della richiesta.

Ad esempio:
```
gcloud compute url-maps add-path-matcher api-gateway-url-map \
  --path-matcher-name=my-pm2  \
  --default-service=my-host-default-backend \
  --path-rules="/video=video-service,/video/*=video-service" \
  --new-hosts my-hosts.com
```
```
gcloud compute url-maps add-host-rule api-gateway-url-map \
  --hosts=my-app-domain \
  --path-matcher-name=my-app-path-matcher
```
Per scoprire di più sulle regole host e sui corrispondenti dei percorsi, consulta la documentazione della mappa URL.
Crea un certificato SSL per il proxy di destinazione, come mostrato nella figura seguente:

Per creare un bilanciatore del carico HTTPS, è necessaria una risorsa certificato SSL per il proxy di destinazione HTTPS. Puoi creare una risorsa del certificato SSL utilizzando un certificato SSL gestito da Google o un certificato SSL autogestito. Ti consigliamo di utilizzare i certificati gestiti da Google.

Per creare un certificato gestito da Google, devi avere un dominio. Se non hai un dominio, puoi utilizzare un certificato SSL autofirmato per i test.

Per creare una risorsa del certificato SSL gestita da Google:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
  --domains DOMAIN
```
Per creare una risorsa del certificato SSL autogestita:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
  --certificate CRT_FILE_PATH \
  --private-key KEY_FILE_PATH
```
Crea un proxy HTTP(S) di destinazione per instradare le richieste alla mappa URL, come mostrato nella figura seguente:

Per creare il proxy target, utilizza il seguente comando, in cui:
- TARGET_HTTP_PROXY_NAME è il nome del proxy di destinazione da creare.
- URL_MAP_NAME è il nome della mappa URL creata in un passaggio precedente.
- (Facoltativo) SSL_CERT_NAME è il nome del certificato SSL creato.
```
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME
  --url-map=URL_MAP_NAME
```
Ad esempio:
```
gcloud compute target-http-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert
  --url-map=api-gateway-url-map
```
Crea una regola di forwarding per instradare le richieste in entrata al proxy, come mostrato nella figura seguente:

Utilizza il seguente comando per creare la regola di forwarding, dove:
- HTTPS_FORWARDING_RULE_NAME è il nome della regola da creare.
- TARGET_HTTP_PROXY_NAME è il nome del proxy di destinazione da creare.
```
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
  --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
  --global \
  --ports=443
```
Ad esempio:
```
gcloud compute forwarding-rules create my-fw \
  --target-https-proxy=api-gateway-https-proxy \
  --global \
  --ports=443
```

Aggiorna i record DNS con l'indirizzo IP del bilanciatore del carico

Se hai un dominio personalizzato, questo passaggio è necessario per configurare le impostazioni DNS in modo che il dominio indichi il nuovo indirizzo IP del servizio. È necessario anche se hai creato un bilanciatore del carico HTTP(S) con un certificato gestito da Google (che richiede un dominio). Ti consigliamo di allocare e utilizzare un indirizzo IP statico se lo utilizzi con il DNS. Le istruzioni specifiche per questo passaggio dipendono dal tuo provider DNS.

Per inviare il traffico al bilanciatore del carico, il record DNS del tuo dominio (in questo tutorial, my-app-domain) deve puntare agli indirizzi IP del bilanciatore del carico.

Per trovare l'indirizzo IP della regola di forwarding globale, utilizza questo comando:
```
gcloud compute forwarding-rules list
```
Aggiorna il record DNS A o AAAA del tuo dominio in modo che rimandi all'indirizzo IP del bilanciatore del carico, in modo che il traffico inviato all'URL del dominio personalizzato esistente venga instradato tramite il bilanciatore del carico. La propagazione di questa modifica al server DNS potrebbe richiedere da alcuni secondi a diverse ore.
Verifica che il gateway riceva traffico utilizzando curl o visitando l'URL nel browser. Ad esempio: https://my-app-domain

Al termine del test, dovresti vedere la risposta generata dal servizio Cloud Run. Ad esempio, potrebbe trattarsi di una pagina HTML "Hello World" o di un'altra risposta prevista generata direttamente dal servizio di backend. Ciò significa che la richiesta passa attraverso il bilanciatore del carico e il servizio di backend indica al bilanciatore del carico di inviarla al gateway.

Considerazioni

Prima di implementare un deployment multiregione di API Gateway, tieni presente quanto segue:

Al momento API Gateway non supporta i controlli di integrità. Con la configurazione di routing tra regioni descritta sopra, se il gateway o il relativo servizio di backend restituisce errori in una regione, ma l'infrastruttura complessiva di API Gateway nella regione è disponibile e ha capacità, il bilanciatore del carico HTTP(S) non reindirizzerà il traffico ad altre regioni.
La combinazione di regioni diverse in un'unica regola di forwarding richiede i prezzi del livello Premium. Per ulteriori informazioni sul calcolo dei prezzi e dell'utilizzo, consulta Prezzi di Network Service Tiers.

Best practice

Quando utilizzi la pubblicazione in più regioni, ti consigliamo di utilizzare una soluzione di archiviazione dei dati gestita replicata a livello globale, come Cloud Spanner, per assicurarti che tutti i dati vengano gestiti a livello globale.