Cómo garantizar la disponibilidad de un servicio web en la nube en caso de falla del centro de datos

El artículo describe la opción de garantizar la disponibilidad de un servicio web implementado en la nube en caso de un mal funcionamiento en el centro de datos. La solución propuesta se basa en un compromiso que consiste en una duplicación parcial : se implementa un sistema de respaldo en otro centro de datos, que puede operar en un modo de funcionalidad limitada cuando el centro de datos principal no está disponible. Este esquema está dirigido principalmente a la aplicación de fallas a corto plazo, pero también proporciona la capacidad de convertir rápidamente el sistema de respaldo en el principal en caso de problemas a gran escala.

Descripción del problema

El año pasado, nos tocó un incidente en el centro de datos de un famoso proveedor de servicios en la nube: uno de nuestros servicios no estuvo disponible para los usuarios durante media hora. Luego vimos con nuestros propios ojos que, en caso de problemas en el centro de datos en la nube, prácticamente no hay palancas para restaurar la salud de la aplicación, y no queda nada para el equipo responsable de la aplicación, excepto para ponerla en espera y esperar. Esta experiencia nos hizo pensar seriamente en usar nubes para nuestros productos.

Lo que sucedió exactamente ese día nunca se supo. Estamos acostumbrados a percibir las nubes como un puesto avanzado indestructible, pero esto no es así. La verdad es que no hay una garantía del cien por ciento de disponibilidad del servicio en la nube, como en cualquier otro lugar. Las nubes son una abstracción detrás de la cual se ocultan los mismos bastidores con hierro en los centros de datos y el factor humano. Cualquier hardware tarde o temprano falla (aunque las fallas de hardware para los centros de datos son más probables en una situación normal) Además, hay casos de problemas más graves que conducen a la inaccesibilidad de los centros de datos: incendios, ataques DDoS, desastres naturales, interrupciones en la electricidad e Internet, etc.

Si hablamos del factor humano, entonces esta no es la última causa de accidentes: "según las estadísticas, en el 80% de las fallas de la infraestructura de la red, las personas tienen la culpa" . Las personas, sin importar cuán bien intencionadas sean guiadas, no son confiables. Incluso usted y sus colegas, personas directamente interesadas en la estabilidad de los productos admitidos, probablemente hayan cometido errores, sin mencionar el personal de la compañía de otra persona, para lo cual sus instancias no son diferentes a las de miles de otros. Cualquiera que sea el equipo profesional detrás de la infraestructura, una nueva falla es cuestión de tiempo.

Todo tiene un precio. Cuando se mueve a la nube, obtiene una abstracción simple, con la cual es conveniente trabajar, una dependencia débil de su departamento de operaciones a cambio de un control total sobre la situación. En este caso, si no se cuida de antemano, habiendo previsto la posibilidad de errores de otras personas, nadie lo hará.

Opciones de solucion

Para nosotros, la falta de disponibilidad del servicio, incluso durante varios minutos, ya es crítica. Por lo tanto, decidimos encontrar una manera de asegurarnos contra problemas similares en el futuro, sin abandonar las nubes.

Al comenzar a resolver el problema de la disponibilidad del servicio en la nube, debe tenerse en cuenta que la accesibilidad es un concepto bastante amplio y, dependiendo de lo que se entiende por él, se consideran varios escenarios de su provisión. Aunque este artículo solo trata el problema de la accesibilidad como resultado de una falla del centro de datos, sería apropiado decir algunas palabras sobre las soluciones a otros problemas de accesibilidad.

Disponibilidad como una oportunidad técnica para proporcionar acceso a un recurso durante un tiempo específico en una carga determinada. El problema ocurre cuando el servicio se está ejecutando, pero debido a los recursos limitados y al marco arquitectónico del sistema, no todos los usuarios pueden acceder a él en un determinado tiempo de respuesta. La tarea se resuelve con mayor frecuencia mediante la implementación de instancias adicionales con la aplicación. Con esta escala, las nubes hacen un gran trabajo.

