En esta sección de la guía de arquetipos de implementación de Google Cloud, se describe el arquetipo de implementación regional.
En una arquitectura en la nube que usa el arquetipo de implementación regional, las instancias de la aplicación se ejecutan en dos o más zonas dentro de una sola región de Google Cloud. Todas las instancias de la aplicación usan un repositorio compartido de archivos de configuración administrado y centralizado. 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 la nube para una aplicación con alta disponibilidad que se ejecuta de forma independiente en tres zonas dentro de una sola región de Google Cloud:
En el diagrama anterior, se muestra una aplicación con componentes de frontend y backend que se ejecutan de forma independiente en tres zonas de una región de Google Cloud. Un balanceador de cargas externo reenvía las solicitudes del usuario a uno de los frontends. Un balanceador de cargas interno reenvía el tráfico de los frontends a los backends. La aplicación usa una base de datos que se replica en todas las zonas. Si ocurre una interrupción zonal, la base de datos se conmuta por error a una réplica en otra zona.
La topología del diagrama anterior es sólida contra las interrupciones zonales, pero no ante las interrupciones regionales. Para poder recuperarte de las interrupciones regionales, debes haber implementado una réplica pasiva de la aplicación en una segunda región (de conmutación por error), como se muestra en el siguiente diagrama:
Cuando se produce una interrupción en la región principal, debes promover la base de datos en la región de conmutación por error y permitir que las políticas de enrutamiento de DNS enruten el tráfico al balanceador de cargas en la región de conmutación por error.
Para optimizar el costo de la infraestructura de conmutación por error, puedes operar la región de conmutación por error a una capacidad más baja mediante la implementación de menos recursos.
Casos de uso
En las siguientes secciones, se proporcionan ejemplos de casos de uso para los que el arquetipo de implementación regional es una opción adecuada.
Aplicación con alta disponibilidad con usuarios dentro de un área geográfica
Recomendamos el arquetipo de implementación regional para aplicaciones que necesitan solidez contra las interrupciones de zona, pero pueden tolerar cierto tiempo de inactividad causado por interrupciones de región. Si alguna parte de la pila de aplicaciones falla, la aplicación continúa 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 los usuarios de una aplicación se encuentran dentro de un área geográfica, como un solo país, el arquetipo de implementación regional puede ayudar a mejorar el rendimiento percibido por el usuario de la aplicación. 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 los usuarios.
Herramientas de redes de baja latencia entre componentes de aplicaciones
Una arquitectura de una sola región puede ser adecuada para aplicaciones como el procesamiento por lotes que necesita 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 por transferencia de datos entre regiones. Aún se aplican los costos de red dentro de la región.
Cumplimiento de los requisitos de soberanía y residencia de datos
El arquetipo de implementación regional puede ayudarte a cumplir con los requisitos reglamentarios para la residencia de los datos y la soberanía operativa. 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 dentro del país. Para cumplir con este requisito, puedes implementar la aplicación en una región de Google Cloud en Europa.
Consideraciones del diseño
Cuando compiles 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 regionales
Cuando se produce una interrupción regional, la aplicación está inactiva. Para reducir el tiempo de inactividad que causan las interrupciones regionales, mantén una réplica pasiva (de conmutación por error) de la pila de infraestructura en otra región de Google Cloud. Si se produce una interrupción en la región principal, puedes activar la pila en la región de conmutación por error y usar políticas de enrutamiento de DNS para enrutar el tráfico al balanceador de cargas en la región de la conmutación por error.
Costo de los recursos redundantes
Por lo general, una arquitectura de varias zonas tiene más recursos en la nube que una implementación de una sola zona. Ten en cuenta el costo de estos recursos en la nube cuando compiles tu arquitectura. Para las aplicaciones que necesitan solidez contra interrupciones zonales, la ventaja de disponibilidad de una arquitectura multizona puede justificar el costo más alto.
Arquitectura de referencia
Si quieres obtener una arquitectura de referencia que puedas usar para diseñar una implementación regional en VMs de Compute Engine, consulta Implementación regional en Compute Engine.