HDCONFHDCONF

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

Максим Барышников

О докладчике● 12+ лет разработки ПО: как разработчик,

руководитель команды, менеджер продукта, архитектор

● Solutuions Architect в Web-департаменте Wargaming.net

2/28

3/28

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

© somebody

Глоссарий

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

5/28

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

6/28

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

Достуность (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

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

Зачастую при этом приходится оперировать BigData.

9/28

Качественная характеристика

10/28

Качество высоконагруженной системы Пропускная способность × Доступность∝

Характеристика Способы оптимизации

Доступность Повышение отказоустойчивости

Пропускная способность

Улучшение алгоритмовПараллеллизм

Отложенные вычисленияПредварительные вычисления

Проблемы и решения

11/28

#0002. Балансировка входящих запросов

Проблема:

На входном каскаде инфраструктуры присутствует SPOF

Задача:

Нужно избежать SPOF на приеме пользовательских запросов + построить инфраструктуру балансировки.

12/28

#0002. Балансировка входящих запросов

13/28

Redundant hardware load balancers

=Heartbeat + Virtual IP

nginx nginx

#0002. Балансировка входящих запросов

● Запущено в течение 2-х недель● Обошлось в 3 раза дешевле аппаратных

балансировщиков● Выполняет дополнительную функцию● ~3 года «без разрывов»

14/28

#0012. Внешняя коммуникация в синхронных запросах

Проблема:

У некоторых запросов время обработки близко к предельно допустимому, характеризуется высокой волатильностью из-за синхронной внешней коммуникации.

Задача:

Снизить время ответа сохранив функциональность.

15/28

#0012. Внешняя коммуникация в синхронных запросах

Было:

16/28

Обработка запроса Логгирование события Обработка события Ответ

50-60% времени ответа 40-50% времени ответа

#0012. Внешняя коммуникация в синхронных запросах

Стало:

17/28

Обработка запроса

Логгирование события Обработка события

Ответ

MQ

#0102. Много времени проводим в работе с базой

Проблема:

Значительную часть времени обработки занимает получаение данных из системы хранения.

Задача:

Снизить время ответа за счет оптимизации доступа к данным.

18/28

#0102. Много времени проводим в работе с базой

Вводная:

Профиль работы с этим конкретным куском данных:

1) read/write ~ 50/50

2) Свежие данные читаются значительно чаще

19/28

#0102. Много времени проводим в работе с базой

LSM-деревья:● Несколько уровней хранения

● Быстрая запись (не нужно переписывать блоки)

● Блочный merge «вниз» при переполнении

Как результат архитектуры — быстрая запись и быстрое чтение недавно записанных данных. То, что нужно!

20/28

#0102. Много времени проводим в работе с базой

21/28

Приложение

Собственная «базочка»на основе LevelDB

Основная БД

read-write

read

relay

#0112. Баннерка (5000 req/sec на ноду)

22/28

Проблема:

Баннерная система подошла к пределу пропускной способности.

Задача:

Решить проблемы масштабирования не переписывая полностью решение (как минимум, сохранить инструменты управления).

#0112. Баннерка (5000 req/sec на ноду)

23/28

Вводная:● Сложная админка, всех устраивающая

● Миграция на другую систему — очень дорогая

● Бутылочное горлышко в способе выдачи баннеров

#0112. Баннерка (5000 req/sec на ноду)

24/28

Админка БД

read/write

Система выдачи

Раз в пять минут читаем в память свежие данныеи сбрасываем накопленные

#1002. Поведенческий анализ

25/28

Задача:

В гетерогенной среде, в которой происходит 3000-5000 событий в секунду, нужно отслеживать определенные паттерны, и реагировать на них. Желательно близко к real time.

#1002. Поведенческий анализ

26/28

System A

[evenA0, eventA1, …, eventAN]

System Z

[evenZ0, eventZ1, …, eventZN]

User

#1002. Поведенческий анализ

27/28

System A

[evenA0, eventA1, …, eventAN]

User

System Z

[evenZ0, eventZ1, …, eventZN]

MQ

Паттерн Blackboard

Анализаторы

Триггеры

A0 Z0 ZN

user

28/28

Q&A