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

Защо корпорация като MegaFon се нуждае от Tarantool при фактуриране? Отвън изглежда, че продавачът обикновено идва, носи някаква голяма кутия, включва щепсела в контакта - и това е таксуването! Някога беше така, но сега е архаично и такива динозаври вече са изчезнали или изчезват. Първоначално билингът е система за издаване на фактури - броячна машина или калкулатор. В съвременните телекоми е така система за автоматизация за целия жизнен цикъл на взаимодействие с абоната от сключване на договор до прекратяване, включително фактуриране в реално време, приемане на плащания и много други. Таксуването в телекомуникационните компании е като боен робот – голям, мощен и зареден с оръжия.

Какво общо има Tarantool с това? Те ще говорят за това Олег Ивлев и Андрей Князев. Олег е главен архитект на компанията МегаФон с богат опит в работа в чуждестранни компании, Андрей е директор бизнес системи. От стенограмата на техния доклад на Конференция на Tarantool 2018 ще научите защо е необходима научноизследователска и развойна дейност в корпорациите, какво е Tarantool, как задънената улица на вертикалното мащабиране и глобализацията станаха предпоставка за появата на тази база данни в компанията, за технологичните предизвикателства, архитектурната трансформация и как technostack на MegaFon е подобен на Netflix , Google и Amazon.

Проект "Единно таксуване"

Въпросният проект се нарича „Унифицирано таксуване“. Именно тук Tarantool показа най-добрите си качества.

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

MegaFon е осем компании в една. През 2009 г. реорганизацията приключи: клонове в цяла Русия се сляха в една компания, MegaFon OJSC (сега PJSC). По този начин компанията разполага с 8 системи за таксуване със собствени „персонализирани“ решения, характеристики на клонове и различни организационни структури, ИТ и маркетинг.

Всичко беше наред, докато не трябваше да пуснем един общ федерален продукт. Тук възникнаха много трудности: за едни тарифите се закръгляват нагоре, за други се закръгляват надолу, а за трети - въз основа на средноаритметичното. Има хиляди такива моменти.

Въпреки факта, че имаше само една версия на системата за таксуване, един доставчик, настройките се разминаваха толкова много, че отне много време да се сглобят. Опитахме се да намалим броя им и се натъкнахме на втори проблем, който е познат на много корпорации.

Вертикално мащабиране. Дори най-готиният хардуер по това време не отговаряше на нуждите. Използвахме оборудване на Hewlett-Packard от линията Superdome Hi-End, но то не отговаряше на нуждите дори на два клона. Исках хоризонтално мащабиране без големи оперативни разходи и капиталови инвестиции.

Очаква се ръст в броя на абонатите и услугите. Консултантите отдавна донесоха истории за IoT и M2M в света на телекомуникациите: ще дойде време, когато всеки телефон и ютия ще имат SIM карта и две в хладилника. Днес имаме един брой абонати, но в близко бъдеще ще бъдат много повече.

Технологични предизвикателства

Тези четири причини ни мотивираха да направим сериозни промени. Имаше избор между надграждане на системата и проектиране от нулата. Дълго мислихме, вземахме сериозни решения, играехме търгове. В резултат на това решихме да проектираме от самото начало и поехме интересни предизвикателства – технологични предизвикателства.

Мащабируемост

Ако беше преди, да кажем, да кажем 8 таксувания за 15 милиона абонати, и сега трябваше да работи 100 милиона абонати и повече - натоварването е с порядък по-голямо.

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

Но по-нататъшното движение към увеличаване на натоварването и абонатната база постави пред нас сериозни предизвикателства.

География на нашата огромна страна

Между Калининград и Владивосток 7500 км и 10 часови зони. Скоростта на светлината е крайна и на такива разстояния забавянията вече са значителни. 150 ms на най-готините съвременни оптични канали е твърде много за таксуване в реално време, особено както е сега в телекома в Русия. Освен това трябва да актуализирате за един работен ден, а при различните часови зони това е проблем.

Ние не предоставяме услуги само срещу абонаментна такса, имаме сложни тарифи, пакети и различни модификатори. Трябва не само да разрешим или забраним на абоната да говори, но и да му дадем определена квота - да изчислим обажданията и действията в реално време, така че той да не забележи.

отказоустойчивост

Това е другата страна на централизацията.

Ако съберем всички абонати в една система, тогава всякакви извънредни събития и бедствия са пагубни за бизнеса. Затова ние проектираме системата по такъв начин, че да елиминираме въздействието на авариите върху цялата абонатна база.

Това отново е следствие от отказа от вертикално мащабиране. Когато мащабирахме хоризонтално, увеличихме броя на сървърите от стотици на хиляди. Те трябва да бъдат управлявани и взаимозаменяеми, автоматично да архивират ИТ инфраструктурата и да възстановяват разпределената система.

Изправихме се пред такива интересни предизвикателства. Ние проектирахме системата и в този момент се опитахме да намерим най-добрите световни практики, за да проверим доколко сме в тенденция, доколко следваме напредналите технологии.

Световен опит

Изненадващо, не открихме нито една референция в световния телеком.

Европа отстъпи по брой абонати и мащаб, САЩ - по плоскост на тарифите си. Разгледахме някои в Китай и намерихме някои в Индия и наехме специалисти от Vodafone India.

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

мащаб

Няколко числа за илюстрация.

Ние проектираме системата за 80 милиона абонати с резерв от един милиард. Ето как премахваме бъдещите прагове. Това не е защото ще превземем Китай, а заради настъплението на IoT и M2M.

300 милиона документа, обработени в реално време. Въпреки че имаме 80 милиона абонати, ние работим както с потенциални клиенти, така и с такива, които са ни напуснали, ако трябва да съберем вземания. Следователно реалните обеми са значително по-големи.

2 милиарда транзакции Балансът се променя ежедневно - това са плащания, такси, обаждания и други събития. 200 TB данни се променят активно, променяйте малко по-бавно 8 PB данни, и това не е архив, а живи данни в едно таксуване. Мащаб по център за данни - 5 хиляди сървъра на 14 сайта.

Технологичен стек

Когато планирахме архитектурата и започнахме да сглобяваме системата, внесохме най-интересните и напреднали технологии. Резултатът е технологичен стек, познат на всеки интернет играч и корпорации, които правят системи с високо натоварване.

Стекът е подобен на стека на други големи играчи: Netflix, Twitter, Viber. Състои се от 6 компонента, но искаме да го съкратим и унифицираме.

Гъвкавостта е добра, но в голяма корпорация няма как без обединение.

Няма да променим същия Oracle на Tarantool. В реалностите на големите компании това е утопия или кръстоносен поход за 5-10 години с неясен изход. Но Cassandra и Couchbase могат лесно да бъдат заменени с Tarantool и това е, към което се стремим.

Защо Tarantool?

Има 4 прости критерия, поради които избрахме тази база данни.

Скорост. Проведохме тестове за натоварване на индустриални системи MegaFon. Tarantool спечели - показа най-добро представяне.

Това не означава, че други системи не отговарят на нуждите на MegaFon. Настоящите решения за памет са толкова продуктивни, че резервите на компанията са повече от достатъчни. Но ние се интересуваме да имаме работа с лидер, а не с някой, който изостава, включително и в теста за натоварване.

Tarantool покрива нуждите на компанията дори в дългосрочен план.

TCO цена. Поддръжката на Couchbase на обеми на MegaFon струва астрономически суми пари, но с Tarantool ситуацията е много по-приятна и те са сходни по функционалност.

Друга хубава характеристика, която леко повлия на избора ни е, че Tarantool работи по-добре с памет от други бази данни. Той показва максимална ефективност.

Надеждност. MegaFon инвестира в надеждност, вероятно повече от всеки друг. Така че, когато разгледахме Tarantool, разбрахме, че трябва да го накараме да отговаря на нашите изисквания.

Ние инвестирахме нашето време и финанси и заедно с Mail.ru създадохме корпоративна версия, която сега се използва в няколко други компании.

Tarantool-Enterprise напълно ни удовлетвори по отношение на сигурността, надеждността и регистрирането.

партньорства

Най-важното за мен е директен контакт с разработчика. Точно с това подкупиха момчетата от Tarantool.

Ако дойдете при играч, особено този, който работи с anchor клиент, и кажете, че имате нужда от базата данни, за да можете да направите това, това и това, той обикновено отговаря:

- Добре, поставете изискванията на дъното на тази купчина - някой ден вероятно ще стигнем до тях.

Мнозина имат пътна карта за следващите 2-3 години и е почти невъзможно да се интегрират там, но разработчиците на Tarantool пленяват със своята откритост, а не само от MegaFon, и адаптират системата си към клиента. Готино е и много ни харесва.

Където използвахме Tarantool

Използваме Tarantool в няколко елемента. Първият е в пилота, който направихме на адресната указателна система. По едно време исках да е система, подобна на Yandex.Maps и Google Maps, но се оказа малко по-различно.

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

Второто приложение е модерна тема, наречена two-speed IT. Това е така, защото консултанти от всеки ъгъл казват, че корпорациите трябва да отидат там.

Има инфраструктурен слой, над него има домейни, например система за таксуване като телеком, корпоративни системи, корпоративно отчитане. Това е сърцевината, която не трябва да се пипа. Това е, разбира се, възможно е, но параноично осигуряване на качество, защото носи пари на корпорацията.

Следва слоят от микроуслуги - това, което отличава оператора или друг играч. Микроуслугите могат бързо да бъдат създадени въз основа на определени кешове, като пренасят данни от различни домейни там. Тук поле за експерименти — ако нещо не се получи, затворих една микроуслуга и отворих друга. Това осигурява наистина увеличено време за пускане на пазара и увеличава надеждността и бързината на компанията.

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

Къде планираме да използваме Tarantool

Ако сравним нашия успешен проект за таксуване с програмите за трансформация на Deutsche Telekom, Svyazcom, Vodafone India, той е изненадващо динамичен и креативен. В процеса на изпълнение на този проект не само MegaFon и неговата структура бяха трансформирани, но и Tarantool-enterprise се появи в Mail.ru, а нашият доставчик Nexign (преди Peter-Service) - BSS Box (решение за таксуване в кутия).

Това е в известен смисъл исторически проект за руския пазар. Може да се сравни с описаното в книгата „Митичният човек-месец” на Фредерик Брукс. След това, през 60-те години, IBM нае 360 души, за да разработят новата операционна система OS/5 за мейнфрейми. Имаме по-малко - 000, но нашите са в жилетки и като се има предвид използването на отворен код и нови подходи, работим по-продуктивно.

По-долу са домейните на таксуването или, по-широко казано, бизнес системите. Хората от предприятието познават много добре CRM. Всеки вече трябва да има други системи: Open API, API Gateway.

Отворете API

Нека отново да разгледаме числата и как Open API работи в момента. Натоварването му е 10 000 транзакции в секунда. Тъй като планираме активно да развиваме слоя с микроуслуги и да изграждаме публичния API на MegaFon, очакваме по-голям растеж в бъдеще в тази част. Определено ще има 100 000 транзакции.

Не знам дали можем да сравним с Mail.ru в SSO - момчетата изглежда имат 1 000 0000 транзакции в секунда. Тяхното решение ни е изключително интересно и смятаме да възприемем техния опит – например правене на функционален SSO бекъп чрез Tarantool. Сега разработчиците от Mail.ru правят това за нас.

CRM

CRM са същите 80 милиона абонати, които искаме да увеличим до милиард, защото вече има 300 милиона документа, които включват тригодишна история. Ние наистина се радваме на нови услуги и тук точка на растеж са свързани услуги. Това е бал, който ще расте, защото ще има все повече услуги. Съответно ще ни трябва история; не искаме да се натъкваме на това.

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

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

Всичко останало са решения на корпоративно ниво. В хранилището за разговори - 2 милиарда на ден, 60 милиарда на месец. Понякога трябва да ги преброите за месец и е по-добре бързо. Финансов мониторинг - това са точно същите 300 милиона, които непрекъснато растат и растат: абонатите често се движат между операторите, увеличавайки тази част.

Най-телекомуникационният компонент на мобилните комуникации е онлайн таксуване. Това са системите, които ви позволяват да се обаждате или да не се обаждате, да вземате решения в реално време. Тук натоварването е 30 000 транзакции в секунда, но като вземем предвид ръста на трансфера на данни, планираме 250 000 транзакции, и затова сме много заинтересовани от Tarantool.

Предишната снимка е домейните, където ще използваме Tarantool. Самият CRM, разбира се, е по-широк и ние ще го използваме в самото ядро.

Нашата прогнозна TTX цифра от 100 милиона абонати ме обърква като архитект - ами ако 101 милиона? Трябва ли да повторите всичко отново? За да предотвратим това да се случи, ние използваме кешове, като в същото време увеличаваме достъпността.

Като цяло има два подхода за използване на Tarantool. първо - изграждане на всички кешове на ниво микросервиз. Доколкото разбирам, VimpelCom следва този път, създавайки кеш от клиенти.

Ние сме по-малко зависими от доставчици, променяме ядрото на BSS, така че имаме един клиентски файл от кутията. Но ние искаме да го разширим. Затова ние възприемаме малко по-различен подход - правете кешове вътре в системите.

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

Методът се вписва добре в подхода на Tarantool с транзакционен скелет, когато се актуализират само части, които се отнасят до актуализации, тоест промени в данните. Всичко останало може да се съхранява на друго място. Няма огромно езеро от данни, неуправляван глобален кеш. Кешовете са предназначени за системата, или за продукти, или за клиенти, или за да улеснят живота при поддръжка. Когато абонат се обади и е разстроен от качеството на вашата услуга, вие искате да предоставите качествена услуга.

RTO и RPO

Има два термина в ИТ - OTR и RPO.

Обективно време за възстановяване е времето, необходимо за възстановяване на услугата след повреда. RTO = 0 означава, че дори ако нещо се провали, услугата продължава да работи.

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

Задача на Tarantool

Нека се опитаме да разрешим проблем за Tarantool.

Дадено: кошница с приложения, които всеки разбира, например в Amazon или някъде другаде. длъжен така че пазарската количка да работи 24 часа 7 дни в седмицата или 99,99% от времето. Поръчките, които идват при нас, трябва да останат в ред, защото не можем произволно да включим или изключим връзката на абоната - всичко трябва да бъде строго последователно. Предишният абонамент засяга следващия, така че данните са важни - нищо не трябва да липсва.

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

Добрият стар архитектурен подход работи тук - трябва да познавате добре предметната област и да я използвате, за да решите този пъзел.

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

Netflix, който сега се смята за един от лидерите в ИТ, имаше само един център за данни до 2012 г. В навечерието на католическата Коледа, 24 декември, този център за данни излезе от строя. Потребителите в Канада и САЩ останаха без любимите си филми, бяха много разстроени и писаха за това в социалните мрежи. Сега Netflix има три центъра за данни на западно-източното крайбрежие и един в Западна Европа.

Първоначално изграждаме гео-разпределено решение - толерантността към грешки е важна за нас.

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

Какво е важно в приложенията? Две части: Хвърляне в кош за вземане на решение за покупка и СЛЕД. Частта DO в телекома обикновено се нарича улавяне на поръчка или договаряне на поръчката. В телекома това може да бъде много по-трудно, отколкото в онлайн магазина, защото там клиентът трябва да бъде обслужен, да му бъдат предложени 5 опции и всичко това се случва за известно време, но кошницата се пълни. В този момент е възможен провал, но не е страшно, защото се случва интерактивно под човешки контрол.

Ако московският център за данни внезапно се провали, тогава чрез автоматично превключване към друг център за данни ще продължим да работим. Теоретично един продукт може да се загуби в количката, но вие го виждате, добавяте отново в количката и продължавате да работите. В този случай RTO = 0.

В същия момент има и втора опция: когато щракнем върху „изпрати“, искаме данните да не бъдат загубени. От този момент нататък автоматизацията започва да работи - това е RPO = 0. Използвайки тези два различни модела, в един случай може просто да бъде гео-разпределен клъстер с един превключваем главен, в друг случай някакъв вид запис на кворум. Моделите може да варират, но ние решаваме проблема.

Освен това, разполагайки с разпределен регистър на приложенията, можем също така да го мащабираме - да имаме много диспечери и изпълнители, които имат достъп до този регистър.

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

Има и друг случай - "витрина на баланси". Ето един интересен случай на съвместно използване на Cassandra и Tarantool.

Използваме Cassandra, защото 2 милиарда обаждания на ден не са ограничението и ще има още. Маркетолозите обичат да оцветяват трафика по източник; все повече и повече подробности се появяват в социалните мрежи, например. Всичко това допринася за историята.

Cassandra ви позволява да мащабирате хоризонтално до произволен размер.

Чувстваме се комфортно с Касандра, но има един проблем - не е добра в четенето. На записа всичко е наред, 30 000 в секунда не е проблем - проблем с четенето.

Затова се появи тема с кеш и в същото време решихме следния проблем: има стар традиционен случай, когато оборудване от превключвател от онлайн таксуване влиза във файловете, които зареждаме в Касандра. Борихме се с проблема с надеждното изтегляне на тези файлове, дори използвайки съвета на мениджъра на IBM за прехвърляне на файлове - има решения, които управляват ефективно прехвърлянето на файлове, използвайки UDP протокола, например, вместо TCP. Това е добре, но все още са минути и все още не сме го заредили, операторът в кол центъра не може да отговори на клиента какво се е случило с неговия баланс - трябва да изчакаме.

За да предотвратим това да се случи, ние използваме паралелен функционален резерв. Когато изпратим събитие чрез Kafka до Tarantool, преизчислявайки агрегатите в реално време, например за днес, получаваме парични наличности, който може да прехвърля баланси с всякаква скорост, например 100 хиляди транзакции в секунда и същите тези 2 секунди.

Целта е след обаждане в рамките на 2 секунди в личния ви акаунт да има не само променения баланс, но и информация защо се е променил.

Заключение

Това бяха примери за използване на Tarantool. Много ни хареса откритостта на Mail.ru и готовността им да разглеждат различни случаи.

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

Докладът на Олег и Андрей е един от най-добрите на конференцията Tarantool миналата година, а на 17 юни Олег Ивлев ще говори на Конференция T+ 2019 с доклад „Защо Tarantool в Enterprise“. Александър Деулин също ще направи презентация от MegaFon „Кеширане на Tarantool и репликация от Oracle“. Нека разберем какво се е променило, какви планове са изпълнени. Присъединете се – конференцията е безплатна, всичко, което трябва да направите е регистър, всички приети доклади и програмата на конференцията е формирана: нови случаи, нов опит в използването на Tarantool, архитектура, предприятие, уроци и микроуслуги.

Източник: www.habr.com