Multirregión es una decisión de coste antes que de arquitectura

La conversación suele empezar después de un incidente. Una región tuvo un mal día, el servicio estuvo caído tres horas y alguien de dirección pregunta por qué el sistema no es multirregión. La respuesta de ingeniería que viene después es un diagrama. La respuesta que debería venir es un precio y un tiempo de recuperación, uno al lado del otro, para tres opciones.

Multirregión no es una capacidad que añades. Es un nivel que compras, y los niveles se diferencian en aproximadamente un orden de magnitud de coste y en minutos frente a horas de recuperación. La mayoría de los entornos que lo piden deberían comprar el nivel de abajo.

Los niveles, y qué compra cada uno

Copia y restauración. Datos replicados a una segunda región, sin cómputo levantado. Recuperar significa aprovisionarlo todo y restaurar, lo que son horas o un día según el volumen de datos. El coste es solo almacenamiento y transferencia. Es la respuesta correcta para sistemas internos y para todo aquello donde un día de parada es sobrevivible.

Reserva fría. Infraestructura definida en código y desplegable en la segunda región, datos replicando de forma continua, nada en marcha. Recuperar es el tiempo de aplicar tu código de infraestructura, restaurar el estado más reciente y redirigir el tráfico, en la práctica una hora o varias. El coste es almacenamiento, transferencia y la disciplina de mantener el código genuinamente desplegable, que es la parte que se degrada.

Reserva templada. Una copia reducida pero en marcha: réplica de base de datos viva, un conjunto mínimo de instancias de aplicación levantadas, todo cableado. Recuperar es promover la base de datos y escalar, lo que son minutos. El coste es aproximadamente la huella mínima de la segunda región más la replicación, habitualmente entre un cuarto y la mitad del coste principal.

Caliente, activo-activo. Las dos regiones sirviendo tráfico. La recuperación es casi instantánea y, más valioso, el camino de conmutación se ejercita continuamente en vez de en teoría. El coste es más del doble del principal, porque además pagas el tráfico de datos entre regiones, una capa de datos capaz de escrituras multirregión y la ingeniería para construirlo.

El salto que sorprende no es de fría a templada. Es de templada a activo-activo, donde el coste aterriza sobre todo en ingeniería y en la capa de datos, no en horas de instancia.

El dato es lo que lo decide todo

El cómputo es fácil de duplicar. La base de datos es el problema, y la forma del problema es el objetivo de punto de recuperación.

La replicación asíncrona es lo que ejecuta casi todo el mundo. Es barata y tiene retraso de replicación, lo que significa que una conmutación pierde lo que no se hubiera replicado: normalmente segundos, a veces minutos bajo carga. Si tu objetivo de punto de recuperación es cero, la replicación asíncrona no lo cumple, y deberías decirlo en voz alta en lugar de dejar que un diagrama insinúe lo contrario.

La replicación síncrona entre regiones significa que cada escritura espera el viaje de ida y vuelta. Entre regiones europeas eso son decenas de milisegundos añadidos a cada transacción. Entre continentes no es viable para una carga interactiva. Es la física que ninguna arquitectura elimina.

Las escrituras multirregión necesitan o una base de datos construida para ello, aceptando su modelo de consistencia y su precio, o una aplicación particionada de forma que cada registro tenga una región de residencia. Lo segundo suele ser la mejor respuesta de ingeniería y es una reescritura, no una configuración.

Y hay un segundo problema de copias: el almacenamiento de objetos, los índices de búsqueda, las cachés, las colas de mensajes y el almacén de secretos necesitan todos su historia de replicación, y cada uno es un sitio donde una conmutación descubre un hueco.

Las facturas que no planificaste

• La transferencia de datos entre regiones, cobrada por gigabyte, de forma continua, en las dos direcciones si la aplicación es parlanchina. En un entorno con mucha replicación esto se convierte en una de las líneas mayores, igual que en almacenamiento y transferencia en Azure.
• Licencias duplicadas y precios de proveedor por nodo, que con frecuencia se duplican en vez de escalar con el uso.
• Los costes fijos de la segunda región. Pasarelas NAT, balanceadores, planos de control de clúster y conectividad privada son cargos por región que existen fluya tráfico o no.
• Observabilidad duplicada. El doble de logs, métricas y trazas, en un sistema con precio por gigabyte.
• Capacidad reservada que no aplica. Un compromiso acotado a una región deja la segunda a tarifa bajo demanda. Comprueba el alcance antes de suponer que tu descuento viaja.

La conmutación de DNS es más lenta de lo que sugiere el tiempo de vida

El mecanismo de conmutación es una segunda fuente de sorpresas. La conmutación basada en DNS depende del intervalo de comprobación de salud más el tiempo de vida del registro más el comportamiento de los resolutores, y los resolutores ignoran los tiempos de vida cortos más a menudo de lo que admite la documentación. Presupuesta minutos, no segundos, y pruébalo con clientes reales y no con una herramienta de consulta.

Un balanceador global de difusión por proximidad mueve el tráfico más rápido porque no depende de la caché del cliente, a cambio de atarte al borde de un proveedor. El reintento en el cliente contra un segundo extremo es el más rápido de todos y exige controlar el cliente.

Elijas el que elijas, la conmutación tiene que poder dispararla una persona con una sola acción, y esa acción tiene que estar documentada y practicada. Una conmutación que requiere que seis personas se pongan de acuerdo tarda más que la caída.

Por qué multizona es la respuesta correcta más a menudo de lo que se admite

Un despliegue multizona en una sola región sobrevive al fallo de un centro de datos, que es con mucha diferencia el fallo de infraestructura más común. Cuesta muy poco más porque las zonas están lo bastante cerca para replicación síncrona y, en la mayoría de proveedores, el tráfico entre zonas dentro de una región se cobra poco o nada.

Los fallos de región completa son raros, y cuando ocurren van acompañados a menudo de una degradación del plano de control que además afecta a tu capacidad de conmutar. Mientras tanto, muchísimas caídas que los equipos achacan a la región las causó un despliegue malo, un certificado caducado o una reserva de conexiones agotada, y multirregión no protege de ninguna de esas.

Calcula lo que cuesta una hora de caída, multiplícalo por las horas que habría añadido el nivel más barato y compáralo con el coste anual del nivel más caro. En la mayoría de los negocios la respuesta honesta es multizona más una restauración probada, que es la disciplina de objetivos de recuperación y la prueba de restauración.

La región que nunca se ha probado no funciona

Todas las conmutaciones que hemos visto por primera vez han encontrado algo: una imagen de máquina que solo existe en la región principal, un secreto creado a mano, un certificado acotado al balanceador de una región, una cuota que está a cero porque nadie la pidió, un registro DNS con una dirección fija, una condición de identidad anclada a una región.

Prueba de forma programada y, donde la arquitectura lo permita, ejecuta una conmutación real y quédate en la región secundaria un tiempo en vez de volver de inmediato. Los entornos que hacen esto descubren que su conmutación funciona. Los que no, se enteran durante el incidente. Un experimento de pérdida de zona, como el de los cinco primeros experimentos de caos, es el ensayo barato.

Qué hacer esta semana

Escribe tres números: lo que le cuesta al negocio una hora de caída total, cuál es tu tiempo de recuperación real si tuvieras que reconstruir hoy en otra región, y cuánto costaría al mes el nivel de reserva templada. Esa tabla es la decisión, y normalmente la toma por ti. Construimos exactamente esa comparación en la fase de resiliencia de un proyecto cloud.