Despliegue global con Compute Engine y Spanner

Last reviewed 2025-08-12 UTC

En este documento se proporciona una arquitectura de referencia para una aplicación multinivel que se ejecuta en máquinas virtuales de Compute Engine y Spanner en una topología global en Google Cloud. El documento también proporciona directrices para ayudarte a crear una arquitectura que utilice otros servicios de infraestructura de Google Cloud . En él se describen los factores de diseño que debes tener en cuenta al crear una arquitectura global para tus aplicaciones en la nube. La audiencia a la que va dirigido este documento son los arquitectos de nube.

Esta arquitectura se ajusta al arquetipo de implementación global. Recomendamos este arquetipo para las aplicaciones que ofrecen servicios a usuarios de todo el mundo y que necesitan alta disponibilidad y solidez frente a las interrupciones en varias regiones. Esta arquitectura admite el escalado elástico en los niveles de red, aplicación y base de datos. Te permite alinear los costes con el uso sin tener que sacrificar el rendimiento, la disponibilidad o la escalabilidad.

Arquitectura

En el siguiente diagrama se muestra la arquitectura de una aplicación que se ejecuta en una infraestructura distribuida globalmente en varias Google Cloud regiones.

Arquitectura de implementación global con Compute Engine y Spanner.

En esta arquitectura, un balanceador de carga global distribuye las solicitudes entrantes a los servidores web de las regiones adecuadas en función de su disponibilidad, capacidad y proximidad a la fuente del tráfico. Una capa de balanceo de carga interno entre regiones gestiona la distribución del tráfico de los servidores web a los servidores de aplicaciones adecuados en función de su disponibilidad y capacidad. Los servidores de aplicaciones escriben datos en una base de datos replicada de forma síncrona y leen datos de ella, que está disponible en todas las regiones.

La arquitectura incluye los siguientes Google Cloud recursos:

Componente Finalidad
Balanceador de carga externo global

El balanceador de carga externo global recibe y distribuye las solicitudes de los usuarios a la aplicación. El balanceador de carga externo global anuncia una sola dirección IP anycast, pero se implementa como un gran número de proxies en Google Front Ends (GFEs). Las solicitudes de los clientes se dirigen al GFE más cercano.

En función de tus requisitos, puedes usar un balanceador de carga de aplicación externo global o un balanceador de carga de red con proxy externo global. Para obtener más información, consulta Elegir un balanceador de carga.

Para proteger tu aplicación frente a amenazas como los ataques de denegación de servicio distribuido (DDoS) y las vulnerabilidades de tipo cross-site scripting (XSS), puedes usar las políticas de seguridad de Google Cloud Armor.

Grupos de instancias gestionados (MIGs) regionales para el nivel web

El nivel web de la aplicación se despliega en máquinas virtuales de Compute Engine que forman parte de grupos de instancias gestionados regionales. Estos MIGs son los backends del balanceador de carga mundial.

Cada MIG contiene VMs de Compute Engine en tres zonas diferentes. Cada una de estas máquinas virtuales aloja una instancia independiente de la capa web de la aplicación.

Capa de balanceo de carga interno interregional

Los balanceadores de carga internos con backends entre regiones gestionan la distribución del tráfico de las VMs de la capa web de cualquier región a las VMs de la capa de aplicación de todas las regiones.

En función de tus requisitos, puedes usar un balanceador de carga de aplicación interno entre regiones o un balanceador de carga de red con proxy interno entre regiones. Para obtener más información, consulta Elegir un balanceador de carga.

Grupos regionales de instancias gestionados para el nivel de aplicación

El nivel de aplicación se despliega en máquinas virtuales de Compute Engine que forman parte de grupos de instancias gestionados regionales. Estos MIGs son los backends de la capa de balanceo de carga interno.

Cada MIG contiene VMs de Compute Engine en tres zonas diferentes. Cada VM aloja una instancia independiente de la capa de aplicación.

Instancia multirregional de Spanner

La aplicación escribe datos en una instancia de Spanner multirregional y los lee de ella. La configuración multirregional de esta arquitectura incluye las siguientes réplicas:

  • Cuatro réplicas de lectura y escritura en zonas diferentes de dos regiones.
  • Una réplica testigo en una tercera región.
Red de nube privada virtual (VPC) y subredes

