Implementación global con Compute Engine y Spanner

Last reviewed 2024-05-12 UTC

En este documento, se proporciona una arquitectura de referencia para una aplicación de varios niveles que se ejecuta en VMs de Compute Engine y Spanner en una topología global en Google Cloud. En el documento, también se proporciona orientación para ayudarte a compilar una arquitectura que use otros servicios de infraestructura de Google Cloud. Se describen los factores de diseño que debes tener en cuenta cuando compilas una arquitectura global para tus aplicaciones en la nube. El público objetivo para este documento son los arquitectos de la nube.

Esta arquitectura está alineada con el arquetipo de implementación global. Recomendamos este arquetipo para aplicaciones que entregan a usuarios de todo el mundo y necesitan alta disponibilidad y solidez contra interrupciones en varias regiones. Esta arquitectura admite el escalamiento elástico a nivel de la red, la aplicación y la base de datos. Te permite alinear los costos con el uso sin tener que comprometer el rendimiento, la disponibilidad o la escalabilidad.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura para una aplicación que se ejecuta en una infraestructura distribuida de forma global en varias regiones de Google Cloud.

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

En esta arquitectura, un balanceador de cargas global distribuye las solicitudes entrantes a los servidores web en regiones adecuadas según su disponibilidad, capacidad y proximidad a la fuente del tráfico. Una capa de balanceo de cargas interno interregional maneja la distribución del tráfico desde los servidores web hasta los servidores de aplicaciones adecuados según su disponibilidad y capacidad. Los servidores de aplicaciones escriben datos en una base de datos replicada de forma síncrona y está disponible en todas las regiones.

La arquitectura incluye los siguientes componentes de Google Cloud:

Componente Objetivo
Balanceador de cargas externo global

El balanceador de cargas externo global recibe y distribuye solicitudes de usuario a la aplicación. El balanceador de cargas externo global anuncia una sola dirección IP anycast, pero el balanceador de cargas se implementa como una gran cantidad de proxies en Google Front End (GFE). Las solicitudes del cliente se dirigen al GFE más cercano al cliente.

Según tus requisitos, puedes usar un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de red de proxy externo global. Para obtener más información, consulta Cómo elegir un balanceador de cargas.

Para proteger tu aplicación contra 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.
Grupos de instancias administrados (MIG) regionales para el nivel web

El nivel web de la aplicación se implementa en las VMs de Compute Engine que forman parte de los MIG regionales. Estos MIG son los backends para el balanceador de cargas global.

Cada MIG contiene VMs de Compute Engine en tres zonas diferentes. Cada una de estas VMs aloja una instancia independiente del nivel web de la aplicación.

Capa de balanceo de cargas interno entre regiones

Los balanceadores de cargas internos con backends interregionales controlan la distribución del tráfico desde las VMs de nivel web en cualquier región hasta las VMs de nivel de aplicación en todas las regiones.

Según tus requisitos, puedes usar un balanceador de cargas de aplicaciones interno entre regiones o un balanceador de cargas de red de proxy interno entre regiones. Para obtener más información, consulta Cómo elegir un balanceador de cargas.

MIG regionales para el nivel de aplicación

El nivel de la aplicación se implementa en las VMs de Compute Engine que forman parte de los MIG regionales. Estos MIG son los backends de la capa de balanceo de cargas interno.

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

Instancia de Spanner multirregional

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

  • Cuatro réplicas de lectura y escritura en zonas diferentes en 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 sola red de VPC. La red de VPC tiene las siguientes subredes:

  • Una subred en cada región para las VMs 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 cargas 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

En esta arquitectura de referencia, se usan los siguientes productos de Google Cloud:

  • Compute Engine: Un servicio de procesamiento seguro y personalizable que te permite crear y ejecutar VMs en la infraestructura de Google.
  • Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.
  • Spanner: Un servicio de base de datos relacional, altamente escalable y coherente a nivel global.

Consideraciones del diseño

En esta sección, se proporciona orientación para ayudarte a usar esta arquitectura de referencia para desarrollar una arquitectura que cumpla con los requisitos específicos del diseño, la seguridad y el cumplimiento, el costo, la confiabilidad, la eficiencia operativa y el rendimiento del sistema.

Diseño de sistemas

En esta sección, se proporciona orientación para que puedas elegir las regiones de Google Cloud para tu implementación global y seleccionar los servicios de Google Cloud adecuados.

Selección de región

Cuando elijas las regiones de Google Cloud 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 Regiones y zonas
  • Requisitos de latencia del usuario final.
  • Costo de los recursos de Google Cloud.
  • Costos de transferencia de datos interregionales.
  • Requisitos reglamentarios

Algunos de estos factores y requisitos pueden incluir compensaciones. Por ejemplo, es posible que la región más rentable no tenga la huella de carbono más baja. Para obtener más información, consulta Selecciona zonas y regiones geográficas en el framework de arquitectura de Google Cloud.

Servicios de Compute

En la arquitectura de referencia de este documento, se usan VMs de Compute Engine para los niveles web y de aplicaciones. Según los requisitos de tu aplicación, puedes elegir entre otros servicios de procesamiento de Google Cloud:

  • Puedes ejecutar aplicaciones alojada en contenedores en los clústeres de Google Kubernetes Engine (GKE). GKE es un motor de organización de contenedores que automatiza la implementación, el escalamiento y la administración de aplicaciones en contenedores.
  • Si prefieres enfocar tus esfuerzos de TI en los datos y las aplicaciones en lugar de configurar y operar recursos de infraestructura, puedes usar servicios sin servidores como Cloud Run y Cloud Functions.

La decisión de usar VMs, contenedores o servicios sin servidores implica un equilibrio entre la flexibilidad de la configuración y el esfuerzo de administración. Las VMs y los contenedores proporcionan más flexibilidad de configuración, pero eres responsable de administrar los recursos. En una arquitectura sin servidores, implementas las cargas de trabajo en una plataforma preconfigurada que requiere un esfuerzo de administración mínimo. Si quieres obtener más información para elegir los servicios de procesamiento adecuados para tus cargas de trabajo en Google Cloud, consulta Elige y administra el procesamiento en el framework de arquitectura de Google Cloud.

Servicios de almacenamiento

En la arquitectura que se muestra en este documento, se usan volúmenes de Persistent Disk regionales para las VMs. Los volúmenes de Persistent Disk regional proporcionan replicación síncrona de datos en dos zonas dentro de una región. Los datos en los volúmenes de Persistent Disk no se replican en todas las regiones.

Otras opciones de almacenamiento para implementaciones multirregionales incluyen los buckets multirregionales o birregionales de Cloud Storage. Los objetos almacenados en un bucket birregional o multirregional se almacenan de manera redundante en al menos dos lugares geográficos separados. Los metadatos se escriben de forma síncrona en todas las regiones, y los datos se replican de forma asíncrona. Para buckets birregionales, puedes usar la replicación turbo, que garantiza una replicación más rápida en todas las regiones. Para obtener más información, consulta Disponibilidad y durabilidad de los datos.

Para almacenar archivos que se comparten en varias VMs en una región, como todas las VMs en el nivel web o en el nivel de la aplicación, puedes usar una instancia de Filestore Enterprise. Los archivos que almacenas en una instancia de Filestore Enterprise se replican de forma síncrona en tres zonas dentro de la región. Esta replicación garantiza la alta disponibilidad y la solidez contra las interrupciones de zona. Puedes almacenar archivos de configuración compartidos, herramientas y utilidades comunes y registros centralizados en la instancia de Filestore, y activar la instancia en varias VMs.

Cuando diseñes el almacenamiento para tus cargas de trabajo multirregionales, considera las características funcionales de las cargas de trabajo, los requisitos de la resiliencia, las expectativas de rendimiento y los objetivos de costos. Si quieres obtener más información, consulta Diseña una estrategia de almacenamiento óptima para tu carga de trabajo en la nube.

Servicios de base de datos

