Балансировка 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" при бронировании билетов.
