Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

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

•
•
Tanya Denisyuk
Tanya Denisyuk

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

1 of 28
Download to read offline
HHDDCCOONNFF «Что такое типовые проблемы нагруженных проектов и как их решают в 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 nginx nginx Heartbeat + Virtual IP
#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. Поведенческий анализ Задача: В гетерогенной среде, в которой происходит 3000-5000 событий в секунду, нужно отслеживать определенные паттерны, и реагировать на них. Желательно близко к real time. 25/28
#1002. Поведенческий анализ 26/28 [evenA0, eventA1, …, eventAN] System A [evenZ0, eventZ1, …, eventZN] System Z User
#1002. Поведенческий анализ 27/28 [evenA0, eventA1, …, eventAN] System A User [evenZ0, eventZ1, …, eventZN] System Z Паттерн Blackboard MQ Триггеры Анализаторы A0 Z0 ZN user
28/28 Q&A

More Related Content

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

  • 1. HHDDCCOONNFF «Что такое типовые проблемы нагруженных проектов и как их решают в Wargaming» Максим Барышников
  • 2. О докладчике ● 12+ лет разработки ПО: как разработчик, руководитель команды, менеджер продукта, архитектор ● Solutuions Architect в Web-департаменте Wargaming.net 2/28
  • 3. 3/28 Big Data (и HighLoad) — как подростковый секс: все говорят о нем; никто толком не знает что значит им заниматься; при этом каждый уверен, что у всех остальных он есть, а потому каждый утверждает, что и у него тоже... © somebody
  • 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 Качество высоконагруженной системы Пропускная способность ∝ × Доступность Характеристика Способы оптимизации Доступность Повышение отказоустойчивости Пропускная способность Улучшение алгоритмов Параллеллизм Отложенные вычисления Предварительные вычисления
  • 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