En la arquitectura de referencia de este documento, se usa Spanner, una base de datos completamente administrada, escalable de forma horizontal, distribuida de forma global y replicada de forma síncrona. Recomendamos una configuración multirregional de Spanner para las implementaciones esenciales que requieren una coherencia sólida entre regiones. Spanner admite la replicación síncrona entre regiones 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 administrados entre los que puedes elegir según tus requisitos, consulta Bases de datos de Google Cloud. Cuando elijas y configures la base de datos para una implementación multirregional, ten en cuenta los requisitos de tu aplicación para la coherencia de los datos entre regiones y ten en cuenta las compensaciones de rendimiento y costo.

Opciones de balanceo de cargas externo

Una arquitectura que usa un balanceador de cargas externo global, como la arquitectura de este documento, admite ciertas funciones que te ayudan a mejorar la confiabilidad de tus implementaciones. Por ejemplo, si usas el balanceador de cargas de aplicaciones externo global, puedes implementar el almacenamiento en caché perimetral con Cloud CDN.

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

Seguridad y cumplimiento

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar y compilar una topología global en Google Cloud que cumpla con los requisitos de seguridad y cumplimiento de las cargas de trabajo.

Protección contra amenazas

Para proteger tu aplicación contra amenazas como ataques DDoS y XSS, puedes usar las políticas de seguridad de Google Cloud Armor. Cada política es un conjunto de reglas que especifican ciertas condiciones que se deben evaluar y las acciones que se deben realizar cuando se cumplen las 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 rango de CIDR en particular, se debe denegar el tráfico. También puedes aplicar reglas de firewall de aplicación web (WAF) preconfiguradas. Para obtener más información, consulta Descripción general de las políticas de seguridad.

Acceso externo para las VMs

En la arquitectura de referencia que se describe en este documento, las VMs que alojan el nivel de la aplicación y el nivel web no necesitan acceso entrante desde Internet. No asignes direcciones IP externas a esas VMs. Los recursos de Google Cloud que solo tienen una dirección IP interna privada pueden acceder a ciertas APIs y servicios de Google a través de Private Service Connect o el Acceso privado a Google. Si quieres obtener más información, consulta Opciones de acceso privado a los servicios.

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

Seguridad de imágenes de VM

Para garantizar que tus VMs solo usen imágenes aprobadas (es decir, imágenes con software que cumpla con tus requisitos de seguridad o políticas), puedes definir una política de la organización que restrinja el uso de imágenes en proyectos de imagen pública específicos. Para obtener más información, consulta Configura políticas de imágenes confiables.

Privilegios de la cuenta de servicio

En los proyectos de Google Cloud en los que la API de Compute Engine está habilitada, se crea una cuenta de servicio predeterminada de forma automática. Para las organizaciones de Google Cloud que se crearon antes del 3 de mayo de 2024, esta cuenta de servicio predeterminada tiene el rol de IAM Editor (roles/editor), a menos que este comportamiento esté inhabilitado.

De forma predeterminada, la cuenta de servicio predeterminada se conecta a todas las VMs que creas con Google Cloud CLI o la consola de Google Cloud. La función de editor incluye una amplia gama de permisos, por lo que conectar la cuenta de servicio predeterminada a las VMs crea un riesgo de seguridad. Para evitar este riesgo, puedes crear y usar cuentas de servicio dedicadas para cada aplicación. Para especificar los recursos a los que puede acceder la cuenta de servicio, usa políticas detalladas. Si quieres obtener más información, consulta Limita los privilegios de la cuenta de servicio en “Prácticas recomendadas para usar cuentas de servicio”.

Más consideraciones de seguridad

Cuando compiles la arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones de seguridad a nivel de la plataforma que se proporcionan en el plano sobre las bases de empresa.

Confiabilidad

En esta sección, se describen los factores de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia a fin de compilar y operar una infraestructura confiable para una implementación global en Google Cloud.

Ajuste de escala automático de MIG

Cuando ejecutas tu aplicación en varios MIG regionales, la aplicación permanece disponible durante las interrupciones de zonas aisladas o las interrupciones regionales. La capacidad de ajuste de escala automático de los MIG sin estado te permite mantener la disponibilidad y el rendimiento de la aplicación en niveles predecibles. Para controlar el comportamiento del ajuste de escala automático de tus MIG sin estado, puedes especificar las métricas de uso objetivo, como el uso de CPU promedio. También puedes configurar el ajuste de escala automático basado en programas para MIG sin estado. Los MIG con estado no pueden realizar un ajuste de escala automático. Si quieres obtener más información, consulta Ajuste de escala automático para grupos de instancias.

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 aplicación. Puede congelarse, fallar o no tener suficiente memoria. Para verificar si una aplicación responde como se espera, puedes configurar las verificaciones de estado basadas en aplicaciones como parte de la política de reparación automática de los MIG. Si la aplicación en una VM en particular no responde, el MIG repara automáticamente (remedia) la VM. Para obtener más información sobre la configuración de la reparación automática, consulta Configura una verificación de estado y una reparación automática de la aplicación.

Ubicación de las VMs

En la arquitectura que se describe en este documento, el nivel de aplicación y el nivel web se ejecutan en las VMs de Compute Engine que se distribuyen en varias zonas. Esta distribución garantiza que la aplicación sea sólida contra las interrupciones zonales. Para mejorar aún más esta solidez, puedes crear una política de posición distribuida y aplicarla a la plantilla de MIG. Cuando el MIG crea VMs, las ubica dentro de cada zona en diferentes servidores físicos (llamados hosts), por lo que tus VMs son sólidas frente a fallas de hosts individuales. Para obtener más información, consulta Aplica políticas de posición de distribución a las VMs.

Planificación de la capacidad de las VMs

Para asegurarte de que la capacidad de las VMs de Compute Engine esté disponible cuando sea necesaria para el ajuste de escala automático de MIG, puedes crear reservas. Una reserva proporciona capacidad garantizada en una zona específica para una cantidad específica de VMs de un tipo de máquina que elijas. Una reserva puede ser específica de un proyecto o compartirse en varios proyectos. Para obtener más información sobre las reservas, incluidas las consideraciones de facturación, consulta Reservas de recursos zonales de Compute Engine.

Estado de Persistent Disk

Una práctica recomendada en el diseño de aplicaciones es evitar la necesidad de discos locales con estado. Pero si el requisito existe, puedes configurar tus discos persistentes para que tengan estado para garantizar que los datos se conserven cuando las VMs se reparen o se vuelvan a crear. Sin embargo, te recomendamos que mantengas los discos de arranque sin estado para que puedas actualizarlos fácilmente a las imágenes más recientes con versiones y parches de seguridad nuevos. Para obtener más información, consulta Configura discos persistentes con estado en MIG.

Durabilidad de los datos

Puedes usar el servicio Backup & DR para crear, almacenar y administrar copias de seguridad de las VMs de Compute Engine. La copia de seguridad y la DR almacenan datos de copia de seguridad en su formato original legible para la aplicación. Cuando sea necesario, puedes restablecer las cargas de trabajo a producción directamente a través del uso de datos de almacenamiento de copia de seguridad a largo plazo sin mucho tiempo de movimiento de datos o actividades de preparación.

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

  • Las instantáneas estándar te permiten capturar el estado de un momento determinado de los volúmenes de Persistent Disk. Las instantáneas se almacenan de forma redundante en varias regiones, con sumas de verificación automáticas para garantizar la integridad de tus datos. Las instantáneas son incrementales de forma predeterminada, por lo que usan menos espacio de almacenamiento y ahorras dinero. Las instantáneas se almacenan en una ubicación de Cloud Storage que puedes configurar. Para obtener más recomendaciones sobre el uso y la administración de instantáneas, consulta Prácticas recomendadas para instantáneas de discos de Compute Engine.
  • Los volúmenes de discos persistentes regionales te permiten ejecutar aplicaciones con alta disponibilidad que no se ven afectadas por fallas en los discos persistentes. Cuando creas un volumen de disco persistente regional, Compute Engine mantiene una réplica del disco en una zona diferente dentro de la misma región. Los datos se replican de forma síncrona en los discos en ambas zonas. Si alguna de las dos zonas tiene una interrupción, los datos permanecen disponibles.

