Имеет ли смысл Nginx перед Node.js на AWS?

Question

[WenSiL]

Собственно вопрос чисто теоретический, задан из личного любопытства.
Суть: например есть приложение на node.js. Есть пара бэкэнд тачек с этой самой приложенькой и есть фронтэнд тачка с nginx для отдачи статики и балансировки нагрузки между бэкэндами. Но вот мне приспичило перейти на AWS, но вот вопрос, а оставлять ли nginx? Ведь по факту все возможности nginx можно заменить с помощью Elastic Load Balancing (для балансировки нагрузки между инстансами node) и CloudFront (для раздачи статики).
Да и вообще нужны ли инстансы с веб серверами, если их можно по большей части заменить связкой ELB и CloudFront?
Зачем вообще на эталонной архитектуре AWS нужен кластер с веб серверами?

Comments

[sim3x]

Если вас не страшит вендор лок и счета, то почему нет

[Александр Аксентьев]

оффтопчег

Но вот мне приспичило перейти на AWS

А почему так приспичило?
Это же в разы дороже чем держать свой парк серверов(а если не парк, а парочка, то тем более) напрямую от крупных ДЦ.

[Philipp]

Александр Аксентьев, зависит от решаемых задач. Когда вам нужно смасштабировать проект в 100 раз за сутки только Amazon, Azure или Google могут помочь. Может IBM еще, не знаю, что там у них сейчас.

[Александр Аксентьев]

Philipp, ну масштабирование это самая главная фича во всех их сервисах.
Но слишком сильно бесценный сервис как по мне.
Ладно была бы какая-то накрутка адекватная на стоимость железа, так ведь в разы выше железа стоит.
Даже америкосы фигеют с расценок этих золотых облаков, но при этом поголовно пользуются =)

И уже не раз были тру стори о том что дудоснули/навалили трафика/еще что-то подобное сделали и чуваки попали за страшные цифры в стопицот раз больше чем обычно тратилось.

[Philipp]

Александр Аксентьев, Amazon берет деньги за то, что вы можете автоматизированно развернуть ваше приложение в десятке геозон и смасштабировать его от 1 пользователя до масштабов государства.
Его основные клиенты - это enterprise. А там принято считать расходы до того, как они будут, планировать, ставить ограничения и т.д. Amazon это все умеет.

Все истории о потраченных деньгах чистое разгильдяйство: "О, я не поставил ограничение на ресурсы, меня задосили/завалили трафиком, я попал и т.д.".

Answer 1

[Philipp]

Смысла не имеет, поскольку контент лучше класть в S3 и раздавать его оттуда через CloudFront.
То, что делает ваш nginx, прекрасно делается через ELB.
Самое главное, если использовать средства Cloud Formation достаточно просто масштабировать проект без исправления каких-либо конфигов и т.п.

Comments

[WenSiL]

А зачем тогда амазон предлагает, как эталонную архитектуру такой конфиг: ELB -> web server cluster -> ELB -> app server cluster? В чем прикол кластера с веб серверами?

[Дмитрий Энтелис]

WenSiL, прикол в счете который вы получите.

ну и в целом, проекты у всех разные, это же картинка просто как идея возможностей.

[abroabr]

WenSiL,

В чем прикол кластера с веб серверами?

ну так то вообще для облака является нормальным масштабирование количеством инстансев.

[Philipp]

Дело в том, что они разделяют понятия "веб-сервер" и "сервер приложений". Это достачно распространено в мире корпоративных приложений, где часть бэкенда выполнена в виде отдельных Java-приложений.

[Dmitry]

AWS ELB, как и ALB, не предоставляют функции кэширующего прокси. Нужно обязательно принимать во внимание, что клиенты с медленным соединением (читай Slowloris) будут занимать поток выполнения. В случае с асинхронным кодом это может показаться не слишком важной необходимостью, но иметь в виду всё же следует.