Расскажу, какие подходы и инструменты практически применяются в Wargaming при обработке данных в гигантской, без преувеличений, системе. Частичный список затрагиваемых вопросов NoSQL versus/with RDBMS или каждый инструмент на своем месте Синхронные и асинхронные подходы к построению систем: почему асинхронные системы не могут быть быстрее синхронных, но асинхронность, тем не менее, очень полезна API и интерфейсы — важная составляющая хорошо спроектированной системы Performance vs Scalability Мониторинг и профилирование

1. HHDDCCOONNFF
«Что такое типовые проблемы
нагруженных проектов и как
их решают в Wargaming»
Максим Барышников

2. О докладчике
● 12+ лет разработки ПО: как разработчик,
руководитель команды, менеджер продукта,
архитектор
● Solutuions Architect в Web-департаменте
Wargaming.net
2/28

3. 3/28
Big Data (и HighLoad) — как подростковый секс: все
говорят о нем; никто толком не знает что значит им
заниматься; при этом каждый уверен, что у всех
остальных он есть, а потому каждый утверждает, что и у
него тоже...
© somebody

4. Глоссарий

5. BigData — когда данных уже слишком много для того,
чтобы иметь возможность выполнять операции «в лоб»
за приемлемое для приложения время.
5/28

6. Пропускная способность (Throughput) системы —
характеризуется количеством пользовательских
запросов, которые система способна обработать в
единицу времени.
6/28

7. Отказоустойчивость (Fault Tolerance) — это свойство
технической системы сохранять свою работоспособность
после отказа одного или нескольких составных
компонентов.

8. Достуность (Availability) системы — возможность
использования системы пользователями.
Доступность, % Простой в год Простой в месяц Простой в неделю
... ... ... ...
99.9% 8.76 часов 43.2 минут 10.1 минут
99.99% 52.56 минут 4.32 минут 1.01 минут
99.999% 5.26 минут 25.9 секунд 6.05 секунд
99.9999% 31.5 секунд 2.59 секунд 0.605 секунд
8/28

9. Highload — когда необходимо обеспечивать высокую пропускную
способность и доступность (за счет отказоустойчивости) системы.
Зачастую при этом приходится оперировать BigData.
9/28

10. Качественная характеристика
10/28
Качество высоконагруженной системы Пропускная способность ∝ × Доступность
Характеристика Способы оптимизации
Доступность Повышение отказоустойчивости
Пропускная способность
Улучшение алгоритмов
Параллеллизм
Отложенные вычисления
Предварительные вычисления

11. Проблемы и решения
11/28

12. #0002. Балансировка входящих запросов
Проблема:
На входном каскаде инфраструктуры присутствует SPOF
Задача:
Нужно избежать SPOF на приеме пользовательских запросов +
построить инфраструктуру балансировки.
12/28

13. #0002. Балансировка входящих запросов
13/28
=
Redundant hardware load balancers
nginx nginx
Heartbeat + Virtual IP

14. #0002. Балансировка входящих запросов
● Запущено в течение 2-х недель
● Обошлось в 3 раза дешевле аппаратных
балансировщиков
● Выполняет дополнительную функцию
● ~3 года «без разрывов»
14/28

15. #0012. Внешняя коммуникация в синхронных запросах
Проблема:
У некоторых запросов время обработки близко к предельно
допустимому, характеризуется высокой волатильностью из-за
синхронной внешней коммуникации.
Задача:
Снизить время ответа сохранив функциональность.
15/28

16. #0012. Внешняя коммуникация в синхронных запросах
Было:
16/28
Обработка запроса Логгирование события Обработка события Ответ
50-60% времени ответа 40-50% времени
ответа

17. #0012. Внешняя коммуникация в синхронных запросах
Стало:
17/28
Обработка запроса
Логгирование события Обработка события
Ответ
MQ

18. #0102. Много времени проводим в работе с базой
Проблема:
Значительную часть времени обработки занимает получаение данных из
системы хранения.
Задача:
Снизить время ответа за счет оптимизации доступа к данным.
18/28

19. #0102. Много времени проводим в работе с базой
Вводная:
Профиль работы с этим конкретным куском данных:
1) read/write ~ 50/50
2) Свежие данные читаются значительно чаще
19/28

20. #0102. Много времени проводим в работе с базой
LSM-деревья:
● Несколько уровней хранения
● Быстрая запись (не нужно переписывать блоки)
● Блочный merge «вниз» при переполнении
Как результат архитектуры — быстрая запись и быстрое чтение недавно записанных
данных. То, что нужно!
20/28

21. #0102. Много времени проводим в работе с базой
21/28
Приложение
Собственная «базочка»
на основе LevelDB
Основная БД
read-write
read
relay

22. #0112. Баннерка (5000 req/sec на ноду)
Проблема:
Баннерная система подошла к пределу пропускной способности.
Задача:
Решить проблемы масштабирования не переписывая полностью
решение (как минимум, сохранить инструменты управления).
22/28

23. #0112. Баннерка (5000 req/sec на ноду)
Вводная:
23/28
● Сложная админка, всех устраивающая
● Миграция на другую систему — очень дорогая
● Бутылочное горлышко в способе выдачи баннеров

24. #0112. Баннерка (5000 req/sec на ноду)
24/28
read/write
Админка БД
Система выдачи
Раз в пять минут читаем в память свежие данные
и сбрасываем накопленные

25. #1002. Поведенческий анализ
Задача:
В гетерогенной среде, в которой происходит 3000-5000 событий в секунду,
нужно отслеживать определенные паттерны, и реагировать на них.
Желательно близко к real time.
25/28

26. #1002. Поведенческий анализ
26/28
[evenA0, eventA1, …, eventAN]
System A
[evenZ0, eventZ1, …, eventZN]
System Z
User

27. #1002. Поведенческий анализ
27/28
[evenA0, eventA1, …, eventAN]
System A
User
[evenZ0, eventZ1, …, eventZN]
System Z
Паттерн Blackboard
MQ
Триггеры
Анализаторы
A0 Z0 ZN
user

28. 28/28
Q&A