Todos los recursos de la arquitectura usan una única red de VPC. La red de VPC tiene las siguientes subredes:

  • Una subred en cada región para las máquinas virtuales del servidor web.
  • Una subred en cada región para las VMs del servidor de aplicaciones.
  • (No se muestra en el diagrama de arquitectura) Una subred de solo proxy en cada región para el balanceador de carga interno entre regiones.

En lugar de usar una sola red de VPC, puedes crear una red de VPC independiente en cada región y conectar las redes mediante Network Connectivity Center.

Productos usados

Esta arquitectura de referencia usa los siguientes Google Cloud productos:

  • Compute Engine: un servicio de computación seguro y personalizable con el que puedes crear y ejecutar máquinas virtuales en la infraestructura de Google.
  • Cloud Load Balancing: una cartera de balanceadores de carga de alto rendimiento, escalables, globales y regionales.
  • Spanner: un servicio de base de datos relacional muy escalable y coherente a nivel mundial.

Factores del diseño

En esta sección se ofrecen directrices para ayudarte a usar esta arquitectura de referencia y desarrollar una arquitectura que cumpla tus requisitos específicos de diseño del sistema, seguridad y cumplimiento, fiabilidad, coste, eficiencia operativa y rendimiento.

Diseño de sistemas

En esta sección se ofrecen directrices para ayudarte a elegir las Google Cloud regiones para tu implementación global y a seleccionar los Google Cloud servicios adecuados.

Selección de regiones

Cuando elijas las Google Cloud regiones en las que se deben implementar tus aplicaciones, ten en cuenta los siguientes factores y requisitos:

  • Disponibilidad de los servicios de Google Cloud en cada región. Para obtener más información, consulta Productos disponibles por ubicación.
  • Disponibilidad de los tipos de máquinas de Compute Engine en cada región. Para obtener más información, consulta el artículo Regiones y zonas.
  • Requisitos de latencia para los usuarios finales.
  • Coste de los Google Cloud recursos.
  • Costes de transferencia de datos entre regiones.
  • Requisitos normativos.

Algunos de estos factores y requisitos pueden implicar concesiones. Por ejemplo, la región más rentable puede no tener la huella de carbono más baja. Para obtener más información, consulta las prácticas recomendadas para seleccionar regiones de Compute Engine.

Infraestructura informática

La arquitectura de referencia de este documento usa máquinas virtuales de Compute Engine para determinados niveles de la aplicación. En función de los requisitos de tu aplicación, puedes elegir entre otros Google Cloud servicios de computación:

  • Contenedores: puedes ejecutar aplicaciones en contenedores en clústeres de Google Kubernetes Engine (GKE). GKE es un motor de orquestación de contenedores que automatiza el despliegue, el escalado y la gestión de aplicaciones en contenedores.
  • Sin servidor: si prefieres centrar tus esfuerzos de TI en los datos y las aplicaciones en lugar de configurar y operar recursos de infraestructura, puedes usar servicios sin servidor, como Cloud Run.

Para decidir si usar máquinas virtuales, contenedores o servicios sin servidor, debes encontrar el equilibrio entre la flexibilidad de la configuración y el esfuerzo de gestión. Las máquinas virtuales y los contenedores ofrecen más flexibilidad de configuración, pero tú eres el responsable de gestionar los recursos. En una arquitectura sin servidor, las cargas de trabajo se despliegan en una plataforma preconfigurada que requiere un esfuerzo de gestión mínimo. Para obtener más información sobre cómo elegir los servicios de computación adecuados para tus cargas de trabajo enGoogle Cloud, consulta Alojar aplicaciones en Google Cloud.

Servicios de almacenamiento

La arquitectura que se muestra en este documento usa volúmenes de disco persistente regional para las VMs. Los volúmenes de discos persistentes regionales proporcionan replicación síncrona de datos en dos zonas de una región. Los datos de los volúmenes de discos persistentes no se replican entre regiones.

Google Cloud Hyperdisk ofrece un mejor rendimiento, flexibilidad y eficiencia que Persistent Disk. Con Hyperdisk Balanced, puedes aprovisionar IOPS y el procesamiento de forma independiente y dinámica, lo que te permite ajustar el volumen a una amplia variedad de cargas de trabajo.

