Esta página se ha traducido con Cloud Translation API.

Crear despliegues multirregionales para API Gateway

En este tutorial se muestra cómo configurar un balanceador de carga HTTP(S) para habilitar las implementaciones multirregión en API Gateway.

Crear un balanceador de carga HTTP(S) para admitir implementaciones multirregión de API Gateway puede mejorar la disponibilidad y reducir la latencia de tu servicio, ya que se sirve 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 sirve las solicitudes desde la región disponible más cercana a tu usuario.

En este tutorial, configurará un único esquema de URL no regional que funcionará en cualquier parte del mundo, pero que atenderá las solicitudes de los usuarios desde la implementación de API Gateway más cercana. Con esta configuración, las solicitudes se dirigen a la región que ofrece la latencia mínima al usuario. Si la región más cercana no está disponible o está sobrecargada, la solicitud se dirige a otra región para garantizar la disponibilidad.

Antes de empezar

Antes de configurar tu implementación multirregión, sigue la guía de inicio rápido de API Gateway para desplegar un servicio de Cloud Run y crear una pasarela que apunte a ese servicio.

En este tutorial, desplegarás tu servicio en dos regiones diferentes. Por ejemplo, puedes desplegar dos instancias de API Gateway:

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

Configurar permisos

En este tutorial, crearás un grupo de endpoints de red (NEG) sin servidor y un balanceador de carga HTTP(S) externo en un proyecto de Cloud. Para ello, debes tener el rol de propietario o editor del proyecto, o los siguientes roles de gestión de identidades y accesos de Compute Engine:

Tarea	Rol obligatorio
Crear balanceadores de carga y componentes de red	Administrador de red
Crear y modificar grupos de puntos de conexión de red	Administrador de instancias de Compute
Crear y modificar certificados SSL	Administrador de seguridad

Crear un recurso de certificado SSL

Para crear un balanceador de carga HTTPS, se debe añadir un recurso de certificado SSL al frontend del balanceador de carga. Crea un recurso de certificado SSL con un certificado SSL gestionado por Google o un certificado SSL autogestionado.

Certificados gestionados por Google. Te recomendamos que uses certificados gestionados por Google porque Google Cloud obtiene, gestiona y renueva estos certificados automáticamente. Para crear un certificado gestionado por Google, debes tener un dominio y los registros DNS de ese dominio para que se pueda aprovisionar el certificado. Si aún no tienes un dominio, puedes obtener uno en Google Domains. Además, tendrás que actualizar el registro A de DNS del dominio para que apunte a la dirección IP del balanceador de carga que se creará en un paso posterior. Para obtener instrucciones detalladas, consulta Usar certificados gestionados por Google.
Certificados autofirmados. Si no quieres configurar un dominio en este momento, puedes usar un certificado SSL autofirmado para hacer pruebas.

En este tutorial se da por hecho que ya has creado un recurso de certificado SSL.

Si quieres probar este proceso sin crear un recurso de certificado SSL (o un dominio, como requieren los certificados gestionados por Google), puedes seguir las instrucciones de esta página para configurar un balanceador de carga HTTP.

Crear el balanceador de carga HTTP(S)

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

Un grupo de puntos finales de red (NEG) especifica un grupo de endpoints de backend para un balanceador de carga. Un NEG sin servidor es un backend que apunta a un servicio como API Gateway, tal como se muestra en la siguiente figura:

Para crear un NEG sin servidor para cada instancia de pasarela, ejecuta el siguiente comando:
- SERVERLESS_NEG_NAME es el nombre del NEG sin servidor que se va a crear.
- GATEWAY_ID especifica el nombre de la pasarela.
- REGION_ID es la región de despliegue del NEG sin servidor (debe coincidir con la región de la pasarela).
```
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 para crear un NEG sin servidor para la siguiente instancia de la pasarela. Usa los valores adecuados para la segunda instancia de la pasarela. 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 distribuye el tráfico Cloud Load Balancing.

La configuración del servicio de backend contiene un conjunto de valores, como el protocolo usado para conectarse a los backends, varios ajustes de distribución y de sesión, comprobaciones de estado y tiempos de espera, tal como se muestra en la siguiente figura:

Para crear un servicio de backend y añadir tu NEG sin servidor como backend al servicio de backend, ejecuta los siguientes comandos, donde:
- BACKEND_SERVICE_NAME es el nombre de tu servicio de backend.
- SERVERLESS_NEG_NAME es el nombre del NEG sin servidor creado en el paso anterior.
- REGION_ID es la región de despliegue del NEG sin servidor (debe coincidir con la región de la pasarela).
```
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 para añadir el segundo NEG sin servidor al servicio de backend. Usa los valores adecuados para el segundo NEG sin servidor. Por ejemplo, api-gateway-serverless-neg-us para my-gateway-us en la región us-central1.
Crea un mapa de URLs para enrutar las solicitudes entrantes al servicio de backend, como se muestra en la siguiente figura:

