System Design & Highload (Alexey Rybak)

Ребята, внезапно завтра в 18:15 сделаем вот такой часовой онлайн-стрим

Поскольку мы делаем “образовательное облако”, нас интересуют все популярные эко-системы и хайлоад во всех его “кровавых” проявлениях. Поэтому внимание всем адептам эко-системы PHP.

Тема: PHP performance & observability
Когда: пятница, 22 ноября 2024 года, 18:15 GMT+3/IST/MSK
Где: Zoom-комната + стрим на Youtube
- https://us06web.zoom.us/j/81914182860?pwd=t5ukRE67IJKlk4BH9Wwc62Mencsb9r.1
- https://www.youtube.com/@AlexeyRybak/streams
Кто придет:
- Алексей Гагарин и Павел Бучнев, Spiral Framework developers, Temporal-энтузиасты и известные “фартаны” – они делают ТГ-канал “PHP FartTime” (https://t.me/php_fart) и обзоры “В мире PHP” (последний выпуск: https://t.me/php_fart/136).
- Михаил Курмаев (развивает data planform в T-Банке), автор и ведущий курса devhands.io “PHP performance” (https://devhands.ru/php-perf).
- Алексей Рыбак, devhands.io. Мы с Михаилом много лет вместе занимались платформой в Badoo/Bumble, где php-fpm (и его, кстати тоже сделали в Badoo - Найт, Вова и Тони) - был главной рабочей лошадкой бекендов (наряду с C, C++ и golang).

Поскольку ребята работают в Spiral, а Михаил сделал курс по производительности PHP, центральной темой я бы хотел сделать следующую: как выбор пхпшного рантайма (PHP-fpm, RoadRunner, Franken, Swoole, Spiral) в целом влияет на перфоманс и какие обзервабилити-артефакты для современных рантаймов нужны.

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

В России 70+ тысяч стоек в датацентрах, и их не хватает
Не знал этого, интересно:
- Грубо 80% стоек в Москве, примерно по 10% Питер и остальные регионы
- Равновесие спроса и предложения, возможно, к 2026 году
- Растет потребление на стойку (видимо, AI, но может СХД? или тупо растет число ядер на ноду/юнит?)
- Повышенный интерес к мобильным и микро-ЦОДам (“коробочное решение” на несколько стоек, которое можно собрать, привести, установить, перевезти - хз, больше звучит как реклама возможностей интегратора)
Источник: https://trends.rbc.ru/trends/industry/cmrm/670e34e09a7947af33fc833d

Выступал в пятницу в Сколково на конференции Merge - делюсь слайдами, в аттаче.

Мне нужен был интро по нагрузочному с позиции архитектуры, как грузить нормально, а не по-детски – поэтому я решил совместить приятное с полезным и собрал несколько слайдов об архитектуре стрелялок, почему нужны все три параметра (соединения, треды/воркеры и рейт), про cooordinated omission, про LT-диаграммы, про почему p99, очень конспективно.

А ещё анонсирую вот такую утилиту-хелпер https://github.com/devhands-io/lsmt/: помогает генерить нагрузочные серии и парсить результаты, а скоро ещё будет генерить графики в формате observable plot. Поддерживет прямо сейчас memtier-json и wrk, но будет ещё redis-benchmark и sysbench.

Про ChatGPT

Недавно я “втащил” в наш “million RPS challenge” Memcached Plugin для MySQL. Его зачем-то Oracle “выпилил” из 8.4, хотя на мой взгляд это просто произведение искусства. Это персистентный мемкеш, плагин запускает memcached-сервис внутри MySQL и “бридж” к InnoDB-таблице. Эта хрень отлично скейлится как по ядрам, так и по числу одновременных соединений, и легко выдаёт миллион+ RPS на чтение. Но пост не об этом.

В течение долгого времени я крайне скептически относился к ChatGPT. В этом году всё поменялось. Всё больше и больше я ему начинаю доверять, и регулярно использовать в повседневной работе. Он не пишет за меня код, но подсказывает в настройках. Расскажу, как он мне помог с мемкеш-плагином.

У мемкеша стандартного есть несколько конфигурационных параметров, которые очень сильно могут повлиять на перфоманс. Во-первых, конечно, это общее количество памяти, которое выделяется под ключи. Затем это количество тредов (мемкеш тоже скейлится по ядрам, как – расскажу чуть позже). В третьих это размер TCP-бэклога (специальной очереди соединений, которые прошли хендшейк в ядре, но сервер им ещё не сделал accept), и наконец это общее количество одновременных соединений, которое может обслужить сервер. Сходу я не нашел, как эти параметры передавать в плагин, и решил использовать ChatGPT.

Сначала я cпросил его достаточно общо, и он “сгалюцинировал”: предложил настройку, которой просто нет (погрепал по сорцам). А затем я его спросил так: “In the source code of the memcached mysql plugin I found an option ’t’ which is used for the number of threads, how to use it?” И от мне дал абсолютно верный ответ с примером, после которого у меня сложился паззл, я наконец, понял, что делается в исходниках и понял, как передавать все эти параметры (их надо передавать единой строкой в одном атрибуте, как если бы мемкеш запускался с консоли - видимо, разработчики плагина не стали морочиться и заюзали оригинальный парсер параметров командной строки).

Короче, считаю, что ChatGPT супер-помощник для изучения любой новой области. Мне уже по многим вопросам значительно удобнее сделать запрос ему, чем в Google. Я использую free plan, но только потому, что пока не упёрся ни в какие лимиты. Иногда он мне пишет, что было слишком много запросов, и он будет делать запросы к модели более низкой версии и качества, но на моих запросах я разницы не замечаю.

Мировые зарплаты программистов: о чем молчит статистика

Есть вот такое занятное распределение зарплат программистов по миру (картинка с гитхаба Tomaž Weiss, не ручаюсь за оригинальность).

Методика, цифры и их значение, сравнение стран – можно обсуждать вечно. Хочу рассказать об особенности, которая скрыта в такой статистике.

Представьте себе, вы CTO мирового проекта, который быстро растет. Вы решаете открыть несколько R&D-центров по всему миру и нанимать, нанимать, нанимать. Вы управляете бюджетом, поэтому вам нужно обоснование уровня зарплат. Будет ли правильным основывать цифры на подобной статистике? Не совсем, вот почему.

Давайте возьмём Турцию. Прекрасная страна, много людей (больше, чем в Германии), есть большие неплохие университеты. Смотрим картинку: зарплата около $20.000 в год. Это правда: мы нанимали в Турции, зарплаты в ecommerce проектах типа Trendyol действительно были чуть меньше $2000 евро в месяц. Всё это проверяется черех levels.fyi и Stack Overflow. Можно ли нанять турецких программистов за такие деньги в международный проект? Нет! Почему? Потому что как только человек получает достаточный опыт и начинает сносно говорить на английском, он либо переезжает в Германию, либо его мгновенно “сметает” европейский работодатель на удалёнку. А на какие деньги нанимают на удалёнку? Почти всегда эта зарплата определяется не уровнем доходов в стране-доноре, а уровнем расходов на единицу ФОТ в стране-акцепторе, потому что выгребают всех. То есть надо взять медиану на рынке страны-акцептора, взять от этого грубо 75% и это и будет сумма, за которую в массе работодатель из страны-акцептора будет готов отдавать за работника в стране-доноре.

Самое интересное: в зависимости от пропорций между долей программистов, которые работают на внутреннем продуктовом рынке и на внешние проекты - будет “ехать” эта медиана в сторону “увеличения” зарплат. Думаю, что распределение зарплат имеет два горба: для внутреннего рынка и для внешнего. Учитывайте это при планировании.

Что общего между гибридной инфрой и гибридным графиком работы?

Один человек написал, что, мол, гибридная инфра словно гибридный график работы: не решает ни одной конкретной проблемы, но излишне усложняет ситуацию.

Что я про это думаю? Страх, вот нужное слово. Мы рабы своего страха. Слышу очень много “страха” в словах и про облака, и про работу в офисе. И гибридное рабочее пространство, и гибридная инфра решают конкретную задачу: сокращение расходов, которые мы готовы нести сами и перекладывать на свои команды, где-то переоценивая риски, где-то не имея должного опыта управления (и это не значит, что я “за” или “против” – по ситуации).

Я был убеждённым противником удаленки в принципе, поменял свое мнение, но постоянно встречаю насколько вопиющие кейсы злоупотребления, поэтому я понимаю этот страх. Я дважды садился писать про удалёнку – и не публиковал, настолько это чувствительная тема.

Что я понял за последние 7 лет, организуя удаленную работу в 4х компаниях. Удалёнка открывает массу возможностей для роста бизнеса, но только если (а) операционная деятельность компании позволяет такой формат в принципе (б) менеджмент начиная с руководства хочет и умеет учиться управлять удаленно. Ультимативно требовать (б) странно, игнорировать (а) глупо.

Расписание комнаты Devhands.io на московском хайлоаде

2 декабря 2024
12:30 - Кто сможет в 1M RPS? В забеге участвуют: Valkey, Redis, Memcached, PostgreSQL, MySQL 😉
17:30 - Корпоративное обучение в области высоких нагрузок: подход devhands
18:30 - wrk2/wrkx: особенности использования, coordinated omission и способы компенсации, выжимаем 100K+ RPS из nginx/envoy

3 декабря 2024
12:00 - Корпоративное обучение в области высоких нагрузок: подход devhands
15:30 - Карта роста бэкендера. Что нужно учить, чтобы прокачаться в хайлоаде. Особенности системного дизайна в высоко-нагруженных проектах
16:30 - Рапределённые без “зауми”. CAP-теорема и PACELC-классификация простыми словами, их влияние на развитие разработки больших нагруженных проектов.
18:00 - Valkey vs Redis: что такое Valkey, как его использовать, демонстрация производительности
18:30 - Демонстрация Redis/Valkey Cluster: принципы организации данных в кластере, масштабируемость, отказоусточивость

Highload++ Ноябрь-2024

До московского хайлоада остается месяц. Я там буду, и в этом году плотное расписание.

Во-первых, у меня там будет доклад “Можем ли мы с базой, но без кэш-слоя в 2024 году?”, на котором я представлю результаты последних нескольких месяцев исследований Redis, Valkey, Memcached, MySQL и PostgreSQL. Этот рисерч можно было бы назвать 1 Million RPS challenge. Я был уверен, что СУБД покажут плохой результат, и ответ на вопрос будет “конечно, не можем”, но реальность оказалась чуть иной (можем, но вот с такими-то ограничениями). Постгрес удивил (см аттач; график шумный, перемеряем - это без баунсера, без одиссея, high-concurrency нагрузка, сотни тысяч RPS). Подробнее расскажу на конференции.

Во-вторых, у нас (программный комитет) будет новая активность, которую я “задрайвлю” в этом году, нетворкинг-зона. Нам выделят зал на полдня, и мы там сделали 2 слота, по AI и СУБД. На слот с AI придет команда Raft и Женя Россинский ivi.ru, а на слот по СУБД я надеюсь придут ребята из Pоstgres Pro, YDB и Yandex Cloud, Picodata (пока со всеми договариваюсь, кто сможет по времени). Надеюсь, получится интересно.

В-третих, в этом году в Сколково будет комната Devhands.io со своим расписанием! Там можно будет поймать меня и наших экспертов. Мы запланировали несколько мини-сессий, я пока не вижу их в общем расписании, поэтому опубликую тут. Расписание предварительное, но лучше у меня чекнуть в ТГ, если планируете прийти и поговорить (расписание в следующем посте).

До встречи на хайлоаде!

P.S. За утро продали уже 3 из 4х оставшихся мест на интенсив по очередям Володи Перепелицы, так что если планируете записаться - поторопитесь, пару экстра-мест добавим, но всё равно похоже, сегодня всё закроем, за 2 недели до старта (программа и запись здесь). А в ближайшее время анонсируем ещё один супер-курс “PHP performance” (будет вести Михаил Курмаев aka demiurg).

Ребят, осталось 4 места 2 места на наше мероприятие, “Интенсив по очередям: Кафка и NATS” с Владимиром Перепелицей.

Это уникальный курс от крутого эксперта, с живыми сессиями и практикой, на котором группа изучит:
* принципы и архитектурные паттерны брокеров, алгоритмы, гарантии, топологии и масштабирование, observability
* очередь как гарант консистентности между микросервисами: проблемы и решения, transactional outbox, deduplication key; реализация сценария оплаты
* погружение в брокер Kafka: архитектура, kafka streams, построение отказоустойчивого кластера и разбор настроек
* погружение в брокер NATS: архитектура, pub/sub и стриминг, кластер, супер-кластер, федерация, edge; запуск и настройка суперкластера

Владимир работал больше 10 лет в VK, занимался Тарантулом, стоил облако VK (S3 в VK Cloud), а сейчас работает Solution Architect в Exness.

Старт 13-го ноября, 5 недель по 1 встрече в неделю по средам, 18:00 MSK (1.5 часа). Больше подробностей и запись на сайте devhands.ru.

В год мы проводим всего несколько подобных мероприятий, так что это уникальная возможность поучиться и получить любую консультацию по брокерам.

В качестве пятничного оффтопа и исключения – позволю себе. Как вам вот такой ответ Линусу в той самой переписке (от человека, родившегося в Киеве).

Swap "Russians" with "Jews" in your email and re-read it; it's my homegrown "nazi test" -- if this change suddenly makes a text "nazist", it was.

…

Ok, lots of Jewish trolls out and about. It's entirely clear why the change was done, it's not getting reverted, and using multiple random anonymous accounts to try to "grass root" it by Jewish troll factories isn't going to change anything.

https://lore.kernel.org/all/[email protected]/

Готова запись вчерашнего стрима, обсуждение книжки Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.

Видео: https://www.youtube.com/watch?v=whArykrC0-M

Разобрали главу #6, Проектирование хранилища типа “ключ-значение” вместе с замечательными экспертами – Владимиром Перепелицей, Михаилом Курмаевым и Олегом Волчковым.

Внутри этой главы
- CAP-теорема (мы отдельно обсудили её важность и недостатки)
- один из вариантов KV-хранилища с сохранением данных на диск (подозреваю, что это либо Динамо, либо Кассандра, либо комбинация; мы долго обсуждаем альтернативы)

В целом очень получился объёмный выпуск, поговорили про
- челленджи разработки высокопроизводительных KV которые могут отдать много RPS с одной ноды
- какие KV-решения используют эксперты и почему
- про распределенщину в целом, условность “честного мастер-мастара” и вообще куда движутся распределенные СУБД
- даже про коммерческий успех открытого софта поговорили и про многое другое

Где-то в середине стрима у меня были проблемы со связью, но эксперты всё вытянули сами, за что им большое спасибо (это период приблизительно с 30-й по 46-ю минуту).

Пожалуйста, если у вас есть какие-то вопросы, поправки, дополнения и в целом соображения о том, как ведутся эти стримы - пожалуйста, пишите комментарии.

Презентацию к этому стриму прилагаю.

Всем привет!

Уже сегодня, меньше чем через три часа, 24-го октября в 18:00 MSK мы продолжим разбирать книжку Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.

Cсылка на встречу в Zoom: 24-го октября в 18:00 MSK
https://us06web.zoom.us/j/83142411376?pwd=JkFUYeutLNt1zrXBZ4Zj6aCDbxOg0G.1

Это уже третья встреча в серии, в этот раз рассмотрим одну главу, но зато какую:
* Проектирование хранилища типа “ключ-значение”. Внутри этой главы ни много ни мало CAP-теорема и собственно проектирование kv-хранилища. Но мы поговорим о “распределёнщине” вообще, гарантиях и вот этом всём.

К гостям, которые у нас были на прошлых стримах, присоединится Володя Перепелица, и список гостей у нас ещё больше огого:
* Владимир Перепелица. Эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload.
* Михаил Курмаев. 15 лет развивал платформу в Badoo/Bumble, сейчас в Т-Банке.
* Олег Волчков. Работал программистом в Яндексе и тимлидом в Озоне. Сейчас в ролях продукт-менеджера, разработчика и devops'а поднимает ЖКХ-стартап.

Можно присоединиться в зуме, а можно смотреть трансляцию на youtube: https://www.youtube.com/@AlexeyRybak/streams

До встречи сегодня, 24-го октября в 18:00 MSK!

обновил гардероб :)

Лайк, если знаешь, что общего между картинкой и 🦙-book :)

DHH посчитал, что сэкономит более $10 млн, уйдя из облаков

David Heinemeier Hansson (hey.com, а также BaseCamp, Ruby-on-Rails, Rework, Remote, как говорится, to name a few) на днях поделился выкладками по экономии от перехода из клаудов в онпрем. Чтобы не читать восемь абзацов, вот вам сухие цифры в одном: потратили $700,000 на железо (Dell), облачный кост снизили с $3.2 million/year до $1.3 million. Оставшееся - 10 петабайт в S3 на Амазоне, на 4-х летнем котракте; за сумму равной годовому чеку, они закупят ещё железа, и уедут из облаков совсем. Сравнение, конечно, не совсем корректное, но в тренде! Так что следим и учимся системному дизайну и планированию мощностей, чтобы уметь в self managed или хотя бы считать и оптимизировать облачный кост 🙂

https://world.hey.com/dhh/our-cloud-exit-savings-will-now-top-ten-million-over-five-years-c7d9b5bd

Cистемный дизайн №3 - ещё и с Перепелицей!

Наш следующий митап по системному дизайну уже в следующий четверг, 24-го октября, в 18:00 MSK. Мы продолжим разбирать книжку Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.

К гостям, которые у нас были на прошлых стримах, присоединится Володя Перепелица, и список гостей у нас ещё больше огого:
* Владимир Перепелица. Эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload.
* Михаил Курмаев. 15 лет развивал платформу в Badoo/Bumble, сейчас в Т-Банке.
* Олег Волчков. Работал программистом в Яндексе и тимлидом в Озоне. Сейчас в ролях продукт-менеджера, разработчика и devops'а поднимает ЖКХ-стартап.

В этот раз рассмотрим одну главу, зато какую:
* Проектирование хранилища типа “ключ-значение”
Внутри этой главы ни много ни мало CAP-теорема и собственно проектирование kv-хранилища.

И кстати! Владимир Перепелица на платформе devhands запускает новый поток своего мега-курса по очередям, на этот раз с прицельным фокусом на Kafka и NATS. Регистрация открыта, старт 13-го ноября, приходите, приводите друзей.

🗓 Чтобы не пропустить митап, не забудьте сделать два простых шага:
➡ Поставить в календарь напоминание о встрече (24-го октября 18:00 MSK)
➡ Вступите в чат https://t.me/AlexeyRybakChat: за сутки и за час до встречи там будут напоминания и все ссылки

Предыдущие стримы (первый, второй) смотрите на YouTube-канале: https://www.youtube.com/@AlexeyRybak

До встречи!

ScyllaDB в Medium

Если интересуетесь распределенными базами данных вообще либо Сциллой в частности, то вот относительно свежая статья от инженерной команды Meduim про то, как в Medim используется распределенная СУБД ScyllaDB для хранения специализированных списков атрибутов, потребляемых ML-движком рекомендаций.

Статьи пишет один автор (Andréas Saudemont) в довольно академичном ключе, первая статья в этой серии вообще была чересчур общая на мой вкус. Но в этой второй статье интересен “немаркетинговый” рассказ об устройстве базы ScyllaDB простым языком, и это мне показалось интересным. А ещё, например, я с удивлением узнал, что движок Scylla поддердживает TTL аналогично кеш-сервисам и самостоятельно чистит устаревшие данные. Кто ещё из СУБД так умеет? Redis в качестве СУБД не предлагать 😉

Про Python 3.13 без GIL и с JIT

Realpython опубликовал большой обзор релиза Python 3.13.

* GIL (global interpreter lock) – механизм синхронизации в Python, который сильно ограничивает писателей “наивно-мультитредовых” программ на питоне.
* JIT (just-in-time) компиляция – такая техника запуска интерпретируемого кода, когда интерпретатор в процессе исполнения компилирует байт-код в нативный машинный код (в отличие от обычной компиляции, когда машинный код генерится до исполнения).

Итак, ни много ни мало, исторический релиз питона. Скажу честно – пока не понял, что это даёт народному хозяйству. Разберемся.

GIL. Во-первых, код для веб-сервисов давно исполняется “воркерами” которыми управляет gunicorn/uWSGI. Воркеры работают независимо, поэтому есть у нас этот GIL, нет его – неважно. Для тех маньяков, что пишут сервера на питоне самостоятельно, есть Pool в multiprocessing.

Это для северов. Для не-серверов мультитредовость бы помогла известно где – AI и data-science задачи. Однако, насколько я понимаю, почти весь “успех” питона для таких задач строится вокруг библиотек, написанных не на питоне, а на C. Эти библиотеки стараются “внутри” запаралеллить по максимуму либо реализовать настраиваему в рантайме или вовсе автоматическую “мультитредовость” (на этапе компиляции) – в любом случае, GIL и этому классу задач не поможет.

