Implementación regional en Compute Engine

Last reviewed 2024-01-31 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 en varias zonas dentro de una región de Google Cloud. Puedes usar esta arquitectura de referencia para volver a alojar (lift-and-shift) aplicaciones locales en la nube de forma eficiente con cambios mínimos en las aplicaciones. En el documento, también se describen los factores de diseño que debes tener en cuenta cuando compilas una arquitectura regional para tus aplicaciones en la nube. El público objetivo para este documento son los arquitectos de la nube.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura de una aplicación que se ejecuta en modo activo-activo en pilas aisladas que se implementan en tres zonas de Google Cloud dentro de una región. La arquitectura está alineada con el arquetipo de implementación regional, que garantiza que la topología de Google Cloud sea sólida contra interrupciones zonales.

Una aplicación se ejecuta en modo activo-activo en pilas aisladas que se implementan en tres zonas de Google Cloud dentro de una región.

La arquitectura se basa en el modelo de nube como infraestructura como servicio (IaaS). Debes aprovisionar los recursos de infraestructura necesarios (procesamiento, herramientas de redes y almacenamiento) en Google Cloud. Conservas el control total sobre la infraestructura y la responsabilidad del sistema operativo, el middleware y las capas superiores de la pila de aplicaciones. Para obtener más información sobre IaaS y otros modelos de nube, consulta PaaS en comparación con IaaS o SaaS frente a CaaS: ¿En qué se diferencian?

En el diagrama anterior, se incluyen los siguientes componentes:

Componente Objetivo
Balanceador de cargas regional externo

El balanceador de cargas externo regional recibe y distribuye las solicitudes del usuario a las VMs de nivel web.

Usa un tipo de balanceador de cargas adecuado según el tipo de tráfico y otros requisitos. Por ejemplo, si el backend consta de servidores web (como se muestra en la arquitectura anterior), usa un balanceador de cargas de aplicaciones para reenviar el tráfico HTTP(S). Para balancear las cargas del tráfico de TCP, usa un balanceador de cargas de red. Para obtener más información, consulta Cómo elegir un balanceador de cargas.

Grupo de instancias administrado (MIG) regional para el nivel web

El nivel web de la aplicación se implementa en las VMs de Compute Engine que forman parte de un MIG regional. El MIG es el backend del balanceador de cargas externo regional.

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.

Balanceador de cargas interno regional

El balanceador de cargas interno regional distribuye el tráfico desde las VMs de nivel web hasta las VMs del nivel de la aplicación.

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

MIG regional para el nivel de la aplicación

El nivel de la aplicación se implementa en las VMs de Compute Engine que forman parte de un MIG regional, que es el backend del balanceador 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.

Base de datos de terceros implementada en una VM de Compute Engine

En la arquitectura de este documento, se muestra una base de datos de terceros (como PostgreSQL) que se implementa en una VM de Compute Engine. Puedes implementar una base de datos en espera en otra zona. Las funciones de replicación y de conmutación por error dependen de la base de datos que uses.

Instalar y administrar una base de datos de terceros implica un esfuerzo adicional y un costo operativo para aplicar actualizaciones, supervisar y garantizar la disponibilidad. Puedes evitar la sobrecarga de instalar y administrar una base de datos de terceros y aprovechar las funciones integradas de alta disponibilidad (HA) con un servicio de base de datos completamente administrado, como Cloud SQL o AlloyDB para PostgreSQL. Para obtener más información sobre las opciones de bases de datos administradas, consulta Servicios de base de datos más adelante en esta guía.

Red de nube privada virtual y subred

Todos los recursos de Google Cloud en la arquitectura usan una sola red de VPC y subred.

Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes de VPC o varias subredes. Para obtener más información, consulta Decide si crear o no varias redes de VPC en “Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC”.

Bucket birregional de Cloud Storage

Las copias de seguridad de las aplicaciones y las bases de datos se almacenan en un bucket de Cloud Storage birregional. Si se produce una interrupción zonal o regional, la aplicación y los datos no se pierden.

De forma alternativa, puedes usar el servicio de copia de seguridad y DR para crear, almacenar y administrar las copias de seguridad de la base de datos.

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.
  • Cloud Storage: Un depósito de objetos de bajo costo y sin límites para varios tipos de datos. Se puede acceder a los datos desde y hacia Google Cloud, y estos se replican en las ubicaciones para aumentar la redundancia.
  • Nube privada virtual: Un sistema virtual que proporciona funcionalidad de red global y escalable para tus cargas de trabajo de Google Cloud.

Casos de uso

En esta sección, se describen casos de uso para los que una implementación regional en Compute Engine es una opción adecuada.

Migración eficiente de aplicaciones locales

Puedes usar esta arquitectura de referencia para compilar una topología de Google Cloud para volver a alojar (lift-and-shift) aplicaciones locales en la nube con cambios mínimos en las aplicaciones. Todos los niveles de la aplicación en esta arquitectura de referencia se alojan en las VMs de Compute Engine. Este enfoque te permite migrar las aplicaciones locales de manera eficiente a la nube y aprovechar los beneficios, la confiabilidad, el rendimiento y la simplicidad operativa que proporciona Google Cloud.

Aplicación con alta disponibilidad con usuarios dentro de un área geográfica

