Fotograma da película "O noso universo secreto: a vida oculta da célula"

O negocio de investimento é unha das áreas máis complexas do mundo bancario, porque non só hai préstamos, préstamos e depósitos, senón tamén valores, moedas, commodities, derivados e todo tipo de complexidades en forma de produtos estruturados.

Recentemente, observamos un aumento da alfabetización financeira da poboación. Cada vez son máis as persoas que se involucran na negociación dos mercados de valores. As contas de investimento individuais apareceron non hai moito tempo. Permítenche negociar nos mercados de valores e recibir deducións fiscais ou evitar pagar impostos. E todos os clientes que veñen a nós queren xestionar a súa carteira e ver os informes en tempo real. Ademais, a maioría das veces esta carteira é multiproduto, é dicir, as persoas son clientes de varias liñas de negocio.

Ademais, as necesidades dos reguladores, tanto rusos como estranxeiros, están crecendo.

Para satisfacer as necesidades actuais e sentar as bases para futuras actualizacións, desenvolvemos un núcleo empresarial de investimento baseado en Tarantool.

Algunhas estatísticas. O negocio de investimento de Alfa-Bank ofrece servizos de corretaxe para persoas físicas e xurídicas para ofrecer a oportunidade de negociar en varios mercados de valores, servizos de depósito para o almacenamento de valores, servizos de xestión de confianza para persoas físicas con capital privado e grande, servizos de emisión de valores para outras empresas. . O negocio de investimento de Alfa-Bank inclúe máis de 3 mil cotizacións por segundo, que se descargan desde varias plataformas de negociación. Durante a xornada laboral, conclúense máis de 300 mil transaccións nos mercados por conta do banco ou dos seus clientes. Ata 5 mil execucións de pedidos por segundo ocorren en plataformas externas e internas. Ao mesmo tempo, todos os clientes, tanto internos como externos, queren ver as súas posicións en tempo real.

prehistoria

Nalgún lugar desde principios da década de 2000, as nosas áreas de negocio de investimento desenvolvéronse de forma independente: negociación de divisas, servizos de corretaxe, negociación de divisas, negociación de valores e varios derivados. Como resultado, caemos na trampa dos pozos funcionais. Que é? Cada liña de negocio ten os seus propios sistemas que duplican as funcións do outro. Cada sistema ten o seu propio modelo de datos, aínda que operan cos mesmos conceptos: transaccións, instrumentos, contrapartes, cotizacións, etc. E a medida que cada sistema evolucionou de forma independente, xurdiu un zoológico diverso de tecnoloxías.

Ademais, a base de códigos dos sistemas xa está bastante desfasada, porque algúns produtos orixináronse a mediados dos anos 1990. E nalgunhas áreas, isto retardou o proceso de desenvolvemento e houbo problemas de rendemento.

Requisitos para unha nova solución

As empresas decatáronse de que a transformación tecnolóxica é vital para un maior desenvolvemento. Déronnos tarefas:

1. Recolle todos os datos empresariais nun único almacenamento rápido e nun único modelo de datos.
2. Non debemos perder nin cambiar esta información.
3. É necesario versionar os datos, porque en calquera momento o regulador pode solicitar estatísticas de anos anteriores.
4. Non debemos só traer algúns DBMS novos e de moda, senón crear unha plataforma para resolver problemas empresariais.

Ademais, os nosos arquitectos establecen as súas propias condicións:

1. A nova solución debe ser de clase empresarial, é dicir, xa debe estar probada nalgunhas grandes empresas.
2. O modo operativo da solución debería ser fundamental. Isto significa que debemos estar presentes en varios centros de datos simultaneamente e sobrevivir con calma á interrupción dun centro de datos.
3. O sistema debe ser escalable horizontalmente. O caso é que todos os nosos sistemas actuais só son escalables verticalmente e xa estamos alcanzando o teito debido ao baixo crecemento da potencia do hardware. Xa que logo, chegou o momento no que necesitamos ter un sistema escalable horizontalmente para sobrevivir.
4. Entre outras cousas, dixéronnos que a solución tiña que ser barata.

Seguimos a vía normalizada: formulamos os requisitos e contactamos co departamento de compras. De aí recibimos unha lista de empresas que, en xeral, están dispostas a facelo por nós. Contámoslles a todos o problema, e recibimos unha valoración das solucións de seis deles.

No banco, non tomamos a palabra de ninguén; gústanos probar todo nós mesmos. Polo tanto, unha condición obrigatoria do noso concurso era superar as probas de carga. Formulamos tarefas de proba de carga e tres de cada seis empresas xa acordaron implementar unha solución prototipo baseada en tecnoloxías en memoria pola súa conta para probala.

