Implementación global con Compute Engine y Spanner

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 prestan servicio 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 recursos 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 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 Google Cloud regiones para tu implementación global y seleccionar los servicios Google Cloud adecuados.

Selección de región

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 Regiones y zonas
  • Requisitos de latencia del usuario final
  • Costo de los Google Cloud recursos.
  • 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. Si deseas obtener más información, consulta Prácticas recomendadas para la selección de regiones de Compute Engine.

Infraestructura de procesamiento

La arquitectura de referencia de este documento usa VMs de Compute Engine para ciertos niveles de la aplicación. Según los requisitos de tu aplicación, puedes elegir entre otros Google Cloud servicios de procesamiento:

  • Contenedores: Puedes ejecutar aplicaciones alojadas en contenedores en 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.
  • Sin servidores: 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.

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 enGoogle Cloud, consulta Hosting Applications on 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.

Google Cloud Hyperdisk proporciona mejor rendimiento, flexibilidad y eficiencia que Persistent Disk. Con Hyperdisk Balanced, puedes aprovisionar IOPS y capacidad de procesamiento por separado y de forma dinámica, lo que te permite ajustar el volumen para una amplia variedad de cargas de trabajo.

Para el almacenamiento de bajo costo que se replica en varias ubicaciones, puedes usar buckets regionales, birregionales o multirregionales de Cloud Storage.

  • Los datos de los buckets regionales se replican de forma síncrona en todas las zonas de la región.
  • Los datos de los buckets birregionales o multirregionales se almacenan de manera redundante en al menos dos ubicaciones geográficas separadas. 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 buckets birregionales, puedes usar la replicación turbo, que garantiza que los objetos se repliquen en pares de regiones, con un objetivo de punto de recuperación (RPO) de 15 minutos. Para obtener más información, consulta Disponibilidad y durabilidad de los datos.

Para almacenar datos 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 regional de Filestore. Los datos que almacenas en una instancia regional de Filestore 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. Para garantizar la solidez ante las interrupciones regionales, puedes 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 usar Cloud SQL para SQL Server. En situaciones en las que Cloud SQL no es compatible con tus requisitos de configuración o si necesitas acceso al sistema operativo, puedes implementar una instancia de clúster de conmutación por error (FCI) de Microsoft SQL Server. En esta situación, puedes usar Google Cloud NetApp Volumes completamente administrado para proporcionar almacenamiento SMB de disponibilidad continua (CA) para la base de datos.

Cuando diseñes almacenamiento para tus cargas de trabajo, considera las características funcionales, los requisitos de resiliencia, las expectativas de rendimiento y los objetivos de costo. 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 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 para la coherencia de los datos entre regiones y ten en cuenta las compensaciones de rendimiento y costo.

Diseño de red

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

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:

Security, privacy, and compliance

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 enGoogle Cloud que cumpla con los requisitos de seguridad, privacidad y cumplimiento de las cargas de trabajo.

Protección contra amenazas externas

Para proteger tu aplicación contra amenazas como los ataques de denegación de servicio distribuido (DSD) y las secuencia 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 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 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 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.

Privilegios de la cuenta de servicio

Para las VMs de Compute Engine en la arquitectura, en lugar de usar las cuentas de servicio predeterminadas, te recomendamos que crees cuentas de servicio dedicadas y especifiques los recursos a los que puede acceder la cuenta de servicio. La cuenta de servicio predeterminada tiene una amplia variedad de permisos, incluidos algunos que podrían no ser necesarios. Puedes personalizar las cuentas de servicio dedicadas para que solo tengan los permisos esenciales. Para obtener más información, consulta Limita los privilegios de la cuenta de servicio.

Seguridad de SSH

Para mejorar la seguridad de las conexiones SSH a las VMs de Compute Engine en tu arquitectura, implementa Identity-Aware Proxy (IAP) y la API de 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 Identity and Access Management (IAM). La API de Cloud OS Login te permite controlar el acceso SSH a Linux en función de la identidad del usuario y las políticas de IAM. Para obtener más información sobre cómo administrar el acceso a la red, consulta Prácticas recomendadas para controlar el acceso de SSH.

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 la empresa y el Google Cloud Framework de Well-Architected: Seguridad, privacidad y cumplimiento.

Confiabilidad