Recomendamos una arquitectura de implementación regional para las aplicaciones que necesitan solidez contra interrupciones zonales, pero que puedan tolerar cierto tiempo de inactividad causado por interrupciones regionales. Si alguna parte de la pila de aplicaciones falla, la aplicación seguirá ejecutándose si existe al menos un componente en funcionamiento con capacidad adecuada en cada nivel. Si se produce una interrupción zonal, la pila de aplicaciones continúa ejecutándose en las otras zonas.

Latencia baja para usuarios de aplicaciones

Si todos los usuarios de una aplicación se encuentran dentro de una sola área geográfica, como un solo país, una arquitectura de implementación regional puede ayudar a mejorar el rendimiento de la aplicación percibido por el usuario. Puedes optimizar la latencia de red para las solicitudes de los usuarios si implementas la aplicación en la región de Google Cloud más cercana a tus usuarios.

Herramientas de redes de baja latencia entre los componentes de la aplicación

Una arquitectura de una sola región puede ser adecuada para aplicaciones como la computación por lotes que necesitan conexiones de red de latencia baja y ancho de banda alto entre los nodos de procesamiento. Todos los recursos se encuentran en una sola región de Google Cloud, por lo que el tráfico de red entre recursos permanece dentro de la región. La latencia de red entre recursos es baja y no se generan costos de transferencia de datos entre regiones. Aún se aplican costos de red dentro de la región.

Cumplimiento de los requisitos de residencia de datos

Puedes usar una arquitectura de una sola región para compilar una topología que te ayude a cumplir con los requisitos de residencia de datos. Por ejemplo, un país en Europa puede requerir que todos los datos del usuario se almacenen y se acceda a ellos en centros de datos ubicados físicamente en Europa. Para cumplir con este requisito, puedes ejecutar la aplicación en una región de Google Cloud en Europa.

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, la confiabilidad, la eficiencia operativa, el costo 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 regional y seleccionar los servicios de Google Cloud adecuados.

Selección de región

Cuando elijas una región de Google Cloud para tus aplicaciones, ten en cuenta los siguientes factores y requisitos:

  • Disponibilidad de los servicios de Google Cloud. Para obtener más información, consulta Productos disponibles por ubicación
  • Disponibilidad de los tipos de máquina de Compute Engine. Para obtener más información, consulta Regiones y zonas.
  • Requisitos de la latencia del usuario final
  • Costo de los recursos de Google Cloud
  • 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

La arquitectura de referencia de este documento usa VMs de Compute Engine para todos los niveles de la aplicación. La guía de diseño de este documento es específica para Compute Engine, a menos que se mencione lo contrario.

Según los requisitos de tu aplicación, puedes elegir entre los siguientes otros servicios de procesamiento de Google Cloud. La guía de diseño de esos servicios está fuera del alcance de este documento.

  • Puedes ejecutar aplicaciones 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

La arquitectura que se muestra en este documento usa volúmenes de discos persistentes regionales para todos los niveles. Los discos persistentes proporcionan una replicación síncrona de datos en dos zonas dentro de una región.

Para el almacenamiento de bajo costo que es redundante en todas las zonas dentro de una región, puedes usar buckets regionales de Cloud Storage.

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 de Filestore Enterprise. Los datos 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 HA y la solidez contra las interrupciones zonales. 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.

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). En esta situación, puedes usar Google Cloud NetApp Volumes completamente administrado a fin de proporcionar almacenamiento SMB de disponibilidad continua (CA) para la base de datos.

Cuando diseñes el almacenamiento para tus cargas de trabajo regionales, 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 una base de datos de terceros, como PostgreSQL, que se implementa en las VMs de Compute Engine. Instalar y administrar una base de datos de terceros implica esfuerzo y costos para las operaciones, como aplicar actualizaciones, supervisar y garantizar la disponibilidad, realizar copias de seguridad y recuperarse de las fallas.

Puedes evitar el esfuerzo y el costo de instalar y administrar una base de datos de terceros a través de un servicio de base de datos completamente administrado como Cloud SQL, AlloyDB para PostgreSQL, Bigtable, Spanner o Firestore. Estos servicios de base de datos de Google Cloud proporcionan Acuerdos de Nivel de Servicio (ANS) de tiempo de actividad e incluyen capacidades predeterminadas de escalabilidad y observabilidad. Si tus cargas de trabajo requieren una base de datos de Oracle, puedes usar la solución Bare Metal que proporciona Google Cloud. Para obtener una descripción general de los casos de uso para los que es adecuado cada servicio de base de datos de Google Cloud, consulta Bases de datos de Google Cloud.

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 regional en Google Cloud que cumpla con los requisitos de seguridad y cumplimiento de las cargas de trabajo.

Protección contra amenazas externas

Para proteger tu aplicación contra amenazas externas como los ataques de denegación de servicio distribuido (DSD) y las secuencias de comandos entre sitios (XSS), puedes usar las políticas de seguridad de Google Cloud Armor. Las políticas de seguridad se aplican en el perímetro, es decir, antes de que el tráfico alcance el nivel web. 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. Además, 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, el nivel web y las bases de datos 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 internas, como las VMs de Compute Engine en esta arquitectura de referencia, puedes usar