Cloud Functions es regional, lo que significa que la infraestructura que lo ejecuta se ubica en una región específica y Google la administra para que esté disponible de manera redundante en todas las zonas de esa región.
Cuando selecciones la región en la que ejecutarás Cloud Functions, las consideraciones principales deben ser la latencia y la disponibilidad. Por lo general, puedes seleccionar la región más cercana a la de los usuarios de tu función de Cloud Functions, pero también debes considerar la ubicación de los otros productos y servicios de Google Cloud que tu aplicación usa. El uso de servidores en varias ubicaciones puede afectar la latencia de la aplicación y los precios.
Cloud Functions está disponible con precios de nivel 1 en las siguientes regiones:
us-central1(Iowa)us-east1(Carolina del Sur)us-east4(Virginia del Norte)europe-west1(Bélgica)europe-west2(Londres)asia-east2(Hong Kong)asia-northeast1(Tokio)asia-northeast2(Osaka)
Cloud Functions está disponible con precios de nivel 2 en las siguientes regiones:
europe-west3(Fráncfort)europe-west6(Zúrich)us-west3(Salt Lake City)northamerica-northeast1(Montreal)australia-southeast1(Sídney)us-west2(Los Ángeles)us-west4(Las Vegas)southamerica-east1São Pauloasia-south1(Bombay)asia-southeast2(Yakarta)asia-northeast3(Seúl)
Puedes implementar funciones en regiones diferentes en un proyecto, pero una vez que hayas seleccionado la región para una función, no la puedes cambiar.
Las funciones en una región o proyecto determinados deben tener un nombre único (distinción entre mayúsculas y minúsculas), pero las funciones entre regiones o proyectos pueden compartir el mismo nombre.
Ten en cuenta que puedes recuperar el conjunto de ubicaciones más reciente de manera programática con el método project.locations/list de la API de Cloud Functions.
Selecciona la región
Puedes seleccionar una región para tu función durante la implementación.
gcloud
Con la herramienta de línea de comandos de gcloud, utiliza la marca --region para especificar la región. Por ejemplo:
gcloud functions deploy FUNCTION_NAME --region REGION FLAGS...
Donde REGION es una de las regiones enumeradas anteriormente.
En el ejemplo anterior, FLAGS... se refiere a los otros argumentos que pasas durante la implementación de tu función. Para obtener una referencia completa del comando deploy, consulta gcloud functions deploy.
Console
Con Cloud Console, puedes seleccionar la región cuando creas y cuando implementas una función.
En Cloud Console, ve a la página de descripción general de Cloud Functions.
Ir a la página con la descripción general de Cloud Functions
Asegúrate de que el proyecto para el que habilitaste Cloud Functions esté seleccionado.
Haz clic en Crear función.
Expande el menú Más.
En Región, selecciona tu región.
Configura una región predeterminada
Puedes establecer una región predeterminada con la herramienta de línea de comandos de gcloud de la siguiente manera:
gcloud config set functions/region REGION
Por ejemplo:
gcloud config set functions/region europe-west1
Residencia de datos
Cloud Functions ofrece una garantía de residencia de datos en el alcance de la ejecución de la función (Cumplimiento de alcance A, ejecución de funciones), en la que una función determinada proporciona residencia de datos para la invocación y ejecución de funciones.
Este cumplimiento se aplica a las funciones de HTTP y las funciones en segundo plano. Para las funciones en segundo plano, Cloud Functions cumple con los requisitos de residencia de datos desde el momento en que el producto ascendente (producto en activación) entrega el evento a Cloud Functions. Por lo tanto, es importante garantizar que el producto ascendente (como Cloud Storage o Pub/Sub) cumpla con la residencia de datos.
Prácticas recomendadas para el cambio de región
Si necesitas cambiar una región en la que se implementa la función, sigue las recomendaciones que aparecen a continuación.
Funciones de HTTP
Para las funciones de HTTP, recomendamos que primero vuelvas a implementar tu función de ese tipo en la región de destino (puede tener el mismo nombre) y, luego, alteres tu función original para redireccionar su solicitud HTTP a la función nueva. Si los clientes de tu función de HTTP admiten redireccionamientos, simplemente cambia tu función original para volver a un estado de redireccionamiento de HTTP (301), además de la URL de tu función nueva. Si tus clientes no controlan de buena forma los redireccionamientos, puedes realizar la solicitud mediante un proxy desde la función original hasta la función nueva si inicias una solicitud nueva desde la función original hasta la función nueva. El paso final es asegurarse de que todos los clientes llaman a la función nueva.
Funciones en segundo plano
Las funciones en segundo plano adoptan una semántica de entrega de eventos “al menos una vez”, lo que significa que reciben eventos duplicados en circunstancias determinadas y, por lo tanto, siempre se deben implementar para ser idempotentes. Si tu función ya es idempotente, simplemente puedes volver a implementarla en la región nueva con el mismo activador de eventos y quitar la función antigua después de que verifiques que la nueva recibe tráfico de forma correcta. Durante esta transición ambas funciones recibirán eventos.
Si tu función no es idempotente, o si su idempotencia no va más allá de la región, te recomendamos que primero implementes la idempotencia antes de mover la función.