Accesibilidad como la disponibilidad de un servicio web para usuarios de una región específica. La solución obvia aquí es fragmentar. En otras palabras, dividir el sistema en varias aplicaciones independientes en diferentes centros de datos con sus propios datos y asignar a cada usuario a su instancia del sistema, por ejemplo, en función de su ubicación geográfica. Al fragmentar, la falla de un centro de datos en el peor de los casos resultará en la falta de disponibilidad del servicio para solo una parte de los usuarios vinculados a este centro de datos. No es el último argumento a favor de la fragmentación: este es un tiempo de ping diferente al centro de datos en diferentes regiones.

Sin embargo, a menudo las restricciones para trabajar con la nube y la necesidad de descentralización son requisitos legislativos que generalmente se tienen en cuenta incluso en la etapa de diseño del sistema. Estos requisitos incluyen: ley de Yarovaya: almacenamiento de datos personales (PD) de usuarios en Rusia; Reglamento general de protección de datos (GDPR): restricciones a la transferencia transfronteriza de PD de usuarios de la UE a algunos países; y la censura china en Internet, donde TODAS las comunicaciones y TODAS las partes de la aplicación deben ubicarse en China y, preferiblemente, en sus servidores.

El problema de la inaccesibilidad técnica del centro de datos se resuelve duplicando el servicio en otro centro de datos. Esta no es una tarea técnica fácil. El principal obstáculo para el despliegue paralelo de servicios en diferentes centros de datos es la base de datos. Por lo general, los sistemas pequeños utilizan una arquitectura de asistente único. En este caso, la falla del centro de datos con el maestro hace que todo el sistema no funcione. Es posible un esquema de replicación maestro de replicación, pero impone fuertes limitaciones que no todos entienden. De hecho, no escala el registro a la base de datos, pero incluso da una pequeña penalización de tiempo, ya que es necesario confirmar a todos los nodos que la transacción ha sido aceptada. El tiempo de operación de escritura aumenta aún más cuando los nodos deben estar espaciados en diferentes centros de datos.

Justificación de la decisión.

El análisis de la carga en nuestro servicio mostró que, en promedio, aproximadamente el 70% de las llamadas a la API se realizan mediante métodos GET. Estos métodos usan una base de datos de solo lectura.


Distribución de llamadas al método HTTP del servicio web

Creo que estos resultados reflejan la imagen completa de los servicios web generalmente disponibles. Por lo tanto, podemos decir que en la API de servicio web promedio, los métodos de lectura se llaman con mucha más frecuencia que los métodos de escritura .

La segunda declaración que me gustaría presentar es que si hablamos de accesibilidad absoluta, entonces los clientes del servicio realmente necesitan dicha accesibilidad no solo de la gran cantidad de métodos API disponibles, sino solo aquellos que son necesarios para continuar el trabajo "habitual" con el sistema y realizar consultas "normales" . Nadie se molestará si un método al que se accede un par de veces al mes no está disponible durante varios minutos. A menudo, el flujo "normal" está cubierto por métodos de lectura.

Por lo tanto, garantizar la disponibilidad absoluta de solo métodos de lectura ya puede considerarse como una opción posible para una solución a corto plazo al problema de disponibilidad del sistema en caso de falla del centro de datos.

¿Qué queremos implementar?

En caso de fallas en el centro de datos, nos gustaría cambiar el tráfico a un sistema de respaldo en otro centro de datos. En el sistema de copia de seguridad, todos los métodos de lectura deberían estar disponibles, y al llamar a los métodos restantes, si es imposible hacerlo sin escribir en la base de datos, se debe mostrar el error correcto.

En funcionamiento normal, la solicitud del usuario se envía al equilibrador, que a su vez lo redirige a la API principal. Si el servicio principal no está disponible, el equilibrador determina este hecho y redirige las solicitudes al sistema de respaldo que funciona en el modo de funcionalidad limitada. En este momento, el equipo analiza el problema y decide esperar la restauración del centro de datos o cambiar el sistema de respaldo al modo principal.

Algoritmo de implementación

Cambios necesarios de infraestructura

1. Crear una replicación esclava de base de datos en otro centro de datos.
2. Configurar una implementación de servicio web, recopilar registros, métricas en el segundo centro de datos.
3. La configuración del equilibrador para cambiar el tráfico a un centro de datos de repuesto en caso de que el primero no esté disponible.

Cambios de código:

1. Agregar una conexión separada a la réplica en el servicio web.
2. Migre todas las rutas API de solo lectura a una réplica.
3. Para los métodos restantes, la introducción del modo de solo lectura a través de una variable de entorno u otro disparador, en el que en lugar de escribir en la base de datos, funcionará parcialmente o, si su funcionalidad se rompe sin escribir en la base de datos, dará un error correcto.
4. Mejoras en la interfaz para mostrar el error correcto al llamar a los métodos de grabación.

Pros y contras de la solución descrita

Los beneficios

• La principal ventaja del esquema propuesto es que siempre hay un servicio duplicado, en cualquier momento listo para servir a los usuarios. En caso de problemas con el centro de datos principal, no tendrá que escribir scripts de implementación en otra infraestructura y ejecutar todo con prisa.
• La solución es barata de implementar y mantener. Si tiene una arquitectura de microservicio y el producto no necesita uno, sino muchos servicios, en este caso no debería haber ningún problema especial con la transferencia de todos los microservicios a este esquema.
• No hay amenaza de pérdida de datos, ya que siempre hay una copia completa de la base de datos en la réplica en otro centro de datos.
• La solución está destinada principalmente a la conmutación de tráfico temporal, hasta media hora. Es esta media hora la que no es suficiente para navegar en caso de problemas con la infraestructura. Si durante este período no se restaura el primer centro de datos, la réplica esclava de la base de datos se convierte en maestra y el servicio duplicado se convierte en el principal.
• En el esquema propuesto, la aplicación y la base de datos están en el mismo centro de datos. Si tiene una API y una base de datos en diferentes centros de datos, lo mejor es transferirlos a uno: esto reducirá significativamente el tiempo de ejecución de la consulta. Por ejemplo, nuestras mediciones mostraron que para Google Cloud, la solicitud de la API a la base de datos dentro de un centro de datos es en promedio de 6 ms, y cuando se envían datos a otro centro de datos, el tiempo aumenta en decenas de milisegundos.

Desventajas

• El principal inconveniente de todo el esquema es que para el cambio de tráfico instantáneo, se requiere un equilibrador que no esté ubicado en el mismo centro de datos con el servicio principal. El equilibrador es el punto de falla: si el centro de datos con el equilibrador falla, entonces su servicio no estará disponible en ningún caso.
• La necesidad de implementar el código en otro servidor, monitorear recursos adicionales, por ejemplo, monitorear la réplica para que no haya retraso.

Conclusión

No puede crear un sistema que sea resistente a todo tipo de fallas. Sin embargo, protegerse de ciertos tipos es una tarea factible. La solución descrita en el artículo, que permite garantizar la disponibilidad de la aplicación en caso de mal funcionamiento en el centro de datos, puede ser interesante y útil en aplicaciones prácticas en muchos casos.

La conversión de un servicio web normal en un sistema completamente distribuido para proteger contra fallas hipotéticas en el centro de datos es muy poco práctico. A primera vista, incluso el esquema propuesto parece redundante y "pesado", pero estas desventajas están más que superpuestas por sus ventajas y facilidad de implementación. Puede hacer una analogía con el seguro de accidentes: existe una alta probabilidad de que nunca necesite dicho seguro, pero si ocurre un accidente, será bienvenido. Con el esquema propuesto, estará seguro de tener siempre un sistema de respaldo listo, que, para problemas a corto plazo, garantizará la disponibilidad de la mayoría de los métodos de servicio y, en caso de fallas prolongadas, puede convertirse completamente en el principal en cuestión de minutos. Muchos aceptarán pagar este precio por tal confianza.

Cada sistema tiene sus propios parámetros de carga únicos y requisitos de accesibilidad. Es por eso que no hay una respuesta correcta o incorrecta a la pregunta: "¿Puedes confiar completamente en Google Cloud o AWS?" - En cada situación específica él será el suyo.