¿Cómo se organiza un banco moderno? Hay un back office donde se realizan varias operaciones, se mantienen cuentas e informes. Hay una oficina intermedia donde se toman decisiones y se evalúan los riesgos, donde se evalúan los riesgos de crédito y se contrarrestan los estafadores. Y hay una oficina principal donde atienden a los clientes y son responsables de su interacción con el banco a través de varios canales.
Sberbank tiene cientos de sistemas de disponibilidad y confiabilidad variables. Tiene su propio desarrollo y soluciones en caja con diferentes grados de personalización, diferentes SLA. Todos los sistemas están integrados entre sí de muchas maneras. En esta publicación, le diremos cómo se construye todo este hormiguero front-end de tal manera que proporcione un servicio continuo al cliente.
Comencemos con la teoría. Los principios clave por los cuales se construye un sistema a prueba de fallas se pueden tomar prestados de un submarino:
- El submarino está dividido en compartimentos independientes. Si un compartimento se inunda, el resto aún sobrevive.
- Todos los componentes críticos están reservados. Motores, tanques de oxígeno. Y los Beatles también reservaron periscopios con ojos de buey.
- El submarino está protegido de condiciones críticas en la superficie; si es necesario, puede ir más profundo y trabajar allí como si nada hubiera pasado.
Ilustramos el primer principio con un ejemplo de nuestra práctica. Teníamos un sistema de caché distribuido. Y una vez bajo carga, uno de los nodos de datos de caché falló. Está bien: para mantener una replicación adecuada, el controlador redistribuyó los datos a los nodos restantes. Pero como resultado de la redistribución, el tráfico de red aumentó y los paquetes comenzaron a perderse, incluida la sobrecarga de caché. En un momento, el controlador decidió que otro nodo de datos falló, redistribuyó los datos nuevamente, el tráfico aumentó ... Como resultado, en menos de un minuto el sistema se cayó por completo. Afortunadamente, fue un circuito de carga y nadie resultó herido. Pero pasamos mucho tiempo buscando la causa.
Se puede argumentar que esto no sucede con las bases de datos en clúster y los servidores de gama alta: hay redundancia incorporada a nivel de hardware. Citando a Werner Vogels, CTO Amazon: "Todo falla todo el tiempo". Nos caímos y agrupamos bases de datos, y servidor de alta gama. Cayó debido a errores de configuración, debido a problemas en el software de gestión. Con la solución de cada problema, nuestra confianza en tales soluciones disminuyó. Como resultado, llegamos a la conclusión: solo aquellos sistemas que están divididos en partes independientes entre sí, principalmente independientes en administración, no se niegan.
Arquitectura multibloques
La solución a nuestros problemas fue la arquitectura de bloques múltiples. En él, todos los componentes de hardware, incluidas las bases de datos, se dividen en bloques sueltos, casi independientes. Cada bloque sirve a parte de los clientes, como al fragmentar en bases de datos. Los nodos dentro de cada bloque están reservados en todos los niveles, incluida la redundancia geográfica. Cualquier problema en un bloque no afecta a los demás. Con un aumento en el número de clientes, podemos agregar fácilmente nuevos bloques y continuar trabajando normalmente.
Arquitectura general de bloques. Todos los bloques están reservados según el esquema 2N. Cada centro de datos tiene un potente equilibrador de carga de hardware. Los centros de datos están conectados por 2-3 canales de comunicación independientes.Los servidores se distribuyen en bloques de cinco tipos:
- Enrutador: una unidad de control que distribuye clientes al resto de las unidades
- Bloque de clientes: el bloque principal que sirve hasta 10 millones de clientes
- Bloque piloto: aquí probamos nuevas versiones de aplicaciones en clientes leales (aproximadamente 300 mil personas, principalmente empleados de Sberbank)
- Unidad de invitado: los usuarios no autenticados reciben servicios a través de ella; aquellos, por ejemplo, que visitan el sitio
- Bloque de reserva: un bloque de seguridad lo suficientemente potente como para reemplazar dos bloques de clientes a la vez
Dentro de cada bloque, el servidor de aplicaciones y el servidor web están separados por canales de servicio, pero las bases de datos son comunes. Entonces podemos aislar los escenarios de falla más comunes para que no vayan más allá de los límites de nuestro canal.
Como funciona
Primero, el usuario ingresa a la unidad de enrutador. Este bloque comprueba a qué bloque de cliente pertenece la persona y lo envía allí (o al bloque de invitado). Además, una persona trabaja tranquilamente dentro de su bloque. Si se produce una falla en la unidad nativa, la persona regresa al enrutador y recibe automáticamente una dirección a la unidad de respaldo para continuar el trabajo.
¿Qué les sucede a los datos durante la operación? La información sobre la interacción del cliente con el banco se replica continuamente desde los bloques del cliente a la base de datos de archivo. Una vez que conoce al usuario, la unidad de respaldo extrae la información necesaria sobre él de la base de datos de archivo y, si es necesario, proporciona datos, para que el usuario no se congele cuando surgen problemas de nuestra parte.
Las operaciones que se realizan en la unidad de respaldo se almacenan en ella. Cuando se restaura el bloque de cliente nativo del usuario, vuelve. Las operaciones acumuladas en el bloque de respaldo se transfieren de forma asíncrona a los bloques de cliente necesarios. Si bien los datos se reducen a la coherencia, el cliente ve un mensaje que indica que todas las operaciones han sido aceptadas y guardadas, pero debido al trabajo técnico, es posible que no se muestren las últimas operaciones.
Esquema general del sistema.En algunos casos, el cambio al bloque de respaldo se planifica por adelantado, por ejemplo, al actualizar en el bloque del cliente. Luego, la unidad de respaldo no recoge las sesiones del cliente, sino que en un momento determinado simplemente inicia todas las operaciones nuevas. Si necesita cambiar urgentemente a la unidad de respaldo, el administrador puede deshabilitar todas las sesiones. En este caso, la sesión del usuario se interrumpirá y él iniciará una nueva en la unidad de respaldo. La unidad de enrutador, por cierto, tiene su propia unidad de respaldo dedicada. Entonces nadie queda sin una rueda de repuesto.
Actualización de sistemas
Las nuevas versiones de software se implementan primero en el bloque piloto y se muestran a un público limitado. Luego, gradualmente, en los bloques del cliente, y ya al final, en los bloques de reserva. Entonces, si hay problemas en el bloque del cliente con la nueva versión del software, podemos transferir clientes al bloque de respaldo desde el anterior.
Cuando una nueva funcionalidad llega a un bloque, no se activa automáticamente. Los administradores hacen esto usando casillas de verificación - alternancia de funciones. Puede cambiar los clientes a la nueva versión por grupos: así es como verificamos la reacción de las actualizaciones al crecimiento de la audiencia.
Autonomía
Nuestro sistema en sí mismo es confiable, pero aún depende del backend utilizado para las operaciones. ¿Cómo protegerse de los problemas? Usamos tres herramientas.
- Solicitudes pendientes . El cliente solicita que se complete la operación. Lo guardamos en nuestra base de datos e intentamos ejecutarlo en el backend. Si el backend no responde, le mostramos al cliente un mensaje de que la operación ha sido aceptada y está siendo procesada. Cuando aumenta el backend, un "acoplador" separado lee las operaciones incompletas de la base de datos y las "empuja" en lotes en el sistema de back-end. Para no sobrecargar la tabla principal con operaciones con una gran cantidad de consultas de baja eficiencia, también utilizamos la llamada tabla de tokens, una lista de identificadores de operaciones incompletas. Para no dejar caer el backend que acaba de aumentar en cientos de miles de operaciones, utilizamos el procesamiento por lotes: dejamos caer doscientas operaciones y esperamos, por ejemplo, unos segundos.
Pero, ¿qué ocurre si se producen cambios importantes entre la solicitud del usuario y la recuperación del backend? Por ejemplo, ¿se han movido los tipos de cambio? En este caso, se activa la doble verificación. Estas operaciones se guardan al ingresar y luego se verifican después de la ejecución. Si algo no converge, la operación se ajustará o rechazará.
- Almacenamiento en caché de datos . Cuando un usuario ingresa, por ejemplo, a Sberbank Online, toda la información necesaria sobre él ya está visible: facturas, tarjetas, préstamos, etc. Estos datos se solicitan a través de un bus de servicio de una docena de sistemas. Si la respuesta se recopiló rápidamente, en unos segundos, mostramos los datos al cliente y los guardamos en la memoria caché del sistema de nuestra base de datos. De lo contrario, buscamos en la base de datos los datos almacenados en caché previamente y se los mostramos al cliente. Por supuesto, para esto, el caché no debe ser anterior a cierta edad. Sin embargo, cuando el bus de servicio recopila los datos necesarios a pedido, se actualiza en la memoria caché de la base de datos y se envía al cliente en lugar de los anteriores.
Al usar la aplicación, esto significa que una persona verá el estado de su cuenta unos segundos después de ingresar. Aunque los datos pueden estar algo desactualizados. Si esto sucede, luego de unos segundos, los datos generalmente se reemplazan por los reales, lo que significa que el bus de servicio ha recopilado todo lo que necesita.
Además, tenemos almacenamiento en caché previo mediante la replicación. Principalmente para diferentes datos de referencia. Precargamos estos datos en el backend, el cliente realiza una solicitud de la operación con calma y los enviamos. Incluso si los sistemas responsables de mantener los datos no funcionan, el usuario no tiene que esperar una vez más.
- Descansos técnicos . Si el sistema de fondo se ha bloqueado o está en mantenimiento, lo marcamos. Y luego las operaciones que lo atraviesan se encuentran inmediatamente con la negativa. Por lo tanto, evitamos que el servidor de aplicaciones se desborde con solicitudes que esperan una respuesta por tiempo de espera. En este modo, se puede utilizar el almacenamiento en caché de operaciones y datos que describimos anteriormente. Los descansos técnicos se establecen para cada escenario de integración, manualmente por el administrador o automáticamente, en función del número de solicitudes.
En cualquier caso, buscamos minimizar las expectativas del usuario: si hay problemas, inmediatamente recibe un mensaje sobre la imposibilidad de la operación. Intentamos minimizar la cantidad de tales mensajes, por lo tanto, aumentamos el tiempo de vida de algunos datos almacenados en caché; esto nos permite extender la interacción normal con los servicios del banco.
En algunos escenarios, el almacenamiento en caché no debe llevarse, por ejemplo, al emitir efectivo. Es posible fraude por parte del cliente. Dichas operaciones en cajeros automáticos y sucursales no se almacenan en caché. En el banco de Internet, esto es más fácil: aceptamos la solicitud, luego la procesamos o la rechazamos.
Como resultado, observando los principios descritos en el artículo, puede obtener sistemas con una disponibilidad de 99.99% o más.
Nuestros planes
Ahora, los planes son minimizar el tiempo de comercialización de nuestro sistema único, para garantizar la omnicanalidad, teniendo en cuenta las características técnicas y comerciales de los canales. Y también migre sistemas heredados mientras mantiene su operatividad durante el traslado.
Agradecemos a Roman Shekhovtsov por su asistencia activa en la preparación de la publicación.