Стратегия и тактика улучшения производительности 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• Снижение нагрузок на системы на

порядок• Производительность перестает быть

ограничивающим фактором – дает больше свободы для бизнес-идей• Развита экспертиза, получен опыт

применения инструментария и выработаны подходы

Спасибо за внимание!