Architektura systému

Datová platforma je realizována jako modulární systém s využitím obsahující jednotlivě funkční, jednotlivě nasaditelné a nahraditelné moduly. Jednotlivé moduly a vrstvy jsou navrženy s myšlenkou nahraditelnosti za jiné řešení, či již existující službu (např. poskytovanou jako SaaS) a s myšlenkou maximální flexibility a škálovatelnosti.

Škálovatelnost a modularita

Z důvodu obtížně předvídatelného rozvoje do budoucna (co se týče datových objemů, počtů poskytovatelů dat a jednotlivých use casů) je kladen velký důraz na škálovatelnost - např. vrstva pro příjem dat je navržena jako minimální (lightweight) bezstavová aplikace, kterou je možné v kombinaci s load balancerem nasadit v několika instancích pro rychlý příjem dat a zajištění zařazení požadavků do fronty pro postupné zpracování. Fronta je také integrální součástí systému a realizuje příjem, persistenci dat, distribuci a synchronizaci mezi jednotlivými výpočetními uzly. Systém je tak schopen reagovat i na velké špičky v datových tocích.

Bestavové aplikace

Maximum modulů je řešeno jako bezstavové aplikace, kde držitelem stavu je společný databázový cluster. Výpočetní uzly (jednotlivé instance realizující zpracování dat, transformace a výpočty dat) jsou také libovolně škálovatelné a navýšením počtu jejich instancí se urychlí proces zpracování a vyzvedávání dat z fronty.

Microservice-oriented

Architektura systému kloubí výhody microservice-oriented architektury (flexibilita, samostatné škálování, nahraditelnost, rychlost roll outů nových aktualizací) s tradičním návrhem. To samozřejmě přináší nejen výhody, ale i několik úskalí, na které musel být brán při návrhu a realizaci (zejména z pohledu provozu a povyšování verzí se zpětně nekompatibilními úpravami), jelikož se u některých modulů nejedná čistě o úplně nezávislé microservices.

Orchestrace

Celý systém je provozován na virtualizované infrastruktuře, jednotlivé aplikace v kontejnerizovaném prostředí (Docker). Nad kontejnery je vystavena orchestrační vrstva, která se stará o load balancing, clusterování, nasazování nových verzí (tzv. rolling update u jednotlivých služeb, kdy se nejprve spustí druhá instance v nové verzi, přesměruje se traffic a až následně se stará verze vypne, proto je dosažen zero-downtime deployment) apod.

CI/CD

Architektura je navržena s myšlenkou kontinuálního nasazování (CI/CD), kde mohou být nové verze jednotlivých services v automatizovaném systému nasazovány průběžně v krátkých iteracích. Platforma je postavena nad cloudovým prostředím s využitím microservices, kontejnerizace, škálování prostředí a využití služeb “as a service”.

Aplikace je rozdělena do jednotlivých samostatných modulů:

  • Vstupní rozhraní (Input Gateway),
  • Přístupová vrstva (ACL, Permission Proxy),
  • Fronta (Message Broker, Queue),
  • Integrační vrstva (Integration Engine),
  • Databázová vrstva,
  • Výstupní rozhraní (Output Gateway),
  • Administrační panel (Admin Panel),
  • Dispečink a datová analýza (Client Panel),
  • Správa časově řízených úkonů (CRON).

Rámcové schéma architektury:

Následující schéma popisuje jednotlivé moduly řešení vč. způsobu napojení mezi nimi (druh připojení, rozhraní) a naznačení komunikace a závislostí. Každý modul obsahuje svůj název a název projektu (repozitáře).

Schéma architektury

Popis jednotlivých modulů na stránce Integrační moduly.

Popis modulů frontendu na stránce Webové aplikace.

Technologické schéma

Následující schéma popisuje technologický stack projektu a využití technologií na jednotlivých součástech platformy. Přesnější definice technologií a použitých frameworků je vždy k dispozici u popisu každého modulu v sekci Integrační moduly.

Technologické Schéma architektury

Základní vlastnosti architektury systému:

  • jednotlivé komponenty mají jasně definované rozhraní a lze je v budoucnu škálovat či nahradit jiným řešením
  • všechny příchozí požadavky (requesty) musí projít skrze Permission proxy, což je vrstva zajištující authentizaci a authorizaci
  • Input gateway definuje příchozí endpointy a validuje datovou strukturu příchozích dat
  • zpracování dat probíhá přes message queue RabbitMQ pomocí workeru v integračním enginu
    • flow workeru: vyzvednu zprávu -> provedu můj úkol -> buď uloží výsledek skrze zprávu do další fronty a nebo se jen ukončí
  • data je možné stahovat z externích zdrojů na základě času (cron) nebo jiné události, která uloží zprávu do fronty
  • využití ETL Keboola je volitelné a umožnuje získání dat z mnoha externích zdrojů bez nutnosti psaní vlastního připojení

Infrastrukturní schéma

Infrastrukturní Schéma

Celý projekt běží na Docker Swarm a jednotlivé komponenty jsou Docker kontejnery.

Reverzní proxy zajištuje Traefik, který distribuuje requety na jednotlivé kontejnery, které mají být dostupné z internetu. Přístup do ostatních kontejnerů je dostupný pouze z vnitřní sítě.

Rozvržení kontejnerů na jednotlivé uzly klastru je dáno jejich potřebami, tedy kontejnery dostupné přímo z internetu jsou na společném uzlu, výkonově náročné aplikace mají k dispozici výrazně výkonější typ uzlu a databázové kontejnery potřebují rozsáhlejší úložiště. Poslední typ uzlu je servisní, kde běží administrace s monitorovacími službami.