Crea implementaciones multirregionales para API Gateway

En este instructivo, se muestra cómo configurar un balanceador de cargas de HTTP(S) a fin de habilitar las implementaciones multirregionales para API Gateway.

Crear un balanceador de cargas HTTP(S) para admitir implementaciones multirregionales de API Gateway puede mejorar la disponibilidad y disminuir la latencia de tu servicio mediante la entrega desde más de una región. Puedes minimizar aún más la latencia y maximizar el tiempo de actividad con el enrutamiento entre regiones, que entrega solicitudes desde la región disponible más cercana al usuario.

A los fines de este instructivo, configurarás un esquema de URL único y no regional que funcione en cualquier lugar del mundo, pero que entregue solicitudes de usuarios desde la implementación de API Gateway más cercana. Con esta configuración, lo ideal es que las solicitudes se enruten a la región que proporciona una latencia mínima al usuario. En caso de que la región más cercana no esté disponible o supere su capacidad, la solicitud se enruta a una región diferente para garantizar la disponibilidad.

Antes de comenzar

Antes de configurar la implementación multirregión, sigue la Guía de inicio rápido de API Gateway para implementar un servicio de Cloud Run y crear una puerta de enlace que apunte a ese servicio.

Para este instructivo, implementa el servicio en dos regiones diferentes. Por ejemplo, puedes implementar dos instancias de API Gateway:

my-gateway-eu a una región de Europa
my-gateway-us a una región de EE.UU.

Configura permisos

En este instructivo, crearás un grupo de extremos de red (NEG) sin servidores y un balanceador de cargas de HTTP(S) externo en un proyecto de Cloud. Esto requiere una función de propietario o editor del proyecto o las siguientes funciones de IAM de Compute Engine:

Tarea	Función requerida
Crear balanceador de cargas y componentes de herramientas de redes	Administrador de redes
Crear y modificar los NEG	Administrador de instancias de procesamiento
Crear y modificar certificados SSL	Administrador de seguridad

Crea un recurso de certificado SSL

Para crear un balanceador de cargas de HTTPS, se debe agregar un recurso de certificado SSL al frontend del balanceador de cargas. Crea un recurso de certificado SSL mediante un certificado SSL administrado por Google o un certificado SSL autoadministrado.

Certificados administrados por Google. Se recomienda usar certificados administrados por Google, ya que Google Cloud obtiene, administra y renueva estos certificados de manera automática. Si quieres crear un certificado administrado por Google, debes tener un dominio y los registros DNS para ese dominio a fin de que se aprovisione el certificado. Si aún no tienes un dominio, puedes obtener uno en Google Domains. Además, deberás actualizar el registro DNS A del dominio para que apunte a la dirección IP del balanceador de cargas creada en un paso posterior. Para obtener instrucciones detalladas, consulta Usa certificados administrados por Google.
Certificados autofirmados. Si no deseas configurar un dominio en este momento, puedes usar un certificado SSL autofirmado para realizar una prueba.

En este instructivo se supone que ya creaste un recurso de certificado SSL.

Si quieres probar este proceso sin crear un recurso de certificado SSL (o un dominio requerido por los certificados administrados por Google), puedes seguir las instrucciones de esta página para configurar un balanceador de cargas de HTTP en su lugar.

Crea el balanceador de cargas HTTP(S)

Crea un NEG sin servidores para cada instancia de API Gateway.

Un grupo de extremos de red (NEG) especifica un grupo de extremos de backend para un balanceador de cargas. Un NEG sin servidores es un backend que apunta a un servicio como API Gateway, como se muestra en la siguiente figura:

Si quieres crear un NEG sin servidores para cada instancia de puerta de enlace, ejecuta el siguiente comando, en el que sucede lo siguiente:
- SERVERLESS_NEG_NAME es el nombre del NEG sin servidores que se creará.
- GATEWAY_ID especifica el nombre de la puerta de enlace.
- REGION_ID es la región de implementación para el NEG sin servidores (debe coincidir con la región de la puerta de enlace).
```
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
```
Por ejemplo:
```
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
```
Repite este comando a fin de crear un NEG sin servidores para la siguiente instancia de puerta de enlace con los valores adecuados de la segunda instancia de puerta de enlace, por ejemplo, api-gateway-serverless-neg-us para my-gateway-us en la región us-central1.
Crea un servicio de backend para definir cómo Cloud Load Balancing distribuye el tráfico.

La configuración del servicio de backend contiene un conjunto de valores, como el protocolo que se usa para conectarse a los backends, varios parámetros de configuración de distribución y sesión, verificaciones de estado y tiempos de espera, como se muestra en la siguiente figura:

Para crear un servicio de backend y agregar tu NEG sin servidores como un backend al servicio de backend, ejecuta los siguientes comandos, en los que sucede lo siguiente:
- BACKEND_SERVICE_NAME es el nombre de tu servicio de backend.
- SERVERLESS_NEG_NAME es el nombre del NEG sin servidores que se creó en el paso anterior.
- REGION_ID es la región de implementación para el NEG sin servidores (debe coincidir con la región de la puerta de enlace).
```
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
```
Por ejemplo:
```
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
```
Repite este comando a fin de agregar el segundo NEG sin servidores al servicio de backend con los valores adecuados para el segundo NEG sin servidores, por ejemplo, api-gateway-serverless-neg-us para my-gateway-us en la región us-central1.
Crea un mapa de URL para enrutar las solicitudes entrantes al servicio de backend, como se muestra en la siguiente figura:

