Ответ 1
Отказ: я никоим образом не являюсь экспертом в этом вопросе и сам изучаю процесс самообучения экосистемы AWS.
ELB (Эластичный балансировщик нагрузки) не имеет никаких функций самостоятельно, за исключением получения запросов и маршрутизации на нужный сервер. Серверы могут запускать nginx, IIS, Apache, lighthttpd, вы называете это.
Я дам вам реальный прецедент.
У меня был один сервер nginx, на котором был один блог Wordpress. Этот сервер, как я сказал, работал на nginx, обслуживая статический контент и "восходящий".php-запрос на phpfpm, запущенный на том же сервере. Все было в порядке до одного дня. Этот блог был показан на телешоу. У меня было много пользователей, и сервер не смог справиться с таким трафиком. Моей первой реакцией было бы просто использовать AMI (образ машины Amazon), чтобы развернуть копию моего сервера на более мощном экземпляре, например m1.heavy. Проблема заключалась в том, что я знал, что со временем количество трафика увеличится в течение следующих нескольких дней. Вскоре мне пришлось бы вращать еще более мощную машину, что означало бы больше времени простоя и неприятностей. Вместо этого я запустил ELB (балансировщик упругой нагрузки) и обновил свой DNS, чтобы указать трафик веб-сайта на ELB, а не непосредственно на сервер. Пользователь не знает сервер ip или что-то еще, он видит только ELB, все остальное происходит внутри облака амазонок. ELB решает, к какому серверу идет трафик. В то время вы можете иметь ELB и только один сервер (если на данный момент трафик низкий) или сотни. Серверы могут быть созданы и добавлены в серверный массив (группа серверов) в любое время или вы можете настроить автоматическое масштабирование для создания новых серверов и добавления их в группу ELB Server с помощью командной строки amazon, все автоматически.
Amazon cloud watch (еще один продукт и важная часть экосистемы AWS) всегда следит за состоянием вашего сервера и решает, на каком сервере он будет маршрутизировать этого пользователя. Он также знает, когда все серверы становятся слишком загруженными и является агентом, который дает заказ на создание другого сервера (используя ваш AMI). Когда серверы не находятся под большой нагрузкой, они автоматически уничтожаются (или останавливаются, я не помню).
Таким образом, я мог обслуживать всех пользователей в любое время, и когда нагрузка была легкой, у меня был бы ELB и только один сервер nginx. Когда загрузка была высокой, я бы позволил ей решить, сколько серверов мне нужно (в зависимости от загрузки сервера). Минимальное время простоя. Конечно, вы можете установить лимиты того, сколько серверов вы можете себе позволить в одно и то же время и тому подобное, чтобы вы не получали счета за то, что вы можете заплатить.
Понимаете, ребята из Instagram сказали следующее: "Мы использовали для запуска 2 nginx-машин и DNS Round-Robin между ними". Это неэффективная ИМО по сравнению с ELB. DNS Round Robin - это DNS-маршрутизация каждого запроса на другой сервер. Итак, сначала идет сервер один, второй идет на сервер два и дальше и дальше. ELB фактически наблюдает за серверами HEALTH (использование процессора, использование сети) и решает, на какой серверный трафик идет на это. Вы видите разницу? И они говорят: "Недостатком такого подхода является время, необходимое DNS для обновления, если одна из машин должна быть выведена из эксплуатации". DNS Round robin - это форма балансировки нагрузки. Но если один сервер идет kaput, и вам нужно обновить DNS, чтобы удалить этот сервер из группы серверов, у вас будет время простоя (DNS требует времени для обновления по всему миру). Некоторые пользователи будут перенаправлены на этот плохой сервер. С ELB это автоматическое - если сервер находится в плохом состоянии, он больше не получает трафика - если, конечно, вся группа серверов не работоспособна, и у вас нет какой-либо автоматической настройки масштабирования.
И теперь ребята на instagram: "В последнее время мы перешли к использованию Amazons Elastic Load Balancer, с тремя экземплярами NGINX за ним, которые можно поменять местами (и автоматически выведены из строя, если они не прошли проверку работоспособности).".
Сценарий, который я проиллюстрировал, вымышленный. Это на самом деле более сложное, чем это, но ничего, что невозможно решить. Например, если пользователи загружают изображения в ваше приложение, как вы можете поддерживать согласованность между всеми машинами в группе серверов? Вам нужно будет хранить изображения на внешнем сервисе, таком как Amazon s3. В другом посте по Instagram engineering - "Сами фотографии идут прямо на Amazon S3, который в настоящее время хранит для вас несколько терабайт фотоданных". Если у них 3 сервера nginx на балансировщике нагрузки, и все серверы обслуживают html-страницы, на которых ссылки для изображений указывают на S3, у вас не будет проблем. Если изображение хранится локально на экземпляре - это невозможно сделать. Все серверы на ELB также нуждаются в внешней базе данных. Для этой амазонки есть RDS. Все машины могут указывать на одну и ту же базу данных и гарантировать целостность данных. На изображении выше вы можете увидеть RDS "Read replica" - это способ балансировки нагрузки RDS. Я не знаю много об этом в это время, извините.
Попробуйте прочитать следующее: http://awsadvent.tumblr.com/post/38043683444/using-elb-and-auto-scaling
С уважением.