Архитектура и възможности на Tarantool Data Grid

През 2017 г. спечелихме конкурса за разработка на транзакционно ядро на инвестиционния бизнес на Альфа-Банк и започнахме работа (на HighLoad++ 2018 с доклад за ядрото на инвестиционния бизнес изнасяше Владимир Дрынкин, ръководител на направление транзакционно ядро на инвестиционния бизнес на Альфа-банк). Тази система трябваше да агрерира данни за сделки от различни източници в различни формати, да приведe данните в унифициран вид, да ги съхранява и да предоставя достъп до тях.

В процеса на разработка системата еволюира и обогатява функционала си, и в някой момент осъзнахме, че изграждаме нещо много по-голямо от просто приложен софтуер, създаден за решаване на строго определен кръг задачи: получихме система за изграждане на разпределени приложения с персистентно хранилище. Полученият от нас опит легна в основата на нов продукт — Tarantool Data Grid (TDG).

Искам да ви разкажа за архитектурата на TDG и решенията, до които стигнахме в процеса на разработка, да ви запозная с основния функционал и да покажа как нашият продукт може да стане основа за изграждане на завършени решения.

Архитектурно разделихме системата на отделни роли, всяка от които е отговорна за решаване на определен кръг задачи. Един стартиран екземпляр на приложението реализира един или няколко типа роли. В клъстъра могат да има няколко роли от един тип:

Connector

Конекторът отговаря за връзката с външния свят; задачата му е да приеме заявка, да я анализира и ако е успешна, да изпрати данните за обработка в входния процесор. Поддържаме формати HTTP, SOAP, Kafka, FIX. Архитектурата позволява лесно добавяне на поддръжка за нови формати, скоро ще има поддръжка и за IBM MQ. Ако разборът на заявката завърши с грешка, конекторът ще върне грешка; в противен случай той ще отговори, че заявката е обработена успешно, дори ако е възникнала грешка при последващата ѝ обработка. Това е направено специално, за да работим с системи, които не могат да повтарят заявки — или обратно, правят го прекалено настоятелно. За да не загубим данни, се използва ремонтна опашка: обектът първо попада в нея и само след успешна обработка се изтрива от нея. Администраторът може да получава известия за обектите, останали в ремонтната опашка, а след отстраняване на софтуерна грешка или хардуерен проблем да извърши повторна опит.

Входен процесор

Входният процесор класифицира получените данни според характерните белези и извиква подходящите обработчици. Обработчиците са код на език Lua, изпълняван в песачница, така че не могат да влияят на функционирането на системата. На този етап данните могат да бъдат приведени в необходимия вид, а също така при нужда да се стартират произволен брой задачи, които могат да реализират необходимата логика. Например, в продукта MDM (Master Data Management), изграден на Tarantool Data Grid, при добавяне на нов потребител, за да не забавим обработката на заявката, създаването на златната записка стартираме като отделна задача. Песачницата поддържа заявки за четене, изменение и добавяне на данни, позволява изпълнение на определена функция на всички роли типа storage и агрегация на резултата (map/reduce).

Обработчиците могат да бъдат описани в файлове:

sum.lua

local x, y = unpack(...)
return x + y

И след това, обявени в конфигурацията:

функции:
  sum: { __file: sum.lua }

Защо Lua? Lua е много прост език. На базата на нашия опит, след няколко часа запознаване с него, хората започват да пишат код, решаващ техния проблем. И това не са само професионални разработчици, а например, аналитични. Освен това, благодарение на JIT компилатора, Lua работи много бързо.

Хранилище

Storage съхранява персистентни данни. Преди запазването данните преминават валидация за съответствие със схемата на данни. За описание на схемата използваме разширен формат. Apache Avro. Пример:

{
    "name": "User",
    "type": "record",
    "logicalType": "Aggregate",
    "fields": [ 
        { "name": "id", "type": "string"}, 
        {"name": "first_name", "type": "string"}, 
        {"name": "last_name", "type": "string"} 
    ], 
    "indexes": ["id"] 
}

На базата на това описание автоматично се генерира DDL (Data Definition Language) за СУБД Тарантул и GraphQL схема за достъп до данните.

Поддържа се асинхронна репликация на данни (в плановете е добавяне на синхронна).

Output processor

Понякога е необходимо да уведомим външни потребители за постъпването на нови данни, затова съществува роля Output processor. След запазването на данните, те могат да бъдат предадени на съответния им обработчик (например, за да бъдат форматирани по начин, изискан от потребителя) — и след това предадени на connector за изпращане. Тук също се използва реновационна опашка: ако обектът не бъде поет, администраторът може да повтори опита по-късно.

Мащабиране

Ролите connector, input processor и output processor нямат състояние, което ни позволява да мащабираме системата хоризонтално, просто добавяйки нови екземпляри на приложението с активирана роля от необходимия тип. За хоризонтално мащабиране, storage използва подход към организацията на клъстера с използване на виртуални контейнери. След добавянето на нов сървър част от контейнерите от старите сървъри на фонов режим се преместват на новия сървър; това се случва прозрачно за потребителите и не влияе на работата на цялата система.

Свойства на данните

Обектите могат да бъдат много големи и да съдържат други обекти. Осигуряваме атомарност при добавяне и актуализиране на данни, запазвайки обекта с всички зависимости в един виртуален контейнер. Така се избягва "разпиляване" на обекта по няколко физически сървъра.

