Хабрахабр

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

Зачем такой корпорации, как МегаФон, Tarantool в биллинге? Со стороны кажется, что обычно приходит вендор, приносит какую-то большую коробку, втыкает штекер в розетку — вот и биллинг! Когда-то так и было, но сейчас это архаика, и такие динозавры уже вымерли или вымирают. Изначально биллинг это система для выставления счетов — считалка или калькулятор. В современном телекоме — это система автоматизации всего жизненного цикла взаимодействия с абонентом от заключения договора до расторжения, включая real-time-тарификацию, прием платежей и еще много чего. Биллинг в телеком-компаниях похож на боевого робота — большого, мощного и обвешанного оружием.

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

Проект «Единый биллинг»

Проект, о котором пойдет речь, называется «Единый биллинг». Именно в нем Tarantool проявил свои лучшие качества.

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

В 2009 году завершилась реорганизация: филиалы по всей России объединились в единую компанию ОАО «МегаФон» (сейчас ПАО). МегаФон — это восемь компаний в одной. Таким образом, в компании появилось 8 биллинговых систем с собственными «кастомными» решениями, филиальными особенностями и разной организационной структурой, ИТ и маркетингом.

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

Мы попытались сократить их число, и наткнулись на вторую проблему, которая знакома многим корпорациям. Несмотря на то, что версия биллинговой системы одна, один поставщик, настройки расходились так, что клеить долго.

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

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

Технологические вызовы

Эти четыре причины двигали нас на серьезные изменения. Был выбор между модернизацией системы и проектированием с нуля. Долго думали, принимали серьезные решения, играли тендеры. В итоге решили спроектировать с самого начала, и взялись за интересные челленджи — технологические вызовы.

Масштабируемость

Если раньше было, условно скажем, 8 биллингов по 15 млн абонентов, а теперь должно было получиться 100 млн абонентов и больше — нагрузка на порядок выше.

Мы стали сопоставимы по масштабу с крупными интернет-игроками, как Mail.ru или Netflix.

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

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

Между Калининградом и Владивостоком 7500 км и 10 часовых поясов. Скорость света конечна и на таких расстояниях задержки уже значимы. 150 мс на самых крутых современных оптических каналах — многовато для real-time-тарификации, особенно такой, как сейчас в телекоме в России. Кроме того, необходимо обновляться за один рабочий день, а с разными часовыми поясами — это проблема.

Нам надо не просто разрешить или запретить абоненту разговаривать, но дать ему определенную квоту — обсчитать вызовы и действия в режиме реального времени так, чтобы он не заметил. Мы не просто предоставляем услуги за абонентскую плату, у нас есть сложные тарифы, пакеты, разные модификаторы.

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

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

Если мы собираем всех абонентов в одной системе, то любые аварийные события и катастрофы плачевны для бизнеса. Поэтому систему проектируем так, чтобы исключить влияние аварий на всю абонентскую базу.

Когда мы ушли в горизонтальное масштабирование, то увеличили количество серверов с сотен до тысяч. Это следствие опять-таки отказа от вертикального масштабирования. Ими надо управлять и строить взаимозаменяемость, автоматически резервировать IT-инфраструктуру и восстанавливать распределенную систему.

Мы спроектировали систему, и в этот момент попытались найти мировой передовой опыт, чтобы проверить, насколько мы в тренде, насколько следуем передовым технологиям. Такие интересные вызовы стояли перед нами.

Мировой опыт

Удивительно, но в мировом телекоме мы не нашли ни одного референса.

Европа отпала по количеству абонентов и масштабу, США — по плоскости своих тарифов. Что-то посмотрели в Китае, а что-то нашли в Индии и взяли специалистов из Vodafone India.

Эти люди могли адекватно оценить, что мы делаем, и привнести в нашу архитектуру определённые знания. Для анализа архитектуры, собрали Dream Team во главе с IBM — архитекторов из разных областей.

Масштаб

Несколько чисел для иллюстрации.

Так мы убираем будущие пороги. Мы проектируем систему под 80 млн абонентов с запасом на миллиард. Это не потому, что мы собираемся захватывать Китай, а из-за напора IoT и M2M.

Хотя у нас 80 млн абонентов, но мы работаем и с потенциальными клиентами, и с теми, которые от нас ушли, если нужно взыскать дебиторскую задолженность. 300 млн документов обрабатываются в реальном времени. Поэтому реальные объемы заметно больше.

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

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

Когда спланировали архитектуру и взялись собирать систему, то импортировали себе самые интересные и передовые технологии. Получился технологический стек, знакомый любому игроку интернета и корпорациям, которые делают высоконагруженные системы.

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

Гибкость — это хорошо, но в большой корпорации без унификации никак.

Мы не собираемся менять тот же Oracle на Tarantool. В реалиях крупных компаний это утопия, или крестовый поход на 5-10 лет с непонятным исходом. Но Cassandra и Couchbase вполне можно заменить на Tarantool, и мы к этому стремимся.

Почему Tarantool?

Есть 4 простых критерия, почему мы выбрали эту БД.

Мы провели нагрузочные тесты на промышленных системах МегаФон. Скорость. Tarantool победил — он показал лучшую производительность.

Текущие memory-решения настолько производительны, что этого запаса компании хватает с лихвой. Нельзя сказать, что другие системы не удовлетворяют потребностям МегаФон. Но нам интересно иметь дело с лидером, а не с тем, кто плетётся в хвосте, в том числе по нагрузочному тесту.

Tarantool закрывает потребности компании даже в долгосрочной перспективе.

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

Он показывает максимальную эффективность. Еще одна приятная особенность, которая немного повлияла на наш выбор — Tarantool лучше остальных баз работает с памятью.

МегаФон вкладывается в надежность, наверное, как никто другой. Надежность. Поэтому когда мы посмотрели на Tarantool, то поняли, что надо сделать так, чтобы он удовлетворял нашим требованиям.

Мы инвестировали свое время и финансы, и вместе с Mail.ru создали enterprise-версию, которая сейчас используется уже в нескольких других компаниях.

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

Партнерство

Самое важное для меня — прямой контакт с разработчиком. Это прямо то, чем ребята из Tarantool подкупили.

Если ты приходишь к игроку, особенно который работает с якорным клиентом, и говоришь, что тебе надо, чтобы БД умела это, это и это, обычно он отвечает:

— Хорошо, положите требования под низ той стопки — когда-нибудь, наверное, мы до них доберемся.

Это круто, и нам очень нравится. У многих есть roadmap на ближайшие 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 (коробочное биллинговое решение).

Его можно сравнить с тем, что описано в книге Фредерика Брукса «Мифический человеко-месяц». Это, в каком-то смысле, исторический для российского рынка проект. У нас меньше — 1 800, но наши в тельняшках, и с учетом использования опенсорса и новых подходов мы работаем производительнее. Тогда, в 60-х годах для разработки новой операционной системы OS/360 для мейнфреймов IBM привлекал 5 000 человек.

Люди из enterprise прекрасно знают CRM. Ниже отображены домены биллинга или, если говорить шире, — бизнес-систем. Другие системы должны быть уже у всех: Open API, API Gateway.

Open API

Давайте опять посмотрим на числа и то, как сейчас работает Open API. Его нагрузка — 10 000 транзакций в секунду. Поскольку мы планируем активно развивать слой микросервисов и строить публичный API МегаФон, то ожидаем большего роста в будущем именно в этой части. 100 000 транзакций точно будет.

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

CRM

CRM — это те самые 80 млн абонентов, которых мы хотим довести до миллиарда, потому что уже есть 300 млн документов, которые включают трехлетнюю историю. Мы действительно ждем новых услуг, и здесь точка роста — это подключенные услуги. Это шар, который будет расти, потому что услуг будет все больше и больше. Соответственно, нужна будет история, мы не хотим на этом споткнуться.

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

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

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

Это те системы, которые позволяют вам звонить или не звонить, принимают решение в реальном времени. Самый телекомовский компонент из мобильной связи — это онлайновая тарификация. Здесь нагрузка 30 000 транзакций в секунду, но с учетом роста передачи данных мы планируем 250 000 транзакций, и поэтому сильно интересуемся Tarantool.

Сам CRM, конечно, шире и мы собираемся применять его в самом ядре. Предыдущая картинка — это те домены, где мы собираемся применять Tarantool.

Опять все переделывать? Наша расчётная цифра ТТХ в 100 млн абонентов меня смущает как архитектора — а что, если 101 млн? Чтобы такого не допустить, мы применяем кэши, заодно поднимая доступность.

Первый — построить все кэши на уровне микросервисов. В целом существует два подхода применения Tarantool. Насколько я понимаю, по этому пути идет ВымпелКом, создавая кэш клиентов.

Но мы хотим ее расшить. Мы же меньше зависим от вендоров, меняем ядро BSS, поэтому у нас единая картотека клиентов уже из коробки. Поэтому применяем немного другой подход — делаем кэши внутрь систем.

Так меньше рассинхрона — одна система отвечает и за кэш, и за основной мастер-источник.

Способ хорошо ложится в подход Tarantool с транзакционным скелетом, когда обновляются только части, которые касаются апдейтов, то есть изменения данных. Все остальное можно хранить где-то еще. Нет огромного data lake, неуправляемого глобального кэша. Кэши проектируются под систему, либо под продукты, либо под клиентов, либо, чтобы облегчить жизнь обслуживанию. Когда звонит расстроенный качеством абонент, хочется качественно его обслужить.

RTO и RPO

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

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

RPO = 0 значит, что мы не теряем данные. Rrecovery point objective — это время восстановления данных, сколько данных мы можем потерять за какой-то период времени.

Задача по Tarantool

Давайте попробуем решить для Tarantool задачу.

Требуется чтобы корзина работала 24 часа 7 дней в неделю, или 99,99% времени. Дано: всем понятная корзина заявок, например, в Амазоне или еще где-нибудь. Предыдущая подписка влияет на следующую, поэтому данные важны — ничто не должно пропасть. Заказы, которые к нам приходят, должны сохранять порядок, потому что мы не можем хаотично включать или отключать абоненту связь — все должно быть строго последовательно.

Можно попробовать решать в лоб и спросить разработчиков БД, но задача математически не решается. Решение. Можно вспоминать теоремы, законы сохранения, квантовую физику, но зачем — ее невозможно решить на уровне БД.

Здесь работает старый добрый архитектурный подход — нужно хорошо знать предметную область и за ее счет разрешить этот ребус.

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

Накануне католического Рождества 24 декабря этот ЦОД лег. У Netflix, который сейчас считается одним из лидеров в IT, до 2012 года был всего один ЦОД. Теперь у Netflix три ЦОДа на западно-восточном побережье и один в западной Европе. Пользователи Канады и США остались без своих любимых фильмов, сильно расстроились и в соцсетях об этом написали.

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

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

Две части: набрасывание корзины ДО принятия решения о покупке, и ПОСЛЕ. Что важно в заявках? В телекоме это может быть сильно сложнее, чем в интернет-магазине, потому что там клиента надо обслужить, предложить 5 вариантов, и это все происходит какое-то время, но корзина наполняется. Часть ДО в телекоме обычно называют order capturing или order negotiation. В этот момент сбой возможен, но это не страшно, потому что происходит в интерактивном режиме под присмотром человека.

Теоретически может потеряться один продукт в корзине, но вы это видите, дополняете корзину снова и продолжаете работать. Если Московский ЦОД внезапно выйдет из строя, то переключившись автоматически на другой ЦОД, мы продолжим работу. В этом случае RTO = 0.

С этого момента начинает работать автоматика — это уже RPO = 0. В тот же момент есть второй вариант: когда мы нажали «submit», то хотим, чтобы данные не потерялись. Шаблоны могут варьироваться, но мы решаем проблему. Применение этих двух разных паттернов в одном случае это может быть просто геораспределенный кластер с одним переключаемым мастером, в другом случае какая-нибудь кворумная запись.

Дальше, имея распределенный реестр заявок, мы можем еще и масштабировать это все — иметь много диспетчеров и исполнителей, которые обращаются к этому реестру.

Cassandra и Tarantool вместе

Есть еще один кейс — «витрина балансов». Здесь как раз интересный случай совместного применения Cassandra и Tarantool.

Маркетологи любят раскрашивать трафик по источникам, появляется все больше деталей по соцсетям, например. Мы применяем Cassandra, потому что 2 млрд звонков в день — не предел, и их будет больше. Это все увеличивает историю.

Cassandra позволяет горизонтально масштабироваться на любые объемы.

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

Мы поборолись с проблемой надежной загрузки этих файлов, применили даже по совету IBM manager file transfer — есть такие решения, которые управляют передачей файлов эффективно, используя протокол UDP, например, а не TCP. Поэтому появилась тема с кэшем, и мы заодно решили следующую проблему: есть старый традиционный кейс, когда оборудование от коммутатора от онлайн-тарификации приходит в файлы, которые мы загружаем в Cassandra. Это хорошо, но все равно минуты, и мы пока это все не прогрузим, оператор в колл-центре не может ответить клиенту, что же случилось с его балансом — надо ждать.

Когда мы отправляем событие через Kafka в Tarantool, пересчитывая агрегаты в реальном времени, например, за сегодня, то получаем кэш балансов, который может отдавать балансы с любой скоростью, например, 100 тысяч транзакций в секунду и те самые 2 секунды. Чтобы этого не произошло, мы применяем параллельный функциональный резерв.

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

Заключение

Это были примеры использования Tarantool. Нам очень понравилась открытость Mail.ru, их готовность рассматривать разные кейсы.

Думаю, что Tarantool в нашем технологическом стеке займет достойное место и заменит множество уже существующих технологий. Консультантам из BCG или McKinsey, Accenture или IBM уже сложно нас удивить чем-то новым — многое из того, что они предлагают, мы либо уже делаем, либо сделали, либо планируем делать. Мы в активной фазе развития этого проекта.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть