Документ описывает подход к балансировке нагрузки и оптимизации загрузки кластера с использованием Nginx для развертывания приложений, включая решения для обработки статических файлов и безопасности. Также рассматривается проблема загрузки тяжелых моделей и использование хэширования URL для маршрутизации запросов к серверам с уже загруженными моделями. В результате предложенные решения повышают емкость кластера в 4 раза и утилизацию серверов до 75%.

1. load balancing и
оптимальная загрузка
кластера
Андрей Свелов
andrew.svetlov@gmail.com

2. ● Пишу на Python с 1999 года
● Python Code Developer
● Соавтор asyncio, aiohttp и ещё дюжины
библиотек
● Работаю в DataRobot

3. Простейшая схема развертывания
Browser Server

4. Проблемы:
1. Статика

5. Проблемы:
1. Статика
2. Безопасность

6. Reverse proxy
Browser Application
Server
Reverse proxy
aka NGINX, HAProxy etc

7. Конфигурация NGINX:
http {
server {
location /static {
root /www/static;
}
location / {
proxy_pass http://127.0.0.7:8080;
}
}
}

8. Балансировка на несколько app servers:
Browser Reverse proxy

9. Конфигурация NGINX:
server {
upstream backend {
server http://127.0.0.7:8080;
server http://127.0.0.7:8081;
}
location / {
proxy_pass http://backend;
}
}

10. Round Robin:
Reverse proxy
1
2
3

11. Ситуация:
1. В DataRobot делаем предсказания на обученых моделях
2. Предсказание занимает в 20-600 милисекунд в среднем.
3. Модель может "весить" гигабайт(ы).
4. Загрузка модели в память требует в 10-30 раз больше времени.
Хочу чтобы запрос шел на сервер с уже загруженной моделью.

12. Каждому узлу -- по своей модели:
Node 1
Reverse proxy Node 2
Model 1
Model 2
Model 3
Model 4

13. Особенность:
url = "/v1/<project_id>/<model_id>/predict"
Удобный hash key

14. URL Hash как решение:
upstream = servers[hash(url) % len(servers)]

15. Конфигурация NGINX:
server {
upstream backend {
hash $request_uri;
server http://127.0.0.7:8080;
server http://127.0.0.7:8081;
}
location / {
proxy_pass http://backend;
}
}

16. URL Hash как плохое решение:
upstream = servers[hash(url) % len(servers)]
Если один сервер умирает -- вся система
требует перебалансировки.

17. Пропадание узла:
4 сервера, 12 объектов 3 сервера, 12 объектов

18. Consistent hash:

19. Consistent hash 2:

20. Конфигурация NGINX:
server {
upstream backend {
consistent_hash $request_uri;
server http://127.0.0.7:8080;
server http://127.0.0.7:8081;
}
location / {
proxy_pass http://backend;
}
}

21. Sticky sessions:
HTTP cookie based upstream selection

22. Всё это классно, но нам не годится:
● Нужен лучший контроль над выбором
upstream
● Велосипедим сами

23. Самодельный контроллер
NGINX
Controller
Node 1
Node 2

24. Конфигурация NGINX:
server {
location / {
set $upstream "<placeholder>";
rewrite_by_lua '
ctrl = require("controller")
ngx.var.upstream = ctrl.get(ngx.var.uri,
"unix://tmp/ctrl.sock")
';
proxy_pass http://$upstream;
}
}

25. LUA:
function get(uri, sock_path)
local sock = ngx.socket.connect(sock_path)
local buf = pack("<HB", string.len(uri)+1, 1)
sock:send({buf, uri})
local resp_len_buf = sock:receive(3)
local resp_len, resp_code = unpack("<HB", resp_len_buf)
local upstream = sock:receive(resp_len - 1)
sock:setkeepalive()
return upstream
end

26. Контроллер:
● asyncio UNIX/TCP сервер
● данные -- в REDIS slave

27. Управление:
● REST сервер -- конфигурирование
● Sentinel -- наблюдение

28. Результат:
● Емкость кластера х4
● Утилизация серверов х3 (75%)

29. Ищем сотрудников в Минский офис
http://datarobot.com
● Python backend
● JavaScript frontend
● DevOps
● Data Science

30. Вопросы?
Андрей Светлов
andrew.svetlov@gmail.com
asvetlov.blogspot.com