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

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

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

Проектът „Единичен billing“

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

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

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

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

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

Вертикално мащабиране. Дори най-доброто оборудване по онова време не отговаряше на нуждите. Работехме с оборудване на 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 Пб данни, и това не е архив, а живи данни в единно фактуриране. Мащабът по ЦОД-овете — 5000 сървъра на 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 пъти! Градът изниква след третата буква. Сега адаптираме интерфейса, за да стане това след първата. Въпреки това, скоростта на отговор е съвсем различна — вече е милисекунди вместо секунди.

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

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

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

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

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

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

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

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

Open API

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

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

CRM

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

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

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

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

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

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

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

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

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

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

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

RTO и RPO

В ИТ съществуват два термина – 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 manager file transfer — съществуват решения, които управляват предаването на файлове ефективно, използвайки протокол 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