У меня неплохо разбирается в балансировке нагрузки веб-приложений с помощью nginx / HAProxy / и т. Д. Насколько я понимаю, в этих случаях вы в основном ограничены такими вещами, как количество одновременных подключений и рукопожатий TLS, но каждый запрос - это относительно небольшой объем передаваемых данных.
В настоящее время я работаю над сервисом, который передает много данных по запросу. Подумайте о потоковой передаче видео или одноранговой передаче файлов через прокси-сервер.
Мне интересно, каков типичный способ балансировки нагрузки что-то вроде этого? Даже если HAProxy сможет справиться с пропускной способностью, наличие всего, что проходит через один VPS, довольно легко насыщает его сеть (по крайней мере, в DigitalOcean; возможно, будет достаточно экземпляра AWS 25 Гбит / с). Я думаю, что переадресация может быть подходящим вариантом, но я бы хотел этого избежать и хотел бы увидеть, есть ли лучший способ.
Еще одна информация о моем сервисе заключается в том, что запросы к одному и тому же URL-адресу должны поступать на один и тот же вышестоящий сервер. Но его волнует только путь. Параметры запроса, заголовки и т. Д. Не имеют значения.
Я быстро проверил YouTube, и похоже, что они используют перенаправления на почти случайные домены, такие как r5---sn-qxo7rn7l.googlevideo.com, r1---sn-qxoedn7e.googlevideo.com.
РЕДАКТИРОВАТЬ: Дополнительные сведения по запросу Тима:
Данные следует считать некэшируемыми. Представьте, что у peer1 есть видеофайл размером 4 ГБ, которым они хотят поделиться с peer2. peer1 подключается к lb.example.com/path и ожидает подключения peer2. peer2 подключается к lb.example.com/path, и данные передаются через сервер от однорангового узла1 к узлу2.
Я бы сделал это с переадресацией так: peer1 подключается к lb.example.com/path. путь хешируется, и значение хеша используется, чтобы определить, перенаправлять ли peer1 на instance1.example.com или instance2.example.com. Когда peer2 подключается по тому же пути, он попадает в один и тот же восходящий экземпляр. Хеш-пространство будет равномерно разделено между instance1 и instance2.
Я согласен с тем, что AWS egress слишком дорого обходится, и это большая часть того, почему я пытаюсь разработать масштабируемое решение, не зависящее от одного огромного сетевого канала.
Для одноранговой сети вы можете напрямую подключиться к другому узлу, полностью устраняя узкое место вашей инфраструктуры. И затраты на входящую и исходящую полосу пропускания для каждого сеанса. Особенно жизнеспособен с IPv6, который возвращает глобальную адресацию. Подбор матчей и обход брандмауэра могут быть сложными.
haproxy может масштабироваться до сотен тысяч соединений, но вы, вероятно, тоже захотите масштабироваться. Ethernet 25 Гбит / с относительно недорого владеть, но аренда стоит дороже. Так много узлов - это данность.
Для балансировщиков нагрузки сохраняйте как можно меньше состояния. Маршрутизация уровня 4 без сохранения состояния. Прямой возврат сервера, чтобы серверные ВМ отвечали напрямую клиентам. Оба делают некоторые уловки с балансировщиком нагрузки сложными, но это цена простого идиотского быстрого безгражданства.
Рассмотрим лабораторию Винсента Берната Многоуровневая балансировка нагрузки с Linux. IPVS + keepalived обеспечивает L4 без сохранения состояния. haproxy обеспечивает завершение L7 с прямым возвратом сервера из-за send-proxy.
Каким бы ни был ваш дизайн, общая пропускная способность ваших пользователей должна превышать максимальную скорость передачи. Либо вы запускаете несколько экземпляров балансировщика нагрузки с быстрыми интерфейсами, либо нанимаете балансировщик нагрузки как услугу из своего облака.