В этом докладе я планирую осветить следующие проблемы: - Почему стандартных механизмов балансировки бывает недостаточно. - Как выбирать фундамент для решения, и какие принципы проектирования использовались. - Как формировались требования для решения, которое работает сейчас в продакшне и пропускает через себя ощутимое количество. Расскажу, как без помощи сторонних сессионных хранилищ и довольно за дёшево организовать "sticky balancing", и как это работает с точки зрения науки. Покажу пример отказоустойчивой геораспределённой системы, расскажу, что мониторить и как правильно это делать при помощи специального расширения для nginx и не только. Расскажу о том, как было организовано нагрузочное и функциональное тестирование конечного продукта. Также расскажу про полный жизненный цикл этого весьма критичного для инфраструктуры приложения. Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.

1. Умная балансировка
нагрузки на базе Nginx и
Lua
Андрей Кононов, Solution architect at EPAM systems

2. О себе

3. Disclaimer
Чем больше мы познаём неизменные законы природы,
тем всё более невероятными становятся для нас чудеса.
Чарльз Дарвин.
Все используемые технологии – опенсорс
Все совпадения с реальными компаниями и
брендами случайны.

4. Какая балансировка бывает
• L7 (DNS, http)
• L4 (TCP)
• L3 (BGP)
TCP/HTTP
VRRP
DNS
BGP

5. Стартовая позиция
• Нет балансировки
• Всё работает
• Фичи пилятся

6. Надо быть защищёнными, но…
1. Поддержки SSl нет
2. Надо разработать

7. Надо быть защищёнными, но…
1. Поддержки SSl нет
2. Надо разработать

8. Надо что-то придумать
Появился Nginx

9. Надо что-то придумать
Появился Nginx

10. Ничто не предвещало…

11. НО пришла корпорация добра!
TIME
RESPONSE TIME, MS

12. Надо что-то придумать
• DNS балансировка

13. Надо что-то придумать
• DNS балансировка

14. Надо что-то придумать
• DNS балансировка
0
500
1000
1500
2000
2500
3000
3500
requests
time
requests/server
app1 app2

15. Жизнь продолжается
• DNS балансировка

16. Балансировка курильщика
• DNS балансировка
0
1000
2000
3000
4000
5000
6000
7000
8000
Requests /server
app1 app2 app3 app4 app5

17. Основные проблемы с DNS балансировкой
• Постоянные выигрыши в лотерею

18. Основные проблемы с DNS балансировкой
• Постоянные выигрыши в лотерею
• UDP не безграничен (512 bytes)

19. Основные проблемы с DNS балансировкой
• Постоянные выигрыши в лотерею
• UDP не безграничен (512 bytes)
• Само по себе распределение не ровное

20. Основные проблемы с DNS балансировкой
• Постоянные выигрыши в лотерею
• UDP не безграничен (512 bytes)
• Само по себе распределение не ровное
• Нужен другой балансировщик

21. Вендорский Балансировщик!

22. Балансировка нормального человека
2200
2300
2400
2500
2600
2700
2800
2900
3000
3100
requests/server
app1 app2 app3 app4 app5

23. НО Вендоры не без греха!
• Vendor lock

24. НО Вендоры не без греха!
• Vendor lock
• ELB на L4 не отправляет клиенту нотификации
о разрыве соединения

25. НО Вендоры не без греха!
• Vendor lock
• ELB на L4 не отправляет клиенту нотификации
о разрыве соединения
• Нет поддержки SNI (один сертификат - один IP)

26. НО Вендоры не без греха!
• Vendor lock
• ELB на L4 не отправляет клиенту нотификации
о разрыве соединения
• Нет поддержки SNI (один сертификат - один IP)
• На L7 нет возможности реализовать хотелки

27. НО Вендоры не без греха!
• Vendor lock
• ELB на L4 не отправляет клиенту нотификации
о разрыве соединения
• Нет поддержки SNI (один сертификат - один IP)
• На L7 нет возможности реализовать хотелки
• Не нулевая вероятность получить на свои
сервера чужой трафик.

28. Подоспели новые требования.
• Новое требование от бизнеса –
всегда показывать пиксел

29. Подоспели новые требования.
• Новое требование от бизнеса –
всегда показывать пиксел

30. Подоспели новые требования.
• Новое требование от бизнеса –
всегда показывать пиксел
• Появился полноценный
балансировщик

31. Подоспели новые требования.
• Новое требование от бизнеса –
всегда показывать пиксел
• Появился полноценный
балансировщик
• Нужно быть ближе к пользователю
• КАК бы CDN

32. GDNSD
• DNS балансировщик
• 100% opensource
• Авторитативный днс сервер
• Геобазы нескольких провайдеров
• Встроенные проверки состояния приложения

34. Никто не ждал но…..
• Взрыв мониторинга.

