Upload
ontico
View
119
Download
5
Embed Size (px)
Citation preview
Стратегия и тактика улучшения производительности BSS систем оператора мобильной связи YotaОлег ФилатьевПавел НашатыревАлександр Семелит
YOTA
Алло Инкогнит
о
Aiva Mo-bile
Matrix Mobile SIM-SIM Другие
Доли рынка
YOTA – 81%
Алло Инкогнито – 7%
SIM-SIM – 4%
Matrix Mobile – 4%
Aiva Mobile – 3%
Другие – 1%
YOTA – самый крупныйMVNO оператор в России
Как сотовый оператор стартовали в середине 2014MVNO – виртуальный оператор без собственной сети
YOTA занимает
место среди MVNO операторов в мире
10
60+ бизнес-процессов
96 систем и сервисов
420+ серверов
13000+ запросов на обслуживание
200+ проектов и релизов
Общая архитектура BSSBSS – 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
MobileApp
• Каждый вызов запускает процесс на ESB• Каждый процесс вызывает 5-10
методов конечных сервисов• Конечные сервисы выполняют 2-5
атомарных операций• 7-10 тыс. атомарных операций в сек• Процессы меняются часто – каждые 2-3
месяца• Критичных процессов – около 10 (всего
~ 60)
Оптимизируем критичные EndToEnd процессы
400 вызовов/сек не много, НО:
Контроль над производительностьюВыделенная группа в разработке-тестировании для контроля над производительностью выпускаемых релизов.Тестовый стенд – половина Production с идентичными настройками.Несколько видов тестов:1.Комплексный 3-х часовой с постепенным увеличением
нагрузки. Контрольный для каждого релиза.2.Длительный 8-часовой для тестирования новых
компонентов и существенных изменениях в старых. Не в каждом релизе.
3.Специализированные тесты, например, на прогрев кэша
Основной инструмент – JMeter 3
Ключевые улучшения за 2016
• Кэширование Product Catalog и справочников• Оптимизация часто вызываемых EndToEnd
процессов• Оптимизация запросов и структур БД• Внедрение in-memory database для быстрого
чтения данных по клиенту – подход CQRS• Java вместо Tibco ESB• Асинхронное взаимодействие с MobileAPP
Кэширование Product Catalog (тарифы) Стратегия кэширования – сохранять вызовы методов
Ключ записи в кэше – хеш-функция от параметровPros:• Легкая реализация + простые структуры• Возможно хранить кэш на стороне вызывающего
сервисаCons:• Комбинаторность, требующая больше памяти при
повышениикол-ва параметров или их комбинаций
• Медленный прогрев кэшаОбщий выигрыш в скорости в десятки раз – БД почти не нагружена после прогреваВ будущем – переход на объекты в памяти
Кэш Product Catalog – разработка
• Ehcache 2.x• Репликация • Сохранение на диск для быстрого прогрева
Нагрузка на БД до:
Нагрузка на БД после:
Внедрение in-memory database Необходимо хранить информацию о СИМ-картах клиентов и
подключенные продукты вне биллинга на Oracle, в более быстрой БД.Сделали БД для чтения на Tarantool с синхронизацией с Oracle БД – CQRS подход.Для синхронизации – GoldenGate. Ограничение по времени синхронизации (latency) < 0.3 сек. Эффект:• Ускорение доступа к данным в 7-10 раз при вызове сервиса. • Снижение нагрузки на сервера БД на порядок (c 20 сессий до 1
или с 8 ядер до 1)
Почему Tarantool?
Сравнивали с Apache Ignite, Oracle TimesTen, CoachBase, Haselcast, Redis
Наличие фич БД (индексы, скрипты)
Техподдержка в РФ
Стоимость техподдержки
Tarantool + + +Apache Ignite + -Oracle Times Ten
+ + -
CoachBase -/+ - -Redis + - -Haselcast - - -
На прошлой Highload 2015 впечатлил доклад о работе Tarantool
Tarantool – разработка
• Разные типы индексов• Активно используем составные индексы• Гранулярная очистка кэша• Обновление процедур без простоев• Написали свой Java connection pool• На самом деле connection pool не нужен
Источники изменения:
• Прямые вызовы сервисов
• Звонки
• Биллинговые процессы
• Скрипты в Oracle
Service
Oracle DB
Invalidate
Tarantool
Modify
Неконсистентность
Чтение 1Изменение Чтение 2
Sync
Del
Save
Чтение 3
Синхронизация баз данных
Java вместо Tibco BW
• Логика требует вложенных циклов• Сталкиваемся с ограничениями среды• Баги, проявляющиеся только под
нагрузкой• Особенности реализации• XML. Ресурсоемкая реализация DOM• Тяжелые абстракции
• В итоге переписали под Java 8 и WildFly 10• Response time уменьшился в 2 раза
Мониторинг
YourKit Java Profiler
+
Oracle AWR
JMX
TPS
RT
TPS: 38Response time: 12 сек.
Результаты 2015
Результаты 2016
TPS
RT
TPS: 240Response time: 0,4 сек.
Результаты проекта
• Изменение архитектуры системы – частичный переход на CQRS• Снижение нагрузок на системы на
порядок• Производительность перестает быть
ограничивающим фактором – дает больше свободы для бизнес-идей• Развита экспертиза, получен опыт
применения инструментария и выработаны подходы
Спасибо за внимание!