Стратегия и тактика улучшения производительности BSS систем оператора мобильной связи Yota / Олег Филатьев, Павел Нашатырев (Yota)
Download as PPTX, PDF•1 like•915 views
Документ рассматривает стратегию улучшения производительности bss систем оператора мобильной связи Yota, анализируя текущее состояние и оптимизацию бизнес-процессов. Основные меры включают кэширование данных, переход на in-memory базу данных и изменение архитектуры системы, что значительно увеличило производительность. Улучшения реальны благодаря комплексному подходу к тестированию и принятию решений на основе анализа нагрузки.
Стратегия и тактика улучшения производительности BSS систем оператора мобильной связи Yota / Олег Филатьев, Павел Нашатырев (Yota)
- 1. Стратегия и тактика улучшения производительности BSS систем оператора мобильной связи Yota Олег Филатьев Павел Нашатырев Александр Семелит
- 2. YOTA Алло Инкогнито Aiva Mobile Matrix Mobile SIM-SIM Другие Доли рынка YOTA – 81% Алло Инкогнито – 7% SIM-SIM – 4% Matrix Mobile – 4% Aiva Mobile – 3% Другие – 1% YOTA – самый крупный MVNO оператор в России Как сотовый оператор стартовали в середине 2014 MVNO – виртуальный оператор без собственной сети
- 3. YOTA занимает место среди MVNO операторов в мире 10
- 5. 60+ бизнес-процессов 96 систем и сервисов 420+ серверов 13000+ запросов на обслуживание 200+ проектов и релизов
- 6. Общая архитектура BSS BSS – Business Support System WebAPI ESB (Java/Tibco) Billing (Oracle. PL/SQL) CRM (MS Dynamics) Customer Interaction Product Catalog Payment System Remote Dealer Business intelligence • 30 сервисов • 70 инстансов сервисов • Production – 20 серверов. • 200 читающих вызовов в сек. • 200 изменяющих вызовов в сек. • Часть подсистем проприетарная OSS Mobile App
- 7. • Каждый вызов запускает процесс на ESB • Каждый процесс вызывает 5-10 методов конечных сервисов • Конечные сервисы выполняют 2-5 атомарных операций • 7-10 тыс. атомарных операций в сек • Процессы меняются часто – каждые 2-3 месяца • Критичных процессов – около 10 (всего ~ 60) Оптимизируем критичные EndToEnd процессы 400 вызовов/сек не много, НО:
- 8. Контроль над производительностью Выделенная группа в разработке-тестировании для контроля над производительностью выпускаемых релизов. Тестовый стенд – половина Production с идентичными настройками. Несколько видов тестов: 1. Комплексный 3-х часовой с постепенным увеличением нагрузки. Контрольный для каждого релиза. 2. Длительный 8-часовой для тестирования новых компонентов и существенных изменениях в старых. Не в каждом релизе. 3. Специализированные тесты, например, на прогрев кэша Основной инструмент – JMeter 3
- 9. Ключевые улучшения за 2016 • Кэширование Product Catalog и справочников • Оптимизация часто вызываемых EndToEnd процессов • Оптимизация запросов и структур БД • Внедрение in-memory database для быстрого чтения данных по клиенту – подход CQRS • Java вместо Tibco ESB • Асинхронное взаимодействие с MobileAPP
- 10. Кэширование Product Catalog (тарифы) Стратегия кэширования – сохранять вызовы методов Ключ записи в кэше – хеш-функция от параметров Pros: • Легкая реализация + простые структуры • Возможно хранить кэш на стороне вызывающего сервиса Cons: • Комбинаторность, требующая больше памяти при повышении кол-ва параметров или их комбинаций • Медленный прогрев кэша Общий выигрыш в скорости в десятки раз – БД почти не нагружена после прогрева В будущем – переход на объекты в памяти
- 11. Кэш Product Catalog – разработка • Ehcache 2.x • Репликация • Сохранение на диск для быстрого прогрева Нагрузка на БД до: Нагрузка на БД после:
- 12. Внедрение in-memory database Необходимо хранить информацию о СИМ-картах клиентов и подключенные продукты вне биллинга на Oracle, в более быстрой БД. Сделали БД для чтения на Tarantool с синхронизацией с Oracle БД – CQRS подход. Для синхронизации – GoldenGate. Ограничение по времени синхронизации (latency) < 0.3 сек. Эффект: • Ускорение доступа к данным в 7-10 раз при вызове сервиса. • Снижение нагрузки на сервера БД на порядок (c 20 сессий до 1 или с 8 ядер до 1)
- 13. Почему Tarantool? Сравнивали с Apache Ignite, Oracle TimesTen, CoachBase, Haselcast, Redis Наличие фич БД (индексы, скрипты) Техподдержка в РФ Стоимость техподдержки Tarantool + + + Apache Ignite + - Oracle Times Ten + + - CoachBase -/+ - - Redis + - - Haselcast - - - На прошлой Highload 2015 впечатлил доклад о работе Tarantool
- 14. Tarantool – разработка • Разные типы индексов • Активно используем составные индексы • Гранулярная очистка кэша • Обновление процедур без простоев • Написали свой Java connection pool • На самом деле connection pool не нужен
- 15. Источники изменения: • Прямые вызовы сервисов • Звонки • Биллинговые процессы • Скрипты в Oracle Service Oracle DB Invalidate Tarantool Modify Неконсистентность Чтение 1Изменение Чтение 2 Sync Del Save Чтение 3 Синхронизация баз данных
- 16. Java вместо Tibco BW • Логика требует вложенных циклов • Сталкиваемся с ограничениями среды • Баги, проявляющиеся только под нагрузкой • Особенности реализации • XML. Ресурсоемкая реализация DOM • Тяжелые абстракции • В итоге переписали под Java 8 и WildFly 10 • Response time уменьшился в 2 раза
- 18. TPS RT TPS: 38 Response time: 12 сек. Результаты 2015
- 19. Результаты 2016 TPS RT TPS: 240 Response time: 0,4 сек.
- 20. Результаты проекта • Изменение архитектуры системы – частичный переход на CQRS • Снижение нагрузок на системы на порядок • Производительность перестает быть ограничивающим фактором – дает больше свободы для бизнес-идей • Развита экспертиза, получен опыт применения инструментария и выработаны подходы