Proč potřebuje taková korporace jako MegaFon Tarantool v billingu? Na první pohled to vypadá, že dodavatel přijde, přinese nějakou velkou krabici, zapojí ji do zásuvky — a voilà, máte billing! To takhle kdysi bylo, ale dnes je to archaické a takoví dinosauři už vymírají nebo už vyhynuli. Původně byl billing systém pro vystavování účtů — kalkulačka pro počítání. V moderním telekomunikačním sektoru je to systém automatizace celého životního cyklu interakce se zákazníkem od uzavření smlouvy až po její zrušení, včetně tarifikace v reálném čase, přijímání plateb a mnoha dalších funkcí. Billing v telekomunikačních společnostech je podobný bojovému robotu — velkému, silnému a vybavenému nejmodernějšími zbraněmi.
A co má společného Tarantool? O tom se dozvíte Oleg Ivlev a Andrej Knyazev. Oleg je hlavní architekt společnosti s bohatými zkušenostmi z práce v zahraničních firmách, Andrej je ředitelem pro obchodní systémy. Z jejich prezentace na se dozvíte, jaký význam má R&D v korporacích, co je Tarantool, jak k úpadku vertikálního škálování a globalizaci došlo a staly se předpoklady pro vznik této DB ve společnosti, o technologických výzvách, transformaci architektury a jak se technologický stack MegaFon podobá Netflixu, Googlu a Amazonu.
Projekt „Jednotný billing“
Projekt, o kterém bude řeč, se nazývá „Jednotný billing“. Právě v něm Tarantool prokázal své nejlepší vlastnosti.
Růst výkonu Hi-End zařízení nedokázal držet krok s růstem uživatelské základny a počtem služeb, očekával se další růst počtu uživatelů a služeb díky M2M, IoT, a místní zvláštnosti vedly ke zhoršení time-to-market. Společnost se rozhodla vytvořit jediné obchodní systém s unikátní modulární architekturou světové úrovně, jako náhradu za 8 různých současných billingových systémů.
MegaFon je osm společností v jedné. V roce 2009 byla dokončena reorganizace: pobočky po celé Rusku se spojily do jediné společnosti OAO „MegaFon“ (nyní PAO). Tak se ve společnosti objevilo 8 billingových systémů s vlastními 'custom' řešeními, místními rysy a různou organizační strukturou, IT a marketingem.
Vše bylo v pořádku, dokud jsme nespustili jeden společný federální produkt. Objevilo se mnoho problémů: u někoho se účtování zaokrouhluje nahoru, u někoho dolů, a někdo má průměrné aritmetické zúčtování. Takových situací jsou tisíce.
I když je verze billingového systému jedna, dodavatel je stejný, nastavení se lišila natolik, že jejich sjednocení trvalo dlouho. Snažili jsme se snížit jejich počet a narazili jsme na další problém, který je znám mnoha korporacím.
Vertikální škálování. I to nejlepší hardwarové vybavení v té době nesplňovalo potřeby. Používali jsme zařízení od Hewlett-Packard, modely Superdome Hi-End, ale ani to nezvládlo potřeby dvou poboček. Chtělo to horizontální škálování bez vysokých provozních nákladů a kapitálových investic.
Očekávání růstu počtu abonentů a služeb. Konzultanti přinesli do telekomunikačního světa příběhy o IoT a M2M: nastanou časy, kdy každý telefon a žehlící prkno bude mít SIM kartu, a v ledničce budou dvě. Dnes máme určité množství abonentů, ale v blízké budoucnosti jich bude o řád více.
Technologické výzvy
Tyto čtyři důvody nás vedly k vážným změnám. Byla volba mezi modernizací systému a návrhem od základů. Dlouho jsme přemýšleli, přijímali vážná rozhodnutí, hráli tendry. Nakonec jsme se rozhodli navrhnout zcela od začátku a pustili jsme se do zajímavých výzev – technologických výzev.
Škálovatelnost
Pokud dříve bylo, řekněme 8 billingů pro 15 milionů abonentů, teď by mělo vyjít 100 milionů abonentů a více – zátěž je o řád vyšší.
Stali jsme se srovnatelnými co do velikosti s velkými internetovými hráči jako Mail.ru nebo Netflix.
Avšak další zvyšování zátěže a počtu abonentů přineslo vážné úkoly.
Geografie naší obrovské země
Mezi Kaliningradem a Vladivostokem 7500 km a 10 časových pásem. Rychlost světla je konečná a na takových vzdálenostech jsou zpoždění již významná. 150 ms na nejmodernějších optických kanálech je pro real-time účtování, jaké se dnes používá v telekomunikacích v Rusku, příliš. Navíc je třeba provádět aktualizace během jednoho pracovního dne, a to s různými časovými pásmy představuje problém.
Nehodláme pouze poskytovat služby za předplatné, máme složité tarify, balíčky a různé modifikátory. Není naším cílem jen povolit nebo zakázat volání předplatiteli, ale poskytnout mu určitou kvótu – počítat hovory a činnosti v reálném čase tak, aby si toho nevšiml.
Odolnost proti výpadkům
To je druhá strana centralizace.
Pokud shromáždíme všechny předplatitele v jednom systému, jakékoli havarijní události a katastrofy mohou být pro podnikání katastrofální. Proto navrhujeme systém tak, aby se minimalizoval vliv havárií na celou základnu předplatitelů.
To je opět důsledkem odmítnutí vertikálního škálování. Když jsme přešli k horizontálnímu škálování, zvýšili jsme počet serverů ze stovek na tisíce. Je třeba je řídit, vybudovat vzájemnou zastupitelnost, automaticky zálohovat IT-infrastrukturu a obnovit distribuovaný systém.
Stály před námi zajímavé výzvy. Navrhli jsme systém a v tu chvíli jsme se pokusili najít světovou nejlepší praxi, abychom zjistili, jak jsme na tom s trendem, jak dodržujeme moderní technologie.
Světová praxe
Je překvapující, že v globálním telekomunikačním průmyslu jsme nenašli žádnou referenci.
Evropa vypadla z hlediska počtu předplatitelů a rozsahu, USA z důvodu plochosti svých tarifů. Něco jsme se podívali v Číně, a něco jsme našli v Indii a vzali odborníky z Vodafone India.
Pro analýzu architektury jsme sestavili Dream Team vedený IBM – architekty z různých oblastí. Tito lidé mohli adekvátně posoudit, co děláme, a přinést do naší architektury určité znalosti.
Škálování
Několik čísel pro ilustraci.
Navrhujeme systém pro 80 milionů předplatitelů s rezervou na miliardu. Tím odstraňujeme budoucí prahy. Není to proto, že bychom měli v plánu dobýt Čínu, ale kvůli náporu IoT a M2M.
300 milionů dokumentů je zpracováváno v reálném čase. Ačkoli máme 80 milionů předplatitelů, pracujeme i s potenciálními klienty a s těmi, kteří od nás odešli, pokud je třeba vymáhat pohledávky. Skutečné objemy jsou proto výrazně vyšší.
2 miliardy transakcí každý den mění zůstatek – jsou to platby, připočítání, hovory a další události. 200 TB dat se aktivně mění, o něco pomaleji se mění 8 PB dat, a to nejsou archivy, ale živá data v jednom billingovém systému. Rozsah podle datových center — 5 tisíc serverů na 14 místech.
Technologický stack
Když jsme plánovali architekturu a začali budovat systém, importovali jsme si ty nejzajímavější a nejmodernější technologie. Vznikl technologický stack, který znají všichni internetoví hráči a korporace vyvíjející vysoce zatížené systémy.
Stack je podobný stackům jiných velkých hráčů: Netflix, Twitter, Viber. Skládá se ze 6 komponent, ale my chceme jeho velikost zkrátit a unifikovat.
Flexibilita je dobrá, ale ve velké korporaci je bez unifikace nemožné.
Neplánujeme nahradit Oracle Tarantool. V realitě velkých společností je to utopie, nebo křížová výprava na 5-10 let s nejistým výsledkem. Ale Cassandra a Couchbase mohou být klidně nahrazeny Tarantool, a tomu se chceme přiblížit.
Proč Tarantool?
Existují 4 jednoduché kritéria, proč jsme vybrali tuto databázi.
Rychlost. Provedli jsme zátěžové testy na průmyslových systémech MegaFon. Tarantool vyhrál — ukázal nejlepší výkon.
Není pravda, že by jiné systémy neuspokojovaly potřeby MegaFon. Současná řešení v paměti jsou tak výkonná, že firma má dostatečné rezervy. Ale nás zajímá spolupracovat s lídrem, a ne s tím, kdo tápe vzadu, včetně výsledků zátěžových testů.
Tarantool pokrývá potřeby společnosti i z dlouhodobého hlediska.
Náklady TCO. Podpora Couchbase na objemech MegaFon stojí astronomické peníze, zatímco situace s Tarantool je mnohem příjemnější, a co se funkcionality týče, jsou si blízké.
Další příjemnou vlastností, která mírně ovlivnila naše rozhodování — Tarantool lépe pracuje s pamětí než ostatní databáze. Ukazuje maximální efektivitu.
Spolehlivost. MegaFon investuje do spolehlivosti, asi jako nikdo jiný. Proto, když jsme se podívali na Tarantool, zjistili jsme, že ho musíme upravit tak, aby splňoval naše požadavky.
Investovali jsme svůj čas a finance a společně s Mail.ru vytvořili enterprise verzi, která se nyní používá již v několika dalších společnostech.
Tarantool-enterprise nás plně uspokojil z hlediska bezpečnosti, spolehlivosti a logování.
Partnerství
Nejdůležitější pro mě je přímý kontakt s vývojářem. To je přesně to, čím nás lidé z Tarantool získali.
Pokud přijdeš k hráči, zejména k tomu, který pracuje s klíčovým klientem, a říkáš, že potřebuješ, aby databáze uměla toto, to a to, obvykle odpovídá:
— Dobře, dejte požadavky na dno té hromady — někdy se k nim asi dostaneme.
Mnozí mají roadmap na příští 2-3 roky a je téměř nemožné se do toho zapojit, zatímco vývojáři Tarantoolu okouzlují otevřeností, a to nejen s MegaFonem, a přizpůsobují svůj systém zákazníkům. To je skvělé a nám se to opravdu líbí.
Kde jsme použili Tarantool
U nás se Tarantool používá v několika prvcích. První — v pilotním projektu, který jsme vytvořili na systému adresního katalogu. V určitém okamžiku jsme chtěli, aby to byl systém, který by vypadal jako Yandex.Maps a Google Maps, ale dopadlo to poněkud jinak.
Pro příklad, adresní katalog v prodejním rozhraní. Na Oracle trvá vyhledání potřebné adresy 12-13 s — to jsou nepříjemná čísla. Když přepneme na Tarantool, vyměníme Oracle za jinou databázi v konzoli a provedeme to samé vyhledání, získáme zrychlení 200krát! Město se zobrazí po třetím písmenu. Nyní přizpůsobujeme rozhraní, aby se to dalo provést po prvním. Přesto je rychlost reakce zcela jiná — už milisekundy místo sekund.
Druhé použití — módní téma, která se nazývá dvourychlostní IT. To proto, že konzultanti z každého kouta říkají, že korporace by měly jít tímto směrem.
Tady je vrstva infrastruktury, nad ní domény, například fakturační systém, jako u telekomunikací, firemní systémy, firemní reporty. To je jádro, které se nemá dotýkat. To znamená, že samozřejmě je možné, ale paranoidně zajišťovat kvalitu, protože to přináší korporaci peníze.
Dále je vrstva mikroslužeb — to, co diferencuje operátora nebo jiného hráče. Mikroslužby je možné rychle vytvářet na základě určitých cache, přičemž se zde zvedají data z různých domén. Tady je pole pro experimenty — pokud něco nevyšlo, uzavřeš jednu mikroslužbu, otevřeš jinou. To opravdu zajišťuje zkrácený time-to-market a zvyšuje spolehlivost a rychlost společnosti.
Mikroslužby — to je pravděpodobně hlavní role Tarantoolu v MegaFonu.
Kde plánujeme použít Tarantool
Pokud srovnáme náš úspěšný projekt fakturace s transformačními programy ve Deutsche Telekom, Svyaznoy, Vodafone India, je úžasně dynamický a kreativní. V průběhu realizace tohoto projektu se nejen transformoval MegaFon a jeho struktura, ale vznikla také Tarantool-enterprise u Mail.ru a náš dodavatel Nexign (dříve «Peter-Service») — BSS Box (krabicové fakturační řešení).
Toto je v jistém smyslu historický projekt pro ruský trh. Lze ho přirovnat k tomu, co je popsáno v knize Fredericka Brookse „Mythical Man-Month“. Tehdy, v 60. letech, pro vývoj nového operačního systému OS/360 pro mainframy IBM zapojil 5 000 lidí. U nás je to méně — 1 800, ale naši lidé jsou v pruhovaném, a s ohledem na použití open-source a nové přístupy pracujeme efektivněji.
Níže jsou uvedeny domény fakturace nebo, pokud to řekneme šířeji, — podnikových systémů. Lidé z enterprise skvěle znají CRM. Ostatní systémy by měly mít již všichni: Open API, API Gateway.
Open API
Podívejme se opět na čísla a na to, jak nyní funguje Open API. Jeho zátěž je — 10 000 transakcí za sekundu. Vzhledem k tomu, že plánujeme aktivně rozvíjet vrstvu mikroslužeb a budovat veřejný API MegaFon, očekáváme v budoucnu větší růst právě v této části. 100 000 transakcí určitě bude.
Nevím, zda se vyrovnáme v SSO s Mail.ru — kluci mají údajně 1 000 0000 transakcí za sekundu. Jejich řešení je pro nás velice zajímavé a plánujeme převzít jejich zkušenosti — například udělat funkční zálohu SSO pomocí Tarantool. Nyní se tím zabývají vývojáři z Mail.ru u nás.
CRM
CRM — to jsou ti 80 milionů předplatitelů, které chceme dostat na miliardu, protože už existuje 300 milionů dokumentů, které zahrnují tříletou historii. Opravdu očekáváme nové služby a zde bude růstový bod — to jsou připojené služby. Toto je oblast, která poroste, protože služeb bude stále více. Podle toho budeme potřebovat historii, nechceme na tom klopýtat.
Samotná fakturace v části vystavování účtů, práce s pohledávkami klientů se transformovala na samostatnou doménu. Abychom zvýšili produktivitu, byl použit architektonický vzor doménové architektury.
Systém je rozdělen do domén, zatížení je rozloženo a zajištěna je odolnost proti výpadkům. Dále jsme pracovali s distribuovanou architekturou.
Všechno ostatní jsou řešení na úrovni enterprise. Ve skladu hovorů – 2 miliardy denně, 60 miliard měsíčně. Někdy je potřeba je přepočítat za měsíc, a je lepší to udělat rychle. Finanční monitoring – to jsou právě těch 300 milionů, které trvale rostou a rostou: abonenti často přeskakují mezi operátory, čímž zvyšují tuto část.
Nejvíce telekomunikační komponenta z mobilního spojení – to je on-line tariface. To jsou ty systémy, které vám umožňují volat nebo nevolat, přijímají rozhodnutí v reálném čase. Zde je zátěž 30 000 transakcí za sekundu, ale s ohledem na rostoucí přenos dat plánujeme 250 000 transakcí, a proto se velmi zajímáme o Tarantool.
Předchozí obrázek ukazuje domény, kde máme v úmyslu aplikovat Tarantool. Samozřejmě je CRM širší a máme v úmyslu jej použít přímo v jádru.
Moje odhadovaná čísla TTX na 100 milionů abonentů mě jako architekta znepokojují – co když to bude 101 milionů? Zase všechno předělávat? Abychom tomu předešli, používáme cache, čímž zvyšujeme dostupnost.
Celkově existují dva přístupy k aplikaci Tarantool. První – vybudovat všechny cache na úrovni mikroslužeb.Jak to chápu, tímto směrem jde VympelCom, který vytváří cache klientů.
My jsme méně závislí na dodavatelích, měníme jádro BSS, proto máme jednotnou kartotéku klientů již z krabice. Ale chceme ji rozšířit. Proto aplikujeme mírně jiný přístup – vytváříme cache uvnitř systémů..
Tak je míněn menší desynchronizace – jeden systém odpovídá jak za cache, tak za hlavní master zdroj.
Tento způsob se dobře hodí do přístupu Tarantool s transakčním skeletonem, kdy se aktualizují pouze části, které se týkají aktualizací, tedy změny dat. Všechno ostatní lze uchovávat někde jinde. Není tu obrovské datové jezero, neřízená globální cache. Cache jsou navrhovány pro systém, buď podle produktů, nebo podle klientů, nebo aby usnadnily život údržbě. Když volá zklamaný abonent ohledně kvality, chceme ho kvalitně obsloužit.
RTO a RPO
V IT existují dva termíny – RTO a RPO.
Recovery time objective — to je doba obnovy služby po selhání. RTO = 0 znamená, že i když něco selže, služba pokračuje v provozu.
Cílový cíl obnovy — to je doba obnovy dat, kolik dat můžeme ztratit za určité časové období. RPO = 0 znamená, že neztrácíme žádná data.
Úloha pro Tarantool
Pojďme se pokusit vyřešit úlohu pro Tarantool.
Dáno: všem známý košík žádostí, například na Amazonu nebo kdekoli jinde. Požaduje se aby košík fungoval 24 hodin 7 dní v týdnu, tedy 99,99 % času. Objednávky, které k nám přicházejí, musí zachovat pořádek, protože nemůžeme chaoticky zapínat nebo vypínat spojení abonentům — vše musí být přísně sekvenční. Předchozí předplatné ovlivňuje následující, proto jsou data důležitá — nic nesmí zmizet.
Řešení. Můžeme se pokusit to řešit přímo a zeptat se vývojářů DB, ale úloha se matematicky nedá vyřešit. Můžeme vzpomenout na teoremy, zákony zachování, kvantovou fyziku, ale proč — není to možné vyřešit na úrovni DB.
Zde funguje osvědčený architektonický přístup — je třeba dobře znát obor a za jeho účet vyřešit tuto hádanku.
Naše řešení: vytváříme distribuovaný registr žádostí na Tarantool — geo-distribuovaný klastr. Na schématu to jsou tři různé datové centra — dvě před Uralem, jedno za Uralem, a distribujeme všechny žádosti mezi těmito centry.
Netflix, který je nyní považován za jednoho z lídrů v IT, měl do roku 2012 jen jedno datové centrum. Na Štědrý den 24. prosince toto datové centrum selhalo. Uživatelé v Kanadě a USA zůstali bez svých oblíbených filmů, byli velmi rozrušení a napsali o tom na sociální sítě. Nyní má Netflix tři datová centra na západním a východním pobřeží a jedno v západní Evropě.
Od počátku budujeme geo-distribuované řešení — důležitá je pro nás odolnost proti selhání.
Takže máme klastr, ale jak to udělat s RPO = 0 a RTO = 0? Řešení je jednoduché, to závisí na předmětu.
Co je důležité v žádostech? Dvě části: návrh košíku PŘED rozhodnutím o koupi, a PO. Část PŘED v telekomunikacích obvykle nazýváme zachycování objednávek nebo vyjednávání objednávek. V telekomunikacích to může být mnohem složitější než v internetovém obchodě, protože je třeba obsloužit zákazníka, nabídnout 5 možností, a to vše probíhá nějakou dobu, ale košík se plní. V tuto chvíli může dojít k chybě, ale to není tak hrozné, protože se to děje v interaktivním režimu pod dohledem člověka.
Pokud moskevské datové centrum náhle selže, automaticky přepneme na jiné datové centrum a budeme pokračovat v práci. Teoreticky může dojít ke ztrátě jednoho produktu v košíku, ale to vidíte, znovu doplníte košík a pokračujete. V tomto případě je RTO = 0.
Ve stejném okamžiku existuje druhá možnost: když stiskneme «odeslat», chceme, aby se data neztratila. Od tohoto okamžiku začne fungovat automatika – to už je RPO = 0. Použití těchto dvou různých vzorů v jednom případě může být prostě geograficky distribuovaný cluster s jedním přepínaným mistrem, v jiném případě nějaký quorum záznam. Šablony se mohou lišit, ale my řešíme problém.
Dále, mít distribuovaný registr žádostí, můžeme to vše i škálovat - mít mnoho dispečerů a vykonavatelů, kteří se obracejí na tento registr.
Cassandra a Tarantool spolu
Existuje ještě jeden případ - «vitrína zůstatků». Tady je právě zajímavý případ společného použití Cassandry a Tarantoolu.
Používáme Cassandru, protože 2 miliardy hovorů denně – to není limit, a bude jich více. Marketéři rádi rozdělují provoz podle zdrojů, objevuje se stále více detailů o sociálních sítích, například. To vše zvyšuje historii.
Cassandra umožňuje horizontální škálování na jakékoli objemy.
Cítíme se komfortně s Cassandrou, ale má jeden problém - není dobrá na čtení. Na zápisu je vše v pořádku, 30 000 za sekundu není problém - problém je v čtení.
Proto se objevilo téma o cache a zároveň jsme vyřešili další problém: existuje starý tradiční případ, kdy zařízení od přepínače od online tariface přichází do souborů, které nahráváme do Cassandry. Potýkali jsme se s problémem spolehlivého nahrávání těchto souborů, dokonce jsme použili na radu IBM manager file transfer – existují taková řešení, která efektivně řídí přenos souborů pomocí protokolu UDP, například, a ne TCP. To je dobré, ale stále to trvá minuty, a dokud to všechno nenahráváme, operátor v call centru nemůže klientovi říct, co se stalo s jeho zůstatkem – je třeba čekat.
Aby se tomu zabránilo, my používáme paralelní funkční rezervu. Když posíláme událost přes Kafka do Tarantool, přepočítáváme agregáty v reálném čase, například za dnešek, a získáváme cache zůstatků, která může dodávat zůstatky jakoukoli rychlostí, například 100 tisíc transakcí za sekundu a stejné 2 sekundy.
Cílem je, aby po provedení hovoru byl už za 2 sekundy v osobním účtu nejen změněný zůstatek, ale také informace o tom, proč se změnil.
Závěr
To byly příklady použití Tarantool. Velmi se nám líbila otevřenost Mail.ru, jejich ochota zvažovat různé případy.
Konzultantům z BCG nebo McKinsey, Accenture nebo IBM už je těžké nás něčím novým překvapit – mnoho z toho, co nabízejí, už buď děláme, nebo jsme udělali, nebo plánujeme udělat. Myslím, že Tarantool v našem technologickém stacku zaujme důstojné místo a nahradí mnoho již existujících technologií. Jsme ve fázi aktivního rozvoje tohoto projektu.
Přednáška Olega a Andrey je jednou z nejlepších na Tarantool Conference loňského roku, a už 17. června Oleg Ivlev vystoupí na s přednáškou . Také od Megafonu vystoupí Alexander Deulin s přednáškou . Zjistíme, co se změnilo, jaké plány se podařilo realizovat. Připojte se – konference je zdarma, stačí se . Všechny a program konference je sestaven: nové případy, nové zkušenosti s používáním Tarantool, architektura, enterprise, tutoriály a mikroservisy.
Zdroj: habr.com
