[Разработка веб-сайтов, Поисковые технологии, Серверная оптимизация, Серверное администрирование] Как не держать лишнее железо и справляться с ростом нагрузки: внедрение graceful degradation в Яндекс.Маркете
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, меня зовут Евгений. Я разрабатываю инфраструктуру поиска Яндекс.Маркета. Хочу рассказать, как graceful degradation помогает нам обрабатывать больше запросов, чем физически могут выдержать наши сервера, и что происходит с поиском в Маркете, если один из дата-центров отключается. ПроблемаВсе критичные сервисы в Яндексе должны переживать отключение одного из дата-центров (ДЦ), поэтому обычно они размещаются минимум в трёх ДЦ. 
Обычное состояниеНо когда все ДЦ работают, каждый из них оказывается задействован лишь на 60%. Ещё 10% резервируются для экспериментов и непредвиденного роста, а оставшиеся 30% используются только в случае, если один из ДЦ отключается, и нужно перераспределить запросы. 
ДЦ 2 отключёнЕсли сервис работает на сотнях серверов, 30% — это огромное количество железа. А поскольку отключаются ДЦ очень редко, резервные мощности почти всегда простаивают. Нам хотелось бы меньше греть воздух, ведь если сократить количество железа в каждом ДЦ хотя бы на 10%, речь уже шла бы о внушительных суммах. При этом, если просто вытащить часть железа, а затем при пиковой нагрузке какой-то из ДЦ отключится, оставшиеся мощности могут не справиться. Резко вырастет время ответа пользователю, а некоторые запросы будут вообще оставаться без ответа.
ДЦ 1 и ДЦ 3 не справляются с нагрузкойПрименяем graceful degradation Graceful degradation или изящная деградация — это подход к построению систем, при котором система продолжает выполнять свою основную функцию, даже если отдельные её элементы вышли из строя.Мой коллега из Яндекс.Такси уже рассказывал про graceful degradation в случае, когда ломается часть сервиса. Мы же применили этот подход на бэкендах для ситуации, когда у нас отключается значительное количество серверов. Нашей целью было сделать так, чтобы сервис продолжал работать полностью, но нагрузка на него уменьшалась бы, а пользователи при этом не замечали бы разницы. Мы хотели научить наш поисковый сервис понижать среднюю нагрузку от одного запроса, что позволило бы обрабатывать большее количество запросов на меньшем количестве железа. Чтобы запустить graceful degradation, нам надо было решить две задачи:
- Разработать механизм уменьшения нагрузки.
- Сделать автоматизацию включения механизма.
Механизм уменьшения нагрузкиУменьшить нагрузку можно по-разному. Один из вариантов — отвечать ошибкой на некоторые запросы. Но тогда надо понять, на что можно так отвечать, а на что нет. То есть нужен какой-то параметр «важность», которого мы не знаем. Если спросить у наших клиентов, что важно, они ответят, что важны все запросы, и ничего нельзя отбрасывать. Поэтому этот путь нам не подошёл.Другой вариант — использовать облегчённый алгоритм ранжирования. Минус в том, что это долго и сложно — новый алгоритм надо обучить и потом постоянно переобучать. Кроме того, состояние нашей системы может быть только «вкл.» или «выкл.», а нам хотелось бы иметь механизм плавного уменьшения нагрузки.Таким образом, мы выбрали третий вариант — снижать качество. Основное преимущество этого подхода — возможность уменьшать нагрузку на 5%, 10% и так далее.Допустим, вы ищете себе новый телефон и заходите в категорию «Смартфоны» на Яндекс.Маркете. Я уже подробно описывал, как работает наш поиск: запрос отправляется во фронтенд, надо показать пользователю 48 лучших предложений из категории с телефонами для конкретного региона. Фронтенд делает свой запрос в поисковый бэкенд.Бэкенд получает запрос и раcпределяет его на 8 серверов с шардами. В шардах хранятся предложения от магазинов.
Общая схема обработки поискового запросаНа каждом шарде поиск проходит несколько стадий. На стадии фильтрации ищется примерно 50 000 предложений, это число зависит от категории. На этапе ранжирования для каждого предложения вычисляется релевантность, учитывается цена, рейтинг товара, рейтинг магазина и ещё более 2000 факторов. ML по факторам вычисляет вес каждого предложения. Затем берётся только 48 лучших. Meta Search получает эти 48 предложений с каждого шарда, то есть всего 48*8=384 предложения. Предложения снова ранжируются, опять берётся 48 лучших. Последние 48 уже показываются пользователю. То есть чтобы показать нашим пользователям 48 телефонов, мы обрабатываем 400 000 предложений. 
Количество обрабатываемых документов без graceful degradationВ случае с graceful degradation, когда надо уменьшить нагрузку, мы можем скомандовать: теперь обрабатывай 95% документов, а теперь 90% или 80%. Если обрабатывать 95%, то есть 400 000*0.95=380 000 документов, то из них всё равно выбираются 48 лучших предложений для выдачи. И в среднем только 2 предложения будут отличаться от изначальной выдачи без снижения качества. При таком маленьком изменении большинство пользователей даже не заметят разницы.
Количество обрабатываемых документов при включении механизма уменьшения нагрузкиАвтоматизация включения механизмаАвтоматизация работает за счёт постоянного мониторинга загрузки CPU. Если нагрузка становится выше 90%, автоматика начинает снижать качество. На 90% снижение небольшое, но если нагрузка продолжает расти, процент деградации повышается линейно и доходит до максимума при 100% загрузки CPU. Такой подход позволяет снижать качество минимально.Общий алгоритм выглядит так:При выключении ДЦ: балансеры перераспределяют запросы в оставшиеся ДЦ => нагрузка на CPU повышается => при превышении порогового значения происходит снижение качества по заданной формуле.При включении ДЦ: балансеры перераспределяют запросы на все ДЦ => нагрузка на CPU снижается => понижение качества прекращается.
Повышение нагрузки при выключении ДЦ. Линии на верхнем графике показывают загрузку CPU в отдельных ДЦ. Нагрузка выросла с 82% до 98%. Нижний график показывает процент срезанных документов. ВнедрениеДля внедрения мы провели несколько экспериментов и понижали качество на небольшом проценте пользователей. В течение недели мы постоянно отслеживали уменьшение нагрузки и одновременно количество переходов на магазины-партнёры. Имея на руках цифры, мы договорились с бизнесом на максимальное снижение кликов в 1% при снижении качества. Исходя из этого мы посчитали, сколько серверов можем отдать другим проектам или выключить для резерва. У нас получилось 15% всех мощностей поиска.В конце, когда всё было готово, мы провели эксперимент с отключением дата-центра, чтобы убедиться, что всё работает как надо.ВыводыGraceful degradation — хороший способ не держать в резерве много железа на случай большой аварии вроде отключения дата-центра, а также для кратковременных повышений нагрузки, например, нашествия поисковых ботов.
===========
Источник:
habr.com
===========
Похожие новости:
- [Платежные системы] ЦБ ограничил работу платежного сервиса Сбербанка «ЮMoney» за работу с онлайн-казино
- [Разработка веб-сайтов, PHP, Программирование] Это не легаси-код, это PHP (перевод)
- [Информационная безопасность, IT-стандарты] Как и зачем проходить сертификацию AICPA SOC 2 и 3. Опыт Яндекс.Паспорта
- [Разработка веб-сайтов, JavaScript, Программирование] Будущее JavaScript: декораторы
- [Разработка под iOS, C++, Xcode, Swift] Создаем Swift Package на основе C++ библиотеки (перевод)
- [Разработка веб-сайтов, JavaScript, Программирование, GitHub, Планшеты] Мой опыт разработки с использованием андроид устройства
- [Разработка веб-сайтов, JavaScript, Angular, TypeScript] Taiga UI — библиотека компонентов под Angular, которую вам стоит попробовать
- [Интерфейсы, ReactJS, TypeScript] Код на React и TypeScript, который работает быстро. Доклад Яндекса
- [Системное администрирование, Серверное администрирование, Хранилища данных, DevOps] Эксплуатация Ceph: что такое Scrub и как им управлять
- [Java, C++, Разработка под Android] Android interop with SWIG (a guide). From simple to weird. Part 2 — weird
Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_poiskovye_tehnologii (Поисковые технологии), #_servernaja_optimizatsija (Серверная оптимизация), #_servernoe_administrirovanie (Серверное администрирование), #_jandeks.market (яндекс.маркет), #_jandeks (яндекс), #_highload, #_balansirovka_nagruzki (балансировка нагрузки), #_poisk (поиск), #_graceful_degradation, #_komanda_jandeks.marketa (команда яндекс.маркета), #_c++, #_bekend (бэкенд), #_blog_kompanii_jandeks (
Блог компании Яндекс
), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_poiskovye_tehnologii (
Поисковые технологии
), #_servernaja_optimizatsija (
Серверная оптимизация
), #_servernoe_administrirovanie (
Серверное администрирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 05:49
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Привет, меня зовут Евгений. Я разрабатываю инфраструктуру поиска Яндекс.Маркета. Хочу рассказать, как graceful degradation помогает нам обрабатывать больше запросов, чем физически могут выдержать наши сервера, и что происходит с поиском в Маркете, если один из дата-центров отключается. ПроблемаВсе критичные сервисы в Яндексе должны переживать отключение одного из дата-центров (ДЦ), поэтому обычно они размещаются минимум в трёх ДЦ.  Обычное состояниеНо когда все ДЦ работают, каждый из них оказывается задействован лишь на 60%. Ещё 10% резервируются для экспериментов и непредвиденного роста, а оставшиеся 30% используются только в случае, если один из ДЦ отключается, и нужно перераспределить запросы.  ДЦ 2 отключёнЕсли сервис работает на сотнях серверов, 30% — это огромное количество железа. А поскольку отключаются ДЦ очень редко, резервные мощности почти всегда простаивают. Нам хотелось бы меньше греть воздух, ведь если сократить количество железа в каждом ДЦ хотя бы на 10%, речь уже шла бы о внушительных суммах. При этом, если просто вытащить часть железа, а затем при пиковой нагрузке какой-то из ДЦ отключится, оставшиеся мощности могут не справиться. Резко вырастет время ответа пользователю, а некоторые запросы будут вообще оставаться без ответа.  ДЦ 1 и ДЦ 3 не справляются с нагрузкойПрименяем graceful degradation Graceful degradation или изящная деградация — это подход к построению систем, при котором система продолжает выполнять свою основную функцию, даже если отдельные её элементы вышли из строя.Мой коллега из Яндекс.Такси уже рассказывал про graceful degradation в случае, когда ломается часть сервиса. Мы же применили этот подход на бэкендах для ситуации, когда у нас отключается значительное количество серверов. Нашей целью было сделать так, чтобы сервис продолжал работать полностью, но нагрузка на него уменьшалась бы, а пользователи при этом не замечали бы разницы. Мы хотели научить наш поисковый сервис понижать среднюю нагрузку от одного запроса, что позволило бы обрабатывать большее количество запросов на меньшем количестве железа. Чтобы запустить graceful degradation, нам надо было решить две задачи:
 Общая схема обработки поискового запросаНа каждом шарде поиск проходит несколько стадий. На стадии фильтрации ищется примерно 50 000 предложений, это число зависит от категории. На этапе ранжирования для каждого предложения вычисляется релевантность, учитывается цена, рейтинг товара, рейтинг магазина и ещё более 2000 факторов. ML по факторам вычисляет вес каждого предложения. Затем берётся только 48 лучших. Meta Search получает эти 48 предложений с каждого шарда, то есть всего 48*8=384 предложения. Предложения снова ранжируются, опять берётся 48 лучших. Последние 48 уже показываются пользователю. То есть чтобы показать нашим пользователям 48 телефонов, мы обрабатываем 400 000 предложений.  Количество обрабатываемых документов без graceful degradationВ случае с graceful degradation, когда надо уменьшить нагрузку, мы можем скомандовать: теперь обрабатывай 95% документов, а теперь 90% или 80%. Если обрабатывать 95%, то есть 400 000*0.95=380 000 документов, то из них всё равно выбираются 48 лучших предложений для выдачи. И в среднем только 2 предложения будут отличаться от изначальной выдачи без снижения качества. При таком маленьком изменении большинство пользователей даже не заметят разницы.  Количество обрабатываемых документов при включении механизма уменьшения нагрузкиАвтоматизация включения механизмаАвтоматизация работает за счёт постоянного мониторинга загрузки CPU. Если нагрузка становится выше 90%, автоматика начинает снижать качество. На 90% снижение небольшое, но если нагрузка продолжает расти, процент деградации повышается линейно и доходит до максимума при 100% загрузки CPU. Такой подход позволяет снижать качество минимально.Общий алгоритм выглядит так:При выключении ДЦ: балансеры перераспределяют запросы в оставшиеся ДЦ => нагрузка на CPU повышается => при превышении порогового значения происходит снижение качества по заданной формуле.При включении ДЦ: балансеры перераспределяют запросы на все ДЦ => нагрузка на CPU снижается => понижение качества прекращается.  Повышение нагрузки при выключении ДЦ. Линии на верхнем графике показывают загрузку CPU в отдельных ДЦ. Нагрузка выросла с 82% до 98%. Нижний график показывает процент срезанных документов. ВнедрениеДля внедрения мы провели несколько экспериментов и понижали качество на небольшом проценте пользователей. В течение недели мы постоянно отслеживали уменьшение нагрузки и одновременно количество переходов на магазины-партнёры. Имея на руках цифры, мы договорились с бизнесом на максимальное снижение кликов в 1% при снижении качества. Исходя из этого мы посчитали, сколько серверов можем отдать другим проектам или выключить для резерва. У нас получилось 15% всех мощностей поиска.В конце, когда всё было готово, мы провели эксперимент с отключением дата-центра, чтобы убедиться, что всё работает как надо.ВыводыGraceful degradation — хороший способ не держать в резерве много железа на случай большой аварии вроде отключения дата-центра, а также для кратковременных повышений нагрузки, например, нашествия поисковых ботов. =========== Источник: habr.com =========== Похожие новости:
Блог компании Яндекс ), #_razrabotka_vebsajtov ( Разработка веб-сайтов ), #_poiskovye_tehnologii ( Поисковые технологии ), #_servernaja_optimizatsija ( Серверная оптимизация ), #_servernoe_administrirovanie ( Серверное администрирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 05:49
Часовой пояс: UTC + 5