Контекст
Веб-приложение с сервером приложений, т.е. Ruby on Rails с puma. Работает в контейнере на AWS ECS с Fargate. Трафик направляется балансировщиком AWS Application Load Balancer напрямую на сервер приложений, работающий в контейнере.
Вопрос
Требуется ли обратный прокси между ALB и самим приложением, т. е. как sidecar-контейнер? В чем будет преимущество?
решение1
Обратный прокси-сервер не требуется, но веб-серверы, поставляемые с Rails, обладают минимальной функциональностью, поэтому для любого публично доступного приложения, которое может потенциально расти, хорошей идеей будет интегрировать обратный прокси-сервер (например, Nginx) на раннем этапе.
Например, это даст вам расширенные возможности ограничения скорости, кэширования и возможность выполнять сквозное завершение SSL с гораздо меньшими усилиями, чем другие реализации веб-сервера. Ведение журнала также становится намного проще, а такие вещи, как повторные попытки TCP, могут спасти жизнь, если ваше приложение находится под нагрузкой.
Вам не нужен sidecar. Вы можете установить Nginx на том же ящике, что и ваше приложение. Он суперэффективен и не повлияет на производительность вашего приложения.
Мы используем несколько прокси-серверов Nginx перед Rails и обрабатываем миллиарды http-запросов в день.
Массовые реализации обратного проксирования, такие как Cloudflare, также построены на Nginx.
решение2
Балансировщик нагрузки — это тип обратного прокси-сервера. Его преимущества включают прием трафика на определенных портах, выполнение функции брандмауэра и предотвращение некоторых видов атак, достигающих сервера.
Для обычного веб-приложения я не вижу существенных преимуществ от наличия балансировщика нагрузки и второго обратного прокси-сервера.