Recientemente se ha lanzado la nueva región de Google Cloud Platform (GCP) en Madrid. Esta nueva región trae consigo mejoras generales en latencias y residencia de datos. Llamada, europe-southwest1, es la primera región de los hiperescalares (AWS, Azure, OCI…) con presencia en nuestro país.

Compararemos la diferencias de latencias entre diferentes regiones de GCP y veremos cómo he migrado una serie de buckets de Google Cloud Storage desde Bélgica a Madrid.

Comparativa de latencias

Metodología

Se han creado máquinas virtuales en las siguientes regiones de Google Cloud:

• Bélgica (europe-west1)
• Milán (europe-west8)
• Madrid (europe-southwest1)

Recientemente también se ha lanzado la región de Paris (europe-west9). No se ha incluido debido a que, por su reciente lanzamiento, es improbable que una entidad con interés en España tenga cargas de trabajo en esta región. Lo típico era desplegarlas en Bélgica, que hasta hace unos meses era (junto con Londres y Fráncfort) la región más cercana en latencia a España.

Estas máquinas virtuales, si bien es cierto que el tamaño y familia de esta influye en la capacidad de red, son  de 1vCPU. Para realizar unas pruebas de ping son más que suficiente.

Desde Madrid se han realizado pings hacia estas máquinas.

Resultados

En la siguiente imagen se pueden ver los resultados:

Como se puede ver en la imagen, los resultados son impresionantes.

• Madrid (europe-southwest1): 4ms
• Milán (europe-west8): 23ms
• Bélgica (europe-west1): 24ms

Respecto a la región típica de despliegue para organizaciones asentadas en españa (Bélgica) tenemos ¡una mejora de 20ms! Puede parecer no ser nada, pero para aplicaciones en tiempo es un gran avance. Es un 17% del tiempo previo.

Otros proyectos relevantes

En este sentido también destaca el proyecto GCPing, cuya web está disponible desde este enlace. Al acceder, automáticamente realizará peticiones a instancias de Cloud Run desplegadas en distintas regiones.

Este es el resultado:

Como se puede ver en la captura de los resultados, la diferencia entre las regiones de Madrid y Bélgica/Milán es de 20ms, en consonancia con los resultados obtenidos en nuestra prueba con las máquinas virtuales.

Traslado de datos en GCS

Planteamiento

Existen algunos buckets de Google Cloud Storage (GCS) que uso para el alojamiento y la compartición de recursos. Uno de ellos es:

Este bucket tiene de nombre un subdominio DNS correcto, y está hecho así de forma consciente. Se han seguido estas instrucciones para conectar el dominio. De esta forma, los recursos son servidos desde un dominio personalizado.

De forma nativa, para los dominios personalizados no es soportado el cifrado SSL/TLS, puesto que el endpoint de Storage tendría que emitir y gestionar certificados. Para este fin tenemos la posibilidad de crear un Balanceador de Carga y conectar el bucket (o los buckets) como endpoints.

El objetivo de esta sección es trasladar los recursos desde Bélgica a Madrid para obtener ventajas en latencia y residencia de datos. Esta operación no podemos realizarla de forma automática (cambiando, por ejemplo, con un selector la ubicación del bucket); de hecho, la localización del bucket no se puede cambiar una vez creado. Es necesario recrear el bucket para la modificación de este parámetro.

Solución

En este artículo de ayuda oficial se encuentran los pasos a seguir. La idea de es automatizar los pasos. Nótese que los pasos a seguir, y/o los comandos a ejecutar, son aplicables a mi caso: buckets públicos y con acceso uniforme activado.

Para la gestión de GCP y GCS tenemos disponibles las utilidades gcloud y gsutil. Usando estos comandos se ha generado el siguiente script:

#!/bin/bash

#### Common variables ####
project_id=
bucket_name=public . gonzaleztroyano . es
target_region=europe-southwest1   # see full list executing: gcloud compute regions list
#### Common variables ####

gcloud config set project ${project_id}

gsutil mb -l ${target_region} gs://temp-${bucket_name} 
gsutil cp -r gs://${bucket_name}/* gs://temp-${bucket_name}
gsutil rm -r gs://${bucket_name}

gsutil mb -l ${target_region} gs://${bucket_name}
gsutil cp -r gs://temp-${bucket_name}/* gs://${bucket_name}

gsutil bucketpolicyonly set on gs://${bucket_name}
gsutil iam ch allUsers:objectViewer gs://${bucket_name}

# Descomentar solo si eres valiente:
# gsutil rm -r gs://temp-${bucket_name}

Para ejecutarlo, si bien podemos instalar el SDK de GCP en cualquier equipo, lo mejor es utilizar Cloud Shell, puesto que la integración con nuestro entorno de GCP es automática.

Editamos en este momento las variables en la parte superior del script.

Permitimos la ejecución del script:

chmod u+x gcs-region-updater.sh

Para ejecutarlo basta con:

./gcs-region-updater.sh

El script realizará los siguientes pasos:

1. (Línea 9) Configura el SDK para usar el proyecto indicado.
2. (Línea 11) Crear un bucket en la región seleccionada, con “temp” como comienzo del nombre.
3. (L12) Copiar los recursos entre el bucket original y el creado en el paso anterior. Según la cantidad de recursos pueden ser segundos o días…
4. (L13) Para poder reutilizar el nombre del bucket en Madrid, debemos eliminar el bucket anterior. Si tuviéramos impuestas reglas de retención en el bucket deberíamos eliminarlas para poder borrar los objetos antes de liberar el bucket que los contiene.
5. (L15) Creamos el bucket destino en la región deseada (Madrid, en nuestro caso), reutilizado el nombre.
6. (L16) Copiamos los recursos entre el bucket temporal y el bucket de destino final.
7. (L17) Activamos el acceso uniforme al bucket
8. (L18) Otorgamos acceso de lectura a los objetos para la entidad allUsers, que implica que estos pasan a ser públicos.
9. (L22) Por defecto está comentado al ser una operación peligrosa, pero esta línea eliminaría el bucket temporal.

Resultado

En este momento tendremos dos buckets en Madrid: el bucket original (trasladado) y el temporal. Una vez verifiquemos que todo está correcto, podremos eliminar el temporal.