Proč společnost jako MegaFon potřebuje Tarantool v účtování? Zvenčí se zdá, že prodejce obvykle přijde, přinese nějakou velkou krabici, zapojí zástrčku do zásuvky – a to je účtování! Kdysi tomu tak bylo, ale nyní je to již archaické a takoví dinosauři již vyhynuli nebo vyhynou. Zpočátku je účtování systém pro vystavování faktur - počítací stroj nebo kalkulačka. V moderních telekomunikacích to tak je automatizační systém pro celý životní cyklus interakce s účastníkem od uzavření smlouvy až po ukončení, včetně fakturace v reálném čase, přijímání plateb a mnoho dalšího. Účtování v telekomunikačních společnostech je jako bojový robot – velký, výkonný a nabitý zbraněmi.
Co s tím má společného Tarantool? Budou o tom mluvit Oleg Ivlev и Andrej Knyazev. Oleg je hlavním architektem společnosti s rozsáhlými zkušenostmi s prací v zahraničních společnostech je Andrey ředitelem obchodních systémů. Z přepisu jejich zprávy dne dozvíte se, proč je potřeba R&D v korporacích, co je Tarantool, jak se slepá ulička vertikálního škálování a globalizace stala předpokladem pro vznik této databáze ve firmě, o technologických výzvách, architektonické transformaci a jak je technostack MegaFonu podobný Netflixu. , Google a Amazon.
Projekt "Sjednocená fakturace"
Daný projekt se nazývá „Sjednocená fakturace“. Právě zde Tarantool ukázal své nejlepší kvality.
Růst produktivity Hi-End zařízení nedržel krok s růstem základny předplatitelů a růstem počtu služeb, další růst počtu předplatitelů a služeb byl očekáván díky M2M, IoT a funkcím poboček. ke zhoršení doby uvedení na trh. Společnost se rozhodla vytvořit jednotný podnikový systém s unikátní modulární architekturou světové třídy namísto 8 současných různých fakturačních systémů.
MegaFon je osm společností v jedné. V roce 2009 byla dokončena reorganizace: pobočky po celém Rusku se sloučily do jediné společnosti MegaFon OJSC (nyní PJSC). Společnost tak disponuje 8 fakturačními systémy s vlastními „zakázkovými“ řešeními, vlastnostmi poboček a různými organizačními strukturami, IT a marketingem.
Všechno bylo v pořádku, dokud jsme nemuseli spustit jeden společný federální produkt. Zde se objevilo mnoho obtíží: pro některé se tarify zaokrouhlují nahoru, pro jiné dolů a pro jiné - na základě aritmetického průměru. Takových momentů jsou tisíce.
Navzdory tomu, že existovala pouze jedna verze fakturačního systému, jeden dodavatel, nastavení se natolik rozcházelo, že trvalo dlouho, než se dal dohromady. Pokusili jsme se snížit jejich počet a narazili jsme na druhý problém, který zná mnoho korporací.
Vertikální škálování. Ani ten nejúžasnější hardware v té době nevyhovoval potřebám. Použili jsme zařízení Hewlett-Packard z řady Superdome Hi-End, ale nevyhovovalo potřebám ani dvou poboček. Chtěl jsem horizontální škálování bez velkých provozních nákladů a kapitálových investic.
Očekávání růstu počtu předplatitelů a služeb. Konzultanti již dlouho přinášejí příběhy o internetu věcí a M2M do světa telekomunikací: přijde čas, kdy každý telefon a žehlička budou mít SIM kartu a dvě v lednici. Dnes máme jeden počet předplatitelů, ale v blízké budoucnosti jich bude mnohem více.
Technologické výzvy
Tyto čtyři důvody nás motivovaly k vážným změnám. Bylo na výběr mezi upgradem systému a návrhem od začátku. Dlouho jsme přemýšleli, dělali vážná rozhodnutí, hráli výběrová řízení. V důsledku toho jsme se rozhodli navrhovat od samého začátku a chopili se zajímavých výzev – technologických výzev.
Škálovatelnost
Pokud to bylo dříve, řekněme, řekněme 8 faktur pro 15 milionů předplatitelůa teď by to mělo fungovat 100 milionů předplatitelů a více - zátěž je řádově vyšší.
V měřítku jsme se stali srovnatelnými s velkými internetovými hráči jako Mail.ru nebo Netflix.
Ale další pohyb ke zvýšení zátěže a základny předplatitelů pro nás znamenal vážné výzvy.
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é vzdálenosti jsou zpoždění již značné. 150 ms na nejlepších moderních optických kanálech je příliš mnoho pro účtování v reálném čase, zvláště když je tomu nyní v telekomunikacích v Rusku. Navíc je potřeba aktualizovat za jeden pracovní den a s různými časovými pásmy je to problém.
Neposkytujeme pouze služby za předplatné, máme komplexní tarify, balíčky a různé modifikátory. Musíme účastníkovi nejen povolit nebo odepřít hovořit, ale dát mu určitou kvótu - vypočítat hovory a akce v reálném čase, aby si toho nevšiml.
odolnost proti chybám
To je druhá stránka centralizace.
Pokud shromáždíme všechny předplatitele v jednom systému, pak jakékoli mimořádné události a katastrofy jsou pro podnikání katastrofální. Systém proto navrhujeme tak, abychom eliminovali dopad havárií na celou účastnickou základnu.
Je to opět důsledek odmítnutí vertikálního měřítka. Když jsme horizontálně škálovali, zvýšili jsme počet serverů ze stovek na tisíce. Musí být spravovány a zaměnitelné, automaticky zálohovat IT infrastrukturu a obnovovat distribuovaný systém.
Čelili jsme takovým zajímavým výzvám. Navrhli jsme systém a v tu chvíli jsme se snažili najít globální osvědčené postupy, abychom si ověřili, jak jsme v trendu, jak moc sledujeme pokročilé technologie.
Světová zkušenost
V globálním telecomu jsme kupodivu nenašli jedinou referenci.
Evropa klesla co do počtu předplatitelů a rozsahu, USA - co do plochosti svých tarifů. Podívali jsme se na některé v Číně a na některé v Indii a najali jsme specialisty z Vodafone India.
Pro analýzu architektury jsme sestavili Dream Team vedený IBM - architekty z různých oborů. Tito lidé mohli adekvátně posoudit, co děláme, a přinést určité znalosti do naší architektury.
Měřítko
Pár čísel pro ilustraci.
Systém navrhujeme pro 80 milionů předplatitelů s rezervou jedné miliardy. Tímto způsobem odstraňujeme budoucí prahové hodnoty. Není to kvůli tomu, že se chystáme ovládnout Čínu, ale kvůli náporu internetu věcí a M2M.
300 milionů dokumentů zpracovaných v reálném čase. Přestože máme 80 milionů předplatitelů, pracujeme jak s potenciálními klienty, tak s těmi, kteří nás opustili, pokud potřebujeme vymáhat pohledávky. Proto jsou skutečné objemy znatelně větší.
2 miliardy transakcí Zůstatek se denně mění – jedná se o platby, poplatky, hovory a další události. 200 TB dat se aktivně mění, změnit trochu pomaleji 8 PB data nejedná se o archiv, ale o živá data v jedné fakturaci. Měřítko podle datového centra - 5 tisíc serverů na 14 stránkách.
Zásobník technologií
Když jsme plánovali architekturu a začali montovat systém, dovezli jsme ty nejzajímavější a nejpokročilejší technologie. Výsledkem je technologický stack, který je známý všem internetovým hráčům a korporacím, které vyrábějí systémy s vysokou zátěží.
Zásobník je podobný zásobníkům jiných velkých hráčů: Netflix, Twitter, Viber. Skládá se ze 6 komponent, ale chceme ho zkrátit a sjednotit.
Flexibilita je dobrá, ale ve velké korporaci to bez sjednocení nejde.
Nechystáme se změnit stejný Oracle na Tarantool. V realitě velkých společností jde o utopii, respektive křížovou výpravu na 5-10 let s nejasným výsledkem. Ale Cassandra a Couchbase mohou být snadno nahrazeny Tarantoolem, a o to se snažíme.
Proč Tarantool?
Existují 4 jednoduchá kritéria, proč jsme zvolili tuto databázi.
Rychlost. Provedli jsme zátěžové testy na průmyslových systémech MegaFon. Tarantool vyhrál - předvedl nejlepší výkon.
To neznamená, že ostatní systémy nesplňují potřeby MegaFonu. Současná paměťová řešení jsou tak produktivní, že rezervy společnosti jsou více než dostatečné. Ale máme zájem jednat s vůdcem, a ne s někým, kdo zaostává, a to i v zátěžovém testu.
Tarantool pokrývá potřeby společnosti i dlouhodobě.
TCO náklady. Podpora Couchbase na objemech MegaFon stojí astronomické peníze, ale s Tarantoolem je situace mnohem příjemnější a funkčností jsou si podobné.
Další příjemnou funkcí, která mírně ovlivnila naši volbu, je, že Tarantool pracuje s pamětí lépe než jiné databáze. Ukazuje maximální účinnost.
Spolehlivost. MegaFon investuje do spolehlivosti, pravděpodobně více než kdokoli jiný. Když jsme se tedy podívali na Tarantool, uvědomili jsme si, že musíme zajistit, aby vyhovoval našim požadavkům.
Investovali jsme svůj čas a finance a společně s Mail.ru jsme vytvořili podnikovou verzi, kterou nyní používá několik dalších společností.
Tarantool-enterprise nás naprosto uspokojil z hlediska bezpečnosti, spolehlivosti a logování.
Partnerství
Nejdůležitější pro mě je přímý kontakt s developerem. Přesně tím upláceli kluci z Tarantool.
Když přijdete za hráčem, zejména za hráčem, který pracuje s kotevním klientem, a řeknete, že potřebujete databázi, abyste mohli dělat toto, toto a toto, obvykle odpoví:
- Dobře, dejte požadavky na dno té hromady - jednoho dne se k nim pravděpodobně dostaneme.
Mnozí mají roadmapu na další 2-3 roky a je téměř nemožné se tam integrovat, ale vývojáři Tarantool uchvacují svou otevřeností, a to nejen od MegaFonu, a přizpůsobují svůj systém zákazníkovi. Je to cool a moc se nám to líbí.
Kde jsme použili Tarantool
Tarantool používáme v několika prvcích. První je v pilotu, který jsme vytvořili v systému adresářů adres. Svého času jsem chtěl, aby to byl systém, který by byl podobný Yandex.Maps a Google Maps, ale dopadlo to trochu jinak.
Například katalog adres v prodejním rozhraní. Na Oracle trvá hledání požadované adresy 12-13 sekund. - nepohodlná čísla. Když přejdeme na Tarantool, nahradíme Oracle jinou databází v konzoli a provedeme stejné vyhledávání, dosáhneme 200násobného zrychlení! Město se objeví po třetím písmenu. Nyní přizpůsobujeme rozhraní tak, aby k tomu došlo po prvním. Rychlost odezvy je však úplně jiná – milisekundy místo sekund.
Druhou aplikací je trendy téma zvané dvourychlostní IT. Je to proto, že konzultanti ze všech koutů říkají, že by tam měly jít korporace.
Existuje vrstva infrastruktury, nad ní jsou domény, například fakturační systém jako telekomunikace, podnikové systémy, podnikový reporting. To je jádro, na které není třeba sahat. To je samozřejmě možné, ale paranoidně zajištění kvality, protože to přináší peníze do korporace.
Dále přichází vrstva mikroslužeb – to, co odlišuje operátora nebo jiného hráče. Mikroslužby lze rychle vytvořit na základě určitých mezipamětí a přinášet tam data z různých domén. Tady pole pro experimenty — pokud něco nefungovalo, zavřel jsem jednu mikroslužbu a otevřel další. To poskytuje skutečně delší dobu uvedení na trh a zvyšuje spolehlivost a rychlost společnosti.
Mikroslužby jsou možná hlavní rolí Tarantool na MegaFon.
Kde plánujeme používat Tarantool
Pokud porovnáme náš úspěšný projekt fakturace s transformačními programy v Deutsche Telekom, Svyazcom, Vodafone India, je překvapivě dynamický a kreativní. V procesu implementace tohoto projektu se transformoval nejen MegaFon a jeho struktura, ale na Mail.ru se objevil také Tarantool-enterprise a náš prodejce Nexign (dříve Peter-Service) - BSS Box (krabicové fakturační řešení).
Pro ruský trh jde v jistém smyslu o historický projekt. Dá se to přirovnat k tomu, co je popsáno v knize „The Mythical Man-Month“ od Fredericka Brookse. Poté, v 60. letech, IBM najalo 360 5 lidí, aby vyvinuli nový operační systém OS/000 pro sálové počítače. Máme méně - 1, ale naši jsou ve vestách a s přihlédnutím k použití open source a nových přístupů pracujeme produktivněji.
Níže jsou uvedeny domény fakturačních nebo, obecněji řečeno, obchodních systémů. Lidé z enterprise prostředí znají CRM velmi dobře. Každý by už měl mít jiné systémy: Open API, API Gateway.
Otevřete rozhraní API
Podívejme se znovu na čísla a na to, jak Open API aktuálně funguje. Jeho zatížení je 10 000 transakcí za sekundu. Vzhledem k tomu, že plánujeme aktivně vyvíjet vrstvu mikroslužeb a budovat veřejné API MegaFon, očekáváme v této části v budoucnu větší růst. Určitě bude 100 000 transakcí.
Nevím, jestli můžeme porovnávat s Mail.ru v SSO - zdá se, že kluci mají 1 000 0000 transakcí za sekundu. Jejich řešení je pro nás nesmírně zajímavé a plánujeme převzít jejich zkušenosti – například vytvoření funkční zálohy SSO pomocí Tarantool. Nyní to za nás dělají vývojáři z Mail.ru.
CRM
CRM je stejných 80 milionů předplatitelů, které chceme navýšit na miliardu, protože už existuje 300 milionů dokumentů, které zahrnují tříletou historii. Moc se těšíme na nové služby a tady bodem růstu jsou připojené služby. To je ples, který poroste, protože služeb bude stále více. V souladu s tím budeme potřebovat příběh; nechceme o to narazit.
Vlastní účtování v rámci vystavování faktur, práce s pohledávkami odběratelů přeměněna na samostatnou doménu. Chcete-li zlepšit výkon, architektonický vzor aplikované architektury domény.
Systém je rozdělen do domén, zátěž je rozložena a je zajištěna odolnost proti poruchám. Kromě toho jsme pracovali s distribuovanou architekturou.
Vše ostatní jsou řešení na podnikové úrovni. V úložišti hovorů - 2 miliardy denně60 miliard měsíčně. Někdy je musíte spočítat za měsíc a je to rychle lepší. Finanční sledování - to je přesně stejných 300 milionů, které neustále rostou a rostou: předplatitelé často běží mezi operátory a tuto část zvyšují.
Nejvíce telekomunikační složkou mobilních komunikací je online fakturace. Jedná se o systémy, které umožňují volat či nevolat, rozhodovat se v reálném čase. Zde je zatížení 30 000 transakcí za sekundu, ale s přihlédnutím k růstu přenosu dat plánujeme 250 000 transakcí, a proto nás Tarantool velmi zajímá.
Předchozí obrázek jsou domény, kde budeme používat Tarantool. Samotné CRM je samozřejmě širší a budeme ho používat v samotném jádru.
Naše odhadované číslo TTX 100 milionů předplatitelů mě jako architekta mate - co když 101 milionů? Musíte vše předělávat znovu? Abychom tomu zabránili, používáme cache a zároveň zvyšujeme dostupnost.
Obecně existují dva přístupy k používání Tarantool. První - vytvořit všechny mezipaměti na úrovni mikroslužeb. Pokud jsem pochopil, VimpelCom jde touto cestou a vytváří mezipaměť klientů.
Jsme méně závislí na dodavatelích, měníme jádro BSS, takže máme po vybalení jeden soubor klienta. Ale chceme to rozšířit. Proto volíme trochu jiný přístup – vytvářet mezipaměti uvnitř systémů.
Tímto způsobem je méně synchronizace - jeden systém je zodpovědný za mezipaměť i hlavní hlavní zdroj.
Metoda dobře zapadá do přístupu Tarantool s transakční kostrou, kdy se aktualizují pouze části, které se týkají aktualizací, tedy změn dat. Vše ostatní lze uložit někde jinde. Neexistuje žádné obrovské datové jezero, nespravovaná globální mezipaměť. Cache jsou navrženy pro systém nebo pro produkty nebo pro klienty nebo pro usnadnění údržby. Když předplatitel zavolá a je naštvaný na kvalitu vaší služby, chcete poskytovat kvalitní službu.
RTO a RPO
V IT existují dva pojmy - RTO и RPO.
Cíl doby zotavení je doba potřebná k obnovení služby po selhání. RTO = 0 znamená, že i když něco selže, služba pokračuje v práci.
Cíl bodu obnovy - toto je doba obnovy dat, kolik dat můžeme za určitou dobu ztratit. RPO = 0 znamená, že o data nepřicházíme.
Tarantool úkol
Zkusme vyřešit problém pro Tarantool.
Dáno: košík aplikací, kterým každý rozumí třeba v Amazonu nebo někde jinde. Je nutné tak, aby nákupní košík fungoval 24 hodin 7 dní v týdnu, tedy 99,99 % času. Objednávky, které k nám přicházejí, musí zůstat v pořádku, protože nemůžeme náhodně zapnout nebo vypnout připojení předplatitele - vše musí být přísně konzistentní. Předchozí předplatné ovlivňuje následující, takže data jsou důležitá – nic by nemělo chybět.
rozhodnutí. Můžete to zkusit vyřešit přímo a zeptat se vývojářů databáze, ale problém nelze vyřešit matematicky. Můžete si pamatovat věty, zákony zachování, kvantovou fyziku, ale proč - to nelze řešit na úrovni DB.
Funguje zde starý dobrý architektonický přístup – je třeba dobře znát předmětnou oblast a využít ji k vyřešení této hádanky.
Naše řešení: vytvoření distribuovaného registru aplikací na Tarantool - geograficky distribuovaný cluster. V diagramu jsou to tři různá centra pro zpracování dat – dvě před Uralem, jedno za Uralem a mezi tato centra rozdělujeme všechny požadavky.
Netflix, který je nyní považován za jednoho z lídrů v IT, měl do roku 2012 pouze jedno datové centrum. V předvečer katolických Vánoc, 24. prosince, toto datové centrum spadlo. Uživatelé v Kanadě a USA zůstali bez svých oblíbených filmů, byli velmi naštvaní a psali o tom na sociálních sítích. Netflix má nyní tři datová centra na západním a východním pobřeží a jedno v západní Evropě.
Zpočátku budujeme geodistribuované řešení – je pro nás důležitá odolnost proti chybám.
Máme tedy shluk, ale co RPO = 0 a RTO = 0? Řešení je jednoduché, záleží na předmětu.
Co je důležité v aplikacích? Dvě části: Házení koše TO rozhodování o koupi a PO. Část DO v telekomunikacích se obvykle nazývá zachycení objednávky nebo vyjednávání objednávky. V telekomu to může být mnohem obtížnější než v internetovém obchodě, protože tam musí být klient obsloužen, nabídnuto 5 možností a to vše se nějakou dobu děje, ale košík je naplněný. V tuto chvíli je možné selhání, ale není to děsivé, protože k němu dochází interaktivně pod lidským dohledem.
Pokud moskevské datové centrum náhle selže, pak automatickým přechodem na jiné datové centrum budeme pokračovat v práci. Teoreticky se může jeden produkt ztratit v košíku, ale vy ho vidíte, znovu přidejte do košíku a pokračujte v práci. V tomto případě RTO = 0.
Zároveň je tu druhá možnost: když klikneme na „odeslat“, chceme, aby se data neztratila. Od této chvíle začíná fungovat automatizace – to je RPO = 0. Pomocí těchto dvou různých vzorů by to v jednom případě mohl být jednoduše geograficky distribuovaný cluster s jedním přepínatelným masterem, v jiném případě nějakým druhem záznamu kvora. Vzory se mohou lišit, ale problém vyřešíme.
Kromě toho, že máme distribuovaný registr aplikací, můžeme to také škálovat - máme mnoho dispečerů a vykonavatelů, kteří přistupují k tomuto registru.
Cassandra a Tarantool spolu
Existuje další případ - "výkladní skříň zůstatků". Zde je zajímavý případ společného použití Cassandry a Tarantoolu.
Používáme Cassandru, protože 2 miliardy hovorů denně není limit a bude jich víc. Marketéři milují kolorování návštěvnosti podle zdroje, stále více detailů se objevuje například na sociálních sítích. To vše dodává příběhu.
Cassandra umožňuje horizontální měřítko na jakoukoli velikost.
S Cassandrou se cítíme dobře, ale má to jeden problém – není dobrá ve čtení. Na nahrávce je vše OK, 30 000 za vteřinu není problém - problém se čtením.
Proto se objevilo téma s cache a zároveň jsme řešili následující problém: existuje starý tradiční případ, kdy do souborů, které načítáme do Cassandry, přichází vybavení z přepínače z online fakturace. Potýkali jsme se s problémem spolehlivého stahování těchto souborů, a to i s využitím rad manažera IBM pro přenos souborů – existují řešení, která přenos souborů zvládají efektivně, například pomocí protokolu UDP místo TCP. To je dobré, ale jsou to ještě minuty a ještě to nemáme všechno načtené, operátor v call centru nemůže klientovi odpovědět, co se stalo s jeho zůstatkem – musíme čekat.
Abychom tomu zabránili, my používáme paralelní funkční rezervu. Když odešleme událost přes Kafku do Tarantoolu a přepočítáváme agregáty v reálném čase, například pro dnešek, dostaneme peněžní zůstatky, který dokáže převádět zůstatky libovolnou rychlostí, například 100 tisíc transakcí za sekundu a stejné 2 sekundy.
Cílem je, aby po uskutečnění hovoru byl do 2 sekund na vašem 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 a jejich ochota zvažovat různé případy.
Pro konzultanty z BCG nebo McKinsey, Accenture nebo IBM je již obtížné překvapit nás něčím novým – mnoho z toho, co nabízejí, buď již děláme, udělali jsme nebo plánujeme udělat. Myslím, že Tarantool zaujme své právoplatné místo v našem technologickém zásobníku a nahradí mnoho stávajících technologií. Jsme v aktivní fázi vývoje tohoto projektu.
Zpráva Olega a Andrey je jednou z nejlepších na konferenci Tarantool v loňském roce a 17. června vystoupí Oleg Ivlev se zprávou . Alexander Deulin také vystoupí s prezentací společnosti MegaFon . Pojďme zjistit, co se změnilo, jaké plány byly realizovány. Připojte se – konference je zdarma, jediné, co musíte udělat, je , vše a program konference byl vytvořen: nové případy, nové zkušenosti s používáním Tarantool, architektura, podnikání, tutoriály a mikroslužby.
Zdroj: www.habr.com