Non vos direi como probamos todo e canto tempo levamos, só resumirei: o mellor rendemento nas probas de carga mostrouse cunha solución prototipo baseada en Tarantool do equipo de desenvolvemento do Grupo Mail.ru. Asinamos un acordo e comezamos o desenvolvemento. Había catro persoas de Mail.ru Group, e de Alfa-Bank había tres desenvolvedores, tres analistas de sistemas, un arquitecto de solucións, un produtor e un Scrum Master.

A continuación falarei de como creceu o noso sistema, como evolucionou, que fixemos e por que exactamente isto.

Desenvolvemento

A primeira pregunta que nos fixemos foi como obter datos dos nosos sistemas actuais. Decidimos que HTTP era moi axeitado para nós, porque todos os sistemas actuais se comunican entre si enviando XML ou JSON a través de HTTP.

Usamos o servidor HTTP integrado en Tarantool porque non necesitamos finalizar sesións SSL e o seu rendemento é suficiente para nós.

Como xa dixen, todos os nosos sistemas viven en diferentes modelos de datos, e na entrada necesitamos achegar o obxecto ao modelo que nós mesmos describimos. Precisaba unha linguaxe que permitise transformar os datos. Escollemos o imperativo Lua. Executamos todo o código de conversión de datos nunha caixa de probas; este é un lugar seguro máis aló do que non vai o código en execución. Para iso, simplemente cargamos o código necesario, creando un ambiente con funcións que non poden bloquear nin soltar nada.

Despois da conversión, débese comprobar que os datos cumpren co modelo que estamos a crear. Discutimos durante moito tempo cal debería ser o modelo e que linguaxe usar para describilo. Escollemos Apache Avro porque a linguaxe é sinxela e ten soporte de Tarantool. As novas versións do modelo e do código personalizado pódense poñer en funcionamento varias veces ao día, mesmo con carga ou sen carga, a calquera hora do día, e adaptarse aos cambios moi rapidamente.

Despois da verificación, os datos deben ser gardados. Facemos isto usando vshard (temos réplicas xeo-dispersas de fragmentos).

Ademais, a especificidade é tal que á maioría dos sistemas que nos envían datos non lles importa se os recibimos ou non. É por iso que implementamos unha cola de reparación dende o principio. Que é? Se por algún motivo un obxecto non se somete a transformación ou verificación de datos, aínda confirmamos a recepción, pero ao mesmo tempo gardamos o obxecto na cola de reparación. É coherente e está situado no almacén de datos empresarial principal. Inmediatamente escribimos unha interface de administrador para el, varias métricas e alertas. Como resultado, non perdemos datos. Aínda que algo cambiou na fonte, se o modelo de datos cambiou, detectarémolo inmediatamente e poderemos adaptalo.

Agora cómpre aprender a recuperar os datos gardados. Analizamos coidadosamente os nosos sistemas e vimos que a pila clásica de Java e Oracle contén necesariamente algún tipo de ORM que converte os datos de relacional a obxecto. Entón, por que non dar inmediatamente obxectos aos sistemas en forma de gráfico? Así que adoptamos GraphQL con gusto, que cumpriu todas as nosas necesidades. Permítelle recibir datos en forma de gráficos e sacar só o que precisa agora. Incluso podes versión a API con moita flexibilidade.

Case inmediatamente decatámonos de que os datos que estabamos a extraer non eran suficientes. Creamos funcións que se poden vincular a obxectos do modelo, esencialmente, campos calculados. É dicir, achegamos unha determinada función ao campo, que, por exemplo, calcula o prezo medio da cotización. E o consumidor externo que solicita os datos nin sequera sabe que se trata dun campo calculado.

Implementou un sistema de autenticación.

Entón notamos que varios papeis cristalizaron na nosa decisión. Un rol é unha especie de agregador de funcións. Normalmente, os roles teñen diferentes perfís de uso do equipo:

• T-Connect: xestiona conexións entrantes, CPU limitada, baixo consumo de memoria, sen estado.
• IB-Core: transforma os datos que recibe mediante o protocolo Tarantool, é dicir, opera con táboas. Tampouco almacena estado e é escalable.
• Almacenamento: só almacena datos, non utiliza ningunha lóxica. Este rol implementa as interfaces máis sinxelas. Escalable grazas a vshard.

É dicir, utilizando roles, desacoplamos diferentes partes do clúster entre si, que se poden escalar independentemente unhas das outras.

Entón, creamos unha gravación asíncrona do fluxo de datos transaccionais e unha cola de reparación cunha interface de administración. A gravación é asíncrona desde o punto de vista empresarial: se temos garantía de escribir datos para nós mesmos, non importa onde, entón confirmarémolo. Se non se confirma, algo saíu mal e hai que enviar os datos. Esta é a gravación asíncrona.

Probas

Desde o inicio do proxecto, decidimos que tentaríamos implementar o desenvolvemento dirixido por probas. Escribimos probas unitarias en Lua usando o framework tarantool/tap e probas de integración en Python usando o framework pytest. Ao mesmo tempo, implicamos tanto a desenvolvedores como a analistas na redacción de probas de integración.

Como usamos o desenvolvemento impulsado por probas?

Se queremos algunha función nova, primeiro tentamos escribir unha proba. Cando descubrimos un erro, asegurámonos de escribir primeiro unha proba e só despois solucionalo. Ao principio é difícil traballar así, hai malentendidos por parte dos empregados, incluso sabotaxe: "Imos arranxalo rapidamente agora, fagamos algo novo e despois cubrimos con probas". Só que este "máis tarde" case nunca chega.

Polo tanto, debes obrigarte a escribir probas primeiro e pedirlle aos demais que o fagan. Créame, o desenvolvemento impulsado por probas trae beneficios incluso a curto prazo. Sentirás que a túa vida se fixo máis fácil. Consideramos que o 99% do código agora está cuberto por probas. Isto parece moito, pero non temos ningún problema: as probas execútanse en cada commit.

Non obstante, o que máis nos gusta son as probas de carga, consideramos que é a máis importante e realizámola con regularidade.

Vouvos contar unha pequena historia sobre como levamos a cabo a primeira fase de probas de carga dunha das primeiras versións. Instalamos o sistema no portátil do programador, activamos a carga e obtivemos 4 mil transaccións por segundo. Bo resultado para un portátil. Instalámolo nun banco de carga virtual de catro servidores, máis débil que en produción. Despregado ao mínimo. Lanzámolo e obtemos un resultado peor que nun portátil nun fío. Contido de choque.

Estabamos moi tristes. Observamos a carga do servidor, pero resulta que están inactivos.

Chamamos aos desenvolvedores, e eles explícannos, persoas que veñen do mundo de Java, que Tarantool é de fío único. Só pode ser usado eficazmente por un núcleo de procesador baixo carga. Despois despregamos o máximo número posible de instancias de Tarantool en cada servidor, activamos a carga e xa recibimos 14,5 mil transaccións por segundo.

Déixame explicar de novo. Debido á división en roles que usan os recursos de forma diferente, os nosos roles responsables do procesamento das conexións e da transformación de datos cargaban só o procesador, e estritamente proporcionais á carga.

Neste caso, a memoria utilizouse só para procesar conexións entrantes e obxectos temporais.

Pola contra, nos servidores de almacenamento, a carga do procesador aumentou, pero moito máis lenta que nos servidores que procesan conexións.

E o consumo de memoria creceu en proporción directa á cantidade de datos cargados.

Servizos

Para desenvolver o noso novo produto específicamente como plataforma de aplicacións, creamos un compoñente para a implantación de servizos e bibliotecas nel.

Os servizos non son só pequenas pezas de código que operan nalgúns campos. Poden ser estruturas bastante grandes e complexas que forman parte dun clúster, verifican datos de referencia, executan a lóxica empresarial e devolven respostas. Tamén exportamos o esquema de servizo a GraphQL e o consumidor recibe un punto de acceso universal aos datos, cunha introspección en todo o modelo. É moi cómodo.

Dado que os servizos conteñen moitas máis funcións, decidimos que debería haber bibliotecas nas que moveremos o código de uso frecuente. Engadímolos á contorna segura, xa que comprobamos previamente que non nos rompe nada. E agora podemos asignar ambientes adicionais ás funcións en forma de bibliotecas.

Queriamos ter unha plataforma non só para o almacenamento, senón tamén para a informática. E como xa tiñamos unha morea de réplicas e fragmentos, implementamos unha especie de computación distribuída e chamámoslle map reduce, porque resultou similar ao map reduce orixinal.

Sistemas antigos

Non todos os nosos sistemas legados poden chamarnos por HTTP e usar GraphQL, aínda que admiten o protocolo. Por iso, creamos un mecanismo que permite replicar os datos nestes sistemas.

