Раздражать (так!) Веб-уровень, чтобы предотвратить узкое место балансировщика нагрузки?

Question

Как крупные веб-сайты, которые не могут быть полностью без состояний, достигают максимальной масштабируемости на веб-уровне?

Существуют такие сайты, как eBay и Amazon, которые не могут быть полностью безлимитными, поскольку у них есть корзина для покупок или что-то в этом роде. Невозможно закодировать каждый элемент в корзине для покупок в URL-адрес, а также невозможно кодировать каждый элемент в файл cookie и отправлять его при каждом подключении. Таким образом, Amazon просто сохраняет идентификатор сессии в файле cookie, который отправляется. Поэтому я понимаю, что масштабируемость веб-уровня eBay и Amazon должна быть намного сложнее, чем масштабируемость поисковой системы Google, где все может быть закодировано в виде URL-адреса.

С другой стороны, как eBay, так и Amazon масштабируются абсолютно. Ходят слухи, что на eBay есть около 15000 серверов приложений J2EE.

Как эти сайты работают как с высокой масштабируемостью, так и с сохранением состояния? Поскольку сайт находится в состоянии отслеживания, невозможно выполнить простую балансировку DNS. Таким образом, можно предположить, что в этих компаниях есть аппаратный балансировщик нагрузки, такой как BigIP, Netscaler или что-то в этом роде, которое является единственным устройством, поддерживающим один IP-адрес этого сайта. Этот балансировщик нагрузки расшифровывает SSL (если он закодирован), проверяет cookie и в зависимости от идентификатора сеанса этого cookie определяет, какой сервер приложений содержит сеанс этого клиента.

Но это просто не может сработать, поскольку ни один балансировщик нагрузки не может справиться с нагрузкой тысяч серверов приложений? Я полагаю, что даже эти аппаратные балансировщики нагрузки не масштабируются до такого уровня.

Кроме того, распределение нагрузки выполняется прозрачно для пользователя, то есть пользователи не перенаправляются на разные адреса, но все вместе все время остаются на www.amazon.com.

Итак, мой вопрос: существует ли какой-то особый прием, с помощью которого можно добиться чего-то вроде прозрачного шардинга веб-уровня (не уровня базы данных, как это обычно делается)? Пока cookie не проверяется, невозможно узнать, какой сервер приложений удерживает этот сеанс.

Редактировать: Я понял, что нужна только прозрачность, если нужно, чтобы сайт был добавлен в закладки и добавлен в закладки. Например. если сайт представляет собой простое веб-приложение, что-то вроде системы бронирования билетов на самолет или поезд, не должно быть проблем с простым перенаправлением пользователей на конкретные кластеры веб-серверов за разными URL-адресами, например a17.ticketreservation.com. В этом конкретном случае было бы целесообразно просто использовать несколько кластеров серверов приложений, каждый из которых имеет собственный балансировщик нагрузки. Интересно, что я не нашел сайт, который использует такую ​​концепцию. Редактировать: Я нашел эту концепцию обсуждается на highscalability.com , где обсуждение относится к статье Лей Чжу под названием "Клиентская сторона Балансировка нагрузки для приложений Web 2.0 ". Лей Чжу использует кросс-сценарии для прозрачного распределения нагрузки на стороне клиента.

Даже если есть недостатки, такие как закладки, xss и т. Д., Я думаю, что это звучит как очень хорошая идея для определенных особых ситуаций, а именно веб-приложений, практически не содержащих контента, которые не нужно разбрасывать или добавлять в закладки ( например, системы бронирования билетов или что-то подобное). Тогда нет необходимости выполнять прозрачную балансировку нагрузки.

Может быть простое перенаправление с основного сайта на сервер, например перенаправление с www.ticketreservation.com на a17.ticketreservation.com. С этого момента пользователь остается на сервере a17. a17 - это не сервер, а сам кластер, с помощью которого можно достичь избыточности.

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

Конечно, перенаправление на разные URL выглядит крайне неприятно, но с простыми веб-приложениями (которые в любом случае не нужно разбрасывать, добавлять ссылки или делать закладки), это должно быть только оптической проблемой для пользователя?

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

Answer 1

Я не знаю, как они это делают, но вот несколько советов:

• Чтобы избежать перегрузки самого хоста балансировщика нагрузки, используйте циклический DNS или ИЛИ
• Перенаправление разных клиентов на разные адреса кластера в зависимости от нагрузки, настроек, геолокации и т. Д.

Для распределения нагрузки среднего уровня,

• Вставить идентификатор сервера сеанса среднего уровня в файл cookie идентификатора сеанса - как предлагали другие. В этом случае внешний интерфейс не имеет значения, его можно добавлять / удалять без какого-либо влияния.
• Если это достаточно важно, иметь механизм перенаправления клиентов на альтернативный сервер среднего уровня во время сеанса, чтобы его можно было отключить для обслуживания и т. Д.
• Клиенты начинают использовать недавно введенный в эксплуатацию сервер среднего уровня при запуске нового сеанса

Чтобы распределить нагрузку на базу данных

• «Обычное» разбиение данных «в реальном времени» для каждой учетной записи или для каждого пользователя
• Асинхронная репликация медленно изменяющихся или относительно статических данных; пользователи могли видеть это устаревшим (но не очень большую часть времени). Средний уровень и веб-серверы подключаются к локальной базе данных, расположенной по их собственному адресу

Answer 2

Вам может пригодиться следующий документ, в котором представлен дизайн и реализация высокодоступной системы хранения с ключом-значением, которую некоторые основные сервисы Amazon используют для обеспечения постоянного взаимодействия:

Джузеппе ДеКандия, Дениз Хасторун, Мадан Джампани, Гунавардхан Какулапати, Авинаш Лакшман, Алекс Пилчин, Свами Сивасубраманян, Питер Воссхолл и Вернер Фогельс , « Динамо: ключ Амазонки Хранилище значений », в материалах 21-го симпозиума ACM по принципам операционных систем, Стивенсон, Вашингтон, октябрь 2007 г.

Answer 3

Вероятно, вам придется быть в команде инженеров в одном из этих мест, чтобы знать наверняка, но есть люди, которые сделали обоснованные предположения на основе бесед и другой информации, которая поступила из обоих мест:

Архитектура Ebay и Архитектура Amazon

В современном мире только один балансировщик нагрузки является своего рода эквивалентом циклического перебора DNS прошлых лет. Сегодня у вас есть такие вещи, как anycast , которые позволяют вам играть всевозможные трюки. Вы можете быть совершенно уверены, что подобные ebay и amazon используют балансировщики нагрузки, и они используют их много.

Возможно, вы захотите еще немного увести его, когда подумаете о том, как он может работать, потому что большая часть трафика не имеет состояния. В одном запросе на страницу потенциально может быть много объектов, которым не нужно знать о состоянии. Уберите эти объекты из картинки, передавая их из системы без сохранения состояния (вот где приходит anycast), и количество запросов резко уменьшается.

Если это не позволяет вам понять, что один балансировщик нагрузки может справиться с нагрузкой, то следующим шагом будет разбиение транзакций с использованием IP-маршрутизации и / или гео-DNS. Сайты, такие как ebay и amazon, будут находиться в разных дата-центрах с большим количеством интернет-соединений в каждом. Вы берете все, что приходит из интернет-поп-квест-запад, и отправляете его на серверы "квестовых" центров обработки данных западного побережья, все, что от att-west, отправляется на серверы "att" центров обработки данных западного побережья, все что угодно с квест-восток и отправляется на серверы «квестовых» центров обработки данных восточного побережья и т. д. Каждая из этих систем может представлять собой отдельный балансировщик нагрузки, способный справиться с нагрузкой, некоторые из них могут обрабатывать сотни тысяч транзакций в секунду, даже с использованием шифрования SSL. С обратной стороны вы постоянно копируете данные в каждый центр обработки данных, но это может быть не синхронизировано.

Answer 4

Легко. Веб-серверы, которые не имеют состояния, сбалансированы по нагрузке. Серверы приложений (средний уровень), которые содержат данные сеанса, не являются. Веб-серверы могут использовать ваш файл cookie идентификатора сеанса, чтобы определить, с каким сервером приложений связаться.

Memcached и Microsoft Velocity - продукты, которые решают именно эту проблему.

Изменить: Как веб-сервер знает, с каким сервером приложений связаться? Это встроено в хэш идентификатора сеанса и может быть сделано, как вам угодно. Это может быть так просто, как ваш идентификатор сеанса, являющийся сервером: guid. Memcached основывает его на хэше.

Важным моментом является то, что клиент должен иметь возможность выяснить, к какому серверу приложений следует обращаться без сохранения состояния. Самый простой способ сделать это - встроить его в ключ, хотя реестр (возможно, на своем собственном уровне) также будет работать и обеспечивать некоторую отказоустойчивость.

Edit2: Возвращаясь к некоторым Ebay интервью , возможно, я неправильно понял детали их реализации. Они не делают кеширование, и они не делают состояния на среднем уровне. Что они делают, так это имеют средний уровень с балансировкой нагрузки (серверы приложений), разделенный по функциям. Таким образом, у них будет пул серверов, например, для просмотра предметов. А потом еще один пул для продажи предметов.

Эти серверы приложений имеют «умный» DAL, который направляет к защищенным базам данных (разделенных по функциям и данным, таким образом, пользователи A-L в базе данных 1, пользователи M-Z в базе данных 2, элементы 1-10000 в элементы 1 и т. Д.).

У них нет состояния на среднем уровне, потому что они разделены по функциям. Таким образом, нормальный пользовательский опыт будет включать более 1 пула серверов приложений. Допустим, вы просматриваете элемент (ViewAppServerPool), а затем переходите к ставке на элемент (BidAppServerPool). Все эти серверы приложений должны были бы синхронизироваться, что требует распределенного кэша для управления всем. Но их масштаб настолько велик, что ни эффективный распределенный кеш не может им эффективно управлять, ни отдельный сервер базы данных. Это означает, что они должны разделять уровень данных, и любая реализация кэша должна быть разбита на одни и те же границы.

Это похоже на то, что я написал выше, только что переместилось вниз по слою. Вместо того, чтобы веб-сервер определял, к какому серверу приложений обращаться, сервер приложений определяет, к какой базе данных обращаться. Только в случае с Ebay он мог поразить более 20 серверов баз данных из-за их стратегии разделения. Но, опять же, у уровня без состояния есть какое-то правило (правила), которые он использует для связи с состоянием с состоянием. Однако правила Ebay немного сложнее, чем простое правило «Пользователь1 на сервере10», которое я объяснял выше.