Si quieres un almacenamiento de bajo coste que se replique en varias ubicaciones, puedes usar segmentos regionales, birregionales o multirregionales de Cloud Storage.

  • Los datos de los segmentos regionales se replican de forma síncrona en las zonas de la región.
  • Los datos de los contenedores birregionales o multirregionales se almacenan de forma redundante en al menos dos ubicaciones geográficas independientes. Los metadatos se escriben de forma síncrona en todas las regiones y los datos se replican de forma asíncrona. En el caso de los segmentos de dos regiones, puedes usar la replicación turbo, que asegura que los objetos se repliquen en los pares de regiones, con un objetivo de punto de recuperación (RPO) de 15 minutos. Para obtener más información, consulta el artículo Disponibilidad y durabilidad de los datos.

Para almacenar datos que se compartan entre varias VMs de una región, como todas las VMs de la capa web o de la capa de aplicación, puedes usar una instancia regional de Filestore. Los datos que almacenas en una instancia regional de Filestore se replican de forma síncrona en tres zonas de la región. Esta replicación asegura una alta disponibilidad y una gran solidez frente a las interrupciones de zonas. Puedes almacenar archivos de configuración compartidos, herramientas y utilidades comunes, y registros centralizados en la instancia de Filestore, así como activar la instancia en varias máquinas virtuales. Para aumentar la solidez frente a las interrupciones de la región, puede replicar una instancia de Filestore en otra región. Para obtener más información, consulta Replicación de instancias.

Si tu base de datos es Microsoft SQL Server, te recomendamos que uses Cloud SQL para SQL Server. En los casos en los que Cloud SQL no admita tus requisitos de configuración o si necesitas acceder al sistema operativo, puedes implementar una instancia de clúster de conmutación por error (FCI) de Microsoft SQL Server. En este caso, puedes usar Google Cloud NetApp Volumes, un servicio totalmente gestionado, para proporcionar almacenamiento SMB de disponibilidad continua (CA) a la base de datos.

Cuando diseñes el almacenamiento de tus cargas de trabajo, ten en cuenta las características funcionales, los requisitos de resiliencia, las expectativas de rendimiento y los objetivos de costes. Para obtener más información, consulta Diseñar una estrategia de almacenamiento óptima para tu carga de trabajo en la nube.

Servicios de bases de datos

La arquitectura de referencia de este documento usa Spanner, una base de datos totalmente gestionada, escalable horizontalmente, distribuida por todo el mundo y replicada de forma síncrona. Recomendamos una configuración multirregional de Spanner para las implementaciones críticas que requieren una consistencia sólida entre regiones. Spanner admite la replicación síncrona interregional sin tiempo de inactividad para la conmutación por error, el mantenimiento o el cambio de tamaño.

Para obtener información sobre otros servicios de bases de datos gestionadas que puedes elegir en función de tus requisitos, consulta Google Cloud Bases de datos. Cuando elijas y configures la base de datos para una implementación multirregional, ten en cuenta los requisitos de tu aplicación en cuanto a la coherencia de los datos entre regiones y los pros y los contras en cuanto al rendimiento y al coste.

Diseño de redes

Elige un diseño de red que cumpla los requisitos técnicos y empresariales. Puedes usar una o varias redes de VPC. Para obtener más información, consulta la siguiente documentación:

Opciones de balanceo de carga externo

Una arquitectura que usa un balanceador de carga externo global, como la arquitectura de este documento, admite determinadas funciones que te ayudan a mejorar la fiabilidad de tus implementaciones. Por ejemplo, si usas el balanceador de carga de aplicación externo global, puedes implementar el almacenamiento en caché perimetral con Cloud CDN.

Si tu aplicación requiere que se finalice la seguridad de la capa de transporte (TLS) en una región específica o si necesitas poder servir contenido desde regiones concretas, puedes usar balanceadores de carga regionales con Cloud DNS para enrutar el tráfico a diferentes regiones. Para obtener información sobre las diferencias entre los balanceadores de carga regionales y globales, consulta la siguiente documentación:

Seguridad, privacidad y cumplimiento

En esta sección se describen los factores que debes tener en cuenta al usar esta arquitectura de referencia para diseñar y crear una topología global enGoogle Cloud que cumpla los requisitos de seguridad, privacidad y cumplimiento de tus cargas de trabajo.

Protección frente a amenazas externas