Se algo cambia para nós, activaranse activadores únicos na función Almacenamento e a mensaxe cos cambios acaba na cola de procesamento. Envíase a un sistema externo usando un rol de replicador separado. Este rol non almacena o estado.

Novas melloras

Como lembrades, dende o punto de vista empresarial, fixemos gravación asíncrona. Pero entón déronse conta de que non sería suficiente, porque hai unha clase de sistemas que precisan recibir inmediatamente unha resposta sobre o estado da operación. Así que ampliamos o noso GraphQL e engadimos mutacións. Encaixan organicamente no paradigma existente de traballar con datos. Para nós, este é un punto único de lectura e escritura para outra clase de sistemas.

Tamén nos demos conta de que os servizos por si só non serían suficientes para nós, porque hai informes bastante pesados ​​que hai que construír unha vez ao día, á semana, ao mes. Isto pode levar moito tempo e os informes poden incluso bloquear o ciclo de eventos de Tarantool. Polo tanto, creamos roles separados: planificador e corredor. Os corredores non almacenan o estado. Realizan tarefas pesadas que non podemos calcular sobre a marcha. E o rol de planificador supervisa o calendario de lanzamento destas tarefas, que se describe na configuración. As tarefas en si almacénanse no mesmo lugar que os datos empresariais. Cando chega o momento oportuno, o planificador toma a tarefa, dálla a algún corredor, que a conta e garda o resultado.

Non todas as tarefas deben executarse nun horario. Hai que ler algúns informes baixo demanda. En canto chega este requisito, créase unha tarefa no sandbox e envíase ao corredor para a súa execución. Despois dun tempo, o usuario recibe unha resposta asíncrona de que todo foi calculado e o informe está listo.

Inicialmente, adherimos ao paradigma de almacenar todos os datos, versionalos e non eliminalos. Pero na vida, de cando en vez aínda tes que borrar algo, sobre todo algunha información bruta ou intermedia. En función do caducidade, creamos un mecanismo para limpar o almacenamento dos datos obsoletos.

Tamén entendemos que tarde ou cedo chegará unha situación na que non haberá espazo suficiente para almacenar os datos na memoria, pero, con todo, os datos deben ser almacenados. Para estes efectos, en breve faremos almacenamento en disco.

Conclusión

Comezamos coa tarefa de cargar datos nun único modelo e levamos tres meses desenvolvéndoo. Tiñamos seis sistemas de subministración de datos. Todo o código de transformación nun único modelo é de preto de 30 mil liñas en Lua. E a maior parte do traballo aínda está por diante. Ás veces hai falta de motivación dos equipos veciños, e son moitas as circunstancias que complican o traballo. Se algunha vez te enfrontas a unha tarefa similar, multiplica por tres ou ata catro o tempo que che parece normal para a súa implementación.

Lembra tamén que os problemas existentes nos procesos empresariais non se poden resolver mediante un novo DBMS, aínda que sexa moi produtivo. O que quero dicir? Ao comezo do noso proxecto, creamos a impresión entre os clientes de que agora traeremos unha nova base de datos rápida e viviremos! Os procesos irán máis rápido, todo estará ben. De feito, a tecnoloxía non resolve os problemas que teñen os procesos empresariais, porque os procesos empresariais son persoas. E hai que traballar coa xente, non coa tecnoloxía.

O desenvolvemento impulsado por probas pode ser doloroso e lento nas fases iniciais. Pero o efecto positivo deste será perceptible mesmo a curto prazo, cando non precisa facer nada para realizar probas de regresión.

É moi importante realizar probas de carga en todas as fases de desenvolvemento. Canto antes note algún fallo na arquitectura, máis fácil será solucionalo, o que che aforrará moito tempo no futuro.

Non hai nada de malo con Lua. Calquera pode aprender a escribir nel: desenvolvedor Java, desenvolvedor JavaScript, desenvolvedor Python, front-end ou back-end. Incluso os nosos analistas escriben sobre el.

Cando falamos do feito de que non temos SQL, aterroriza á xente. "Como se obteñen datos sen SQL? Isto é posible? Certamente. Nun sistema de clases OLTP, SQL non é necesario. Hai unha alternativa na forma dalgún tipo de linguaxe que o devolve inmediatamente a unha vista orientada ao documento. Por exemplo, GraphQL. E hai unha alternativa en forma de computación distribuída.

Se entendes que terás que escalar, deseña a túa solución en Tarantool de forma que poida executarse en paralelo en decenas de instancias de Tarantool. Se non o fas, será difícil e doloroso máis tarde, xa que Tarantool só pode usar un núcleo do procesador de forma efectiva.

Fonte: www.habr.com