Architektura a možnosti Tarantool Data Grid

V roce 2017 jsme vyhráli soutěž na rozvoj transakčního jádra investičního podnikání Alfa-Bank a začali pracovat (na HighLoad++ 2018 se zprávou o jádru investičního byznysu provedeno Vladimir Drynkin, vedoucí transakčního jádra investičního podnikání Alfa Bank). Tento systém měl agregovat transakční data z různých zdrojů v různých formátech, převádět data do jednotné podoby, ukládat je a poskytovat k nim přístup.

Během procesu vývoje se systém vyvíjel a získával funkčnost a v určitém okamžiku jsme si uvědomili, že krystalizujeme něco mnohem víc než jen aplikační software vytvořený pro řešení přesně definovaného rozsahu úkolů: uspěli jsme systém pro vytváření distribuovaných aplikací s trvalým úložištěm. Zkušenosti, které jsme získali, vytvořily základ nového produktu – Tarantool datová mřížka (TDG).

Chci mluvit o architektuře TDG a řešeních, ke kterým jsme dospěli během procesu vývoje, představit vám hlavní funkcionalitu a ukázat, jak se náš produkt může stát základem pro budování kompletních řešení.

Architektonicky jsme systém rozdělili na samostatné role, z nichž každý je zodpovědný za řešení určitého okruhu problémů. Jedna spuštěná instance aplikace implementuje jeden nebo více typů rolí. V clusteru může být několik rolí stejného typu:

konektor

Connector je zodpovědný za komunikaci s vnějším světem; jeho úkolem je přijmout požadavek, analyzovat jej, a pokud se to podaří, odeslat data ke zpracování vstupnímu procesoru. Podporujeme formáty HTTP, SOAP, Kafka, FIX. Architektura umožňuje jednoduše přidat podporu pro nové formáty, s podporou IBM MQ již brzy. Pokud se analýza požadavku nezdařila, konektor vrátí chybu; v opačném případě odpoví, že požadavek byl úspěšně zpracován, i když při jeho dalším zpracování došlo k chybě. Bylo to provedeno speciálně za účelem práce se systémy, které neumí opakovat požadavky – nebo to naopak dělají příliš vytrvale. Aby nedošlo ke ztrátě dat, používá se opravná fronta: objekt se do ní nejprve dostane a teprve po úspěšném zpracování je z ní odstraněn. Administrátor může přijímat upozornění na objekty zbývající ve frontě oprav a po odstranění softwarové chyby nebo selhání hardwaru to zkusit znovu.

Vstupní procesor

Vstupní procesor klasifikuje přijatá data podle charakteristických vlastností a volá příslušné procesory. Obslužné rutiny jsou kód Lua, který běží v sandboxu, takže nemohou ovlivnit fungování systému. V této fázi lze data zredukovat do požadované podoby a v případě potřeby spustit libovolný počet úloh, které mohou implementovat potřebnou logiku. Například v produktu MDM (Master Data Management) postaveném na Tarantool Data Grid při přidávání nového uživatele, abychom nezpomalili zpracování požadavku, spouštíme tvorbu zlatého záznamu jako samostatný úkol. Sandbox podporuje požadavky na čtení, změnu a přidávání dat, umožňuje provádět některé funkce na všech rolích typu úložiště a agregaci výsledku (mapovat/redukovat).

Handlery lze popsat v souborech:

sum.lua

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

A pak deklarováno v konfiguraci:

functions:
  sum: { __file: sum.lua }

Proč Lua? Lua je velmi jednoduchý jazyk. Na základě našich zkušeností začnou lidé pár hodin po seznámení psát kód, který vyřeší jejich problém. A nejde jen o profesionální vývojáře, ale například i o analytiky. Navíc díky jit kompilátoru běží Lua velmi rychle.

Skladování

Úložiště ukládá trvalá data. Před uložením jsou data ověřena podle datového schématu. K popisu obvodu používáme rozšířený formát Apache Avro. Příklad:

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

Na základě tohoto popisu je automaticky generován DDL (Data Definition Language) pro Tarantula DBMS a GraphQL schéma pro přístup k datům.

Je podporována asynchronní replikace dat (plánuje se přidat synchronní).

Výstupní procesor

Někdy je potřeba upozornit externí spotřebitele na příchod nových dat, k tomu slouží role Výstupní procesor. Po uložení dat je lze předat příslušnému obslužnému programu (například je převést do podoby požadované spotřebitelem) – a poté předat konektoru k odeslání. Zde se také používá fronta oprav: pokud nikdo objekt nepřijal, může to správce zkusit znovu později.

Měřítko

Role konektoru, vstupního procesoru a výstupního procesoru jsou bezstavové, což nám umožňuje horizontálně škálovat systém jednoduchým přidáním nových instancí aplikací s povoleným požadovaným typem role. Úložiště se používá pro horizontální škálování přístup k uspořádání clusteru pomocí virtuálních bucketů. Po přidání nového serveru se některé buckety ze starých serverů přesunou na nový server na pozadí; děje se to transparentně pro uživatele a nemá to vliv na chod celého systému.

Vlastnosti dat

Objekty mohou být velmi velké a obsahovat další objekty. Atomičnost přidávání a aktualizace dat zajišťujeme uložením objektu se všemi závislostmi do jednoho virtuálního bucketu. Tím se zabrání tomu, aby byl objekt „rozprostřen“ na několik fyzických serverů.

