Архитектура за наплата на новата генерација: трансформација со преминот кон Tarantool

Зошто на корпорација како МегаФон и е потребен Tarantool во наплатата? Однадвор се чини дека продавачот обично доаѓа, носи некаква голема кутија, го приклучува приклучокот во штекерот - и тоа е наплата! Ова некогаш беше случај, но сега е архаично, а таквите диносауруси веќе изумреа или исчезнуваат. Првично, наплатата е систем за издавање фактури - машина за броење или калкулатор. Во современите телекомуникации ова е систем за автоматизација за целиот животен циклус на интеракција со претплатник од склучување на договор до раскинување, вклучувајќи наплата во реално време, прифаќање плаќања и многу повеќе. Наплатата во телекомуникациските компании е како борбен робот - голем, моќен и натоварен со оружје.

Каква врска има Tarantool со тоа? Ќе зборуваат за тоа Олег Ивлев и Андреј Књазев. Олег е главен архитект на компанијата Мегафон со долгогодишно искуство со работа во странски компании, Андреј е директор на деловни системи. Од транскриптот на нивниот извештај за Конференција на Тарантул 2018 година ќе научите зошто е потребно истражување и развој во корпорациите, што е Tarantool, како ќорсокакот на вертикалното скалирање и глобализацијата станаа предуслови за појавата на оваа база на податоци во компанијата, за технолошките предизвици, архитектонската трансформација и како техностакот на MegaFon е сличен на Netflix , Гугл и Амазон.

Проект „Унифицирана наплата“

Проектот за кој станува збор се нарекува „Унифицирана наплата“. Тука Тарантул ги покажа своите најдобри квалитети.

Растот на продуктивноста на опремата Hi-End не се држеше во чекор со растот на базата на претплатници и растот на бројот на услуги; се очекуваше понатамошен раст на бројот на претплатници и услуги поради карактеристиките на M2M, IoT и филијали. до влошување на времето до пазарот. Компанијата одлучи да создаде унифициран деловен систем со единствена модуларна архитектура од светска класа, наместо 8 сегашни различни системи за наплата.

МегаФон е осум компании во една. Во 2009 година, реорганизацијата беше завршена: филијалите низ цела Русија се споија во една компанија, MegaFon OJSC (сега PJSC). Така, компанијата има 8 системи за наплата со сопствени „прилагодени“ решенија, карактеристики на филијалите и различни организациски структури, ИТ и маркетинг.

Сè беше во ред додека не моравме да лансираме еден заеднички федерален производ. Тука се појавија многу тешкотии: за некои, тарифите се заокружуваат нагоре, за други се заокружуваат надолу, а за други - врз основа на аритметичката средина. Има илјадници такви моменти.

И покрај фактот дека имаше само една верзија на системот за наплата, еден добавувач, поставките толку многу се разликуваа што беше потребно долго време да се соберат. Се обидовме да го намалиме нивниот број и наидовме на втор проблем кој им е познат на многу корпорации.

Вертикално скалирање. Дури и најкул хардверот во тоа време не ги задоволуваше потребите. Ја користевме опремата на Hewlett-Packard од линијата Superdome Hi-End, но таа не ги задоволуваше потребите на ниту две филијали. Сакав хоризонтално скалирање без големи оперативни трошоци и капитални инвестиции.

Очекување на раст на бројот на претплатници и услуги. Консултантите одамна носат приказни за IoT и M2M во светот на телекомуникациите: ќе дојде време кога секој телефон и пегла ќе имаат SIM картичка, а две во фрижидер. Денес имаме еден број претплатници, но во блиска иднина ќе има уште многу.

Технолошки предизвици

Овие четири причини не мотивираа да направиме сериозни промени. Имаше избор помеѓу надградба на системот и дизајнирање од нула. Долго размислувавме, донесовме сериозни одлуки, игравме тендери. Како резултат на тоа, решивме да дизајнираме од самиот почеток, и презедовме интересни предизвици - технолошки предизвици.

Приспособливост

Ако беше порано, да речеме, да речеме 8 сметки за 15 милиони претплатници, и сега требаше да функционира 100 милиони претплатници и повеќе - оптоварувањето е по ред по големина.

Станавме споредливи во обем со големите интернет играчи како Mail.ru или Netflix.

Но, натамошното движење за зголемување на оптоварувањето и базата на претплатници ни постави сериозни предизвици.

Географија на нашата огромна земја

Помеѓу Калининград и Владивосток 7500 км и 10 временски зони. Брзината на светлината е конечна и на такви растојанија доцнењата се веќе значителни. 150 ms на најкул модерните оптички канали се премногу за наплата во реално време, особено како што е сега во телеком во Русија. Покрај тоа, треба да се ажурирате во еден работен ден, а со различни временски зони ова е проблем.

Ние не обезбедуваме услуги само за претплата, имаме сложени тарифи, пакети и разни модификатори. Треба не само да му дозволиме или да му одбиеме на претплатникот да зборува, туку да му дадеме одредена квота - да пресметаме повици и дејства во реално време за да не забележи.

толеранција на грешки

Ова е другата страна на централизацијата.

Ако ги собереме сите претплатници во еден систем, тогаш сите итни настани и катастрофи се погубни за бизнисот. Затоа, го дизајнираме системот на таков начин што ќе го елиминира влијанието на несреќите врз целата претплатничка база.

Ова е повторно последица на одбивањето да се скалира вертикално. Кога скалиравме хоризонтално, го зголемивме бројот на сервери од стотици на илјадници. Тие треба да бидат управувани и заменливи, автоматски да се направи резервна копија на ИТ инфраструктурата и да се обнови дистрибуираниот систем.

Се соочивме со толку интересни предизвици. Го дизајниравме системот и во тој момент се обидовме да најдеме глобални најдобри практики за да провериме колку сме во тренд, колку ги следиме напредните технологии.

Светско искуство

Изненадувачки, не најдовме ниту една референца во глобалниот телеком.

Европа падна во однос на бројот на претплатници и обемот, САД - во однос на рамномерноста на нејзините тарифи. Разгледавме некои во Кина, најдовме некои во Индија и ангажиравме специјалисти од Водафон Индија.

За да ја анализираме архитектурата, составивме Dream Team предводен од IBM - архитекти од различни области. Овие луѓе можеа соодветно да оценат што правиме и да донесат одредено знаење во нашата архитектура.

Скала

Неколку бројки за илустрација.

Ние го дизајнираме системот за 80 милиони претплатници со резерва од една милијарда. Вака ги отстрануваме идните прагови. Ова не е затоа што ќе ја преземеме Кина, туку поради нападот на IoT и M2M.

300 милиони документи обработени во реално време. Иако имаме 80 милиони претплатници, работиме и со потенцијалните клиенти и со оние кои не напуштиле доколку треба да наплатиме побарувања. Затоа, вистинските волумени се значително поголеми.

2 милијарди трансакции Билансот се менува секојдневно - тоа се плаќања, трошоци, повици и други настани. 200 TB податоци активно се менуваат, менувајте се малку побавно 8 PB податоци, и ова не е архива, туку податоци во живо во една наплата. Размер по центар за податоци - 5 илјади сервери на 14 сајтови.

Технолошки оџак

Кога ја планиравме архитектурата и почнавме да го склопуваме системот, ги увезовме најинтересните и најнапредните технологии. Резултатот е технолошки оџак познат на секој интернет плеер и корпорации кои произведуваат системи со големо оптоварување.

Магацинот е сличен на куповите на другите големи играчи: Нетфликс, Твитер, Вибер. Се состои од 6 компоненти, но сакаме да го скратиме и обединиме.

Флексибилноста е добра, но во голема корпорација нема начин без обединување.

Ние нема да го промениме истиот Oracle во Tarantool. Во реалноста на големите компании, ова е утопија, или крстоносна војна за 5-10 години со нејасен исход. Но, Касандра и Каучбејс лесно може да се заменат со Тарантул, и тоа е она кон што се стремиме.

Зошто Tarantool?

Постојат 4 едноставни критериуми зошто ја избравме оваа база на податоци.

Брзина. Спроведовме тестови за оптоварување на индустриските системи МегаФон. Тарантул победи - покажа најдобри перформанси.

Ова не значи дека другите системи не ги задоволуваат потребите на МегаФон. Сегашните решенија за меморија се толку продуктивни што резервите на компанијата се повеќе од доволни. Но, ние сме заинтересирани да имаме работа со лидер, а не со некој што заостанува, вклучително и во тестот за оптоварување.

Tarantool ги покрива потребите на компанијата дури и на долг рок.

TCO цена. Поддршката за Couchbase на тома на MegaFon чини астрономски суми на пари, но со Tarantool ситуацијата е многу попријатна и тие се слични по функционалност.

Друга убава карактеристика што малку влијаеше на нашиот избор е тоа што Tarantool работи подобро со меморија од другите бази на податоци. Тој покажува максимална ефикасност.

Сигурност. МегаФон инвестира во доверливост, веројатно повеќе од кој било друг. Така, кога го погледнавме Tarantool, сфативме дека треба да го направиме да ги исполни нашите барања.

Го вложивме нашето време и финансии, а заедно со Mail.ru создадовме верзија за претпријатие, која сега се користи во неколку други компании.

Tarantool-претпријатието целосно не задоволи во однос на безбедноста, доверливоста и сечата.

партнерство

Најважно ми е директен контакт со инвеститорот. Токму со ова поткупуваа момците од Тарантул.

Ако дојдете кај играч, особено оној кој работи со сидро клиент, и кажете дека ви треба базата на податоци за да можете да го направите ова, ова и ова, тој обично одговара:

- Добро, стави ги барањата на дното на тој куп - еден ден, веројатно ќе дојдеме до нив.

Многумина имаат патоказ за следните 2-3 години и таму е речиси невозможно да се интегрираат, но програмерите на Tarantool пленат со својата отвореност, и не само од MegaFon, и го прилагодуваат својот систем на клиентот. Прекрасно е и навистина ни се допаѓа.

Каде што користевме Tarantool

Ние користиме Tarantool во неколку елементи. Првиот е во пилотот, што го направивме на системот за директориуми за адреси. Едно време сакав да биде систем кој е сличен на Yandex.Maps и Google Maps, но испадна малку поинаку.

На пример, каталогот за адреси во продажниот интерфејс. На Oracle, пребарувањето за саканата адреса трае 12-13 секунди. - непријатни бројки. Кога ќе се префрлиме на Tarantool, ќе го замениме Oracle со друга база на податоци во конзолата и ќе го извршиме истото пребарување, добиваме 200x забрзување! Градот се појавува по третата буква. Сега го прилагодуваме интерфејсот така што тоа ќе се случи по првиот. Сепак, брзината на одговор е сосема поинаква - милисекунди наместо секунди.

Втората апликација е трендовска тема наречена ИТ со две брзини. Тоа е затоа што консултантите од секој агол велат дека корпорациите треба да одат таму.

Има инфраструктурен слој, над него има домени, на пример, систем за наплата како телеком, корпоративни системи, корпоративно известување. Ова е јадрото што не треба да се допира. Тоа е, се разбира, можно, но параноично да се обезбеди квалитет, затоа што и носи пари на корпорацијата.

Следува слојот на микросервиси - што го разликува операторот или другиот играч. Микроуслугите може брзо да се креираат врз основа на одредени кешови, носејќи податоци од различни домени таму. Еве поле за експерименти - ако нешто не функционираше, затворив еден микросервис и отворив друг. Ова обезбедува навистина зголемено време до пазарот и ја зголемува доверливоста и брзината на компанијата.

Микроуслугите се можеби главната улога на Tarantool во MegaFon.

Каде што планираме да користиме Tarantool

Ако го споредиме нашиот успешен проект за наплата со програмите за трансформација во Дојче Телеком, Свјазком, Водафон Индија, тој е изненадувачки динамичен и креативен. Во процесот на имплементација на овој проект, не само МегаФон и неговата структура беа трансформирани, туку и Tarantool-enterprise се појави на Mail.ru, а нашиот продавач Nexign (поранешен Peter-Service) - BSS Box (решение за наплата во кутии).

Ова е, во извесна смисла, историски проект за рускиот пазар. Може да се спореди со она што е опишано во книгата „Митскиот човек-месец“ од Фредерик Брукс. Потоа, во 60-тите, IBM ангажираше 360 луѓе да го развијат новиот оперативен систем OS/5 за мејнфрејмови. Имаме помалку - 000, но нашите се во елеци и земајќи го предвид користењето на отворен код и новите пристапи, работиме попродуктивно.

Подолу се домени на наплата или, пошироко кажано, деловни системи. Луѓето од претпријатието многу добро го познаваат CRM. Секој треба веќе да има други системи: Open API, API Gateway.

Отворете API

Ајде повторно да ги погледнеме бројките и како во моментов работи Open API. Нејзиното оптоварување е 10 трансакции во секунда. Бидејќи планираме активно да го развиваме слојот за микросервис и да го изградиме јавниот API на MegaFon, очекуваме поголем раст во иднина во овој дел. Дефинитивно ќе има 100 трансакции.

Не знам дали можеме да се споредиме со Mail.ru во ДЗС - момците се чини дека имаат 1 трансакции во секунда. Нивното решение е исклучително интересно за нас и планираме да го усвоиме нивното искуство - на пример, правење функционална резервна копија на ДЗС со помош на Tarantool. Сега програмерите од Mail.ru го прават ова за нас.

CRM

CRM се истите 80 милиони претплатници кои сакаме да ги зголемиме на милијарда, бидејќи веќе има 300 милиони документи кои вклучуваат тригодишна историја. Навистина се радуваме на новите услуги и тука точка на раст е поврзани услуги. Ова е топка која ќе расте, бидејќи ќе има се повеќе услуги. Според тоа, ќе ни треба приказна; не сакаме да се сопнуваме на ова.

Самата наплата во однос на издавање фактури, работа со побарувања од клиенти трансформиран во посебен домен. За да се подобрат перформансите, применета архитектура на домен архитектонски модел.

Системот е поделен на домени, оптоварувањето се распределува и се обезбедува толеранција на грешки. Дополнително, работевме и со дистрибуирана архитектура.

Сè друго се решенија на ниво на претпријатие. Во складиштето за повици - 2 милијарди дневно, 60 милијарди месечно. Понекогаш треба да ги изброите за еден месец, и тоа е подобро брзо. Финансиски мониторинг - ова се токму истите 300 милиони кои постојано растат и растат: претплатниците често се движат меѓу операторите, зголемувајќи го овој дел.

Најмногу телеком компонента на мобилните комуникации е онлајн наплата. Ова се системи кои ви дозволуваат да се јавите или да не се јавите, да донесувате одлуки во реално време. Овде оптоварувањето е 30 трансакции во секунда, но земајќи го предвид растот на преносот на податоци, планираме 250 трансакции, и затоа сме многу заинтересирани за Tarantool.

Претходната слика се домените каде што ќе користиме Tarantool. Самиот CRM, се разбира, е поширок и ние ќе го користиме во самото јадро.

Нашата проценета бројка на TTX од 100 милиони претплатници ме збунува како архитект - што ако 101 милион? Дали треба повторно да направите сè? За да го спречиме тоа да се случи, користиме кешови, истовремено зголемувајќи ја пристапноста.

Општо земено, постојат два пристапа за користење на Tarantool. Прво - изградете ги сите кешови на ниво на микросервис. Колку што разбрав, VimpelCom го следи овој пат, создавајќи кеш на клиенти.

Ние сме помалку зависни од продавачите, го менуваме јадрото на BSS, така што имаме една датотека со клиент надвор од кутијата. Но, ние сакаме да го прошириме. Затоа, заземаме малку поинаков пристап - направи кешови во системите.

На овој начин има помала синхронизација - еден систем е одговорен и за кешот и за главниот главен извор.

Методот добро се вклопува со пристапот на Tarantool со трансакциски скелет, кога се ажурираат само деловите што се однесуваат на ажурирањата, односно промените на податоците. Сè друго може да се складира на друго место. Нема огромно езеро со податоци, неуправуван глобален кеш. Кешовите се дизајнирани за системот, или за производите, или за клиентите, или за да го олеснат животот за одржување. Кога некој претплатник се јавува и е вознемирен поради квалитетот на вашата услуга, сакате да обезбедите квалитетна услуга.

RTO и RPO

Постојат два термина во ИТ - РТО и RPO.

Цел на времето на закрепнување е времето потребно за да се врати услугата по дефект. RTO = 0 значи дека дури и ако нешто не успее, услугата продолжува да работи.

Цел на точката за опоравување - ова е времето за обновување на податоците, колку податоци можеме да изгубиме во одреден временски период. RPO = 0 значи дека не губиме податоци.

Tarantool задача

Ајде да се обидеме да решиме проблем за Tarantool.

Со оглед на: кошница со апликации што сите ги разбираат, на пример, во Амазон или на друго место. Потребна е така што количката работи 24 часа 7 дена во неделата, или 99,99% од времето. Нарачките што доаѓаат кај нас мора да останат во ред, бидејќи не можеме случајно да ја вклучиме или исклучиме врската на претплатникот - сè мора да биде строго конзистентно. Претходната претплата влијае на следната, така што податоците се важни - ништо не треба да недостасува.

Решение. Може да се обидете да го решите директно и да ги прашате развивачите на базата на податоци, но проблемот не може да се реши математички. Можете да запомните теореми, закони за зачувување, квантна физика, но зошто - тоа не може да се реши на ниво на ДБ.

Стариот добар архитектонски пристап функционира овде - треба добро да ја знаете тематската област и да ја искористите за да ја решите оваа загатка.

Нашето решение: создавање дистрибуиран регистар на апликации на Tarantool - гео-дистрибуиран кластер. На дијаграмот, ова се три различни центри за обработка на податоци - два пред Урал, еден надвор од Урал, и ние ги дистрибуираме сите барања меѓу овие центри.

Нетфликс, кој сега важи за еден од лидерите во ИТ, имаше само еден центар за податоци до 2012 година. Во пресрет на католичкиот Божиќ, 24 декември, овој центар за податоци падна. Корисниците во Канада и САД останаа без омилените филмови, беа многу вознемирени и пишуваа за тоа на социјалните мрежи. Нетфликс сега има три центри за податоци на западно-источниот брег и еден во западна Европа.

Првично градиме геодистрибуирано решение - толеранцијата на грешки е важна за нас.

Значи, имаме кластер, но што е со RPO = 0 и RTO = 0? Решението е едноставно, во зависност од темата.

Што е важно во апликациите? Два дела: фрлање кош TO донесување одлука за купување и ПО СЕ. Делот DO во телеком обично се нарекува нарачка фаќање или преговарање за нарачка. Во телеком тоа може да биде многу потешко отколку во онлајн продавница, бидејќи таму клиентот мора да биде услужен, да му се понудат 5 опции и сето тоа се случува некое време, но корпата е исполнета. Во овој момент можен е неуспех, но не е страшен, бидејќи се случува интерактивно под надзор на човекот.

Ако центарот за податоци во Москва ненадејно пропадне, тогаш со автоматско префрлување на друг центар за податоци, ќе продолжиме да работиме. Теоретски, еден производ може да се изгуби во количката, но вие го гледате, додадете повторно во количката и продолжете со работа. Во овој случај RTO = 0.

Во истиот момент, постои и втора опција: кога кликнавме на „поднеси“, сакаме податоците да не се изгубат. Од овој момент, автоматизацијата почнува да работи - ова е RPO = 0. Користејќи ги овие две различни шеми, во еден случај тоа едноставно може да биде гео-дистрибуиран кластер со еден преклоплив господар, во друг случај некој вид на кворумски запис. Моделите може да се разликуваат, но ние го решаваме проблемот.

Понатаму, имајќи дистрибуиран регистар на апликации, можеме да го зголемиме сето тоа - да имаме многу диспечери и извршители кои пристапуваат до овој регистар.

Касандра и Тарантул заедно

Има уште еден случај - „излог на салда“. Еве еден интересен случај на заедничка употреба на Касандра и Тарантул.

Ја користиме Касандра бидејќи 2 милијарди повици дневно не се ограничување, а ќе има повеќе. Пазарџиите сакаат да го обојат сообраќајот по извор; се повеќе и повеќе детали се појавуваат на социјалните мрежи, на пример. Сето тоа додава на приказната.

Касандра ви овозможува хоризонтално скалирање до која било големина.

Со Касандра се чувствуваме удобно, но таа има еден проблем - не ја бива во читање. Се е во ред на снимањето, 30 во секунда не е проблем - проблем со читање.

Затоа, се појави тема со кеш, а во исто време го решивме следниов проблем: постои стар традиционален случај кога опремата од прекинувачот од онлајн наплата влегува во датотеките што ги вчитуваме во Касандра. Се боревме со проблемот со сигурно преземање на овие датотеки, дури и користејќи ги советите на менаџерот за пренос на датотеки на IBM - постојат решенија кои ефикасно управуваат со преносот на датотеки, користејќи го протоколот UDP, на пример, наместо TCP. Ова е добро, но сè уште има минути, а сè уште не сме го вчитале, операторот во центарот за повици не може да му одговори на клиентот што се случило со неговото салдо - треба да почекаме.

За да го спречиме тоа да се случи, ние користиме паралелна функционална резерва. Кога испраќаме настан преку Кафка до Tarantool, повторно пресметувајќи ги агрегатите во реално време, на пример, за денес, добиваме готовински салда, кој може да пренесува салда со која било брзина, на пример, 100 илјади трансакции во секунда и истите тие 2 секунди.

Целта е по упатувањето повик, во рок од 2 секунди на вашата лична сметка нема да има само изменето салдо, туку информации зошто се променило.

Заклучок

Ова беа примери за користење на Tarantool. Навистина ни се допадна отвореноста на Mail.ru и нивната подготвеност да разгледаат различни случаи.

Веќе е тешко за консултантите од BCG или McKinsey, Accenture или IBM да не изненадат со нешто ново - многу од она што тие го нудат, ние или веќе го правиме, сме направиле или планираме да го направиме. Мислам дека Tarantool ќе го заземе своето заслужено место во нашиот технолошки куп и ќе замени многу постоечки технологии. Ние сме во активна фаза на развој на овој проект.

Извештајот на Олег и Андреј е еден од најдобрите на конференцијата Тарантул минатата година, а на 17 јуни Олег Ивлев ќе зборува на Т+ Конференција 2019 година со извештај „Зошто Tarantool во претпријатието“. Презентација од МегаФон ќе има и Александар Деулин „Кеши на Tarantool и репликација од Oracle“. Ајде да дознаеме што се сменило, какви планови се спроведени. Придружете се - конференцијата е бесплатна, се што треба да направите е се регистрирате. Сите прифатени извештаи а формирана е и конференциската програма: нови случаи, ново искуство во користење на Tarantool, архитектура, претпријатие, упатства и микросервиси.

Извор: www.habr.com