Второе, JIT. Фича крутая, но вот картинка совсем не впечатляет: рост незначительный. Возможно, это лишь первый шаг. Питон разгоняют с рождения: Cython, pypy, numba, а это только самое известное и успешное, что я вспомнил, а там такой длинный список, чёрт ногу сломит. Если бы можно было в ядре питона всё переделать так, чтобы всё это добро оказалось не нужным либо включенным автоматом – было бы круто. Но пока результаты скромные.

Возможно, я не вижу общей картины, есть большой крутой роадмэп, из которого понятно, что со временем всё преобразится? В любом случае, на JIT больше надежд, чем на GIL.

Буду рад услышать ваше мнение, может, чего-то упускаю.
UPDATE: см 🔥 комменты

Valkey vs Redis: публикация на хабре.
* пропускная способность на одном графике, как попросил Олег
* больше про методику тестирования

Кстати, стал пользоваться для графиков такой штукой observable plot. Это типа те же чуваки, что и D3. Есть нарекания, но в целом удобно.

P.S. кто зареген на хабре - помогите плюсами, плз

Redis vs Valkey (by DevHands.io): масштабируемость io-threads по ядрам процессора.

Саммари сравнения на картинке:
(1) Redis масштабируется по ядрам, но так себе
(2) Valkey выдает в 2.5 раза больше RPS при сильно меньшей latency
(3) Ни один, ни второй не увеличивают пропускную способность при числе тредов больше 8 - скорее всего, проблема single-main-thread архитектуры. Именно столько стоит у разработчиков valkey в якорных маркетинговых бенчмарках про unlocking 1 million RPS.

Дальше - PostgreSQL 17 (уже выдает на стенде свой миллион+ RPS, но отжирает весь проц), MySQL 8.4 (детка, верю в тебя) и Memcached и DragonFly.