Навіщо такий корпорації, як Мегафон, Tarantool у білінгу? Збоку здається, що зазвичай приходить вендор, приносить якусь велику коробку, встромляє штекер у розетку — ось і білінг! Колись так і було, але зараз це архаїка і такі динозаври вже вимерли чи вимирають. Спочатку білінг це система для виставлення рахунків - лічилка або калькулятор. У сучасному телекомі - це система автоматизації всього життєвого циклу взаємодії з абонентом від укладання договору до розірвання, включаючи real-time-тарификацію, прийом платежів та ще багато чого. Білінг у телеком-компаніях схожий на бойового робота — великого, потужного та обвішаного зброєю.
До чого ж тут Tarantool? Про це розкажуть Олег Івлєв и Андрій Князєв. Олег – головний архітектор компанії з величезним досвідом роботи у зарубіжних компаніях, Андрій — директор із бізнес-систем. З розшифровки їхньої доповіді на ви дізнаєтеся, навіщо потрібен 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.
Відкрити API
Давайте знову подивимося на числа та те, як зараз працює Open API. Його навантаження 10 000 транзакцій за секунду. Оскільки ми плануємо активно розвивати шар мікросервісів та будувати публічний API Мегафон, то очікуємо більшого зростання у майбутньому саме в цій частині. 100 000 транзакцій точно буде.
Не знаю, чи порівняємося в SSO з Mail.ru - у хлопців, начебто, 1 транзакцій в секунду. Нам їхнє рішення вкрай цікаве і ми плануємо запозичити їхній досвід — наприклад, робити функціональний резерв 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.
Цільовий час відновлення - Це час відновлення сервісу після збою. RTO = 0 означає, що якщо щось впало, сервіс продовжує працювати.
Recovery point objective — це час відновлення даних, скільки даних ми можемо втратити за певний період. RPO = 0 означає, що ми не втрачаємо дані.
Завдання по Tarantool
Давайте спробуємо вирішити завдання Tarantool.
дано: всім зрозумілий кошик заявок, наприклад, в Амазоні чи ще десь. Вимагається щоб кошик працював 24 години 7 днів на тиждень, або 99,99% часу. Замовлення, які приходять до нас, повинні зберігати порядок, тому що ми не можемо хаотично включати або відключати абоненту зв'язок — все має бути суворо послідовно. Попередня передплата впливає на таку, тому дані важливі — ніщо не повинно зникнути.
Рішення. Можна спробувати вирішувати в лоб і запитати розробників БД, але завдання математично не вирішується. Можна згадувати теореми, закони збереження, квантову фізику, але навіщо її неможливо вирішити на рівні БД.
Тут працює старий добрий архітектурний підхід — треба добре знати предметну область і за її рахунок дозволити цей ребус.
Наше рішення: створюємо розподілений реєстр заявок на Tarantool – георозподілений кластер. На схемі це три різних центри обробки даних - два до Уралу, один за Уралом, і ми розподіляємо всі заявки по цих центрах.
Netflix, який зараз вважається одним з лідерів в IT, до 2012 року був лише один ЦОД. Напередодні католицького Різдва 24 грудня цей ЦОД ліг. Користувачі Канади та США залишилися без своїх улюблених фільмів, дуже засмутилися і в соцмережах про це написали. Тепер у Netflix три ЦОДи на західно-східному узбережжі та один у західній Європі.
Ми спочатку будуємо георозподілене рішення — нам важлива стійкість до відмови.
Отже, ми маємо кластер, але як бути з RPO = 0 і RTO = 0? Рішення просте, яке залежить від предметики.
Що важливо у заявках? Дві частини: накидання кошика ДО прийняття рішення про купівлю, та ПІСЛЯ. Частина ДО у телекомі зазвичай називають захоплення замовлення або 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 червня Олег Івлєв виступить на з доповіддю . Також від Мегафону виступить Олександр Деулін із доповіддю . Дізнаємось, що змінилося, які плани вдалося реалізувати. Приєднуйтесь - конференція безкоштовна, треба тільки . Усе та програма конференції сформована: нові кейси, новий досвід використання Tarantool, архітектура, ентерпрайз, туторіали та мікросервіси.
Джерело: habr.com