En esta sección, se describen los factores de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia para 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.

Límite de tamaño del MIG

Cuando decidas el tamaño de tus MIGs, ten en cuenta los límites predeterminados y máximos en la cantidad de VMs que se pueden crear en un MIG. Para obtener más información, consulta Agrega y quita VMs en 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 aplicación. 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 tus 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 Información sobre la reparación de VMs para alta disponibilidad.

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 la solidez de la arquitectura, puedes crear una política de posición de distribución 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 Crea y aplica políticas de posición distribuida 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 se deban aprovisionar VMs, 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, consulta Elige un tipo de reserva.

Almacenamiento con estado

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 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 Backup and 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 y evitar la necesidad de preparar o mover datos.

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

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 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 los recursos de tus instancias de VM, 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. Luego, 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, las siguientes recomendaciones pueden ayudarte a reducir los costos:

  • 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 inhabilitando los multiprocesos simultáneos (SMT).

Si implementas una base de datos de terceros, como Microsoft SQL Server en las VMs de Compute Engine, debes considerar los costos de la licencia del software de terceros. Cuando usas un servicio de base de datos administrado como Cloud SQL, los costos de la licencia de la base de datos se incluyen en los cargos del servicio.

Más consideraciones de los costos

Cuando compiles la arquitectura para tu carga de trabajo, también considera las prácticas recomendadas y las recomendaciones generales que se proporcionan en Google Cloud Framework de Well-Architected: 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 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 tus VMs, en lugar de usar imágenes públicas que proporciona Google, te recomendamos que crees y uses imágenes de SO 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. Debes actualizar tus imágenes personalizadas con regularidad para incluir las actualizaciones de seguridad y los parches que proporciona el proveedor del SO.

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 Google Cloudy herramientas 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 para tu carga de trabajo, considera las prácticas recomendadas y las recomendaciones generales para la eficiencia operativa que se describen en el Google Cloud Framework de Well-Architected: 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 enGoogle Cloud que cumpla con los requisitos de rendimiento de las cargas de trabajo.

Rendimiento de la red

Para las cargas de trabajo que necesitan una baja latencia de red entre VM dentro de los niveles de aplicación y web, puedes crear una política de posición compacta y aplicarla a la plantilla de MIG que se usa para esos niveles. Cuando el MIG crea las VMs, las coloca en servidores físicos que están cerca. Si bien una política de posición compacta ayuda a mejorar el rendimiento de la red entre VMs, una política de posición distribuida puede ayudar a mejorar la disponibilidad de la VM, como se describió anteriormente. Para lograr un equilibrio óptimo entre el rendimiento y la disponibilidad de la red, cuando creas una política de posición compacta, puedes especificar la distancia a la que se deben colocar las VMs. Para obtener más información, consulta la Descripción general de las políticas de posición.

Compute Engine tiene un límite por VM 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 de VPC que la VM de origen. En el caso de las VMs con ciertos tipos de máquinas, para mejorar el rendimiento de la red, puedes obtener un mayor ancho de banda de salida máximo si habilitas las redes de nivel 1.

Rendimiento de procesamiento

Compute Engine ofrece una amplia variedad de tipos de máquinas predefinidos y personalizables para las cargas de trabajo que ejecutas en VMs. Elige un tipo de máquina adecuado según tus requisitos de rendimiento. 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 las aplicaciones que implican operaciones altamente 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.

Los subprocesos múltiples de VM pueden tener implicaciones de licencias para algún software de terceros, como las bases de datos. Para obtener más información, lee la documentación sobre licencias del software de terceros.

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. Puedes elegir los niveles Premium o Estándar. El nivel Premium canaliza el tráfico en la red troncal global de Google para lograr una pérdida de paquetes mínima y una latencia baja. El nivel Estándar entrega tráfico a través de redes de intercambio de tráfico, proveedores de servicios de Internet (ISP) o tránsito en un punto de presencia (PoP) perimetral más cercano a la región en la que se ejecuta tu carga de trabajo Google Cloud . Para optimizar el rendimiento, te recomendamos que uses el nivel Premium. Para optimizar el costo, te recomendamos que uses el nivel 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:

Almacenamiento 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 de forma periódica 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 Google Cloud Framework de Well-Architected: Optimización del rendimiento.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores: