company_banner

Балансировка 70 тысяч запросов в секунду на HighLoad++


    Библиотека докладов


    Это не просто статья — это целая библиотека докладов про внутреннее устройство тех или иных крупных и высоконагруженных проектов. Все эти доклады звучали на конференциях HighLoad++ и РИТ++ за последние несколько лет.



    И еще:





    Секция «Архитектуры»


    Ключевая секция конференции разработчиков высоконагруженных систем HighLoad++, которая пройдет уже через две недели в Москве, это, конечно, Архитектуры. Доклады в этой секции меняются — если три-четыре года назад мы слушали общие слова о том, сколько серверов в Фейсбуке и где хранятся файлы у ВКонтакте, то сейчас в Программу такие доклады уже не проходят. Сейчас время деталей, микросервисов, подробных разборов того или иного архитектурного паттерна.
     
    Итак, архитектурные паттерны. На этой конференции подробно разберем пару из них, и первый — это, конечно, микросервисы.
     
    Единое приложение строится как набор небольших микросервисов, каждый из которых работает в собственном процессе, максимально независим от других микросервисов, реализует, как правило, одну бизнес-функцию и коммуницирует с остальными, используя легковесные механизмы, тот же http.

    Антон Резников и Владимир Перепелица расскажут не только о микросервисной архитектуре Облака@Mail.ru, но и конкретной реализации паттерна на NoSQL-базе данных Tarantool. Да, Tarantool — это еще одна NoSQL база данных, но еще это полноценный сервер приложений. Приложений, расположенных рядом с данными!



    Денис Иванов (2Gis) продолжит тему в докладе «Путь от монолита на PHP к микросервисам на Scala». Так и хочется воскликнуть: «Денис, остановись, что ты делаешь, зачем?!». И Денис отвечает на этот вопрос просто — 6 нод с приложениями вместо 18. Ответ достойный, надеемся услышать на конференции детали.

    Еще один паттерн, часто используемый в высоконагруженных проектах — это очереди. Тему раскрывает Павел Филонов (Positive Technologies) в докладе «101 способ приготовления RabbitMQ и немного о pipeline-архитектуре».
    В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless, так и statefull фильтров.

    Доклад похож на учебный, но тема-то уж больно хороша!


    Следующий доклад о балансировке от Юрия Насретдинова из компании Badoo — серьезная заявка на победу. Пользуясь случаем, мы попробовали задать Юрию несколько вопросов, чтобы пролить свет на один из самых захватывающих докладов, ожидающихся на конференции:

    — Юра, как вы подошли к уровню нагрузки в 70к запросов в секунду?

    К такому уровню нагрузки мы подходили весьма плавно, в течение уже почти 10 лет. В последние годы у нас также начало сильно расти количество пользователей на мобильных устройствах, что тоже вызвало рост количества запросов в секунду — наше мобильное приложение отправляет больше мелких запросов на сервер, чем веб-сайт. Хотелось бы отметить, что 70к запросов в секунду приходится на PHP-FPM, общее число HTTP-запросов на наш сайт составляет до 250к в секунду.

    — Что, кроме яиц, нужно для того, чтобы держать такие нагрузки?

    В целом нет никакой проблемы с тем, чтобы обслуживать 250 000 HTTP-запросов в секунду. Вы можете обслуживать такую нагрузку с помощью банального nginx и DNS round-robin. Мы используем «хардварные» решения для обработки входящего трафика — GTM и LTM от компании F5. Они позволяют обрабатывать все запросы на одном IP-адресе, то есть без использования DNS round-robin. На входном маршрутизаторе задаются правила, по которым запросы попадают на тот или иной кластер, задаются веса машин при необходимости, и остальное делает за вас эта железка (или nginx, который мы используем для проксирования запросов на мобильный кластер).

    Грубо говоря, распределение запросов по серверам — это не архисложная задача, и для PHP масштабирование заключается просто в добавлении серверов в backend с соответствующими весами.

    Намного сложнее не просто держать такую нагрузку, но и создать архитектуру для хранения пользовательских данных, которая бы могла хранить и отдавать сотни терабайт и даже петабайты фотографий и текстовых данных. О нашей архитектуре было много докладов, например мастер-класс от Алексея Рыбака на DevConf в 2012 году или мой доклад про архитектуру хранения фотографий в 2015 году. К сожалению, кратко рассказать об архитектуре в рамках интервью не представляется возможным, поэтому я бы рекомендовал посмотреть на наши презентации для деталей.

    — Каким образом достигается подобная пропускная способность архитектуры, какие есть отдельные интересные места?

    Опять же – подобная пропускная способность не является чем-то выдающимся, и тот же LTM с нагрузкой справляется даже без дополнительных «подпорок» с нашей стороны.

    Если говорить про архитектуру хранения данных пользователей, то здесь всё немного интереснее. Мы храним данные каждого пользователя на одном сервере, то есть шардим данные по пользователям, а не по ID или другим синтетическим величинам. Это позволяет нам делать достаточно сложные выборки при работе с данными пользователей, использовать JOIN и сложные сортировки. При этом пользователи не «прибиваются гвоздями» к своему серверу, а могут перемещаться по кластеру при необходимости. Это достигается за счёт того, что мы храним «spot_id» и «place_id» пользователя (идентификаторы, из которых можно определить имя сервера и имя таблицы на сервере) в центральном сервисе, называемом «authorizer». К этому сервису делаются запросы каждый раз, когда нужно установить соединение с базой данных пользователя. На сервис приходится около 40к запросов на чтение в секунду, и обслуживаются они по протоколу HandlerSocket одним инстансом MySQL. Этот сервис является, пожалуй, самым высоконагруженным внутренним сервисом, который обслуживает один сервер, и в данный момент у нас есть запас по производительности минимум в 2 раза. Даже если мы упремся в масштабируемость MySQL + handlersocket, всегда можно попробовать, к примеру, Tarantool для этой задачи — этот демон может выдавать 100к запросов/сек на _ядро_ (ср. с 100к запросов на _сервер_ в случае с MySQL+handlersocket).

    – И пару слов о твоём докладе на HighLoad++

    В докладе я расскажу о системе, которая выставляет веса для серверов на наших балансировщиках (LTM для веб-нагрузки и nginx для мобильного кластера). Система нужна для того, чтобы достичь намного более равномерного распределения нагрузки по кластеру, чем получается сделать «руками». С ростом нагрузки и количества запросов нам начало требоваться всё большее число серверов, и помимо добавления новых серверов мы решили потратить некоторые усилия на то, чтобы обеспечить более равномерную загрузку существующих. До того, как мы начали что-то делать, разброс между CPU usage на самом нагруженном сервере и на самом свободном составлял около 20-30%, а после — всего 2,5%. На наших объемах это позволило нам сэкономить до сотни серверов, и оно, безусловно, стоило того.

    Я расскажу о существующих подходах к автоматическому распределению весов для машин, о том, какие подходы мы попробовали, и на чём в результате установились. Написанное нами решение будет выложено в open-source, чтобы вы могли использовать его в своем проекте при необходимости.



    И напоследок, классический доклад об архитектуре крупного проекта, правда очень крупного, самого крупного сервиса объявлений в Рунете — Avito.ru. Михаил Тюрин, главный системный архитектор Avito, расскажет о том, «Где живут ваши объявления?»
    Одинаковых высоконагруженных проектов не бывает, дьявол кроется в мелочах, в нюансах работы той или иной функции, хранения и использования того или иного блока данных. Именно поэтому свой курс лекций о высоконагруженных системах в МФТИ я начинаю с рассказа и демонстрации важности аналитической части работы над высоконагруженных проектом. И именно поэтому я рекомендую сходить на доклад Михаила — крупнейший классифайд в Европе, 600 миллионов объявлений – как это все работает?
    До встречи на конференции!

    P.S. Учебник


    Кстати, вот уже несколько недель мы обкатываем новый учебник по проектированию высоконагруженных систем. Это серия писем, построенных на лекциях лучших в России специалистов. Где-то мы расшифровываем лекции, где-то предоставляем видео, но важно следующее – каждый из материалов перепроверен нами, на нём стоит печать качества конференции HighLoad++.

    Если интересно – подписывайтесь, это бесплатно: http://highload.guide/
    И последнее: Для пользователей «Хабрахабра» конференция предлагает специальную скидку в 15%, всё что нужно сделать — это воспользоваться кодом "IAmHabr" при бронировании билетов.
    Конференции Олега Бунина (Онтико)
    503,00
    Конференции Олега Бунина
    Поделиться публикацией

    Похожие публикации

    Комментарии 11

      +3
      Судя по докладам, основная проблема высоких нагрузок только у всяких баннеро-крутилок и баннерных сетей.
        +1
        Может быть они просто рассказывают об этом охотнее остальных?
          +2
          Это не должно вас удивлять, как мне кажется. На сервисы для баннерной (и любой другой) рекламы обычно приходится на порядок больше запросов, чем на «веб»-бэкенд, поскольку на одной странице может быть легко штук 10 разного рода баннеров, таргетированных объявлений и прочего.
          То есть, если наши 70к RPS умножить на 10, то получится, что системе рекламы только для нашего сайта пришлось бы обслуживать 700к запросов в секунду. Такой поток запросов уже сложно обрабатывать одной железкой, придется в любом случае придумывать какие-то более сложные схемы для отдачи содержимого. Если на это накладывается необходимость отдавать всё с одного и того же домена (как это часто бывает с баннерокрутилками), то проблема становится ещё интересней.
            +1
            Не, просто подборка докладов такая. Темы разные, проблемы высоких нагрузок есть у всех.
              +1
              Да просто когда материалы собираю (особенно в контексте http-серверов), практически всегда на упоминание баннерных сетей попадаю :)
                0
                А можете поделиться накопленным материалом по баннерым сетям?
                У меня тут недавно интересовались.
                  0
                  Конкретно по баннерным ничего нет — мне нужно для своего микро сервера для http live стриминга. Просто упоминания встречались, например в интервью с автором nxweb. Если вообще сервера интересны, то можно глянуть на haywire (https://github.com/kellabyte/Haywire), но это больше исследовательский проект для выжимания максимальной производительности. Про архитектуру же сетей в целом ничего не скажу — вне моей области интересов.

                  В любом случае, структурированной информации нет. Потому и написал: «когда собираю» — уже раза три приходилось делать :)
            0
            Чувствую себя неудачником со своими 11к рек-сек.
              +1
              11rps это очень хорошо! Не стоит :)
              Вполне можно на конфу подаваться.
                +2
                По ссылке попал в горячо любимую заглушку от рт и ркн. Включил проксик, зашёл повторно и попал на заглушку
                с 500 ошибкой


                Я наверно 11001-ый? Тоже почувствовал себя неудачником ))
                  0
                  =). Ресурс не мой. Вот ссылка на гугл доки этой статьи. Форматинг не очень, но лучше чем ничего.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое