Комментарии 16
Спасибо. полезная статья. Заберу в закладки. Подскажите. Чем вы генерите запросы на балансер? Ну чтобы понять визуализацию балансировки. Понять на какой ноде дропается?
Чем вы генерите запросы на балансер?
ничем не генерят. это перевод.
The other common theme was "how did you make this?" I used PixiJS and I'm really happy with how it turned out. It's my first time using this library and it was quite easy to get to grips with. If writing visual explanations like this are something you're interested in, I recommend it!
Из оригинала
Спасибо за перевод, очень красиво оформленная статья.
Правда, по-моему, автор ошибается насчет алгоритма по умолчанию для AWS ALB - на самом деле это round robin, а не least connections. Написал ему, посмотрим что скажет.
Если честно, я не понял, как least connections справляется с тем, что сервера имеют разную мощность. Или с тем, что клиенты по-разному нагружают сервер в рамках коннекта.
Особенно, если у нас долгоиграющие сессии, вроде websocket или коннекта к бд.
Ну смотрите, распределитель знает, сколько в данный момент у какого сервера в очереди задач, и пихает новую в один из серверов с самой короткой очередью. Самая короткая очередь будет у самого быстрого сервера - он свою очередь быстрее всего укорачивает. Так тупенько при более-менее одного размера задачах неплохо получится.
повторюсь. А если у нас сессия - вебсокет? Я ее поднял, она висит, генерирует минимальную нагрузку. А другая сессия у другого человека генерит кучу траффика. Явно ведь не одинаковая нагрузка будет.
И даже без вебсокета. Что в данном случае есть connection? Tcp сессия? А что если клиент не смог ее корректно завершить - как лоад баллансер поймет, что сервер свободен?
И даже если клиент закрыл сессию, сервер считается нагруженным все это время, пока пакеты движутся по сети, что, учитывая множественные syn-ask-и может быть в разы больше времени обработки запроса.
Кажется, часть проблем можно было бы решить, если бы лоад баланнсер был "man in the middle", терминировал клиентское подключение и начинал новое к серверам, но такая сложная схема обычно сама по себе становится узким местом и источников высоких задержек.
Нет, тут нагрузка типа "запрос-ответ", не сессия. Коннект - это вот такая транзакция. Вы уже совсем в детали ушли, а тут схема простая как валенок. Например, возьмём фотобанк: при загрузке фотографии он создаёт её копии в разных размерах, и идёт постоянный поток новых фото, вот балансер и разбрасывает такую работу по серверам.
А есть ли такой алгоритм, где автоматически высчитываются веса не только у серверов, но и у разных запросов? Чтобы подсовывать более "тяжёлый" запрос серверу, который справится с ним быстрее, даже если у него очередь, а у соседей нет.
Это все, безусловно, можно, хотя и сложно реализовать. Проблема в том, что алгоритмы в статье ничего не знают про сам запрос, поэтому они универсальны. В вашем примере необходимо реализовывать кастомную логику на балансировщике с учетом знания о природе запросов. В простейшем случае на примере nginx можно разные запросы обработать разными location с разными настройками балансировки. Но дальше встает вопрос, что сложность запроса зависит от его параметров, а это гораздо сложнее учитывать.
Жаль, что не рассказано про алгоритм ”power of two”. Он очень прост и показывает хорошие сбалансированные результаты в среднем. Вкратце (если я правильно помню), это когда тоже для каждого сервера считается, например, средняя задержка последних N запросов (к примеру, трех), или же число сессий, или какой-то фидбэк из заголовка ответа (короче, любая пузометрика) и потом при очередном запросе:
Случайным (!) образом выбираются ДВА сервера.
Из этих двух выбирается тот, у которого пузометрика меньше, и туда посылается.
Преимущество - простота: не надо хранить никакой глобально упорядоченный список (потому это все lock-free).
Спасибо, тема интересно и доходчиво раскрыта.
А как-то борются с тем, что сам балансировщик это по факту единая точка отказа в такой схеме? Ведь если он упадет, то все сервера станут недоступными, несмотря на то что они могут вполне себе нормально себя чувствовать.
Алгоритмы балансировки нагрузок