Puedes usar la función de copia de seguridad y restablecimiento en Spanner para protegerte contra la corrupción de datos causada por errores de operador y problemas de aplicaciones. Para obtener más información, consulta Descripción general de la copia de seguridad y restablecimiento de Spanner.

Confiabilidad de la base de datos

Los datos que se almacenan 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 en dos regiones.
  • Una réplica testigo en una tercera región.

Una operación de escritura en una instancia multirregional de Spanner se confirma después de que al menos tres réplicas (en zonas diferentes en dos regiones) hayan confirmado la operación. Si se produce una falla de zona o región, Spanner tiene acceso a todos los datos, incluidos los de las últimas operaciones de escritura, y continúa entregando solicitudes de lectura y escritura.

Spanner usa almacenamiento desagregado en el que se separan los recursos de procesamiento y de almacenamiento. No es necesario mover datos cuando agregas capacidad de procesamiento para HA o escalamiento. Los recursos de procesamiento nuevos obtienen datos cuando los necesitan desde el nodo Colossus más cercano. Esto hace que la conmutación por error y el escalamiento sean más rápidos y menos riesgosos.

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 de confiabilidad

Cuando compiles la arquitectura de nube para tu carga de trabajo, revisa las prácticas recomendadas y las recomendaciones relacionadas con la confiabilidad que se proporcionan en la siguiente documentación:

Optimización de costos

En esta sección, se proporciona orientación para optimizar el costo de configurar y operar una topología de Google Cloud global que compilas a través de esta arquitectura de referencia.

Tipos de máquinas de VMs

Para ayudarte a optimizar el uso de tus recursos de VMs, Compute Engine proporciona recomendaciones sobre los tipos de máquinas. Usa las recomendaciones para elegir los tipos de máquinas que coincidan con los requisitos de procesamiento de tu carga de trabajo. Para cargas de trabajo con requisitos de recursos predecibles, puedes personalizar el tipo de máquina según tus necesidades y ahorrar dinero a través de los tipos personalizados de máquinas.

Modelo de aprovisionamiento de VM

Si tu aplicación es tolerante a errores, las VMs Spot pueden ayudarte a reducir los costos de Compute Engine para las VMs en los niveles de aplicación y la Web. El costo de las VMs Spot es significativamente menor que las VMs normales. Sin embargo, Compute Engine podría detener o borrar las VMs Spot de forma preventiva para recuperar capacidad. Las VMs Spot son adecuadas para trabajos por lotes que pueden tolerar la interrupción y no tienen requisitos de alta disponibilidad. Las VMs Spot ofrecen los mismos tipos de máquinas, opciones y rendimiento que las VMs normales. Sin embargo, cuando la capacidad de recursos en una zona es limitada, es posible que los MIG no puedan escalar horizontalmente (es decir, crear VMs) de forma automática al tamaño objetivo especificado hasta que la capacidad requerida vuelva a estar disponible.

Uso de recursos de VMs

La capacidad de ajuste de escala automático de los MIG sin estado permite que tu aplicación maneje los aumentos de tráfico con facilidad y te ayuda a reducir los costos cuando la necesidad de recursos es baja. Los MIG con estado no pueden realizar un ajuste de escala automático.

Costo de la base de datos

Spanner ayuda a garantizar que los costos de la base de datos sean predecibles. La capacidad de procesamiento que especifiques (cantidad de nodos o unidades de procesamiento) determina la capacidad de almacenamiento. Las capacidades de procesamiento de lectura y escritura se escalan de forma lineal con la capacidad de procesamiento. Solo pagas por lo que usas. Cuando necesitas alinear los costos con las necesidades de tu carga de trabajo, puedes ajustar el tamaño de tu instancia de Spanner.

Licencias de terceros

