В 2018 году highload-проектами уже никого не удивишь. Тому способствует как и новомодная микросервисная архитектура, так и ставшая уже классикой SOA (Service-oriented Architecture), пришедшие на смену монолитным приложениям. Удобство разработки, мониторинга, администрирования и масштабирования современного ПО создают многократные оверхеды на все типы ресурсов: процессор, оперативную память, дисковую подсистему и сеть, что многократно увеличивает требования к аппаратным ресурсам.
При расточительном использовании ресурсов стоимость инфраструктуры проекта может вырасти в десятки раз и продолжать расти в геометрической прогрессии, особенно при использовании не оптимальных алгоритмов. Однако, существуют подходы, которые позволят сильно ускорить обработку запроса приложением и увеличить количество запросов обрабатываемых одной единицей железа — это и называется искусством highload-разбработки.
Что такое highload сервис?
Например, рассмотрим сервис для авторизации пользователей и проверки прав доступа.
В монолитном приложении задачу проверки существования пользователя и его прав доступа обычно выделяют в отдельный модуль или компонент системы, который выполняет прямые запросы к базе данных или к кэширующему серверу. Однако, создание под задачи авторизации отдельного микро-сервиса сразу увеличивает нагрузку за счёт появления дополнительного оверхеда на передачу данных по сети и конвертирования данных из одного формата в другой.
Но зачем тогда выносить всё это в отдельный сервис, если это снижает производительность системы? Однозначно стоит, такой подход сильно упрощает задачи масштабирования системы. Разработчикам нужно будет масштабировать только конкретные сервисы испытывающие большую нагрузку, а не всё приложение целиком.
Когда проект считается высоконагруженным?
Вопрос который волнует многих разработчиков и администраторов —когда заканчивается «обычный» проект и начинается highload? Как только сайт или сервис перестаёт справляться с возрастающей нагрузкой — то перед разработчиками проекта встают задачи по выдерживанию высокой нагрузки.
Это может быть как небольшой сайт на самом бюджетном виртуальном сервере с 256 Мб оперативной памяти и 10 запросами в минуту, так и жирный сервис крутящийся на полноценном сервере с 256 Гб оперативки и обрабатывающий сотни тысяч запросов в минуту. И в том и другом случае нужно начинать предпринимать действия по ускорению своего программного продукта. Медленные сайты и сервисы никому уже не нужны!
Будут отличаться лишь методы оптимизации и масштабирования. Если в случае самого слабого тарифа хостинга проблема решится переходом на следующий тарифный план, то в случае топового выделенного сервера придётся покупать ещё одну дорогущую железку, либо заниматься низкоуровневым тюнингом и оптимизациями либо вообще переписыванием проекта на более быстром языке программирования.
Ещё один критерий, по которому можно отличить highload-проекты — это стоимость минуты простоя системы. Например, цена минуты простоя крупного федерального интернет-магазина может составлять сотни тысяч рублей, т.к. покупатели вряд ли будут ждать, пока магазин снова заработает, гораздо проще сделать заказ в другом магазине. А если при этом покупатель перешёл с платной рекламы, а сайт недоступен — то потраченные впустую рекламные бюджеты становятся прямым убытком.
Итак, какой же сайт считается высоконагруженным? Например тот, в котором внедрение нового не оптимизированного функционала потребует удвоить количество серверов для работы сайта, тем самым увеличив издержки. Либо обратная ситуация, когда оптимизация какого-либо компонента системы позволит в разы сократить нагрузку на железо, что позволит снизить количество серверов, тем самым сэкономить бюджет.
С другой стороны какой-нибудь сервис прогноза погоды имеет гораздо меньшую стоимость простоя. Вряд ли из-за недоступности погодного виджета или показа не самых актуальных данных из кэша какая-либо компания понесёт какие-то значительные убытки. Даже если такой сервис имеет десятки и сотни тысяч обращений в секунду. Будет ли такой сервис считаться высоконагруженным а его разработчик получать highload-зарплату?
Стоит ли заранее готовиться к high load?
Под определение хайлоад могут подпадать совершенно разные проекты с нагрузкой различающейся на порядки. Даже схожие сервисы в рамках различных компаний в одном случае будут высоконагруженным, а в другом — нет. Угадать заранее попадёт тот или иной проект в зал славы highload невозможно, как бы того не хотели заказчики, инвесторы и разработчики.
Многие работодатели, а точнее технические директора, архитекторы и тимлиды хотят набрать в свои команды самых лучших специалистов за минимальные деньги. И зачастую одним из важных требований в своих вакансиях указывают опыт работы с высокими нагрузками от 10 000 запросов в минуту. Но будет ли такому специалисту интересно работать над таким проектом, особенно если его судьба ещё не ясна, а высокие нагрузки ещё далеко впереди?
Плох тот руководитель, который не верит в успех своего проекта и не грезит высокой посещаемостью с не менее высокой прибылью. Однако, заниматься всевозможными оптимизациями и написанием идеального и в то же время максимально быстрого кода может быть пустой тратой времени. Ведь не известно как отреагируют потребители на ваш проект. История знает много случаев, когда самые навороченные и оптимизированные проекты не вызывали никакого интереса у сообщества и закрывались с миллионными убытками.
Сколько программистов работает над высоконагруженным проектом?
Как это ни странно, но существует множество высоконагруженных сервисов над которыми работает один единственный highload- разработчик. Например, какое-либо API может быть весьма простым по функционалу и не требовать большого количества времени на разработку и поддержку. Также какой-нибудь погодный виджет или счётчик посещаемости установленный на десятки тысяч сайтов весьма прост в реализации и мог быть разработан за пару дней. Что не мешает ему получать сотни тысяч запросов в секунду на несколько десятков серверов.
Highload-проект это не обязательно большая и сложная система с сотней разработчиков, а скорее даже наоборот.
Примеры хайлоад-проектов
Примеры сервисов и приложений которые могут испытывать высокие нагрузки:
- сервис для регистрации и авторизации пользователей
- автодополнение (autocomplete/suggestion) запросов в поисковой строке
- сервис сокращения ссылок
- сервис поиска по каталогу
- сервис показа рекламных материалов
Сколько получают highload разработчики?
Гораздо большие зарплаты в высоконагруженных проектах у системных администраторов и DevOps, технических директоров и архитекторов, а также у всевозможных менеджеров. Средний highload-разработчик имеет зарплату на 30-40% ниже, чем у средних fullstack, frontend и blockchain разработчиков. На 2018 год диапазон на который может рассчитывать разработчик высоконагруженных систем составляет от 120 до 180 тысяч белых рублей в месяц после вычета всех налогов. В сером сегменте дела чуть получше и особо удачливые разработчики могут получать до 260 000 рублей ежемесячно.
Как правило, чем крупнее компания, тем хуже у них условия работы. А за недополученные 30 000 рублей ежемесячно, а это 360 000 рублей в год компания вам предложит бесплатные фрукты или что-то подобное, что никак того не стоит.
Что нужно знать хайлоад-разработчику?
Как правило, разработчики высоко нагруженных систем занимаются разработкой серверной части, т.е. backend и сильно реже занимаются fullstack-разработкой. При это далеко не каждый серверный backend-разработчик занимается проектами с высокой нагрузкой. В разных компаниях требования к highload-разработчикам могут различаться кардинально. Однако, есть некоторые вещи, которые пригодятся почти в каждом высоконагруженном проекте.
В каких компаниях есть highload вакансии?
Среди московских компаний это конечно же: Badoo, Mamba, Avito, 8bit group, Yandex и Mail.Ru Group. А жители Санкт-Петербурга или желающие туда переехать могут обратить внимание на: Vkontakte, IQ Option и Embria. Конечно же существует огромное количество более мелких и менее известных компаний, но вакансии у них открыты не всегда.
Стек технологий в highload разработке
В высоконагруженных проектах применяется широкий стек технологий. В принципе он ничем не ограничен, но чаще всего это сервера на базе Linux, а в качестве фронт-веб-сервера используется nginx. Далее идут приложения на языках PHP, Python или Go. Системы хранения данных в памяти типа Redis, Riak, Tarantool или Memcache. Ну и СУБД по типу MySQL (MariaDB) или Postgres. Отдельно стоить сказать о приложениях на Java, в которых веб-сервер и другие компоненты могут быть частью самого приложения.
Бывают ли высоконагруженные проекты на PHP и MySQL?
Бывают и их тысячи по всему миру! Из самых известных это социальные сети Facebook и VK. Также среди них Badoo, Mamba, Avito, ICQ. Однако, это не означает, что в проектах этих компаний используется только PHP. Правильнее будет сказать, что на PHP приходится не самая сильная нагрузка, а благодаря продуманной архитектуре и балансировки нагрузки пользователю комфортно работать с системой.
Ultralow latency highload — как новый тренд
Бывают ли системы, где борьба идёт за каждую микросекунду? Бывают, подробнее можно посмотреть видео про ультрахайлоад и сверхоперативную память.