Para crear el mapa de URLs, ejecuta el siguiente comando:
- URL_MAP_NAME es el nombre del mapa de URLs que se va a 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 URLs de ejemplo solo tiene como destino un servicio de backend que representa una única pasarela, por lo que no se necesitan reglas de host ni matchers de ruta. Si tienes más de un servicio de backend, puedes usar reglas de host para dirigir las solicitudes a diferentes servicios en función del nombre de host. Usa matchers de ruta para dirigir las solicitudes a diferentes servicios en función de 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 matchers de ruta, consulta la documentación sobre mapas de URLs.
Crea un certificado SSL para tu proxy de destino, tal como se muestra en la siguiente figura:

Para crear un balanceador de carga HTTPS, se necesita un recurso de certificado SSL para el proxy HTTPS de destino. Puedes crear un recurso de certificado SSL con un certificado SSL gestionado por Google o con un certificado SSL autogestionado. Te recomendamos que uses certificados gestionados por Google.

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

Para crear un recurso de certificado SSL gestionado por Google, sigue estos pasos:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
  --domains DOMAIN
```
Para crear un recurso de certificado SSL autogestionado, sigue estos pasos:
```
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 URLs, como se muestra en la siguiente figura:

Para crear el proxy de destino, usa el siguiente comando:
- TARGET_HTTP_PROXY_NAME es el nombre del proxy de destino que se va a crear.
- URL_MAP_NAME es el nombre del mapa de URLs 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 dirigir las solicitudes entrantes al proxy, como se muestra en la siguiente figura:

Usa el siguiente comando para crear la regla de reenvío, donde:
- HTTPS_FORWARDING_RULE_NAME es el nombre de la regla que se va a crear.
- TARGET_HTTP_PROXY_NAME es el nombre del proxy de destino que se va a 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
```

Actualizar los registros DNS con la dirección IP del balanceador de carga

Si tienes un dominio personalizado, debes seguir este paso para configurar los ajustes de DNS de tu dominio de forma que apunten a la nueva dirección IP de tu servicio. También es necesario si has creado un balanceador de carga HTTP(S) con un certificado gestionado por Google (que requiere un dominio). Se recomienda asignar y usar una dirección IP estática cuando se usa con DNS. Las instrucciones específicas de este paso dependen de tu proveedor de DNS.

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

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 de DNS de tu dominio para que dirija a la dirección IP del balanceador de carga. De esta forma, el tráfico enviado a la URL del dominio personalizado se enrutará a través del balanceador de carga. El DNS puede tardar desde unos segundos hasta varias horas en propagar este cambio al servidor DNS.
Haz una prueba para confirmar que tu pasarela recibe tráfico mediante curl o visitando la URL en tu navegador. Por ejemplo: https://my-app-domain

Después de hacer las pruebas, deberías ver la respuesta generada por el servicio de Cloud Run. Por ejemplo, puede ser una página HTML "Hola, mundo" u otra respuesta esperada generada directamente por el servicio backend. Esto significa que tu solicitud está pasando por el balanceador de carga y que el servicio de backend está indicando al balanceador de carga que la envíe a tu pasarela.

Cuestiones importantes

Antes de implementar un despliegue multirregional de API Gateway, tenga en cuenta lo siguiente:

Actualmente, API Gateway no admite comprobaciones de estado. Con la configuración de enrutamiento entre regiones descrita anteriormente, si tu pasarela o su servicio backend devuelven errores en una región, pero la infraestructura general de API Gateway de la región está disponible y tiene capacidad, tu balanceador de carga HTTP(S) no dirigirá el tráfico a otras regiones.
Para combinar diferentes regiones en una sola regla de reenvío, se necesita la tarifa del nivel Premium. Para obtener más información sobre cómo calcular los precios y el uso, consulta los precios de Niveles de servicio de red.

Prácticas recomendadas

Cuando se usa el servicio multirregión, recomendamos usar una solución de almacenamiento de datos gestionada y replicada a nivel mundial, como Cloud Spanner, para asegurarse de que todos los datos se gestionen a nivel mundial.