Поддържа се версионност: всяко обновление на обекта създава нова версия и ние винаги можем да направим времеви срез и да видим как е изглеждал светът тогава. За данните, които не се нуждаят от дълга история, можем да ограничим броя на версиите или дори да съхраняваме само една — последната, тоест фактически да деактивираме версионирането за определен тип. Може също така да ограничим историята по време: например, да изтриваме всички обекти от определен тип, по-стари от 1 година. Поддържа се и архивиране: можем да експортираме обекти, по-стари от указаното време, освобождавайки място в клъстера.

Задачи

От интересните функции заслужава да се отбележи възможността за стартиране на задачи по график, по искане на потребителя или програмно от пясъчника:

Тук виждаме още една роля — runner. Тази роля няма състояние, и при необходимост в клъстера могат да се добавят допълнителни екземпляри на приложението с тази роля. Отговорността на runner е изпълнението на задачите. Както се казва, от пясъчника е възможно генерирането на нови задачи; те се съхраняват в опашката на storage и след това се изпълняват от runner. Този тип задачи се нарича Job. Имаме и тип задачи, наречен Task — това са задачи, определяни от потребителя и стартирани по график (използва се синтаксиса cron) или по искане. За стартиране и следене на такива задачи разполагаме с удобен диспечер на задачи. За да бъде наличен този функционал, е необходимо да включим роля scheduler; тази роля има състояние, затова не е мащабируема, което всъщност и не е необходимо; тя, както и всички останали роли, може да има реплика, която започва работа, ако мастерът случайно не успее.

Logger

Още една роля се нарича logger. Тя събира логове от всички членове на клъстера и предоставя интерфейс за тяхното експортиране и преглед през уеб интерфейса.

Услуги

Заслужава да се спомене, че системата позволява лесно създаване на услуги. В конфигурационния файл може да се посочи, какви заявки да се насочват към написания от потребителя обработчик, изпълняван в пясъчника. В този обработчик можем, например, да изпълним някакъв аналитичен запит и да върнем резултата.

Услугата се описва в конфигурационния файл:

services:
   sum:
      doc: "добавя две числа"
      function: sum
      return_type: int
      args:
         x: int
         y: int

GraphQL API се генерира автоматично и услугата става достъпна за извикване:

query {
   sum(x: 1, y: 2) 
}

Това ще доведе до извикване на обработчика sum, който ще върне резултата:

3

Профилиране на запитвания и метрики

За да разберем как работи системата и да профилираме запитвания, реализирахме поддръжка на протокола OpenTracing. Системата може при нужда да изпраща информация на инструменти, поддържащи този протокол, например Zipkin, за да разберем как е протекло запитването:

Разбира се, системата предоставя вътрешни метрики, които могат да бъдат събирани с помощта на Prometheus и визуализирани с помощта на Grafana.

Деплой

Tarantool Data Grid може да бъде инсталиран от RPM пакети или архив, с помощта на предоставената утилита или Ansible, също така има поддръжка за Kubernetes (Tarantool Kubernetes Operator).

Приложението, реализиращо бизнес логика (конфигурация, обработчици), се зарежда в разположения клъстер Tarantool Data Grid под формата на архив през UI или с помощта на скрипт, чрез предоставеното от нас API.

Примери за приложения

Какви приложения могат да се създадат с помощта на Tarantool Data Grid? Всъщност повечето бизнес задачи по един или друг начин са свързани с обработка на потока от данни, тяхното съхранение и достъп до тях. Затова, ако разполагате с големи потоци от данни, които трябва да бъдат надеждно съхранени и достъпни, нашият продукт може да спести много време за разработка и да се фокусирате върху своята бизнес логика.

Например, желаем да събираме информация за пазара на недвижими имоти, за да притежаваме впоследствие информация за най-изгодните предложения. В този случай можем да идентифицираме следните задачи:

1. Роботи, които събират информация от открити източници — това ще бъдат нашите източници на данни. Тази задача можете да решите, като използвате готови решения или написвайки код на който и да е език.
2. След това Tarantool Data Grid ще приеме и съхрани данните. Ако форматите на данните от различни източници се различават, можете да напишете код на Lua, който да трансформира данните в единен формат. На етапа на предварителната обработка ще можете, например, да филтрирате дублирани предложения или допълнително да актуализирате информацията в базата данни за агенти, работещи на пазара.
3. Сега имате мащабируемо решение в клъстера, което можете да зареждате с данни и да извършвате заявки за данни. Вие можете да реализирате нови функционалности, например, да напишете услуга, която да направи запитване към данните и да предостави най-доброто предлагане за 24 часа — това ще изисква няколко реда в конфигурационния файл и малко код на Lua.

Какво следва?

Приоритет за нас е повишаването на удобството при разработката чрез Tarantool Data Grid. Например, IDE с поддръжка на профилиране и дебъгване на обработчици, работещи в пясъчник.

Също така, ние отделяме голямо внимание на въпросите за безопасността. В момента преминаваме сертификация от ФСТЕК на Русия, за да потвърдим високото ниво на безопасност и да отговорим на изискванията за сертификация на софтуерните продукти, използвани в информационните системи на лични данни и държавни информационни системи.

Източник: habr.com