En esta sección de la guía sobre Google Cloud arquetipos de implementación se describe el arquetipo de implementación regional.
En una arquitectura de nube que usa el arquetipo de implementación regional, las instancias de la aplicación se ejecutan en dos o más zonas de una sola región. Google CloudTodas las instancias de la aplicación usan un repositorio compartido y gestionado de forma centralizada de archivos de configuración. Los datos de la aplicación se replican de forma síncrona en todas las zonas de la arquitectura.
En el siguiente diagrama se muestra la topología de nube de una aplicación de alta disponibilidad que se ejecuta de forma independiente en tres zonas de una mismaGoogle Cloud región:
El diagrama anterior muestra una aplicación con componentes frontend y backend que se ejecutan de forma independiente en tres zonas de una región de Google Cloud . Un balanceador de carga externo reenvía las solicitudes de los usuarios a uno de los frontends. Un balanceador de carga interno reenvía el tráfico de los frontend a los backend. La aplicación usa una base de datos que se replica en todas las zonas. Si se produce una interrupción en una zona, la base de datos pasa a una réplica de otra zona.
La topología del diagrama anterior es robusta frente a los fallos de zona, pero no frente a los fallos de región. Para poder recuperarte de las interrupciones de una región, debes haber desplegado una réplica pasiva de la aplicación en una segunda región (de conmutación por error), tal como se muestra en el siguiente diagrama:
Cuando se produce una interrupción en la región principal, debe promover la base de datos en la región de failover y permitir que las políticas de enrutamiento de DNS dirijan el tráfico al balanceador de carga de la región de failover.
Para optimizar el coste de la infraestructura de conmutación por error, puedes operar la región de conmutación por error con una capacidad inferior desplegando menos recursos.
Casos prácticos
En las siguientes secciones se proporcionan ejemplos de casos prácticos en los que el arquetipo de implementación regional es una opción adecuada.
Aplicación de alta disponibilidad con usuarios de un área geográfica
Recomendamos el arquetipo de implementación regional para las aplicaciones que necesitan solidez frente a las interrupciones de zonas, pero que pueden tolerar cierto tiempo de inactividad causado por interrupciones de regiones. Si falla alguna parte de la pila de aplicaciones, la aplicación seguirá ejecutándose si hay al menos un componente que funcione con capacidad suficiente en cada nivel. Si se produce una interrupción en una zona, la pila de aplicaciones sigue ejecutándose en las demás zonas.
Latencia baja para los usuarios de la aplicación
Si los usuarios de una aplicación se encuentran en un área geográfica, como un solo país, el arquetipo de implementación regional puede ayudar a mejorar el rendimiento de la aplicación percibido por los usuarios. Puedes optimizar la latencia de la red para las solicitudes de los usuarios desplegando la aplicación en la Google Cloud región más cercana a tus usuarios.
Redes de baja latencia entre componentes de aplicaciones
Una arquitectura de una sola región puede ser adecuada para aplicaciones como la computación por lotes, que necesitan conexiones de red de baja latencia y gran ancho de banda entre los nodos de computación. Todos los recursos están en una sola Google Cloud región, por lo que el tráfico de red entre recursos permanece en la región. La latencia de la red entre recursos es baja y no se te aplican costes de transferencia de datos entre regiones. Se siguen aplicando los costes de red dentro de la misma región.
Cumplimiento de los requisitos de residencia y soberanía de los datos
El arquetipo de implementación regional puede ayudarte a cumplir los requisitos normativos de residencia de datos y soberanía operativa. Por ejemplo, un país de Europa puede exigir que todos los datos de los usuarios se almacenen y se acceda a ellos en centros de datos ubicados físicamente en el país. Para cumplir este requisito, puedes desplegar la aplicación en una región deGoogle Cloud Europa.
Factores del diseño
Cuando crees una arquitectura basada en el arquetipo de implementación regional, ten en cuenta los siguientes factores de diseño.
Tiempo de inactividad durante las interrupciones de la región
Cuando se produce una interrupción en una región, la aplicación deja de funcionar. Puedes reducir el tiempo de inactividad provocado por interrupciones en una región manteniendo una réplica pasiva (de conmutación por error) de la pila de infraestructura en otra región. Google Cloud Si se produce una interrupción en la región principal, puedes activar el stack en la región de failover y usar políticas de enrutamiento de DNS para enrutar el tráfico al balanceador de carga de la región de failover.
Coste de los recursos redundantes
Una arquitectura multizona suele tener más recursos en la nube que una implementación de una sola zona. Ten en cuenta el coste de estos recursos en la nube al crear tu arquitectura. En el caso de las aplicaciones que necesitan solidez frente a las interrupciones de las zonas, la ventaja de disponibilidad de una arquitectura multizona puede justificar el mayor coste.
Arquitectura de referencia
Para ver una arquitectura de referencia que puedes usar para diseñar una implementación regional en máquinas virtuales de Compute Engine, consulta Implementación regional en Compute Engine.