Cuando migras cargas de trabajo de terceros a Google Cloud, es posible que puedas reducir los costos si usas licencias adquiridas por el usuario (BYOL). Por ejemplo, para implementar VMs de Microsoft Windows Server, en lugar de usar una imagen premium que genere un costo adicional por la licencia de terceros, puedes crear y usar una imagen de BYOL de Windows personalizada. Solo pagas por la infraestructura de VM que usas en Google Cloud. Esta estrategia te ayuda a descubrir el valor de tus inversiones existentes en licencias de terceros. Si decides usar el enfoque BYOL, te recomendamos que hagas lo siguiente:

  • Aprovisiona la cantidad necesaria de núcleos de CPU de procesamiento sin importar la memoria a través de tipos personalizados de máquinas. De esta manera, limitas el costo de las licencias externas a la cantidad de núcleos de CPU que necesitas.
  • Reduce la cantidad de CPU virtuales por núcleo de 2 a 1 a través de la inhabilitación de los multiprocesos simultáneos (SMT) y reduce tus costos de licencia en un 50%.

Más consideraciones de los costos

Cuando compiles la arquitectura de tu carga de trabajo, también considera las prácticas recomendadas y las recomendaciones generales que se proporcionan en Framework de la arquitectura de Google Cloud: Optimización de costos.

Eficiencia operativa

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar y compilar una topología de Google Cloud global que puedas operar de manera eficiente.

Actualizaciones de la configuración de VMs

Para actualizar la configuración de las VMs en un MIG (como el tipo de máquina o la imagen de disco de arranque), debes crear una plantilla de instancias nueva con la configuración necesaria y, luego, aplicar la plantilla nueva al MIG. El MIG actualiza las VMs a través del 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 MIG, consulta Aplica una configuración de VM nueva en un MIG.

Imágenes de VM

Para las plantillas de instancias de MIG, en lugar de usar imágenes públicas que proporciona Google, te recomendamos que crees y uses imágenes personalizadas que contengan la configuración y el software que requieren tus aplicaciones. Puedes agrupar tus imágenes personalizadas en una familia de imágenes personalizada. Una familia de imágenes siempre apunta a la imagen más reciente de esa familia para que tus plantillas de instancias y secuencias de comandos puedan usarla sin que tengas que actualizar las referencias a una versión de imagen específica.

Plantillas de instancias deterministas

Si las plantillas de instancias que usas para tus MIG incluyen secuencias de comandos de inicio para instalar software de terceros, asegúrate de que las secuencias de comandos especifiquen de forma explícita parámetros de instalación de software, como la versión del software. De lo contrario, cuando el MIG crea las VMs, es posible que el software instalado en las VMs no sea coherente. Por ejemplo, si tu plantilla de instancias incluye una secuencia de comandos de inicio para instalar Apache HTTP Server 2.0 (el paquete apache2), asegúrate de que la secuencia de comandos especifique la versión apache2 exacta que se debe instalar, como la versión 2.4.53. Para obtener más información, consulta Plantillas de instancias determinísticas.

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 restricciones de tiempo de inactividad y la complejidad del código de la aplicación. Para ayudarte a planificar y a implementar la migración a Spanner de manera eficiente, proporcionamos una variedad de herramientas de Google Cloud y de terceros. Para obtener más información, consulta Descripción general de la migración.

Database administration (Administra la base de datos)

Con Spanner, no necesitas configurar ni supervisar 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. La aplicación no experimenta tiempo de inactividad por 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 ajuste de escala automático. Con el ajuste de escala automático habilitado, no necesitas supervisar ni escalar el tamaño de la instancia de forma manual.

Más consideraciones operativas

Cuando compiles la arquitectura de tu carga de trabajo, considera las prácticas recomendadas y las recomendaciones generales para la eficiencia operativa que se describen en Framework de la arquitectura de Google Cloud: Excelencia operativa.

Optimización del rendimiento

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar y compilar una topología global en Google Cloud que cumpla con los requisitos de rendimiento de las cargas de trabajo.

Ubicación de las VMs

Para las cargas de trabajo que requieren una baja latencia de red entre VMs, puedes crear una política de posición compacta y aplicarla a la plantilla de MIG. Cuando el MIG crea las VMs, las coloca en servidores físicos que están cerca. Para obtener más información, consulta Reduce la latencia con las políticas de colocación compacta.

Tipos de máquinas de VMs