Para proteger tu aplicación frente a amenazas como los ataques de denegación de servicio distribuido (DDoS) y las secuencias de comandos entre sitios (XSS), puedes usar las políticas de seguridad de Google Cloud Armor. Cada política es un conjunto de reglas que especifica determinadas condiciones que se deben evaluar y las acciones que se deben llevar a cabo cuando se cumplan esas condiciones. Por ejemplo, una regla podría especificar que, si la dirección IP de origen del tráfico entrante coincide con una dirección IP o un intervalo CIDR específicos, se debe denegar el tráfico. También puede aplicar reglas de cortafuegos de aplicación web (WAF) preconfiguradas. Para obtener más información, consulta el artículo Información general sobre la política de seguridad.

Acceso externo a las VMs

En la arquitectura de referencia que se describe en este documento, las VMs de Compute Engine no necesitan acceso entrante desde Internet. No asignes direcciones IP externas a las VMs. Google Cloud Los recursos que solo tienen una dirección IP interna privada pueden acceder a determinadas APIs y servicios de Google mediante Private Service Connect o Acceso privado de Google. Para obtener más información, consulta el artículo sobre las opciones de acceso privado a servicios.

Para habilitar conexiones salientes seguras desde Google Cloud recursos que solo tienen direcciones IP privadas, como las VMs de Compute Engine de esta arquitectura de referencia, puedes usar Secure Web Proxy o Cloud NAT.

Privilegios de cuenta de servicio

En el caso de las máquinas virtuales de Compute Engine de la arquitectura, en lugar de usar las cuentas de servicio predeterminadas, te recomendamos que crees cuentas de servicio específicas y que indiques los recursos a los que puede acceder la cuenta de servicio. La cuenta de servicio predeterminada tiene una amplia gama de permisos, incluidos algunos que puede que no sean necesarios. Puedes adaptar las cuentas de servicio dedicadas para que solo tengan los permisos esenciales. Para obtener más información, consulta Limitar los privilegios de las cuentas de servicio.

Seguridad de SSH

Para mejorar la seguridad de las conexiones SSH a las VMs de Compute Engine de tu arquitectura, implementa Identity-Aware Proxy (IAP) y la API Cloud OS Login. IAP te permite controlar el acceso a la red en función de la identidad del usuario y las políticas de Gestión de Identidades y Accesos (IAM). La API Cloud OS Login te permite controlar el acceso SSH de Linux en función de la identidad del usuario y las políticas de gestión de identidades y accesos. Para obtener más información sobre cómo gestionar el acceso a la red, consulta las prácticas recomendadas para controlar el acceso de inicio de sesión SSH.

Más consideraciones sobre seguridad

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones de seguridad a nivel de plataforma que se proporcionan en el blueprint de bases empresariales y en el Google Cloud framework Well-Architected: seguridad, privacidad y cumplimiento.

Fiabilidad

En esta sección se describen los factores de diseño que debes tener en cuenta al usar esta arquitectura de referencia para crear y operar una infraestructura fiable para una implementación global en Google Cloud.

Autoescalado de MIG

Si ejecutas tu aplicación en varios MIGs regionales, la aplicación seguirá estando disponible durante las interrupciones aisladas de zonas o regiones. La función de autoescalado de los MIGs sin estado te permite mantener la disponibilidad y el rendimiento de las aplicaciones en niveles predecibles.

Para controlar el comportamiento del autoescalado de tus MIGs sin estado, puedes especificar métricas de utilización objetivo, como la utilización media de la CPU. También puedes configurar el escalado automático basado en la programación para los MIGs sin estado. Las MIGs con estado no se pueden escalar automáticamente. Para obtener más información, consulta Grupos de instancias con autoescalado.

Límite de tamaño de MIG

Cuando decidas el tamaño de tus MIGs, ten en cuenta los límites predeterminados y máximos del número de VMs que se pueden crear en un MIG. Para obtener más información, consulta Añadir y quitar VMs de un MIG.

Reparación automática de VMs

A veces, las VMs que alojan tu aplicación pueden estar en ejecución y disponibles, pero puede haber problemas con la propia aplicación. Es posible que la aplicación se bloquee, falle o no tenga suficiente memoria. Para verificar si una aplicación responde según lo esperado, puedes configurar comprobaciones de estado basadas en aplicaciones como parte de la política de reparación automática de tus MIGs. Si la aplicación de una máquina virtual concreta no responde, el MIG se recupera automáticamente (repara la máquina virtual). Para obtener más información sobre cómo configurar la reparación automática, consulta Información sobre la reparación de VMs para la alta disponibilidad.