Je podporováno verzování: každá aktualizace objektu vytvoří novou verzi a vždy si můžeme vzít časový úsek a podívat se, jak tehdy svět vypadal. U dat, která nepotřebují dlouhou historii, můžeme omezit počet verzí nebo dokonce uložit pouze jednu – tu nejnovější – tedy v podstatě zakázat verzování pro určitý typ. Historii můžete také omezit časem: například smazat všechny objekty určitého typu starší než 1 rok. Podporována je také archivace: můžeme uvolnit objekty starší než zadaný čas, čímž se uvolní místo v clusteru.

úkoly

Mezi zajímavé funkce stojí za zmínku možnost spouštět úlohy podle plánu, na žádost uživatele nebo programově z karantény:

Zde vidíme další roli – běžce. Tato role je bezstavová a podle potřeby lze do clusteru přidat další instance aplikace s touto rolí. Úkolem běžce je plnit úkoly. Jak již bylo zmíněno, z sandboxu je možné generovat nové úkoly; jsou uloženy ve frontě na úložišti a poté spuštěny na běžci. Tento typ úkolu se nazývá Job. Máme také typ úlohy nazvaný Task – jedná se o uživatelem definované úlohy, které se spouštějí podle plánu (pomocí syntaxe cron) nebo na vyžádání. Pro spouštění a sledování takových úloh máme pohodlného správce úloh. Aby byla tato funkce dostupná, musíte povolit roli plánovače; tato role má stav, takže se neškáluje, což však není vyžadováno; zároveň, stejně jako všechny ostatní role, může mít repliku, která začne fungovat, pokud mistr náhle odmítne.

Záznamník

Další role se nazývá logger. Shromažďuje protokoly od všech členů clusteru a poskytuje rozhraní pro jejich nahrávání a prohlížení prostřednictvím webového rozhraní.

Služby

Za zmínku stojí, že systém usnadňuje vytváření služeb. V konfiguračním souboru můžete určit, které požadavky se odesílají uživateli napsanému ovladači, který běží v karanténě. V tomto handleru můžete například spustit nějaký analytický dotaz a vrátit výsledek.

Služba je popsána v konfiguračním souboru:

services:
   sum:
      doc: "adds two numbers"
      function: sum
      return_type: int
      args:
         x: int
         y: int

GraphQL API je generováno automaticky a služba je dostupná pro volání:

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

To zavolá psovoda sumkterý vrátí výsledek:

3

Profilování dotazů a metriky

Pro pochopení fungování systému a požadavků na profilování jsme implementovali podporu protokolu OpenTracing. Systém může na vyžádání odeslat informace nástrojům, které tento protokol podporují, jako je Zipkin, což vám umožní pochopit, jak byl požadavek proveden:

Systém samozřejmě poskytuje interní metriky, které lze shromažďovat pomocí Prometheus a vizualizovat pomocí Grafany.

Nasadit

Tarantool Data Grid lze nasadit z RPM balíčků nebo archivu, pomocí utility z distribuce nebo Ansible, nechybí ani podpora pro Kubernetes (Operátor Tarantool Kubernetes).

Aplikace, která implementuje obchodní logiku (konfigurace, handlery) se nahraje do nasazeného clusteru Tarantool Data Grid formou archivu přes UI nebo pomocí skriptu přes námi poskytnuté API.

Základy filozofie

Jaké aplikace lze vytvořit pomocí Tarantool Data Grid? Ve skutečnosti většina obchodních úkolů nějak souvisí se zpracováním, ukládáním a přístupem k datovému toku. Pokud tedy máte velké datové toky, které je třeba bezpečně ukládat a přistupovat k nim, pak vám náš produkt může ušetřit spoustu času na vývoj a soustředit se na vaši obchodní logiku.

Chceme například sbírat informace o trhu s nemovitostmi, abychom v budoucnu měli například informace o nejlepších nabídkách. V tomto případě zdůrazníme následující úkoly:

1. Našimi datovými zdroji budou roboti, kteří shromažďují informace z otevřených zdrojů. Tento problém můžete vyřešit pomocí hotových řešení nebo psaním kódu v libovolném jazyce.
2. Dále Tarantool Data Grid přijme a uloží data. Pokud se formát dat z různých zdrojů liší, můžete napsat kód v Lua, který provede převod do jediného formátu. Ve fázi předzpracování budete také moci například filtrovat duplicitní nabídky nebo dodatečně aktualizovat informace o agentech působících na trhu v databázi.
3. Nyní již máte škálovatelné řešení v clusteru, který lze naplnit daty a provádět výběr dat. Pak můžete implementovat novou funkcionalitu, například napsat službu, která požádá o data a dá nejvýhodnější nabídku za den - to bude vyžadovat pár řádků v konfiguračním souboru a trochu kódu Lua.

Co bude dál?

Naší prioritou je zjednodušit vývoj Tarantool datová mřížka. Jedná se například o IDE s podporou obslužných rutin profilování a ladění běžících v sandboxu.

Velkou pozornost věnujeme také otázkám bezpečnosti. Právě nyní procházíme certifikací FSTEC z Ruska, abychom potvrdili vysokou úroveň zabezpečení a splnili požadavky na certifikaci softwarových produktů používaných v informačních systémech osobních údajů a vládních informačních systémech.

Zdroj: www.habr.com