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

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

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

Проект „Единен биллинг“

Проектът, за който ще се говори, се нарича „Единен биллинг“. Именно в него Tarantool прояви своите най-добри качества.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Това е обратната страна на централизацията.

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

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

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

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

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

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

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

Мащаб

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

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

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

2 млрд транзакции ежедневно променят баланса – това са плащания, начисления, повиквания и други събития. 200 Тб данни се променят активно, малко по-бавно се променят 8 Пб данни, и това не е архив, а живи данни в единен билнинг. Мащабът по ЦОД-ове — 5 хиляди сървъра на 14 площадки.

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

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

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

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

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

Защо Tarantool?

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

Скорост. Проведохме натоварващи тестове на индустриални системи на МегаФон. Tarantool спечели — той показа най-добра производителност.

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

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

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

Още една приятна особеност, която малко повлия на нашия избор — Tarantool работи по-добре с паметта от останалите бази. Той показва максимална ефективност.

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

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

Tarantool-enterprise напълно ни задоволи по безопасност, надеждност и логиране.

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

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

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

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

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

Къде приложихме Tarantool

При нас Tarantool се използва в няколко елемента. Първият — в пилота,, който направихме на системата за адресен каталог. В свое време искахме да бъде система, която прилича на Яндекс.Карти и Google Maps, но стана малко по-различно.

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

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

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

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

Микросервизите са, може би, основната роля на Tarantool в МегаФон.

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

Ако сравняваме нашия успешен проект за фактуриране с програмите за трансформации в Deutsche Telekom, Связьком и Vodafone India, той е удивително динамичен и креативен. В процеса на реализиране на този проект не само МегаФон и неговата структура се трансформираха, но и се появи Tarantool-enterprise в Mail.ru, а при нашия доставчик Nexign (по-рано «Петер-Сервис») — BSS Box (коробочно решение за фактуриране).

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

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

Open API

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

Не знам дали ще се сравним с Mail.ru в SSO — при тях сякаш има 1 000 0000 трансакции в секунда. Нах тяхното решение е изключително интересно и планираме да приемем техния опит — например, да създадем функционален резерв на SSO с помощта на Tarantool. В момента разработчиците от Mail.ru работят в тази насока при нас.

CRM

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

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

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

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

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

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

Нашето изчислено число TTH в 100 милиона абонати ме тревожи като архитект — а какво, ако станат 101 милиона? Пак ли ще трябва да преработваме всичко? За да предотвратим това, използваме кешове, увеличавайки достъпността.

Въобще съществуват два подхода за прилагане на Tarantool. Първият е да изградим всички кешове на ниво микросервис.Насколько я разберем, по този път върви ВымпелКом, създавайки кеш на клиентите.

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

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

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

RTO и RPO

В IT съществуват два термина — RTO и RPO.

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

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

Задача за Tarantool

Нека опитаме да решим задачата за Tarantool.

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

Решение. Може да се опитате да решите направо и да питате разработчиците на бази данни, но задачата математически не може да се реши. Може да се припомнят теореми, закони на запазването, квантова физика, но защо — тя не може да се реши на ниво база данни.

Тук работи добрият стар архитектурен подход — трябва да познавате добре предметната област и чрез нея да разрешите този ребус.

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

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

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

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

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

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

В същия момент има и втори вариант: когато натиснем „submit“, искаме данните да не се загубят. От този момент нататък автоматика започва да работи — това вече е RPO = 0. Прилагането на тези два различни шаблона в едно случай може да бъде просто геораспределен кластер с един превключваем мастер, а в друг случай някаква квотна запись. Шаблоните могат да варират, но ние решаваме проблема.

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

Cassandra и Tarantool заедно

Има още един случай — „витрина на баланси“. Тук точно имаме интересен случай на съвместно приложение на Cassandra и Tarantool.

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

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

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

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

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

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

Заключение

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

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

Докладът на Олег и Андрей е един от най-добрите на Tarantool Conference миналата година, а на 17 юни Олег Ивлев ще участва на T+ Conference 2019 с доклад «Защо Tarantool в Enterprise». Също така от МегаФон ще участва Александър Деулин с доклад «Кешове на Tarantool и репликация от Oracle». Ще разберем какво се е променило, какви планове са успели да реализират. Присъединете се — конференцията е безплатна, просто трябва да да се регистрирате. Всички доклади са приети и програмата на конференцията е формулирана: нови случаи, нов опит в използването на Tarantool, архитектура, ентерпрайз, уроци и микросервизи.

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