Para crear el mapa de URL, ejecuta el siguiente comando, en el que sucede lo siguiente:
- URL_MAP_NAME es el nombre del mapa de URL que se creará.
- BACKEND_SERVICE_NAME es el nombre de tu servicio de backend.
```
gcloud compute url-maps create URL_MAP_NAME \
  --default-service BACKEND_SERVICE_NAME
```
Por ejemplo:
```
gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service
```
Este mapa de URL de ejemplo solo se orienta a un servicio de backend que representa una única puerta de enlace, por lo que no se requieren reglas de host ni comparadores de rutas de acceso. Si tienes más de un servicio de backend, puedes usar las reglas de host para dirigir las solicitudes a diferentes servicios según el nombre del host. Usa comparadores de rutas de acceso para dirigir las solicitudes a diferentes servicios según la ruta de la solicitud.

Por ejemplo:
```
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
```
Para obtener más información sobre las reglas de host y los comparadores de rutas de acceso, consulta la documentación de Mapa de URL.
Crea un certificado SSL para tu proxy de destino, como se muestra en la siguiente figura:

Si quieres crear un balanceador de cargas HTTPS, se requiere un recurso de certificado SSL para el proxy HTTPS de destino. Puedes crear un recurso de certificado SSL mediante un certificado SSL administrado por Google o un certificado SSL autoadministrado. Se recomienda usar certificados administrados por Google.

Para crear un certificado administrado por Google, debes tener un dominio. Si no tienes un dominio, puedes usar un certificado SSL autofirmado para las pruebas.

Si deseas crear un recurso de certificado SSL administrado por Google, haz lo siguiente:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
  --domains DOMAIN
```
Si deseas crear un recurso de certificado SSL autoadministrado, haz lo siguiente:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
  --certificate CRT_FILE_PATH \
  --private-key KEY_FILE_PATH
```
Crea un proxy HTTP(S) de destino para enrutar las solicitudes a tu mapa de URL, como se muestra en la siguiente figura:

Para crear el proxy de destino, usa el siguiente comando, en el que sucede lo siguiente:
- TARGET_HTTP_PROXY_NAME es el nombre del proxy de destino que se creará.
- URL_MAP_NAME es el nombre del mapa de URL creado en un paso anterior.
- Opcional: SSL_CERT_NAME es el nombre del certificado SSL creado.
```
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME
  --url-map=URL_MAP_NAME
```
Por ejemplo:
```
gcloud compute target-http-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert
  --url-map=api-gateway-url-map
```
Crea una regla de reenvío para enrutar las solicitudes entrantes al proxy, como se muestra en la siguiente figura:

Usa el siguiente comando para crear la regla de reenvío, en la que sucede lo siguiente:
- HTTPS_FORWARDING_RULE_NAME es el nombre de la regla que se creará.
- TARGET_HTTP_PROXY_NAME es el nombre del proxy de destino que se creará.
```
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
  --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
  --global \
  --ports=443
```
Por ejemplo:
```
gcloud compute forwarding-rules create my-fw \
  --target-https-proxy=api-gateway-https-proxy \
  --global \
  --ports=443
```

Actualiza los registros DNS con la dirección IP del balanceador de cargas

Si tienes un dominio personalizado, debes realizar este paso para establecer la configuración de DNS de tu dominio de modo que apunte a la nueva dirección IP de tu servicio. También es necesaria si creaste un balanceador de cargas HTTP(S) con un certificado administrado por Google (que requiere un dominio). Se recomienda asignar y usar una dirección IP estática cuando se utiliza con DNS. Las instrucciones específicas para este paso dependen de tu proveedor de DNS.

Para enviar tráfico al balanceador de cargas, el registro DNS de tu dominio (en este instructivo, my-app-domain) debe apuntar a las direcciones IP del balanceador de cargas.

Para encontrar la dirección IP de tu regla de reenvío global, usa este comando:
```
gcloud compute forwarding-rules list
```
Actualiza el registro A o AAAA del DNS de tu dominio para que apunte a la dirección IP del balanceador de cargas a fin de que el tráfico enviado a la URL del dominio personalizado existente se enrute a través del balanceador de cargas. El DNS puede tardar varios segundos o varias horas en propagar este cambio al servidor DNS.
Realiza una prueba para confirmar que la puerta de enlace recibe tráfico con curl o visitando la URL en el navegador. Por ejemplo: https://my-app-domain

Después de realizar las pruebas, deberías ver la respuesta que generó el servicio de Cloud Run. Por ejemplo, puede ser una página HTML de “Hello World” o alguna otra respuesta esperada generada directamente por el servicio de backend. Esto significa que tu solicitud pasará por el balanceador de cargas, y el servicio de backend le indicará al balanceador de cargas que la envíe a tu puerta de enlace.

Consideraciones

Antes de implementar una implementación multirregional de API Gateway, ten en cuenta lo siguiente:

Por el momento, API Gateway no es compatible con las verificaciones de estado. Con la configuración de enrutamiento entre regiones descrita antes, si la puerta de enlace o su servicio de backend muestran errores en una región, pero la infraestructura general de API Gateway en la región está disponible y tiene capacidad, tu balanceador de cargas HTTP(S) no dirigirá el tráfico a otras regiones.
La combinación de diferentes regiones en una sola regla de reenvío requiere precios del nivel Premium. Si quieres obtener más información para calcular los precios y el uso, consulta los precios de los Niveles de servicio de red.

prácticas recomendadas

Cuando uses la entrega multirregional, recomendamos usar una solución de almacenamiento de datos administrada de forma global, como Cloud Spanner, para garantizar que todos los datos se administren de forma global.