Требуется уточнение nginx и балансировка нагрузки

Question

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

Каждый запрос на серверы Instagram проходит через устройства балансировки нагрузки; мы использовали для запуска 2 nginx-машин и DNS Round-Robin между ними. Недостатком этого подхода является время, которое требуется для обновления DNS, если один из компьютеров нуждается в декомпозиции. В последнее время мы перешли к использованию балансировки эластичных нагрузок Amazon с тремя экземплярами NGINX, которые могут быть заменены и выведены (и автоматически выведены из строя, если они не прошли проверку работоспособности). Мы также завершаем наш SSL на уровне ELB, что снижает нагрузку на процессор на nginx. Мы используем Route53 Amazon для DNS, который недавно добавили в консоль AWS довольно удобный графический интерфейс.

Вопрос есть. Правильно ли, что на данный момент у них есть DNS-сервер, который использует RR, чтобы решить, на каком nginx-сервере отправить запрос. И каждый из этих серверов nginx в свою очередь передает запрос кластеру?

И второй вопрос. Какая разница между nginx и балансировщиком нагрузки. Почему мы не можем использовать nginx?

Answer 1

Для вашего первого вопроса, я считаю, что ответ кажется, что Instagram теперь использует Route53 для привязки DNS к балансировщику эластичных нагрузок, что делает две вещи: он трассирует трафик довольно равномерно на три балансировщика нагрузки NGINX и обеспечивает SSL для всего трафика. Затем серверы NGINX действуют в качестве балансировщиков нагрузки на серверы контента/приложений дальше по стеку. Использование ELB вместо циклического DNS означает, что они могут добавлять/удалять/обновлять экземпляры, прикрепленные к ELB, даже не беспокоясь о обновлениях DNS или TTL.

Что касается второго вопроса, вы можете использовать NGINX так же легко, как HAproxy или другие сервисы для балансировки нагрузки. Я уверен, что часть обращения к Instagram при выборе NGINX - это его невероятная скорость и что он асинхронный и «управляемый событиями» вместо потокового, как Apache2. При правильной настройке это может означать меньше головных болей при тяжелых нагрузках.