35. Никто не ждал но…..
• Взрыв мониторинга.
• 100 gb за 2 часа error log
• LA > 8 (8 cores instance)
used space

36. Никто не ждал но…..
• Взрыв мониторинга.
• 100 gb за 2 часа error log
• LA > 8 (8 cores instance)
main.all.http_1xx = 0
main.all.http_2xx = 480
main.all.http_3xx = 11
main.all.http_4xx = 3
main.all.http_5xx = 0

37. Продолжаем развиваться !
• Бизнес хочет странного, а именно - что то типа сессий

38. Продолжаем развиваться !
• Бизнес хочет странного, а именно - что то типа сессий

39. Продолжаем развиваться !
• Бизнес хочет странного, а именно - что то типа сессий

40. Продолжаем развиваться !
• Бизнес хочет странного, а именно - что то типа сессий
• Ограничения – никакого сессионного хранилища
• Минимальное перераспределение пользователей
при добавление ноды.

41. Продолжаем развиваться !
• Бизнес хочет странного, а именно - что то типа сессий
• Ограничения – никакого сессионного хранилища
• Минимальное перераспределение пользователей
при добавление ноды.
Включаем Ip_hash method в nginx

42. Продолжаем развиваться !
• Бизнес хочет странного, а именно - что то типа сессий.
• Ограничения – никакого сессионного хранилища.
• Минимальное перераспределение пользователей
при добавление ноды.
Включаем Ip_hash method в nginx
0
1000
2000
3000
4000
5000
6000
7000
8000
app1 app2 app3 app4 app5

43. Балансировка - не только балансировка
SSL offload

44. Балансировка - не только балансировка
SSL offload
Pixel

45. Балансировка - не только балансировка
SSL offload
Pixel
Redundancy

46. Балансировка - не только балансировка
SSL offload
Pixel
Redundancy
Geo distribution

47. Балансировка - не только балансировка
SSL offload
Pixel
Redundancy
Geo distribution
Easy configuration

48. Балансировка - не только балансировка
SSL offload
Pixel
Redundancy
Geo distribution
Easy configuration
Automatic add/remove nodes

49. Балансировка - не только балансировка
SSL offload
Pixel
Redundancy
Geo distribution
Easy configuration
Automatic add/remove nodes
oStickiness

50. • Consistent Hash !
https://en.wikipedia.org/wiki/Consistent_hashing
David Karger

55. Мозговой штурм, выбор не велик
• 1. Компилируемый модуль

56. Мозговой штурм, выбор не велик
• 1. Компилируемый модуль
2. Логика на LUA

57. Мозговой штурм, выбор не велик
• 1. Компилируемый модуль
2. Логика на LUA

58. Забег по граблям
• Генерили много точек по умолчанию - начала кончаться память

59. Забег по граблям
• Генерили много точек по умолчанию - начала кончаться память
Решение – динамическая генерация количества точек

60. Забег по граблям
• Генерили много точек по умолчанию - начала кончаться память
Решение – динамическая генерация количества точек
• 1 worker отказ в обслуживании при добавлении

61. Забег по граблям
• Генерили много точек по умолчанию - начала кончаться память
Решение – динамическая генерация количества точек
• 1 worker отказ в обслуживании при добавлении
Решение “cpu_count-2” workers на балансировщик

62. Продолжаем бежать
• Fallback не фолбечит

63. Продолжаем бежать
• Fallback не фолбечит
Решение – перенос в отдельный процесс нджинкс

64. Продолжаем бежать
• Внутренний хелфчек не способен
добавить много хостов (массовый
деплой например), полная
деградация целиком сервиса
запросы становятся в очередь, вот
это всё

65. Продолжаем бежать
• Внутренний хелфчек не способен
добавить много хостов (массовый
деплой например), полная
деградация целиком сервиса
запросы становятся в очередь, вот
это всё
Решение – инкрементальный
пересчёт consistent hash

66. Пример конфигурации nginx
location / {
...
proxy_pass http://$best_upstream;
...
}
upstream app1 {
…
server app1 max_fails=n fail_timeout=k;
server unix:/var/run/nginx_fallback.sock backup;
}
upstream app2 {
…
server app2 max_fails=n fail_timeout=k;
server unix:/var/run/nginx_fallback.sock backup;
}

67. Итоговая архитектура.

68. Выводы
• Хорошая балансировка всегда знает о приложении довольно
много
• Нагрузочное тестирование
• Ну и конечно здравый смысл

69. Links
1. http://luajit.org
2. http://nginx.org
3. https://github.com/openresty/lua-nginx-module
4. https://github.com/openresty/lua-upstream-nginx-module
5. https://github.com/goldenclone/nginx-sla
6. http://gdnsd.org
GDNSD

70. Всем Спасибо!
akononov.job@gmail.com
https://www.linkedin.com/in/andkononov