Comments 9
причина, по которой мы полностью живем в облаках, — это скалируемость, то есть у нас реально часто нужно добавлять/удалять инстансы, иногда очень много.

Точнее это назвать эластичностью. Скалируемость это свойство архитектуры поддерживать эластичность
Сколько реквестов 1 инстанс хендлит? Какой траффик? Какие технологии бекенда?
У нас довольно много проектов и цифры отличаются от проекта к проекту.
Количество реквестов, с которыми может справится 1 инстанс может зависеть, например, от типа реквестов. Как я говорил, юзерский трафик != серверный трафик. Да и внутри пользовательского и серверного типы запросов могут сильно отличаться как по размеру, так и по времени процессинга.
Технологии бекенда — у нас свой in-house http-сервер, который парсит довольно сложную бизнес-логику, написанную отдельно (т.е. это не часть серверного кода как такового).
Мне просто пришла идея, что если сделать отдельный сервер довольно мощным (заоптимизировать). Скажем чтобы он мог обрабатывать 10к рек-сек. Тогда проблем с балансировкой у Вас было бы поменьше.
Я 5 лет назад создавал подобную систему. Детали тут. Правда нам нужно было держать всего 11к рек-сек.
Хорошая статья. Для тех, у кого ещё нет столько траффика, есть о чем подумать и к чему готовиться.

Отличная статья. Единственное, есть уточнение по:


Если ваш бэкенд отчаянно пятисотит [выдаёт код состояния HTTP 5XX, что говорит об ошибке сервера] и не справляется, то балансировщик думает, что бэкэнд очень быстро отдает ответы, и начинает слать ему ещё больше трафика, загибая ваш бэкэнд ещё сильнее.

ELB проверяет жизнь инстанса по настраиваемому URL. И 500-я ошибка говорит о том, что нужно выбросить инстанс с пула. То есть, если ELB смотрит на пользовательскую страницу и она вернет ошибку 500, то он корректно отработает. Зачастую этого достаточно.

Да, всё верно, более интеллектуальные health check'и, кажется, спасли бы ситуацию.
Но при этом «отчаянно пятисотит» в данном контексте может означать не «100% реквестов», а, например, 20%. В таком случае нагрузка на инстанс увеличивается, технически он всё ещё здоров, но за счёт бОльшего количества запросов, отсылаемого на него балансировщиком, ему становится хуже и он начинает дропать больше запросов.

Ну тогда просто делается end-point, который будет репортить статус опираясь на LA к примеру (ну или на любую другую метрику)

Замечательные ребята из Spotinst относительно недавно сделали https://spotinst.com/products/multai-load-balancer/
Вы не рассматривали это решение?
Only those users with full accounts are able to leave comments. Log in, please.