Карьера в хайлоад-проекте: к чему готовиться - I?

Что такое “хайлоад-проект” для инженера, например, бекендера? Каждый раз, отвечая на подобный вопрос, вспоминаю расхожую фразу о том, что хайлоада не существует. Что за бред, как так? - спросите вы. Поясняю.

Во-первых, простите за занудство, в англоязычном мире просто не говорят “highload“, наиболее близкий термин – “large scale”. Термин “хайлоад” - русское изобретение, полагаю, это придумали Олег Бунин и Павел Рогожин, когда делали первую конференцию по разработке высоко-нагруженных систем, если не ошибаюсь, в 2007-м году. Сделали крутое дело, название отличное, прижилось, но для английского уха это звучит как нечто, простите, на наркоманском слэнге: high и loaded - это всё натурально “under the influence”, “под воздействием веществ”.

Во-вторых, хайлоад начинался с треда “как писать сервера” в RU.UNIX.PROG и веб-страницы “C10K (10000 connections) Problem” от Dan Kegel, посвященной проблеме обработки десяти тысяч одновременных соединений одним сервером. Поэтому один из моих приятелей любит говорить, что хайлоад начинается с 10K RPS (десять тысяч запросов в секунду на ноду). Но сейчас даже в очень многих крупных проектах одна нода держит тысячи или вовсе сотни RPS, и виной всему сложная, нещадно сжирающая процессор бизнес-логика, крайне редко позволяющая отдать больше сотни запросов в секунду с одного ядра. Масла в огонь подливает повальное использование скриптовых языков без JIT, но это отдельный разговор (мы их любим не только за это). А, ну и Постгрес до сих пор под каждое активное соединение использует процесс - полный хайлоад, конечно.

Наконец, в-третьих, нет какого-то отдельного “хайлоад-знания”: есть область знаний на стыке прикладного и системного программирования, системного администрирования, и всяких подобных тем - производительности, масштабирования, надежности. Все эти темы объединяет одно: это всё погружение под капот, в направлении, вообще говоря противоположном тому, куда обычно начинает развиваться программист, приобретая опыт (паттерны, фреймворки и тд).

Так вот главное, к чему вам нужно готовиться, если вы переходите в хайлоад-проект – это быть готовым погружаться “под капот”. Поменьше думать про “код”, и больше - про сервисы и данные, как и в каком количестве они “едут” между вашими компонентами. Надо сказать, что хотят этим заниматься не только лишь все. Современное прикладное программирование строится вокруг миллиона абстракций, которые скрывают от нас детали. Сколько занимает времени то или иное действие, сколько байтов куда поехало, и в какой момент, где и почему это всё начнет тормозить? Наши фреймворки и инструменты не только не дают простых способов ответить на эти вопросы, они наоборот оборачивают наши проекты в миллион одёжек, абстракций, чтобы наш код был более “чистым”, “выразительным”, порой приводя к феерически неэффективному использованию ресурсов, а наши поделия - к тормозам даже под минимальными нагрузками.

(продолжение следует)