Compute Engine ofrece una amplia variedad de tipos predefinidos y personalizables de máquinas que puedes elegir según tus requisitos de costo y rendimiento. Los tipos de máquinas se agrupan en familias y series de máquinas. En la siguiente tabla, se proporciona un resumen de las familias de máquinas recomendadas para diferentes tipos de cargas de trabajo:

Requisito Familia de máquinas recomendada
Mejor relación precio-rendimiento en una variedad de cargas de trabajo Familia de máquinas de uso general
Mayor rendimiento por núcleo y optimizado para cargas de trabajo de procesamiento intensivo Familia de máquinas optimizadas para procesamiento
Proporción alta de memoria a CPU virtual para cargas de trabajo que requieren mucha memoria Familia de máquinas con optimización de memoria
GPU para cargas de trabajo paralelizadas de forma masiva Familia de máquinas con optimización de acelerador
Uso bajo de núcleos y alta densidad de almacenamiento Familia de máquinas optimizadas para el almacenamiento

Para obtener más información, consulta la guía de comparación y recurso de familias de máquinas.

Subprocesos múltiples de VMs

Cada CPU virtual que asignas a una VM de Compute Engine se implementa como un solo subproceso de hardware único. De forma predeterminada, dos CPU virtuales comparten un núcleo de CPU física. Para cargas de trabajo que son muy paralelas o que realizan cálculos de punto flotante (como el análisis de secuencias genéticas y el modelado de riesgo financiero), puedes mejorar el rendimiento si reduces la cantidad de subprocesos que se ejecutan en cada CPU física. Para obtener más información, consulta Configura una cantidad de subprocesos por núcleo.

Niveles de servicio de red

Los niveles de servicio de red te permiten optimizar el costo de red y el rendimiento de las cargas de trabajo. Según tus requisitos, puedes elegir el nivel Premium o el Estándar.

La arquitectura de este documento usa un balanceador de cargas externo global con una dirección IP externa y backends en varias regiones. Esta arquitectura requiere que uses el nivel Premium, que usa la red troncal global altamente confiable de Google para ayudarte a minimizar la pérdida de paquetes y la latencia.

Si usas balanceadores de cargas externos regionales y enrutas el tráfico a regiones mediante Cloud DNS, puedes elegir el nivel Premium o el Estándar según tus requisitos. Los precios del nivel Estándar son más bajos que el 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 latencia baja.

Rendimiento de Spanner

Cuando aprovisionas una instancia de Spanner, debes especificar la capacidad de procesamiento de la instancia en términos de la cantidad de nodos o unidades de procesamiento. Supervisa el uso de recursos de tu instancia de Spanner y escala la capacidad según la carga esperada y los requisitos de rendimiento de tu aplicación. Puedes escalar la capacidad de una instancia de Spanner de forma manual o automática. Para obtener más información, consulta Descripción general 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 operaciones de lectura de baja latencia desde varias ubicaciones. La compensación es una latencia más alta para 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 adaptado al líder (habilitado de forma predeterminada).

Si deseas obtener recomendaciones para optimizar el rendimiento de la instancia y las bases de datos de Spanner, consulta la siguiente documentación:

Almacenar en caché

Si tu aplicación entrega elementos de sitios web estáticos y si tu arquitectura incluye un balanceador de cargas de aplicaciones externo global, puedes usar Cloud CDN para almacenar en caché el contenido estático al que se accede con frecuencia más cerca de tus usuarios. Cloud CDN puede ayudar a mejorar el rendimiento para los usuarios, reducir el uso de los recursos de la infraestructura en el backend y los costos de entrega de la red. Si quieres obtener más información, consulta Rendimiento web más rápido y mayor protección web para el balanceo de cargas.

Más consideraciones sobre el rendimiento

Cuando compiles la arquitectura para tu carga de trabajo, considera las prácticas recomendadas y las recomendaciones generales que se proporcionan en Framework de la arquitectura de Google Cloud: Optimización del rendimiento.

Próximos pasos

Colaboradores

Autor: Kumar Dhanagopal | Desarrollador de soluciones entre productos

Otros colaboradores: