Зачем такой корпорации, как МегаФон, Tarantool в биллинге? Со стороны кажется, что обычно приходит вендор, приносит какую-то большую коробку, втыкает штекер в розетку — вот и биллинг! Когда-то так и было, но сейчас это архаика, и такие динозавры уже вымерли или вымирают. Изначально биллинг это система для выставления счетов — считалка или калькулятор. В современном телекоме — это система автоматизации всего жизненного цикла взаимодействия с абонентом от заключения договора до расторжения, включая real-time-тарификацию, прием платежей и еще много чего. Биллинг в телеком-компаниях похож на боевого робота — большого, мощного и обвешанного оружием.
Причем же здесь Tarantool? Об этом расскажут Олег Ивлев и Андрей Князев. Олег — главный архитектор компании МегаФон с огромным опытом работы в зарубежных компаниях, Андрей — директор по бизнес-системам. Из расшифровки их доклада на Tarantool Conference 2018 вы узнаете, зачем нужен R&D в корпорациях, что такое Tarantool, как тупик вертикального масштабирования и глобализация стали предпосылками появления этой БД в компании, про технологические вызовы, трансформацию архитектуры, и чем техностек МегаФон похож на Netflix, Google и Amazon.
Проект, о котором пойдет речь, называется «Единый биллинг». Именно в нем Tarantool проявил свои лучшие качества.
Рост производительности Hi-End оборудования не успевал за ростом абонентской базы и ростом количества услуг, ожидался дальнейший рост количества абонентов и услуг за счет M2M, IoT, да и филиальные особенности приводили к ухудшению time-to-market. Компанией было принято решение создать единую бизнес систему с уникальной модульной архитектурой мирового уровня, взамен 8 текущих разных биллинговых систем.
МегаФон — это восемь компаний в одной. В 2009 году завершилась реорганизация: филиалы по всей России объединились в единую компанию ОАО «МегаФон» (сейчас ПАО). Таким образом, в компании появилось 8 биллинговых систем с собственными «кастомными» решениями, филиальными особенностями и разной организационной структурой, ИТ и маркетингом.
Все было хорошо, пока не пришлось запустить один общий федеральный продукт. Здесь появилась куча сложностей: у кого-то тарификация с округлением в большую сторону, у кого-то в меньшую, а у кого-то — по среднему арифметическому. Таких моментов тысячи.
Несмотря на то, что версия биллинговой системы одна, один поставщик, настройки расходились так, что клеить долго. Мы попытались сократить их число, и наткнулись на вторую проблему, которая знакома многим корпорациям.
Вертикальное масштабирование. Даже самое крутое в то время железо не отвечало потребностям. В работе использовали оборудование Hewlett-Packard, линейки Superdome Hi-End, но оно не тянуло потребность даже двух филиалов. Хотелось горизонтального масштабирования без больших операционных затрат и капитальных вложений.
Ожидание роста количества абонентов и услуг. Консультанты давно принесли в телеком-мир рассказы про IoT и M2M: настанут времена, когда в каждом телефоне и утюге будет по сим-карте, а в холодильнике по две. Сегодня у нас одно количество абонентов, а в ближайшем будущем их будет на порядок больше.
Эти четыре причины двигали нас на серьезные изменения. Был выбор между модернизацией системы и проектированием с нуля. Долго думали, принимали серьезные решения, играли тендеры. В итоге решили спроектировать с самого начала, и взялись за интересные челленджи — технологические вызовы.
Если раньше было, условно скажем, 8 биллингов по 15 млн абонентов, а теперь должно было получиться 100 млн абонентов и больше — нагрузка на порядок выше.
Но дальнейшее движение на увеличение нагрузки и абонентской базы поставило перед нами серьезные задачи.
Между Калининградом и Владивостоком 7500 км и 10 часовых поясов. Скорость света конечна и на таких расстояниях задержки уже значимы. 150 мс на самых крутых современных оптических каналах — многовато для real-time-тарификации, особенно такой, как сейчас в телекоме в России. Кроме того, необходимо обновляться за один рабочий день, а с разными часовыми поясами — это проблема.
Мы не просто предоставляем услуги за абонентскую плату, у нас есть сложные тарифы, пакеты, разные модификаторы. Нам надо не просто разрешить или запретить абоненту разговаривать, но дать ему определенную квоту — обсчитать вызовы и действия в режиме реального времени так, чтобы он не заметил.
Если мы собираем всех абонентов в одной системе, то любые аварийные события и катастрофы плачевны для бизнеса. Поэтому систему проектируем так, чтобы исключить влияние аварий на всю абонентскую базу.
Это следствие опять-таки отказа от вертикального масштабирования. Когда мы ушли в горизонтальное масштабирование, то увеличили количество серверов с сотен до тысяч. Ими надо управлять и строить взаимозаменяемость, автоматически резервировать 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, и мы к этому стремимся.
Есть 4 простых критерия, почему мы выбрали эту БД.
Скорость. Мы провели нагрузочные тесты на промышленных системах МегаФон. Tarantool победил — он показал лучшую производительность.
Нельзя сказать, что другие системы не удовлетворяют потребностям МегаФон. Текущие memory-решения настолько производительны, что этого запаса компании хватает с лихвой. Но нам интересно иметь дело с лидером, а не с тем, кто плетётся в хвосте, в том числе по нагрузочному тесту.
Стоимость TCO. Поддержка Couchbase на объемах МегаФон стоит космических денег, с Tarantool же ситуация гораздо приятнее, а по функциональности они близки.
Еще одна приятная особенность, которая немного повлияла на наш выбор — Tarantool лучше остальных баз работает с памятью. Он показывает максимальную эффективность.
Надежность. МегаФон вкладывается в надежность, наверное, как никто другой. Поэтому когда мы посмотрели на Tarantool, то поняли, что надо сделать так, чтобы он удовлетворял нашим требованиям.
Мы инвестировали свое время и финансы, и вместе с Mail.ru создали enterprise-версию, которая сейчас используется уже в нескольких других компаниях.
Самое важное для меня — прямой контакт с разработчиком. Это прямо то, чем ребята из Tarantool подкупили.
Если ты приходишь к игроку, особенно который работает с якорным клиентом, и говоришь, что тебе надо, чтобы БД умела это, это и это, обычно он отвечает:
— Хорошо, положите требования под низ той стопки — когда-нибудь, наверное, мы до них доберемся.
У многих есть roadmap на ближайшие 2-3 года, и встроиться туда практически невозможно, а разработчики Tarantool подкупают открытостью, и не только с МегаФон, и адаптируют свою систему под заказчика. Это круто, и нам очень нравится.
У нас Tarantool используется в нескольких элементах. Первый — в пилоте, который мы сделали на системе адресного каталога. В свое время хотелось, чтобы это была система, которая похожа на Яндекс.Карты и Google Maps, но вышло несколько иначе.
Для примера, адресный каталог в интерфейсе продаж. На Oracle поиск нужного адреса занимает 12-13 с. — некомфортные цифры. Когда мы переключаемся на Tarantool, подменяем Oracle на другую БД в консоли, и выполняем тот же поиск, то получаем ускорение в 200 раз! Город выскакивает после третьей буквы. Сейчас адаптируем интерфейс, чтобы это происходило после первой. Тем не менее, скорость отклика совсем другая — уже миллисекунды вместо секунд.
Второе применение — модная тема, которая называется двухскоростной IT. Все потому что консультанты из каждого утюга говорят, что корпорациям следует туда идти.
Здесь есть слой инфраструктуры, над ним домены, например, биллинговая система, как у телекома, корпоративные системы, корпоративная отчетность. Это ядро, которое трогать не надо. То есть, конечно, можно, но параноидально обеспечивая качество, потому что это приносит корпорации деньги.
Дальше идет слой микросервисов — то, что дифференцирует оператора или другого игрока. Микросервисы можно быстро создавать на основе неких кэшей, поднимая туда данные из разных доменов. Здесь поле для экспериментов — если что-то не получилось, закрыл один микросервис, открыл другой. Это обеспечивает действительно повышенный time-to-market и увеличивает надежность и скорость компании.
Если сравнивать наш успешный проект биллинга с программами трансформации в Deutsche Telekom, Связькоме, Vodafone India, он удивительно динамичен и креативен. В процессе реализации этого проекта не только трансформировался МегаФон и его структура, но и появился Tarantool-enterprise у Mail.ru, а у нашего вендора Nexign (ранее «Петер-Сервис») — BSS Box (коробочное биллинговое решение).
Это, в каком-то смысле, исторический для российского рынка проект. Его можно сравнить с тем, что описано в книге Фредерика Брукса «Мифический человеко-месяц». Тогда, в 60-х годах для разработки новой операционной системы OS/360 для мейнфреймов IBM привлекал 5 000 человек. У нас меньше — 1 800, но наши в тельняшках, и с учетом использования опенсорса и новых подходов мы работаем производительнее.
Ниже отображены домены биллинга или, если говорить шире, — бизнес-систем. Люди из enterprise прекрасно знают CRM. Другие системы должны быть уже у всех: Open API, API Gateway.
Давайте опять посмотрим на числа и то, как сейчас работает Open API. Его нагрузка — 10 000 транзакций в секунду. Поскольку мы планируем активно развивать слой микросервисов и строить публичный API МегаФон, то ожидаем большего роста в будущем именно в этой части. 100 000 транзакций точно будет.
Не знаю, сравнимся ли в SSO с Mail.ru — у ребят, вроде, 1 000 0000 транзакций в секунду. Нам их решение крайне интересно и мы планируем перенять их опыт — например, делать функциональный резерв SSO с помощью Tarantool. Сейчас разработчики из Mail.ru этим занимаются у нас.
CRM — это те самые 80 млн абонентов, которых мы хотим довести до миллиарда, потому что уже есть 300 млн документов, которые включают трехлетнюю историю. Мы действительно ждем новых услуг, и здесь точка роста — это подключенные услуги. Это шар, который будет расти, потому что услуг будет все больше и больше. Соответственно, нужна будет история, мы не хотим на этом споткнуться.
Сам биллинг в части выставления счетов, работы с дебиторской задолженностью клиентов трансформировался в отдельный домен. Чтобы расшить производительность, применен архитектурный шаблон доменной архитектуры.
Все остальное — это решения уровня enterprise. В хранилище звонков — 2 млрд в день, 60 млрд в месяц. Иногда приходится пересчитать их за месяц, и лучше быстро. Финансовый мониторинг — это как раз те самые 300 млн, которые постоянно растут и растут: абоненты часто бегают между операторами, увеличивая эту часть.
Самый телекомовский компонент из мобильной связи — это онлайновая тарификация. Это те системы, которые позволяют вам звонить или не звонить, принимают решение в реальном времени. Здесь нагрузка 30 000 транзакций в секунду, но с учетом роста передачи данных мы планируем 250 000 транзакций, и поэтому сильно интересуемся Tarantool.
Предыдущая картинка — это те домены, где мы собираемся применять Tarantool. Сам CRM, конечно, шире и мы собираемся применять его в самом ядре.
Наша расчётная цифра ТТХ в 100 млн абонентов меня смущает как архитектора — а что, если 101 млн? Опять все переделывать? Чтобы такого не допустить, мы применяем кэши, заодно поднимая доступность.
В целом существует два подхода применения Tarantool. Первый — построить все кэши на уровне микросервисов. Насколько я понимаю, по этому пути идет ВымпелКом, создавая кэш клиентов.
Мы же меньше зависим от вендоров, меняем ядро BSS, поэтому у нас единая картотека клиентов уже из коробки. Но мы хотим ее расшить. Поэтому применяем немного другой подход — делаем кэши внутрь систем.
Способ хорошо ложится в подход Tarantool с транзакционным скелетом, когда обновляются только части, которые касаются апдейтов, то есть изменения данных. Все остальное можно хранить где-то еще. Нет огромного data lake, неуправляемого глобального кэша. Кэши проектируются под систему, либо под продукты, либо под клиентов, либо, чтобы облегчить жизнь обслуживанию. Когда звонит расстроенный качеством абонент, хочется качественно его обслужить.
В IT существует два термина — RTO и RPO.
Recovery time objective — это время восстановления сервиса после сбоя. RTO = 0 значит, что даже если что-то упало, сервис продолжает работать.
Rrecovery point objective — это время восстановления данных, сколько данных мы можем потерять за какой-то период времени. RPO = 0 значит, что мы не теряем данные.
Давайте попробуем решить для Tarantool задачу.
Дано: всем понятная корзина заявок, например, в Амазоне или еще где-нибудь. Требуется чтобы корзина работала 24 часа 7 дней в неделю, или 99,99% времени. Заказы, которые к нам приходят, должны сохранять порядок, потому что мы не можем хаотично включать или отключать абоненту связь — все должно быть строго последовательно. Предыдущая подписка влияет на следующую, поэтому данные важны — ничто не должно пропасть.
Решение. Можно попробовать решать в лоб и спросить разработчиков БД, но задача математически не решается. Можно вспоминать теоремы, законы сохранения, квантовую физику, но зачем — ее невозможно решить на уровне БД.
Здесь работает старый добрый архитектурный подход — нужно хорошо знать предметную область и за ее счет разрешить этот ребус.
Наше решение: создаем распределенный реестр заявок на Tarantool — геораспределенный кластер. На схеме это три разных центра обработки данных — два до Урала, один за Уралом, и мы распределяем все заявки по этим центрам.
У Netflix, который сейчас считается одним из лидеров в IT, до 2012 года был всего один ЦОД. Накануне католического Рождества 24 декабря этот ЦОД лег. Пользователи Канады и США остались без своих любимых фильмов, сильно расстроились и в соцсетях об этом написали. Теперь у Netflix три ЦОДа на западно-восточном побережье и один в западной Европе.
Итак, у нас есть кластер, но как быть с RPO = 0 и RTO = 0? Решение простое, которое зависит от предметики.
Что важно в заявках? Две части: набрасывание корзины ДО принятия решения о покупке, и ПОСЛЕ. Часть ДО в телекоме обычно называют order capturing или order negotiation. В телекоме это может быть сильно сложнее, чем в интернет-магазине, потому что там клиента надо обслужить, предложить 5 вариантов, и это все происходит какое-то время, но корзина наполняется. В этот момент сбой возможен, но это не страшно, потому что происходит в интерактивном режиме под присмотром человека.
Если Московский ЦОД внезапно выйдет из строя, то переключившись автоматически на другой ЦОД, мы продолжим работу. Теоретически может потеряться один продукт в корзине, но вы это видите, дополняете корзину снова и продолжаете работать. В этом случае RTO = 0.
В тот же момент есть второй вариант: когда мы нажали «submit», то хотим, чтобы данные не потерялись. С этого момента начинает работать автоматика — это уже RPO = 0. Применение этих двух разных паттернов в одном случае это может быть просто геораспределенный кластер с одним переключаемым мастером, в другом случае какая-нибудь кворумная запись. Шаблоны могут варьироваться, но мы решаем проблему.
Дальше, имея распределенный реестр заявок, мы можем еще и масштабировать это все — иметь много диспетчеров и исполнителей, которые обращаются к этому реестру.
Есть еще один кейс — «витрина балансов». Здесь как раз интересный случай совместного применения Cassandra и Tarantool.
Мы применяем Cassandra, потому что 2 млрд звонков в день — не предел, и их будет больше. Маркетологи любят раскрашивать трафик по источникам, появляется все больше деталей по соцсетям, например. Это все увеличивает историю.
Мы себя чувствуем комфортно с Cassandra, но у нее есть одна проблема — она не хороша на чтении. На записи все ОК, 30 000 в секунду не проблема — проблема в чтении.
Поэтому появилась тема с кэшем, и мы заодно решили следующую проблему: есть старый традиционный кейс, когда оборудование от коммутатора от онлайн-тарификации приходит в файлы, которые мы загружаем в Cassandra. Мы поборолись с проблемой надежной загрузки этих файлов, применили даже по совету IBM manager file transfer — есть такие решения, которые управляют передачей файлов эффективно, используя протокол UDP, например, а не TCP. Это хорошо, но все равно минуты, и мы пока это все не прогрузим, оператор в колл-центре не может ответить клиенту, что же случилось с его балансом — надо ждать.
Чтобы этого не произошло, мы применяем параллельный функциональный резерв. Когда мы отправляем событие через Kafka в Tarantool, пересчитывая агрегаты в реальном времени, например, за сегодня, то получаем кэш балансов, который может отдавать балансы с любой скоростью, например, 100 тысяч транзакций в секунду и те самые 2 секунды.
Цель в том, чтобы после совершения звонка уже через 2 секунды в личном кабинете был не только измененный баланс, но информация о том, почему он изменился.
Это были примеры использования Tarantool. Нам очень понравилась открытость Mail.ru, их готовность рассматривать разные кейсы.
Консультантам из BCG или McKinsey, Accenture или IBM уже сложно нас удивить чем-то новым — многое из того, что они предлагают, мы либо уже делаем, либо сделали, либо планируем делать. Думаю, что Tarantool в нашем технологическом стеке займет достойное место и заменит множество уже существующих технологий. Мы в активной фазе развития этого проекта.
Причем же здесь Tarantool? Об этом расскажут Олег Ивлев и Андрей Князев. Олег — главный архитектор компании МегаФон с огромным опытом работы в зарубежных компаниях, Андрей — директор по бизнес-системам. Из расшифровки их доклада на Tarantool Conference 2018 вы узнаете, зачем нужен R&D в корпорациях, что такое Tarantool, как тупик вертикального масштабирования и глобализация стали предпосылками появления этой БД в компании, про технологические вызовы, трансформацию архитектуры, и чем техностек МегаФон похож на Netflix, Google и Amazon.
Проект «Единый биллинг»
Проект, о котором пойдет речь, называется «Единый биллинг». Именно в нем Tarantool проявил свои лучшие качества.
Рост производительности Hi-End оборудования не успевал за ростом абонентской базы и ростом количества услуг, ожидался дальнейший рост количества абонентов и услуг за счет M2M, IoT, да и филиальные особенности приводили к ухудшению time-to-market. Компанией было принято решение создать единую бизнес систему с уникальной модульной архитектурой мирового уровня, взамен 8 текущих разных биллинговых систем.
МегаФон — это восемь компаний в одной. В 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.
300 млн документов обрабатываются в реальном времени. Хотя у нас 80 млн абонентов, но мы работаем и с потенциальными клиентами, и с теми, которые от нас ушли, если нужно взыскать дебиторскую задолженность. Поэтому реальные объемы заметно больше.
2 млрд транзакций ежедневно меняют баланс — это платежи, начисления, вызовы и другие события. 200 Тб данных меняются активно, чуть медленнее меняются 8 Пб данных, и это не архив, а живые данные в едином биллинге. Масштаб по ЦОДам — 5 тысяч серверов на 14 площадках.
Технологический стэк
Когда спланировали архитектуру и взялись собирать систему, то импортировали себе самые интересные и передовые технологии. Получился технологический стек, знакомый любому игроку интернета и корпорациям, которые делают высоконагруженные системы.
Стек аналогичен стекам других крупных игроков: Netflix, Twitter, Viber. Он состоит из 6 компонентов, но мы хотим его сократить и унифицировать.
Гибкость — это хорошо, но в большой корпорации без унификации никак.
Мы не собираемся менять тот же 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 (коробочное биллинговое решение).
Это, в каком-то смысле, исторический для российского рынка проект. Его можно сравнить с тем, что описано в книге Фредерика Брукса «Мифический человеко-месяц». Тогда, в 60-х годах для разработки новой операционной системы OS/360 для мейнфреймов IBM привлекал 5 000 человек. У нас меньше — 1 800, но наши в тельняшках, и с учетом использования опенсорса и новых подходов мы работаем производительнее.
Ниже отображены домены биллинга или, если говорить шире, — бизнес-систем. Люди из 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
В IT существует два термина — RTO и RPO.
Recovery time objective — это время восстановления сервиса после сбоя. RTO = 0 значит, что даже если что-то упало, сервис продолжает работать.
Rrecovery point objective — это время восстановления данных, сколько данных мы можем потерять за какой-то период времени. RPO = 0 значит, что мы не теряем данные.
Задача по Tarantool
Давайте попробуем решить для Tarantool задачу.
Дано: всем понятная корзина заявок, например, в Амазоне или еще где-нибудь. Требуется чтобы корзина работала 24 часа 7 дней в неделю, или 99,99% времени. Заказы, которые к нам приходят, должны сохранять порядок, потому что мы не можем хаотично включать или отключать абоненту связь — все должно быть строго последовательно. Предыдущая подписка влияет на следующую, поэтому данные важны — ничто не должно пропасть.
Решение. Можно попробовать решать в лоб и спросить разработчиков БД, но задача математически не решается. Можно вспоминать теоремы, законы сохранения, квантовую физику, но зачем — ее невозможно решить на уровне БД.
Здесь работает старый добрый архитектурный подход — нужно хорошо знать предметную область и за ее счет разрешить этот ребус.
Наше решение: создаем распределенный реестр заявок на Tarantool — геораспределенный кластер. На схеме это три разных центра обработки данных — два до Урала, один за Уралом, и мы распределяем все заявки по этим центрам.
У Netflix, который сейчас считается одним из лидеров в IT, до 2012 года был всего один ЦОД. Накануне католического Рождества 24 декабря этот ЦОД лег. Пользователи Канады и США остались без своих любимых фильмов, сильно расстроились и в соцсетях об этом написали. Теперь у Netflix три ЦОДа на западно-восточном побережье и один в западной Европе.
Мы изначально строим геораспределенное решение — нам важна отказоустойчивость.
Итак, у нас есть кластер, но как быть с RPO = 0 и RTO = 0? Решение простое, которое зависит от предметики.
Что важно в заявках? Две части: набрасывание корзины ДО принятия решения о покупке, и ПОСЛЕ. Часть ДО в телекоме обычно называют order capturing или order negotiation. В телекоме это может быть сильно сложнее, чем в интернет-магазине, потому что там клиента надо обслужить, предложить 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, архитектура, энтерпрайз, туториалы и микросервисы.
