Co tady vlastně děláme

Varování: následující článek obsahuje řadu technických pojmů a je psán pro specifické publikum. Pokud si nejste jistí, zda byste měli být jeho čtenáři, zkuste si prosím provést následující krátký test 🙂 Pokračování bez zvládnutí testu alespoň na 50%, je pouze na vlastní nebezpečí.

Pár lidí mě už upozorňovalo, ať si dám při psaní článků bacha na mlčenlivost. Už jim prý některé příspěvky připadaly za hranou. Vzhledem k tomu, co všechno píšeme na www.codevoyagers.com, mi ani nepřišlo, že bych se k nějaké hraně vůbec blížil. Pro jistotu jsem se na to dnes zeptal Bryana. Říkal ať si s tím nelámu hlavu 🙂 Pro něj je ta hranice platná až pro unikátní business záležitosti (tam zatím ani nemám co prozrazovat 🙂 ). Technologické záležitosti, náš přístup k řešení problémů, které může mít i někdo další, … to vše je prý v pohodě.

Ještě než budu psát o mém prvním úkolu, dovolím si odbočku směrem k high level architektuře. Ono také psát rovnou o parciálních úkolech, by bez toho nemuselo dávat smysl. Už jsem zmiňoval dříve, že náš kmen má za cíl poskytovat data as a service. Směrem ke zbytku organizace to funguje tak, že budujeme SDK pro snadné logování čehokoliv. Ukládají se business eventy, metriky služeb, chování uživatelů v produktu, tak i prosté aplikační logy. Prostě cokoliv kdo chce zaznamenat, je mu to umožněno přes poměrně sofistikovanou architekturu.

Vstupním rozhraním pro zbytek Skyscanneru je Grappler SDK (Python a Java), které odstiňuje většinu producentů dat od čistě HTTP API. Skrz toto HTTP API protékala historicky všechna data, a přes Apache Kafka se ukládala do AWS S3, OpenTSDB (time series databáze) a elasticsearch databáze. AWS S3 je něco jako primární úložiště dat. Nad OpenTSDB probíhá dotazování a reporting přes Bosun (zejména sledování různých veličin v čase, vyhazování alertů při překročení kritických hranic a podobně). Pro monitoring služeb a zobrazování dashboardů pak používáme ještě Grafanu. Elasticsearch se v našem kmeni primárně používá jako zdroj dat pro různé experimenty v Kibaně.

Část KPI našeho data tribe jsou dostupnost dat 99.99% max do 2 minut od zalogování (ještě tam nejsme). Historicky zde došlo k nějakým problémům se ztrátou dat v Apache Kafka, a tak se rozhodli vybudovat novou, spolehlivější větev. V podstatě data putují z rozhraní přes AWS Kinesis Firehose jako datové soubory přímo do AWS S3. Tam jsou „jen“ nějaké AWS Lambda funkce pro konverzi / manipulaci s datovými soubory. Tato větev je zatím v pilotním provozu pro první business event topic. Hlavní výhodou je naprostá bezpečnost uložení dat – jelikož data jdou dvěma službami od Amazonu rovnou do AWS S3. A i nízká chybovost – v podstatě se tam nemá co pos***, jelikož kromě konfigurace AWS CloudFormation (Infrastructure as a code) to neobsahuje žádný custom kód 🙂 AWS cloudové služby monitorujeme pomocí AWS CloudWatch.

Původní větěv se zatím stále používá, výhledově se asi bude i nadále využívat pro non-business metriky. Nad Apache Kafka jsou provozovány téměř real-time výpočty business metric, např. pro potřeby následného fakturování provizí od leteckých společností. Nová trasa Grappler SDK – AWS Kinesis Firehose – AWS S3 je sice bezpečnější, akorát tyto real-time výpočty neobsahuje. No a proč je psát znovu zde, když už existují nad Kafkou. Poměrně správně (z toho co mohu se svými “dvěma týdny znalostí i s cestou” soudit 🙂 ) se tedy rozhodli, že po tom co jsou data bezpečně uložena, je možné zahájit jejich přehrání do původní trasy pro potřeby real-time reportingu. No a tím se pomalu dostávám k jednomu z cílů, co si dali kluci na minulý sprint – přehrání dat z AWS S3 do Apache Kafka

Po zápisu dat do AWS S3 je s využitím AWS SNS uložena informace o novém datovém souboru do AWS SQS. Nad touto frontou pak poslouchá přehrávací aplikace Roces. Ta postupně z fronty vyzvedává informace o nově uložených datových souborech, stahuje je z AWS S3 a jednotlivé zprávy pak přes původní rozhraní posílá do Apache Kafka. Jelikož KPI jsou rovněž na nulovou ztrátu dat, musí se korektně zapsat všechny zprávy z datového souboru, než dojde k potvrzení do AWS SQS. Zní to poměrně jednoduše, jen si to představte s terabyty dat a s průměrným počtem cca 80k zpráv za sekundu. No a nesmíte zapomenout na 2 minuty na end-to-end zpracování – ale jak jsem říkal, ještě tam nejsme 🙂

Protože obrázek vydá za tisíc slov, přiložím nákres od Randyho. Jedná se o druhou verzi, konkrétně takto reagoval na připomínku od Alexe, že by dokumentace mohla být „a bit more jazzy“.

No trošku jsem se rozepsal, abych Vás nezahlcoval informacemi, a zároveň z důvodů vlastní ješitnosti, jsem se rozhodl mému prvnímu reálnému úkolu věnovat vlastní příspěvek. 🙂

6 odpovědí na “Co tady vlastně děláme”

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *