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

На этом фоне возникает эффект «стада», когда много запросов дружно бегут туда, где вроде бы свободно и по итогу перегружают сервер еще больше.

Это можно решить проще — например перенаправлять запросы случайно.

Работает это вроде неплохо, но опять же всегда есть шанс, что нагрузка будет неравномерной. И снова получаем, что какой-то из серверов будет перегружен запросами.

Какой-то замкнутый круг, печаль и говнище.

А чё делать?

Представь: я в рандоме выбираю два сервера, смотрю какой из них менее загружен и отправляю туда запросы. Все!

Вроде мелочь, но работает этот подход прям заебись! И что интересно у этого подхода есть официальная формулировка — Power of Two Choices или «Сила двух выборов».

Почему это заебись?

На просторах есть задачка «яйца и корзины», в оригинале там конечно не «яйца», а шары.

Короче. Мы случайно кидаем яйца в корзины. Если класть каждое яйцо в случайную корзину, то в итоге некоторые корзины будут переполнены.

Но если каждый раз выбирать две корзины и класть яйцо туда, где их меньше — ситуация резко улучшается.

Максимальная перегрузка корзины падает в разы. И это при том, что мы по-прежнему делаем случайный выбор, просто из двух вариантов, а не из одного.

Все просто! Тоже самое и с серверами:

- Если мы выбираем сервер наугад, нагрузка на сервер может стать критической.
- Если выбираем между двумя, вероятность перегрузить сервер падает квадратично.

Давай на котиках:

Представь, что у тебя есть куча серверов, и на четверти из них пришло по 4 запроса.

- Если я выбираю сервер случайно, есть 25% шанс попасть именно на сервер, которому уже пезда.

- Если я выбираю два сервера и беру менее загруженный — вероятность того, что оба окажутся с нагрузкой 4, уже всего 6,25% (1/16).

Получается, что вероятность перегрузки падает очень быстро. А дальше — ещё быстрее: чтобы нагрузка выросла до 5, 6 и так далее, нужно каждый раз «удачно» попасть в редкие перегруженные сервера, и шанс становится ничтожным.

Видишь, математика нужна не только бекендерам, но и в девопсе можно применить.

Что получаем на практике:

На практике балансировка «выбором из двух» делает распределение нагрузки по серверам почти равномерной. При этом мы не тратим кучу ресурсов на мониторинг и не пытаемся каждый раз точно узнать состояние всех серверов.

Такой подход - простой и элегантный. Как говорится — без хуйни!

Формулы и расчеты визуально можешь глянуть тут. Там как раз разбирается способ с яйцами, но уже с углубленной математикой и формулами.

Этот же принцип используют, например, в cuckoo hashing (структура данных для хранения ключей).

Cuckoo hashing (кукушкино хеширование) — алгоритм разрешения коллизий значений хеш-функций в таблице с постоянным временем выборки в худшем случае.

upstream backend {

    random two; # Power of 2 Choices

    server app1.bashdays.ru;

    server app2.bashdays.ru;

    server app3.bashdays.ru;

}

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

Этот же принцип используют, например, в cuckoo hashing (структура данных для хранения ключей).

Мотай на ус, глядишь сгодится в хозяйстве.

🛠 #devops #nginx
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Есть такая книга — «Не работайте с мудаками». Я ее не читал, но вся суть в названии. Ща расскажу поучительную историю.
ㅤ
Отдел продаж разжился постоянным клиентом, успешно работают с ним 5 и более лет, сайтики там рисуют, CI/CD настраивают и т.п. Для постоянного клиента все блага, фиксированные скидки, обработка экстравагантных запросов, отлизывание жопы, где-то даже бесплатно, полное доверие.

В какой-то момент, у постоянного клиента меняется менеджер. Прилетает очередная таска на доработку. Доработки сделаны, но менеджер визжит-пищит и орет — я просил другое!

По ТЗ все гладко, перепроверяют, как просили — так и сделали. Не доебаться!

Но нет, откуда-то берутся новые вводные. Новые вводные предварительно озвучены не были. Вводные в голове нового менеджера, которые он получил из космоса. То, что их нет в ТЗ, это сугубо личные проблемы исполнителя.

Кто виноват? Конечно — исполнитель! Он должен был догадаться сам. А значит виноват — исполнитель!

Исполнитель пробует решить всё миром, объясняет, так и так, что это дополнительные человеко-часы, в договоре такого нет, нужно доплатить и вообще так не делается.

По итогу — виноват исполнитель, переделывайте за свой счет.

Классика! Ну такое себе…

Что имеем: С таким менеджером дальше работать никто не будет, искать концы до главного босса тем более (других клиентов жопой ешь). Конфликт конечно же нужно уладить, спустить на тормозах. Мы же взрослые люди. Но на этом увы всё, сотрудничество закончено!

Да, у айтишников есть свой «черный список», который гуляет в приватных чатах в телеграм. Не только HRы этим грешат.

В таких ситуациях не стоит хамить, нужно разобраться и найти какие-то общие точки соприкосновений.

Искать правду и что-то доказывать смысла нет, если человек живет в своем мире, его от туда уже не вытащить. И нужно ли вытаскивать? Ему там комфортно, он таким уродился!

Не профессионально? Вопрос не корректный, тратить время на выяснения отношений себе дороже, дешевле распрощаться, проще освободить ресурс и взять нового клиента. Виз из Спарта!

Конфликт решается просто — ок, сделаем как вы хотите. Пусть думают что всё пошло по их правилам, но это лишь начало конца.

Это наглядный пример, как один менеджер способен за полчаса уничтожить протоптанные годами мосты сотрудничества.

Теперь сайтики и CI/CD, бывшему клиенту обойдутся в x2-x3 дороже, потому что рыночные цены ушагали вперед семимильными шагами, даже на фрилансе.

Мосты сожжены, а реквест на расторжение договора выслан по почте. Всё рамках трудовых отношений.

Подведем итоги:

Если у тебя свой бизнес, всегда контролируй основные звенья своего коллектива. Либо делегируй этот контроль проверенным людям.

Для ИПешников с сотрудниками это прям критично.

Но порой и проверенные люди тоже дают сбой (оказываются пидарасами), это как продакшен. Продакшен в 99% случаев тот еще пидарас.

Поэтому изредка сам вылазий из берлоги и проходись по всем процессам самостоятельно, узнаешь много нового и (интересного) хуевого.

Ну а если это твой основной заказчик (который делает тебе 90% прибыли), найди выходы на главного и обсуди все вопросы с ним, благо это делается на раз-два. Менеджер уйдет сразу нахуй и будет выкинут на улицу. Проходили, знаем.

Но лично я предпочитаю чтобы овнер сам это всё просек и нашел крысу. Без подсказок и т.п. Если не просекет, то извините, выше уже не прыгнет с такими кадрами.

Большего и не скажешь. Если читал книгу «Не работайте с мудаками» расскажи в паре слов, о чем она. А то всё руки не дойдут полистать.

😀😃😄😁😅😂🤣😊
😇🙂🙃😉😌😍🥰😘
😗😙😚😋😛😝😜🤪
🤨🧐🤓😎🤩🥳😏😒
😞😔😟😕🙁☹️😣😖
😫😩🥺😢😭😤😠😡

Спасибо за внимание и до свидания!

🛠 #рабочиебудни
—
✅ @bashdays ✅ @linuxfactory ✅ @blog