Emplazamiento de VM

En la arquitectura que se describe en este documento, los niveles de aplicación y web se ejecutan en máquinas virtuales de Compute Engine distribuidas en varias zonas. Esta distribución asegura que tu aplicación sea robusta frente a interrupciones de zona.

Para mejorar la solidez de la arquitectura, puedes crear una política de colocación de réplicas y aplicarla a la plantilla de MIG. Cuando el MIG crea VMs, las coloca en servidores físicos diferentes (llamados hosts) dentro de cada zona, por lo que tus VMs son resistentes a los fallos de hosts concretos. Para obtener más información, consulta Crear y aplicar políticas de colocación dispersa a VMs.

Planificación de la capacidad de las VMs

Para asegurarte de que haya capacidad disponible para las VMs de Compute Engine cuando sea necesario aprovisionarlas, puedes crear reservas. Las reservas proporcionan capacidad asegurada en una zona específica para un número determinado de máquinas virtuales de un tipo de máquina que elijas. Una reserva puede ser específica de un proyecto o compartirse entre varios proyectos. Para obtener más información sobre las reservas, consulta Elegir un tipo de reserva.

Almacenamiento con estado

Una práctica recomendada en el diseño de aplicaciones es evitar la necesidad de usar discos locales con estado. Sin embargo, si es necesario, puedes configurar tus discos persistentes para que tengan reconocimiento del estado y así asegurarte de que los datos se conserven cuando se reparen o se vuelvan a crear las VMs. Sin embargo, te recomendamos que mantengas los discos de arranque sin reconocimiento del estado para que puedas actualizarlos a las imágenes más recientes con nuevas versiones y parches de seguridad. Para obtener más información, consulta Configurar discos persistentes con reconocimiento del estado en MIGs.

Durabilidad de los datos

Puedes usar Backup y DR para crear, almacenar y gestionar copias de seguridad de las máquinas virtuales de Compute Engine. Backup y recuperación tras fallos almacena los datos de las copias de seguridad en su formato original, legible por las aplicaciones. Cuando sea necesario, puedes restaurar tus cargas de trabajo en producción usando directamente los datos del almacenamiento de copias de seguridad a largo plazo, sin tener que preparar ni mover datos.

Compute Engine ofrece las siguientes opciones para ayudarte a asegurar la durabilidad de los datos almacenados en volúmenes de Persistent Disk:

Fiabilidad de la base de datos

Los datos almacenados en una instancia multirregional de Spanner se replican de forma síncrona en varias regiones. La configuración de Spanner que se muestra en el diagrama de arquitectura anterior incluye las siguientes réplicas:

  • Cuatro réplicas de lectura y escritura en zonas diferentes de dos regiones.
  • Una réplica testigo en una tercera región.

Una operación de escritura en una instancia de Spanner multirregional se confirma después de que al menos tres réplicas (en zonas independientes de dos regiones) hayan completado la operación. Si se produce un fallo en una zona o una región, Spanner tiene acceso a todos los datos, incluidos los de las operaciones de escritura más recientes, y sigue atendiendo las solicitudes de lectura y escritura.

Spanner usa el almacenamiento desagregado, donde los recursos de computación y almacenamiento están desacoplados. No tienes que mover datos cuando añades capacidad de computación para la alta disponibilidad o el escalado. Los nuevos recursos de computación obtienen los datos que necesitan del nodo Colossus más cercano. Esto hace que la conmutación por error y el escalado sean más rápidos y menos arriesgados.

Spanner proporciona coherencia externa, que es una propiedad más estricta que la serialización para los sistemas de procesamiento de transacciones. Para obtener más información, consulta lo siguiente:

Más consideraciones sobre la fiabilidad

Cuando crees la arquitectura en la nube de tu carga de trabajo, consulta las prácticas recomendadas y las recomendaciones relacionadas con la fiabilidad que se proporcionan en la siguiente documentación:

Optimización de costes

En esta sección se ofrecen directrices para optimizar el coste de configurar y operar una topología global Google Cloud que se cree con esta arquitectura de referencia.

Tipos de máquinas virtuales

