В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.). Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов: - Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов? - Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга? - Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"? Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.

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 раза

17. Мониторинг
YourKit
Java
Profiler
+
Oracle AWR
JMX

18. TPS
RT
TPS: 38
Response time: 12 сек.
Результаты 2015

19. Результаты 2016
TPS
RT
TPS: 240
Response time: 0,4 сек.

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

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