Насколько повысится среднее время обработки одного запроса если увеличить нагрузку вдвое? Почему производительность базы данных может снизиться при росте числа клиентов? Как добиться эффективного распределения большого числа задач на весь кластер? О практике и о теории обработки очередей на которой основана практика в моём докладе.

1. Очереди:
теория и
практика
Константин
Осипов
kostja@tarantool.org
Москва, 2015-05-21

2. Очереди как паттерн
отказоустойчивой архитектуры
• СУБД – пионер технологии очередей
• транзакции необходимы, но не достаточны
• пример: банковский перевод

3. Очереди: за и против
+ клиент и сервер полностью “развязаны”
+ состояние задачи всегда известно
+ применимо для load balancing
+ поддержка приоритетов
- дополнительная. сущность
- больше операций на задачу
- очередь должна быть персистентной

4. Очереди в Web Apps
● Рассылка email
● Сжатие картинок ← мультиплексирование
● Сборка email!
● мессенджеры

5. Практика применения
● отложенное выполнение
● управление “плохими” задачами
● таймауты выполнения
● приоритеты и повторное выполнение
● вложенные очереди и зависимые задачи
зависшие воркеры

6. Балансировка нагрузки
● задачи балансировки нагрузки
● два подхода к балансировке нагрузки:
моделирование (теория очередей) и
симуляция (бенчмарки).
● типичные ошибки при бенчмаркинге
● предотвращение перегрузки

7. 1
10
100
1000
10000
Запросов/секунду
Время
обработки
одного
запроса
Диаграмма насыщения системы
массового обслуживания
Перегрузка
Насыщение
Минимум
Оптимально

8. Что такое load balancing
Wikipedia: “…методология
распределения запросов на несколько
компьютеров … позволяющая достичь
оптимальной утилизации ресурсов,
максимизировать пропускную
способность системы, минимизировать
время ответа на запрос, и избежать
перегрузки”
Все части графика нагрузки

9. 1
10
100
1000
10000
Запросов/секунду
Время
обработки
одного
запроса
Ограничиваем latency
Перегрузка
Насыщение
Минимум
Оптимально
Допустимый
максимум

10. 1
10
100
1000
10000
Запросов/секунду
Время
обработки
одного
запроса
Максимизируем RPS
Перегрузка
Насыщение
Минимум
Оптимально
Максимальный RPS
при разумном latency

11. Основы теории очередей
•
Виды очередей – нотация Кендалла
•
Модель с одним сервером
•
Модель с несколькими серверами –
лучше не влезать...

12. Нотация Кендалла (Kendall)
A/B/c/K/m/Z
• A — распределение времени между
прибытиями
• B — распределение времени
обслуживания
• c — количество серверов
• K — ёмкость системы обслуживания
• m — популяция источника клиентов
• Z — принцип обслуживания

13. Модели для одного сервера
= /  = степень утилизации (traffic intensity)
k = вероятность k задач в очереди
0 = 1 –  и k = k(1 – )
L = мат. ожидание числа задач в очереди
L = /(-) если   
Lq = 2/(-)мат. ожидание длины очереди
(не включая задачи в работе)
Lq = 2/(-)
2
(-)

14. Теория очередей: выводы
• среднее время выполнения запроса
отличается от минимального
пропорционально длине очереди
• при приближении загрузки к 100%
длина очереди может расти
полиномиально
• единая очередь на несколько серверов
позволяет снизить дисперсию, и,
повысить утилизацию при сохранении
необходимого latency

15. Использование глобальной
очереди
1 2 3 4 5 6 7 8 9 10
0.1
1
10
Random assignment
Global Job Queue
Размер кластера
Latency
при 80%
загрузке

16. Закон Литтла
Q = R*W
• (Q)ueue size = (R)ate * (W)ait-time
• Q – средняя длина очереди
• R – скорость поступления запросов
(запросов/секунду)
• W – среднее время ожидания (секундах)
• для любой (!) системы в стабильном
состоянии

17. Закон Литтла – пример
Q = R*W
• Система получает R=10,000 запросов
в секунду
• Врема обработки одного запроса – 1
мс (W = 0.001)
• Закон Литтла: средняя длина очереди
10

18. Закон Литтла: выводы
Q = R*W
• В распределённой системе:
– R масштабируется с ростом числа
серверов
– W остаётся неизменным или несколько
ухудшается
• Для масштабирования, необходимо
пропорционально увеличивать число
задач “в обработке”

19. Конфликт требований к
оптимизации
• Для того, чтобы снизить latency, необходимо
уменьшить среднюю длину очереди
(очередей) в системе
• Для того, чтобы увеличить RPS (throughput),
необходимо увеличить среднюю длину
очередей в системе, чтобы избежать
простоев на фoне неравномерной нагрузки
• Для равномерного распределения нагрузки
в распределённой системе, необходимо,
чтобы очереди к разным узлам были
примерно одного размера

20. Симуляция/бенчмарки
Лучший способ исследования поведения
распределённой системы
Что измеряем:
- конечно rps!?
- время обработки одного запроса
- средняя длина очереди
- осцилляцию?
→ ищем причины задержек

21. Как правильно измерять
время выполнения запроса
• Необходимо измерять распределение
(гистограмма) времени обработки, а
не среднее
• Обращаем внимание на среднее,
минимум, максимум, и дисперсию (!)

22. Гистограмма распределения
latency

23. Определяем SLA

24. Проблема наивной симуляции:
coordinated omission

25. Проблема наивной симуляции:
coordinated omission

26. 1
10
100
1000
10000
Запросов/секунду
Время
обработки
одного
запроса
Борьба с перегрузкой
Перегрузка

27. Ограничение размера
очереди
0 2 4 6 8 10 12 14 16 18 20
0
5
10
15
20
25
30
35
40
Queued job limit
% of dropped jobs

28. Каскад очередей

29. Общая идея: backpressure

30. Колебания
производительности
1 1.5 2 2.5 3 3.5 4 4.5 5
0
10
20
30
40
50
60
70
Node A
Node B
Utilization %

31. Сглаживаем колебания
• Это уже теория управления —avoid if
possible!
• Чем выше частота контроля, тем
сложнее добиться результата
• Стратегии:
– Увеличить масштаб (реже изменять
параметры системы)
– “загрубить” контроль, т.е. не реагировать
на мелкие колебания

32. Спасибо!