Para ayudarte a optimizar el uso de los recursos de tus instancias de VM, Compute Engine ofrece recomendaciones sobre el tipo de máquina. Usa las recomendaciones para elegir los tipos de máquinas que se ajusten a los requisitos de computación de tu carga de trabajo. En el caso de las cargas de trabajo con requisitos de recursos predecibles, puedes personalizar el tipo de máquina según tus necesidades y ahorrar dinero usando tipos de máquinas personalizadas.

Modelo de aprovisionamiento de VMs

Si tu aplicación es tolerante a fallos, las VMs de acceso puntual pueden ayudarte a reducir los costes de Compute Engine de las VMs de los niveles de aplicación y web. El coste de las máquinas virtuales de acceso puntual es significativamente inferior al de las máquinas virtuales normales. Sin embargo, Compute Engine puede detener o eliminar de forma preventiva las Spot VMs para recuperar capacidad.

Las máquinas virtuales Spot son adecuadas para tareas por lotes que pueden tolerar la interrupción y no tienen requisitos de alta disponibilidad. Las VMs de acceso puntual ofrecen los mismos tipos de máquinas, opciones y rendimiento que las VMs normales. Sin embargo, cuando la capacidad de recursos de una zona es limitada, es posible que los MIGs no puedan aumentar la escala (es decir, crear VMs) automáticamente hasta el tamaño de destino especificado hasta que la capacidad necesaria vuelva a estar disponible.

Uso de recursos de las VMs

La función de autoescalado de los MIGs sin estado permite que tu aplicación gestione los aumentos de tráfico de forma adecuada y te ayuda a reducir los costes cuando la demanda de recursos es baja. Las MIGs con estado no se pueden escalar automáticamente.

Coste de la base de datos

Spanner te ayuda a asegurarte de que los costes de tu base de datos sean predecibles. La capacidad de computación que especifique (número de nodos o unidades de procesamiento) determina la capacidad de almacenamiento. El rendimiento de lectura y escritura se escala de forma lineal con la capacidad de computación. Solo pagas por lo que usas. Cuando necesites ajustar los costes a las necesidades de tu carga de trabajo, puedes modificar el tamaño de tu instancia de Spanner.

Licencias de terceros

Cuando migras cargas de trabajo de terceros a Google Cloud, puedes reducir los costes si utilizas tus propias licencias (BYOL). Por ejemplo, para desplegar máquinas virtuales de Microsoft Windows Server, en lugar de usar una imagen premium que suponga un coste adicional por la licencia de terceros, puedes crear y usar una imagen de Windows BYOL personalizada. Después, solo pagas por la infraestructura de las máquinas virtuales que utilizas en Google Cloud. Esta estrategia te ayuda a seguir obteniendo valor de tus inversiones en licencias de terceros. Si decides usar el enfoque BYOL, las siguientes recomendaciones pueden ayudarte a reducir los costes:

  • Aprovisiona el número de núcleos de CPU de cálculo que necesites independientemente de la memoria mediante tipos de máquinas personalizadas. De esta forma, el coste de las licencias de terceros se limita al número de núcleos de CPU que necesites.
  • Reduce el número de vCPUs por núcleo de 2 a 1 inhabilitando el multihilo simultáneo (SMT).

Si despliegas una base de datos de terceros, como Microsoft SQL Server, en máquinas virtuales de Compute Engine, debes tener en cuenta los costes de licencia del software de terceros. Si usas un servicio de base de datos gestionado como Cloud SQL, los costes de la licencia de la base de datos se incluyen en los cargos del servicio.

Más consideraciones sobre los costes

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las sugerencias generales que se proporcionan en el Google Cloud framework Well-Architected: optimización de costes.

Eficiencia operativa

En esta sección se describen los factores que debes tener en cuenta al usar esta arquitectura de referencia para diseñar y crear una Google Cloud topología Google Cloud global que puedas gestionar de forma eficiente.

Actualizaciones de configuración de máquinas virtuales

Para actualizar la configuración de las VMs de un MIG (como el tipo de máquina o la imagen del disco de arranque), crea una plantilla de instancia con la configuración necesaria y, a continuación, aplícala al MIG. El MIG actualiza las VMs mediante el método de actualización que elijas: automático o selectivo. Elige un método adecuado en función de tus requisitos de disponibilidad y eficiencia operativa. Para obtener más información sobre estos métodos de actualización de MIGs, consulta Aplicar nuevas configuraciones de VM en un MIG.

Imágenes de máquina virtual

En el caso de tus VMs, en lugar de usar imágenes públicas proporcionadas por Google, te recomendamos que crees y uses imágenes de SO personalizadas que contengan las configuraciones y el software que necesiten tus aplicaciones. Puedes agrupar tus imágenes personalizadas en una familia de imágenes personalizadas. Una familia de imágenes siempre apunta a la imagen más reciente de esa familia, por lo que tus plantillas de instancia y tus secuencias de comandos pueden usar esa imagen sin que tengas que actualizar las referencias a una versión específica de la imagen. Debe actualizar periódicamente sus imágenes personalizadas para incluir las actualizaciones y los parches de seguridad que proporcione el proveedor del SO.

Plantillas de instancia deterministas

Si las plantillas de instancia que usas en tus MIGs incluyen secuencias de comandos de inicio para instalar software de terceros, asegúrate de que las secuencias de comandos especifiquen explícitamente los parámetros de instalación del software, como la versión del software. De lo contrario, cuando el MIG cree las VMs, es posible que el software instalado en ellas no sea coherente. Por ejemplo, si tu plantilla de instancia incluye un script de inicio para instalar el servidor HTTP de Apache 2.0 (el paquete apache2), asegúrate de que el script especifique la versión exacta de apache2 que se debe instalar, como la versión 2.4.53. Para obtener más información, consulta Plantillas de instancia deterministas.

Migración a Spanner

Puedes migrar tus datos a Spanner desde otras bases de datos, como MySQL, SQL Server y Oracle Database. El proceso de migración depende de factores como la base de datos de origen, el tamaño de los datos, las limitaciones de tiempo de inactividad y la complejidad del código de la aplicación. Para ayudarte a planificar e implementar la migración a Spanner de forma eficiente, te ofrecemos una serie de Google Cloudherramientas propias y de terceros. Para obtener más información, consulta la descripción general de la migración.

Administración de bases de datos

Con Spanner, no es necesario configurar ni monitorizar la replicación ni la conmutación por error. La replicación síncrona y la conmutación por error automática están integradas. Tu aplicación no experimenta ningún tiempo de inactividad durante el mantenimiento de la base de datos y la conmutación por error. Para reducir aún más la complejidad operativa, puedes configurar el autoescalado. Con el autoescalado habilitado, no es necesario que monitorices y escales el tamaño de la instancia manualmente.

Más consideraciones operativas

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas generales y las recomendaciones para mejorar la eficiencia operativa que se describen en el Google Cloud framework Well-Architected: excelencia operativa.

Optimización del rendimiento

En esta sección se describen los factores que debe tener en cuenta al usar esta arquitectura de referencia para diseñar y crear una topología global enGoogle Cloud que cumpla los requisitos de rendimiento de sus cargas de trabajo.

Rendimiento de la red

En el caso de las cargas de trabajo que necesiten una latencia de red baja entre las máquinas virtuales en los niveles de aplicación y web, puedes crear una política de emplazamiento compacta y aplicarla a la plantilla de MIG que se utilice en esos niveles. Cuando el MIG crea máquinas virtuales, las coloca en servidores físicos que están cerca unos de otros. Aunque una política de emplazamiento compacta ayuda a mejorar el rendimiento de la red entre máquinas virtuales, una política de emplazamiento dispersa puede ayudar a mejorar la disponibilidad de las máquinas virtuales, como se ha descrito anteriormente. Para conseguir un equilibrio óptimo entre el rendimiento y la disponibilidad de la red, cuando crees una política de colocación compacta, puedes especificar la distancia que debe haber entre las VMs. Para obtener más información, consulta el resumen de las políticas de colocación.

Compute Engine tiene un límite por máquina virtual para el ancho de banda de red de salida. Este límite depende del tipo de máquina de la VM y de si el tráfico se enruta a través de la misma red VPC que la VM de origen. En las VMs con determinados tipos de máquinas, puedes habilitar redes Tier_1 para mejorar el rendimiento de la red y obtener un ancho de banda de salida máximo más alto.

Rendimiento de computación

Compute Engine ofrece una amplia gama de tipos de máquinas predefinidos y personalizables para las cargas de trabajo que ejecutas en las VMs. Elige un tipo de máquina adecuado en función de tus requisitos de rendimiento. Para obtener más información, consulta la guía de comparación y recursos de las familias de máquinas.

Multihilo de VM

Cada CPU virtual (vCPU) que asignas a una máquina virtual de Compute Engine se implementa como un único multihilo de hardware. De forma predeterminada, dos vCPUs comparten un núcleo de CPU físico. En las aplicaciones que implican operaciones altamente paralelas o que realizan cálculos de coma flotante (como el análisis de secuencias genéticas y la modelización de riesgos financieros), puedes mejorar el rendimiento reduciendo el número de subprocesos que se ejecutan en cada núcleo de CPU físico. Para obtener más información, consulta Definir el número de hilos por núcleo.

El multihilo de las máquinas virtuales puede tener implicaciones en las licencias de algunos softwares de terceros, como las bases de datos. Para obtener más información, consulta la documentación de licencias del software de terceros.

Niveles de servicio de red

Los niveles de servicio de red te permiten optimizar el coste y el rendimiento de la red de tus cargas de trabajo. Puedes elegir el nivel Premium o el nivel Estándar. El nivel premium ofrece tráfico en la red troncal mundial de Google para minimizar la pérdida de paquetes y la latencia. El nivel Estándar envía el tráfico mediante el emparejamiento, los proveedores de servicios de Internet (ISPs) o las redes de tránsito en un punto de presencia (PoP) de la periferia que esté más cerca de la región en la que se ejecuta tu carga de trabajo de Google Cloud . Para optimizar el rendimiento, le recomendamos que utilice el nivel Premium. Para optimizar los costes, te recomendamos que uses el nivel Estándar.

La arquitectura de este documento usa un balanceador de carga externo global con una dirección IP externa y backends en varias regiones. Esta arquitectura requiere que uses el nivel premium, que utiliza la red troncal mundial de alta fiabilidad de Google para ayudarte a conseguir una pérdida de paquetes y una latencia mínimas.

Si usas balanceadores de carga externos regionales y diriges el tráfico a regiones mediante Cloud DNS, puedes elegir el nivel Premium o el nivel Estándar en función de tus necesidades. Los precios del nivel Estándar son más bajos que los del nivel Premium. El nivel Estándar es adecuado para el tráfico que no es sensible a la pérdida de paquetes y que no tiene requisitos de baja latencia.

Rendimiento de Spanner

Cuando aprovisionas una instancia de Spanner, especificas su capacidad de computación en términos de número de nodos o unidades de procesamiento. Monitoriza el uso de recursos de tu instancia de Spanner y ajusta la capacidad en función de la carga prevista y los requisitos de rendimiento de tu aplicación. Puedes ajustar la capacidad de una instancia de Spanner de forma manual o automática. Para obtener más información, consulta el resumen del ajuste de escala automático.

Con una configuración multirregional, Spanner replica los datos de forma síncrona en varias regiones. Esta replicación permite realizar operaciones de lectura con baja latencia desde varias ubicaciones. La contrapartida es una mayor latencia en las operaciones de escritura, ya que las réplicas de quórum se distribuyen en varias regiones. Para minimizar la latencia de las transacciones de lectura y escritura en una configuración multirregional, Spanner usa el enrutamiento con reconocimiento del líder (habilitado de forma predeterminada).

Para obtener recomendaciones sobre cómo optimizar el rendimiento de su instancia y sus bases de datos de Spanner, consulte la siguiente documentación:

Almacenamiento en caché

Si tu aplicación sirve recursos de sitios web estáticos y tu arquitectura incluye un balanceador de carga de aplicaciones externo global, puedes usar Cloud CDN para almacenar en caché el contenido estático al que se accede con regularidad más cerca de tus usuarios. Cloud CDN puede ayudarte a mejorar el rendimiento para tus usuarios, reducir el uso de recursos de infraestructura en el backend y reducir los costes de distribución de la red. Para obtener más información, consulta Rendimiento web más rápido y protección web mejorada del balanceo de carga.

Más consideraciones sobre el rendimiento

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las sugerencias generales que se proporcionan en el artículo Google Cloud Well-Architected Framework: optimización del rendimiento.

Siguientes pasos

Colaboradores

Autores:

Otros colaboradores: