System Design & Highload (Alexey Rybak) @rybakalexey Channel on Telegram

System Design & Highload (Alexey Rybak)

@rybakalexey


Архитектура больших проектов и управление продуктово-инженерными организациями; статьи, выступления по теме управление и разработка больших IT-проектов. Https://DevHands.io - хайлоад-прокачка бекендеров. ЛС: @alexeyrybak.

System Design & Highload (Alexey Rybak) (Russian)

Вы когда-нибудь задумывались над архитектурой больших проектов и управлением продуктово-инженерными организациями? Если да, то канал @rybakalexey создан специально для вас! Здесь вы найдете статьи, выступления по теме управления и разработки больших IT-проектов, а также много полезной информации о хайлоад-прокачке бекендеров на ресурсе Https://DevHands.io. Автор канала - Алексей Рыбак, эксперт в области системного дизайна и высоконагруженных систем. Присоединяйтесь к нам и узнавайте первыми о самых передовых методах управления и разработки в IT-сфере! Для связи с автором канала обращайтесь в личные сообщения: @alexeyrybak.

System Design & Highload (Alexey Rybak)

15 Feb, 10:45


Радар DevHands: почитать на неделе 8-15 февраля 2025

Yandex: Как главная страница Яндекса переезжала на Go
Это уже отшумевшая статья (ей целых три дня) из которой можно узнать, что в Яндексе есть Группа Бекендеров Главной Страницы, что до сих пор Яндекс жил с Perl на главной, но титанически смог смочь пересилить себя.
Зацените! Запретить у себя безобидный похапе, но иметь в хозяйстве такое:

sub respond ($;$$@) {
my ($req, $headers, %args) = @_[0, 2 .. $#_];
return undef unless ref $_[1]
}

Все, кто помнит, что значит my и $_[1] приглашаются в комментарии ещё раз вспомнить, за что же мы ненавидели перл (вот за таких перлописателей главных страниц) и что же блин, мать его, значило $#_. Brainbench Master Perl 2000 не помнит.

Atlassian: How we migrated Bitbucket Cloud to Envoy proxy
Bitbucket (Git-хаб от Atlassian) обрабатывает миллиарды запросов и петабайты данных в день. У них был Amazon Global Accelerator, это было очень дорого, плюс они упирались в лимиты по пропускной способности. Заменили это дело на связку network-балансеров и envoy и написали про это.

Graphana learning journeys
Графана запускает новый раздел - мини-туториалы для пользователей. Интересный пример работы с сообществом, может быть интересен как кейс менеджерам и дев-адвокатам.

JetBrains/Ktor: Релиз Ktor 3.1.0
Вышла очередная версия Ktor, в целом минорная, но возможно, интересная тем, кто как и я, “приглядывается” к связке Ktor+Kotlin. Из интересное: Ktor поддерживает из коробки SSE (server side events) и постоянно что-то в них улучшает, они добавили поддержку WebAssembly (Wasm) и анонсировали поддержку gRPC.

Rust: 2024 State of Rust Survey Results
Сам опрос мне не очень нравится, но я считаю, что все survey такого уровня надо смотреть и изучать: это прикольные инсайты и кейсы, как по маркетингу, так и по работе с сообществами. Итак, что там интересного по фактам? Россия - на восьмом месте по числу опрошенных. Англия на 3-м, Франция на 4м (WTF?). Израиль с кучей стартапов и университетов на 24-м. Прод-рантаймы на винде у 44%. VS Code 62%, vim/neovim 31%. Но главный график закопан в середине, на Rust как на основном языке на работе пишет, внимание, 30%. Топ-3 вызова за два последних года: не достаточно популярный в технологичной среде (43%), становится более сложным (43 %), разработчики языка не получают достаточно поддержки (32%). Но это мне не помешает начать писать на Rust в 2025-м, а если вы вдруг Rust хорошо знаете и хотите запустить или уже запустили свой курс – напишите мне, возможно, я предложу вам интересное партнёрство.

Enjoy

System Design & Highload (Alexey Rybak)

14 Feb, 07:43


Интервью по системному дизайну: хайп или необходимость?

TL;DR: приходите на очередной митап в среду 19-го февраля, в 18:00 МСК (Youtube).

🤩Мы уже привыкли, что design-секцию на программистские senior-позиции проходят все. C удивлением даже можно обнаружить, что design-секции теперь проходят не только бекендеры, но аналитики, и даже продакты. Однако есть сомнение, что эта секция приносит пользу и решает эффективно задачи нанимающей компании. Я позвал на разговор Фила Дельгядо (lekton.io), который придерживается этой точки зрения.

🤩Фил Дельгадо – архитектор и java-бекендер, и в карьере своей чем только не занимался, от двухзвенок на Visual Basic до хардкорного SQL. Последние годы делает разные платежные системы, рассказывает про это на митапах и конференциях, в частности, является одним из регулярных спикеров конференции Хайлоад. Помимо прочего Фил является активным участником, наверное, всех архитектурных Telegram-чатов, которые я знаю, обладает потрясающе широкой эрудицией и непревзойденным полемическим талантом. Касательно архитектуры в целом и design-интервью в частности у Фила вполне здравые рассуждения, которые он последовательно отстаивает.

Мы обсудим:
🤩 почему design-секции могут приносить больше вреда, чем пользы
🤩 чем их можно заменить и масштабируется ли этот подход для больших компаний
🤩 как готовиться тем, кто всё равно понимает, что design-секция неизбежна?

Ссылки:
🤩 вещание на Youtube: https://www.youtube.com/@AlexeyRybak/streams.
🤩 календарь Google: https://calndr.link/e/sUWoUsLgGx?s=google
🤩 календарь Apple: https://calndr.link/e/sUWoUsLgGx?s=apple

System Design & Highload (Alexey Rybak)

07 Feb, 14:49


Радар: почитать на неделе 1 - 7 февраля 2025

Уж не знаю, как так получается, но теперь в фокусе LLM.

LLM ищет баги в софте Фейсбука. Блин, это уже не из области фантастики. Короче, цель: иметь систему, которая сама находит баги. Сначала учим систему искать баги. Инженер написал сервис. Написал текстом, о каких багах он “беспокоится”, обычным естественным языком. Софт это прочитал, и нагеренил баги – в отдельную ветку, чтобы не ушло в прод. Инженер отсмотрел, отметил годное. Далее нагенерил тест-кейсы, чтобы найти эти баги. И это всё повторяется на этапе тренировки. После чего софт генерит тест-кейсы, чтобы найти неизвестные баги по тестовым описаниям. Статья попсовая, но есть ссылка на статью в arXiv c результатами (ACH was used by Messenger and WhatsApp test-athons where engineers accepted 73% of its tests)
https://engineering.fb.com/2025/02/05/security/revolutionizing-software-testing-llm-powered-bug-catchers-meta-ach/.

Яндекс написал огромный лонгрид про оптимизацию и ускорение в LLM-задачах: https://habr.com/ru/companies/yandex/articles/878230/

Интересный обзорный рассказ Мичила Егорова на Хайлоаде про то, как в X5 запустили с нуля AI-отдел со своей инфрой. Будет интересно, если думаете строить свою инфраструктуру. Мотивация, стэк, компоненты, архитектура, фейлы. Доклад полугодовой давности, но открыли вот прям сейчас: https://www.youtube.com/watch?v=EEi0eO8ztaY

Redis системно “качает” тему RAG и GenAI, но я пока не понимаю, действительно ли они видят в этом рынок (а я нет), или это просто хайп: https://redis.io/blog/you-need-more-than-a-vector-database/

Ну и ссылка от Олега Волчкова для любителей оптимизации запросов — https://www.pgmustard.com/blog/index-scan-doesnt-mean-its-fast: “Не всегда достаточно убедиться, что запрос использует индекс. Можно и нужно покопать дальше, если видим всякие bitmap index scan, много записей удалённых фильтром и т.п.” А если кто хочет прокачаться в оптимизации запросов PostgreSQL – подсказываю, что делать.

Если что ещё интересное выходило - скидывайте в каменты.

P.S. Специально для Романа: если кого-то тошнит от моих постов, можно теперь не сдерживать себя. На сверкающую фиолетовую какашку 💩 буста не хватило, добавлю, если забустите: https://t.me/boost/rybakalexey.

System Design & Highload (Alexey Rybak)

07 Feb, 07:14


Запись стрима про СУБД и саммари

Готова запись стрима: https://www.youtube.com/watch?v=8x3lgZoV7EA

Шикарный был стрим, за что огромное спасибо экспертам, Леше Копытову и Коле Ихалайнену (MyDB), и Антону Герасимову (Гиперус), и всем остальным, кто пришел. Мне кажется, это один из лучших наших стримов.

Знатно (хоть и слегка сумбурно) зарубились под конец про лицензии. Всего обсудили три темы:
- Тренды на рынке СУБД. Никто из экспертов не верит, что в экосистему открытых традиционных баз всё-таки “завезут” готовые cloud-native/кластерные решения. Думаю, это обязательно произойдет, вопрос срока.
- Обучение бекендеров: ORM – только для MVP. Знаю, что тема мега-флеймовая, но это мнение экспертов, если интересно – послушайте.
- Обсуждение лицензий: основная рубка была вокруг “тонкостей” удовлетворения GPL, есть по сути два мнения на этот счет: мнение “корпоративное” - даже не надо пытаться, риски не оправданы, поэтому венндорская модель с GPL-компонентом невозможна. Второе мнение: в большом количестве случаев GPL не диктует открывать код и не является блокером для вендорской модели, а все опасения и терминология “вирусная” от юридической неграмотности. К соглашению так и не пришли, все остались при своих.

Как мы резюмировали на стриме, хорошим результатом этой дискуссии мог бы стать (а) набор легальных приёмов, которые наглядно демонстрируют, как именно можно распространять закрытый софт с GPL-компонентами (линковка с открытым рантаймом, использование LGPL-версий или вовсе открытых клиентских библиотек и др). Примеры коробочного софта битрикса, ispmanager и многих других хорошо показывают: есть компании, которые не бояться строить вендорскую модель с GPL-софтом. (б) обзор судебных и (самое сложное) не дошедших до суда кейсов, когда использование GPL приводило к последствиям (отказ от модели, выплата лицензионных отчислений, судебные компенсации издержки). Если знаете такие кейсы - кидайте в каменты.

System Design & Highload (Alexey Rybak)

06 Feb, 08:32


Напоминание: сегодня в 18:00 стрим за СУБД!

Знаете ли вы:
* когда завезут planet-scale в PostgeSQL/MySQL и закончится ли уже этот бесконечный парад planet-scale СУБД с хер пойми какими лицензиями?
* что будет в тренде СУБД через 5 лет? действительно ли будущее за разделённым compute/storage и есть ли уже PostgreSQL/MySQL поверх S3?
* кто из СУБД лучше готов к гонке открытых много-слойных архитектур? превратится ли СУБД как продукт в конструктор из открытых компонент?
* зачем компаниям типа Visa, UBER, Facebook консультанты СУБД и с какими проблемами эти компании обращаются к консультатам?
* что важно для облачного вендора при выборе СУБД?

Это дело и многие другие вопросы обсудим сегодня с замечательными гостями. Приходите.

https://t.me/rybakalexey/192

System Design & Highload (Alexey Rybak)

03 Feb, 09:29


Встречайте нового эксперта DevHands и курс по PostgreSQL

Важная новость: с января к нам присоединился Николай Ихалайнен, проработавший более 10 лет в Percona.

Николай консультировал и помогал исправить баги и проблемы производительности СУБД для крупнейших интернет-игроков планеты: Facebook, Uber, Booking, Broadcom, United Healthcare, Nokia и многих других проектов с много-миллионной аудиторией. До этого Николай работал в “старом” Кинопоиске, сделав возможным масштабирование крупнейшего российского сайта о кино “Кинопоиск” с 60 тыс до 20 М уников в сутки.

Наша основная политика – работа с топовыми экспертами по модели revenue share. Это исключает ставки 5 т.р. за лекцию (или 4 т.р.?), ухудшающий отбор, и прочие перекосы, убивающие индустрию качественного профессионального образования. Если вы обладаете уникальным опытом в топовых российских и мировых компаниях, продолжаете работать “руками” и следить за трендами, если у вас уже есть курс или идея запуска крутого курса, вы готовы разработать его и запускать хотя бы 3-4 группы в год на нашей площадке – напишите мне, поможем с запуском и поделимся выручкой (рассчитываем на доход в 300-700 т.р. в месяц для авторов).

Николай фактический сделал возможным запуск направления Баз Данных с DevHands. Месяц назад мы проводили голосование о направлениях в области СУБД, которые могли быть вам интересны – и ожидаемо с большим отрывом победил PostgreSQL. И уже в марте мы стартуем первый курс, посвященный PostgreSQL: “PostgreSQL 17: архитектура и тюнинг SQL-запросов”. Мы верны своей традиции: с первого дня каждый слушатель получает в управление неслабую виртуалку (8 vCPU, 12G RAM, 100G NVMe) с настроенным PostgreSQL, чтобы вы могли погрузиться как можно глубже в архитектуру и особенности работы этой СУБД.

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

System Design & Highload (Alexey Rybak)

02 Feb, 09:04


TechFounders и питерский Highload

TechFounders
— новая конференция от команды Highload, объединяющая инвесторов, IT-стартапы и предпринимателей. Нам нужны клёвые доклады на темы:
- Финансы и юридические вопросы
- HR
- Технологии и инфраструктура
- Маркетинг и продажи
- И любые другие темы, которые могут быть полезны сообществу будущих и настоящих технологических предпринимателей

Подавайте заявки.

А в это время питерский Highload скоро закроет приём докладов.

Если сомневаетесь в теме, приходите на встречу с программным комитетом 6 февраля в 19:00 в офис Nexign (Санкт-Петербург, ул. Уральская, 4). Сбор с 18:30, возможен онлайн-формат (ниже ссылки). Будет обсуждение актуальных для 2025 года тем, разбор заявок и обратная связь по ним в режиме реального времени.

Мне лично особенно интересны доклады про внедрения: кластерные стораджи и базы, шардинг-прокси - чем больше кровища, говна и палок, тем интереснее.

В конце встречи — нетворкинг и фуршет. Правда, с безалкогольным пивом, но оргов можно понять: это же Питер, культурная столица, эта песня, в целом, о туризме, для туристов я её пою. Короче, регистрируйтесь: оффлайн сюда, а онлайн туда.

System Design & Highload (Alexey Rybak)

31 Jan, 15:44


Радар: почитать на неделе 24-31 января

Сегодня в фокусе технология eBPF (Extended Berkeley Packet Filter) — это технология в ядре Linux, которая позволяет выполнять безопасный и эффективный профайлинг в ядре без необходимости вносить изменения в код прикладных приложений. То есть вы включаете такой профайлер на “хуках” для сисколов ядра, который без установки софта анализирует всё, что происходит. Дополнительных костов, типа, минимум. Применения широкие: сбор метрик, трассировка вызовов, анализ задержек, обнаружение аномалий и анализ трафика и многое другое. Всё - без модификации приложений.

🤩 Perforator: открытый eBPF-инструмент + описание проблем профилирования в линухе
Яндекс выпустил в open source систему непрерывного профилирования Perforator, ранее использовавшуюся для анализа производительности внутренних сервисов. Perforator позволяет детально изучать работу приложений, выявлять узкие места и оптимизировать их, что приводит к значительному повышению эффективности работы сервисов. Система доступна на GitHub под лицензией MIT и может быть развёрнута в кластере Kubernetes или использоваться локально как замена perf record с меньшими накладными расходами. Perforator также поддерживает профилирование JIT-компилируемых языков и может применяться для автоматической оптимизации программ с использованием Profile-Guided Optimization (PGO), что, по результатам тестов, обеспечивает ускорение около 10% в различных сценариях.

🤩 Для справки. Другое интересное решение на базе eBPF, если вы вдруг не слышали – Coroot. Это observability-инструмент, opensource (open core, если точнее), разработанный для упрощения мониторинга и диагностики микро-сервисных архитектур. Ключевые особенности:
🤩 Автоматическое обнаружение сервисов и их зависимостей: Coroot строит топологию микросервисов, отображая их взаимодействия и состояния, что облегчает понимание структуры приложения.
🤩 Использование eBPF для сбора данных: собирает метрики и трассировки без необходимости внесения изменений в код приложений, что снижает накладные расходы и упрощает интеграцию.
🤩 Интеграция с OpenTelemetry: умеет собирать и анализировать распределенные трассировки, предоставляя детальную информацию о производительности и задержках в системе.
Короче, такое решение с акцентом на простоту, быструю установку, чтобы ничего не настраивать, поставил - и работает. Делают “наши” - Николай Сивко и Петя Зайцев сотоварищи.

Еще больше почитать:
🤩 Martin Fowler и Bharani Subramaniam популярно обьясняют, как интегрироваться с LLM от прямых промт-запросов к эмбеддингам (и очень простая иллюстрация, что такое эмбеддинги)
🤩 В новом выпуске CTO-craft помимо кучи воды любопытная статья “Продуктивность разработчиков в 2025 году: больше ИИ, но неоднозначные результаты”. Джунам напрячься, Синьорам снова учиться.
🤩 Если вы бекендер, зачем-то сидите на винде и вам зачем-то понадобился нативный Redis под винду без виртуализации - теперь есть такая шняга Memurai (девелоперам бесплатно).

Если я что-то интересное пропустил - скидывайте в комментарии.

🤩 Enjoy

System Design & Highload (Alexey Rybak)

31 Jan, 06:21


Стрим Devhands 6-го февраля 18:00 MSK про СУБД

Рад сообщить, что в следующий четверг, 6-го февраля 2025 года в 18:00 МСК, в YouTube будет очередной стрим, посвященный базам данных, тенденциям, открытому ПО, лицензиям, облачным СУБД.

Тема: Тренды в мире открытых СУБД: ламповый обмен мнениями
Обсудим следующие вопросы:
🤩 Тренды развития СУБД, комментарии экспертов по статье Эндрю Павло и Майкла Стоунбрейкера
🤩 Коммерциализация open source СУБД: как на этом заработать
🤩 СУБД со стороны облачного вендора: что его бесит и чего не хватает?
🤩 Нужно ли учить СУБД бекендерам, или всё запилит ORM, а DBA за ним «разгребёт»?
🤩 Что происходит с лицензиями и как это затронет нас всех?

Придут супер-эксперты:

🤩 Алексей Копытов. Основатель и генеральный директор MyDB. В разработке MySQL и родственных проектов участвует с 2004 года в таких компаниях, как MySQL AB (впоследствии Oracle), Percona и Huawei. Автор многих функций и оптимизаций производительности в MySQL, Percona Server и Percona XtraBackup. Руководил лабораторией баз данных в российском R&D центре Huawei, где разрабатывались облачные решения на основе MySQL и других СУБД. Один из организаторов митапа Database Internals.

🤩 Николай Ихалайнен. Со-основатель MyDB. Энтузиаст открытого програмного обеспечения, провел больше десятка лет, консультируя и поддерживая проекты, использующие MySQL, PostgreSQL, MongoDB на реальном железе, в облаках и Kubernetes в компании Percona. Автор ведущий нового курса Devhands “PostgreSQL 17: архитектура и тюнинг SQL-запросов”. Построил инфраструктуру и работал над оптимизации LAMP в старом Кинопоиске. Участвовал в разработке биллиновых систем для ISP/IPTV разработчиком на C++. Внедрял e-commerce в России в составе e-House как сисадмин и программист.

🤩 Антон Герасимов — Гиперус, CTO. Специализируется на разработке облачных решений, масштабируемых системах, сетевой безопасности. Cейчас Антон – CTO в компании Гиперус, занимающейся разработкой коробочного решения для on-prem облаков (продукт, реализующий гиперконвергентную ИТ-платформу внутри компаний). Ранее работал в компаниях МойОфис, Спутник и Rambler.

🤩 Ссылки для удобного добавления в календарь
Google: https://calndr.link/e/5oYHlpYS5G?s=google
Apple: https://calndr.link/e/5oYHlpYS5G?s=apple

В рамках стрима заодно расскажем с Николаем про наш новый курс, “PostgreSQL 17: архитектура и тюнинг SQL-запросов”. Zoom в этот раз будет только для участников программ Devhands (в прошлый раз какие-то анонимные задроты нам пытались сорвать эфир).

System Design & Highload (Alexey Rybak)

28 Jan, 06:07


Вы все уже знаете про DeepSeek? Это китайский ChatGPT, который вчера наделал кучу шума и это привело к грандиозному снижению стоимости акций NVidia. Пока я этот текст писал, процентов до 17%, и это в общем просто дохера (это предложение можно спеть на мотив восьмиклассницы).

По наводке чата бывших коллег обнаружил занятный эффект. На вопрос “Can Chinese government make mistakes” дипсик сначала отвечает, что, да, может совершать ошибки (как и любое правительство), но потом меняет ответ (ой это выходит за рамки, давайте о другом)!

Такое впечатление, что там другая сетка поверх проверяет, а не является ли утверждение негативным по отношению к Китаю и разным уважаемым товарищам, и если да - ставится заглушка. Хак грязный, но работает!

Саммари делает нормально, президент в США – Байден (у ChatGPT уже нет), русские IP не блочит. Говорят, дешевый API. Срыв стэка на Расте продемонстрировал с unsafe. Больше кода генерить пока не пробовал.

Что ещё сказать? Слава великому китайскому народу, завоевавшему свободу, независимость и счастье.

System Design & Highload (Alexey Rybak)

24 Jan, 08:20


Подсознательные улучшения и другие пятничные набросы

Отличная тема для пятничного флейма! Олег Волчков в нашем чате подкинул статью Степана Коршакова (экс-Телеграм). Статья вчерашняя. Называется по-детски прямолинейно: You should write "without bugs”. Если её прочитать, особенно не вдумываясь, будет впечатление, что статья – вечная жвачка, хорошее против плохого, дисциплина, “качество” с занудством Пирсига, “нормально делай – нормально будет”, и вот это всё.

Но в статье есть одна идея, по-моему очень глубокая. Это идея «подсознательных улучшений», при котором привычки и навыки разработчика совершенствуются благодаря осознанным усилиям и регулярной практике, контролируемой строгой само-дисциплиной. Со временем эти улучшения становятся частью подсознания, требуя меньше осознанных размышлений и усилий.

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

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

И вторая идея, ещё более важная – что единственным способом достижения такого уровня является не свободное плавание пассажиром, а регулярный “пуш” себя и своей команды, без попыток свалить обеспечение качества на QA.

А от себя добавлю, что для компаний нет лучшего способа этого достичь, чем следовать практике “You build it - you run it”, и насаждения этой практики везде, где это можно сделать (вот в банках, например, такие возможности традиционно ограничены, но не невозможны. Это у меня просто боль последнего года, особенно было больно от приложений банка желтого цвета).

Согласны? Юниты будем писать? А саппортить прод? Ну хотя бы пирамиду метрик выстроить и следить?

System Design & Highload (Alexey Rybak)

23 Jan, 10:45


Радар: почитать/посмотреть на неделе (17-24 января 2025)

Команда конференции Хайлоад внезапно выложила в свободный доступ доклады летней конференции в Питере. Там 80+ видео, и кажется, это не всё. Я выбрал некоторое количество докладов, из которых, как мне кажется, вы точно сможете выбрать хотя бы 1-2 посмотреть, но в целом рекомендую пробежатся по списку на странице канала, вероятно, вы что-то ещё подберете интересное себе.

* Enterprise deploy: почему это больно / Филипп Дельгядо (lekton.io)
* Геораспределенные системы / Евгений Кузовлев (Т-Банк)
* Как воспитать себе помощника: применение локального ИИ для разработки / Алексей Цветков
* Как научить почтовый сервер Exim под нагрузкой 1 000 000 писем/мин. переживать отказ ЦОД / Максим Уймин (VK)
* Переосмысление Picodata как cluster-first-СУБД / Ярослав Дынников (Picodata)
* Redis — такой простой и такой сложный! / Андрей Комягин (STM Labs)
* Про UUID v.7 / Андрей Бородин (Yandex Cloud)
* Балансировка нагрузки шардированного PostgreSQL не своими руками / Денис Волков (Yandex Cloud)
* Как мы шли к 5000 RPS на запись / Ян Силов (Ozon)

Как говорится, инджой. Если ещё что-то супер-интересное пропустил - скидывайте в комментарии. Публикую такие обзоры в телеге регулярно, так что подписывайтесь, если ещё не.

System Design & Highload (Alexey Rybak)

20 Jan, 07:56


Вывод #5: Memcached Plugin жив (но пока только в MySQL 8x)

Последний, 5й вывод, который я сделал после прошлогоднего тестирования, касается эко-системы MySQL. Поскольку она сейчас не очень популярна в РФ, напишу кратко.

В MySQL удачно сделана “слоеная” структура СУБД , которая позволяет полноценно делать pluggable storage engines. Поэтому в свое время в MySQL оказалось так много разных прикольных движков: помимо основного транзакционного ACID-движка InnoDB есть 2 других, интересных для нашей кеш-нагрузки: HEAP (он же Memory) и Memcached Plugin. Вообще в MySQL был миллион разных движков: даже Pinba (до сих пор самая крутая штука для backend observability, которую я не видел ни у кого) - тоже была сделана в виде движка MySQL.

Два последних мы потестили на кеш-нагрузке, и оказалось, что Memcached plugin не только жив, но и прекрасно работает, показывает отличную производительность при большом количестве одновременных соединений (см. слайды, ссылка ниже).

HEAP же наоборот немного разочаровал: показывая очень хорошие результаты для low concurrency workloads он быстро “сдувается” и показывает невысокую производительность на high concurrency – скорее всего кто-то где-то намудрил с блокировками. Наверное это можно обойти, реализовав что-то типа хэш-слотов и разбив ключи по разным inmemory-таблицам, но в целом это костыль, и мало ли что ещё вылезет.

Кстати, HEAP engine иногда прямо вот очень нас спасал в Badoo, так что учитывайте эту особенность, если вы тоже его используете.

Для справки:
- Исследование PostgreSQL/MySQL/Redis/Valkey/Memcached (HighLoad MSK-2024)
- Вывод #1 (Робкое напоминание о железе и гибридном подходе)
- Вывод #2 (PostgreSQL “сгладил” родовую травму)
- Вывод #3 (Valkey “сгладил” родовую травму Redis)
- Вывод #4 (MySQL, и PosgreSQL легко вывозят “простые” 1.000.000 RPS)

System Design & Highload (Alexey Rybak)

17 Jan, 06:14


Программисты, вы ещё не используете ChatGPT? Начинайте немедленно.

Этот пост для LLM-скептиков. На протяжение последних лет я сам крайне скептически относился к возможностям ChatGPT в программировании. Эдакая смесь лени, невежества и спеси кожаного мешка, плюс неудачный опыт использования ранних версий.

Это в прошлом. Вот еще один кейс, на этот раз автоматического «переписывания» кода. Возможно, тривиальный с точки зрения искушенных программистов, но пост не для них, а для тех, кто еще сомневается.

У нас есть ряд скриптовых утилит, написанных на PHP (возможно вы удивитесь, PHP может быть идеален для платформенных и devops задач. В Badoo куча подобного кода было написано на PHP и насколько я помню, никто особенно не предьявлял к этому коду претензий только потому, что это – неподходящий язык. Просто в нашей среде он, мягко говоря, непопулярен, и программиста, знающего Linux и умеющего писать консольные утилиты и автоматизации на PHP найти сложно).

Ради интереса я взял одну из утилит и попросил ChatGPT переписать её на Golang. Утилита, конечно, очень простая. Грубо, она генерит несколько случайных строк заданной длины с тривиальной логикой использования разных групп символов. Это используется для создания паролей, секретных токенов-ключиков и тд.

ChatGPT её успешно переписал на Go, причем правильно подсветил с его точки зрения необязательный кусок кода. Код собрался без ошибок.

Повторю, утилита очень простая, но факт остается фактом: в деле изучения чего-то нового это выглядит как незаменимый инструмент, значительно ускоряющий «погружение».

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

Надо будет попробовать теперь то же самое на Rust.

А как ещё вы используете ChatGPT в программировании? Авто-комплит не в счёт.

System Design & Highload (Alexey Rybak)

15 Jan, 07:23


Вывод #4: И MySQL, и PosgreSQL легко вывозят “простые” 1.000.000 RPS c “сравнимым” перфомансом.

В последние годы ряд исследователей замечали, что PostgreSQL свой перфоманс системно “подтягивает”, в то время как перфоманс MySQL пусть медленно, но заметно деградирует (см. посты Mark Callahan, например, на его сайте https://smalldatum.blogspot.com/).

Наши результаты с этим расходятся (см. ссылку на исследование внизу или картинку в первом комментарии).
По двум причинам:
1) мы взяли специфическую Read-Only нагрузку с компактными данными, “симулирующую” работу кешей.
2) мы собирали MySQL/MyDB со специализированными настройками, которые практически нивелируют проблему увеличения “InnoDB code bloat”. Интересно было бы “перепрогнать” тесты Марка на таких сборках и убедиться, что этот эффект будет виден и на других нагрузках.

Без оптимизаций ванильный MySQL проигрывает по производительности PosgtreSQL на low concurrency workloads (число одновременных соединений << 1000). Но уже при числе одновременных соединений 3000+ пропускная способность MySQL начинает опережать пропускную способность PosgtreSQL. А с оптимизациями на всем диапазоне MySQL показывает производительность лучше, чем PosgtreSQL. Замечу, что если в продакшене у вас что-то типа баунсера, то производительнсть связки постгрес+баунсер будет ещё ниже (для MySQL, напомню, баунсер не нужен).

Является ли это критичным, говорит ли это о том, что нужно выбирать MySQL, а не PostgreSQL? Ни в коем случае! Речь идёт о миллионе запросов в секунду, характер нагрузке специфичный. Но это хорошая иллюстрация того, что обе СУБД, и MySQL, и PostgreSQL достаточно хорошо ведут себя на таких нагрузках.

Для справки:
- Исследование PostgreSQL/MySQL/Redis/Valkey/Memcached (HighLoad MSK-2024)
- Вывод #1 (Робкое напоминание о железе и гибридном подходе)
- Вывод #2 (PostgreSQL “сгладил” родовую травму)
- Вывод #3 (Valkey “сгладил” родовую травму Redis)

System Design & Highload (Alexey Rybak)

14 Jan, 08:48


Вывод #3: Valkey “сгладил” родовую травму Redis, но Memcached их по-прежнему рвёт в cache-only сценарии

Disclaimer: всё, что дальше понаписано, касается исключительно специфичных кейсов, когда ваша инфра обрабатывает как минимум многие десятки/сотни тысяч запросов к кеш-слою в секунду. Если нет - вам отлично зайдёт Redis.

Третий вывод, который я сделал: Valkey действительно удалось сделать продукт, который в состоянии отдать миллион RPS с одного инстанса, а в целом Valkey отдает примерно в 2.5 раза больше RPS, чем Redis (график в презентации и в первом комментарии). У Евгения Дюкова из Яндекса был на эту тему достаточно подробный доклад на последнем хайлоаде – думаю, что скоро он окажется в свободном доступе.

Проблема (и сила) Redis заключается в простой до невозможности архитектуре. У Redis есть один единственный main thread, который отвечает “за всё”, и есть некоторое количество io-threads, которые отвечают за ввод-вывод. С ростом нагрузки, если вашему Redis можно отдать хотя бы несколько ядер, можно чуть поднять io-threads и таким образом слегка повысить пропускную способность. Это, кстати, не все знают: да, Redis можно немножечко “поскейлить” по ядрам, раза в 2 можно поднять RPS, но этот скейлинг крайне неэффективный, будет заметен рост в дипазоне 1-4 io-тредов, но дальше они начнут затыкаться в борьбе за локи (lock contention).

Что сделали в Valkey: они внесли много исправлений, позволивших “развязать” main-тред и io-треды и заметно повысили параллелизм в Redis. Плюс внесли ряд исправлений, позволивших лучше утилизировать префетч-возможности современных процессоров, что также заметно снижает latency. Короче, Valkey молодец - но родовая травма всё-таки никуда не делась. На наших тестах хорошо видно, что поднимать число io-threads выше 8-10 уже не имеет особенного смысла, сколько бы ядер у нас ни было.

В свою очередь Memcached, который конечно по сравнению c Redis/Valkey не умеет почти ничего кроме базовых get/set/del/incr операций, может выдать значительно бОльшую пропускную способность, нежели Valkey. У Memcached есть похожие проблемы с lock contention, но насколько я понимаю, используется другой подход к партиционированию данных, что снижает contention. Если вам нужен только кеш без персистенстности - Memcached по-прежнему отличный вариант.

Для справки
- Собственно презентация по результатам исследования PostgreSQL/MySQL/Redis/Valkey/Memcached
- Вывод #1 (Робкое напоминание о железе и гибридном подходе)
- Вывод #2 (PostgreSQL “сгладил” родовую травму)

System Design & Highload (Alexey Rybak)

13 Jan, 07:21


Вывод #2: PostgreSQL “сгладил” родовую травму

Второй вывод, который я сделал: PosgtreSQL к 17й версии (а может, и раньше – не изучал) значительно “смягчил” свою родовую травму, модель process-per-connection в обработке соединений. Я собственными глазами видел, как наша тестовая машинка “жила” с 5000 процессами. И это с 128G памяти, что по нынешним меркам немного, то есть при желании 20-25 тысяч одновременных соединений PostgreSQL может легко вытянуть на достаточно мощном железе просто даже без кеша соединений.

Конечно, другие СУБД справятся с таким количеством соединений на значительно более скромном железе, но поскольку я последовательно выступаю за “разумную” комбинацию горизонтального и вертикального масштабирования – большинство проектов PostgreSQL “потянет” даже без баунсера. С баунсером, кстати, тоже не всё гладко, дополнительное звено и extra-hop, это раз, но поскольку он по-прежнему однопоточный – это может ограничивать пропускную способность на больших нагрузках (надо делать пул баунсеров, уносить баунсеры на бекенд-машины – короче, всё это делается, но заметно увеличивает сложность). Тут интерес представляет мульти-поточный яндексовский одиссей – мы его даже поставили, но банально руки так и не дошли: с пол-пинка он не завелся, а ковырять уже времени не было.

Кстати, большое спасибо всем, кто голосовал за СУБД-направления (ещё можно это сделать). На мой взгляд, такой перевес интереса к PostgreSQL по сравнению c MySQL не соответствует реальному уровню этих СУБД и эко-систем вокруг них. Лично я считаю, что они равнозначны, и я ожидал бы распределения интереса 50% на 50%. Но объективно голосование лишь подтверждает известный факт: в русско-язычных командах PostgreSQL или связка PostgreSQL/Redis является самой популярной.

Для справки:
- презентация по результатам исследования PostgreSQL/MySQL/Redis/Valkey/Memcached
- вывод #1

System Design & Highload (Alexey Rybak)

11 Jan, 10:26


Самый странный мерч в моей жизни и трек по СУБД.

Я хотел написать этот пост в поддержку чего-то очень важного, и кажется такой момент настал. Это пост про мерч с богатой историей - в поддержку нашего нового трека по СУБД (да-да, наконец).

Много лет назад я был в Калифорнии на конференции MySQL. Света Смирнова (за что ей громаднейшее спасибо) где-то раздобыла дико смешной мерч, трусы MySQL, и на моё робкое замечание об их огромном размере сказала что-то типа “бери эти, взяла тебе последние”.

А потом мы попросили художника Николая Копейкина нарисовать картину, которая долго провисела в московском офисе Badoo. Ко мне даже приходили люди и спрашивали, мол, а правда, что у вас в офисе картина Копейкина висит. Правда, только теперь не в офисе - а у нас дома. Кстати, те самые трусы лежат на фото под картиной.

А теперь в честь чего пост. Ребята, у меня к вам огромная просьба: помогите нам понять приоритеты для нашего трека по СУБД. У нас есть 6 программ. Нам нужно понять, в каком порядке их лучше запустить - это определит голосование. Голосование публикую следующим постом. Если вам нравится этот пост или то, что мы делаем - пожалуйста, оставьте ваш голос.

Заранее спасибо!

System Design & Highload (Alexey Rybak)

10 Jan, 07:32


Миллион, миллион, миллион RPS

Привет всем вернувшимся к работе после праздников! Начинаю публиковать основные выводы, которые я для себя лично сделал после проведения прошлогоднего тестирования (презентация и графики в предыдущем посте).

Вывод номер один: действительно получить сейчас “миллион RPS” с одной “сторадж”-ноды в режиме чтения не составляет большого труда, причем с этим вполне справляются традиционные открытые СУБД. Достигается это исключительно использованием большого количества ядер, в пересчёте на 1 ядро процессора типа Xeon Gold почти все продукты выдают “грубо” 50-150 тысяч RPS.

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

А следствие такое: огромное количество проектов, даже вполне себе немаленьких, возможно, “влезет” в несколько серверов, которые даже в режиме аренды суммарно обойдутся меньше зарплаты одного девопса (10 “железных” серверов типа того, что был у нас на тестах, обойдется примерно в 3000 евро в месяц).

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

System Design & Highload (Alexey Rybak)

26 Dec, 12:22


Презентация с хайлоада MHL-2024

Cовсем забыл выложить презентацию с Highload – в аттаче.

Напомню, мы в devhands.io взяли Redis, Valkey, Memcached, PostgreSQL и MySQL и провели тесты на “железном сервере” в режиме read-only кеш-нагрузки. Результаты меня лично немного удивили, но не буду спойлерить – смотрите графики в презентации.

По докладу были вопросы: почему всего 10 млн ключей, неясна методика тестирования, почему такое неширокое продуктовое покрытие. Это всё справедливые замечания, на них отвечу кратко в следующих постах.

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

P.S. Один из слушателей заметил, что по его мнению в кластерном режиме Redis может работать без AOF, я пока не проверил, если это так – нужно будет собрать стенд с кластером без AOF.

System Design & Highload (Alexey Rybak)

15 Dec, 09:29


Antirez (Salvatore Sanfilippo) возвращается в Redis

https://antirez.com/news/144

Перспективы Redis после релиза Valkey были туманны
- все или почти все фичи Redis есть в Valkey
- Valkey ударил в больное место и показал очень хорошие результаты (см. например наши исследования в devhands)
- отток клиентов или случился или случится в ближайший год, Valkey маниакально следит за полной совместимостью, минимизируя усилия для перпехода не только девелоперам, но и инженерам инфры: апи тот же, для всех бинарей есть симлинки со старыми названиями
- многие чуваки перешли под крыло новой команды, особенно нет смысла продолжать сотрудничать с Redis облачным компаниям, а многие обновления шли от них, Valkey не писал ничего про участи Яндекса, но в кулуарах Хайлоада ребята из Яндекс.Облака мне подтвердили, что и они раньше патчили Redis, а теперь Valkey

Что может дать возвращение Salvatore, и прочие соображения:
- плюсище в карму, но фундаментально без изменения лицензии “перевес” пока на стороне облаков
- в среднесрочной можно собрать или пересобрать команду, выстроить бэкпортирование патчей Valkey, особенно оптимизационные – и если не уравнять, то сбалансировать разрыв в мозгах и руках
- лицензию Redis вероятно не поменяет, особенно после отдельной части поста Salvatore (иронично Петя Зайцев в посте на Линкедин в очередной раз вспоминает про обещание “open source навсегда” - но я согласен с Salvatore, запрет на использование managed без раскрытия обвязок не делает софт “закрытым”)
- фокус на вектора и RAG прикольный, но пока выглядит как частность, KV “берут” не за этим

Короче, похоже, Redis даже не собирается сдаваться и нам предсоить наблюдать интересную конкуренцию двух таланливых команд. Жду включения макретинга DragonFly, пиара вокруг родовых травм Redis/Valkey. Всё это очень интересно наблюдать, конкуренция – почти всегда хорошо.

System Design & Highload (Alexey Rybak)

12 Dec, 09:42


Кейс использования K6 в Picodata

Внутри эко-системы Grafana Labs есть инструмент для нагрузочного тестирования k6. Он немного странный (прожорливость, автоматизация на ява-скрипте, паралеллизация не по тредам/соединениям, а по параллельным пользовательским сессиям whatever it means). Но он становится всё более популярным, и выглядит мощно в плане кастомизаций. Кейс про то, как Picodata прикрутили k6 к тестированию своей СУБД.

Лонг-рид: https://habr.com/ru/companies/arenadata/articles/864974/

Ниже - краткое саммари (кстати, как вам промт?)

Кому будет интересна статья
* Гошникам
* Разработчикам распределённых систем и баз данных.
* Инженерам по нагрузочному тестированию.
* Специалистам, занимающимся построением инфраструктуры тестирования производительности.

Статья посвящена подходу компании Picodata к нагрузочному тестированию распределённых баз данных (NewSQL СУБД). Рассматриваются проблемы, с которыми сталкиваются разработчики таких систем, и выбор инструментов для создания практики тестирования производительности. Основное внимание уделяется созданию собственного решения — системы Picostress, основанной на инструментарии k6.

Используемые продукты и решения
* Picostress - разработанный инструмент для нагрузочного тестирования.
* Go - язык программирования, на котором написан весь код Picostress, а также k6
* k6 - утилита для создания нагрузочных тестов, поддерживающая выполнение скриптов на JavaScript.
* xk6-модуль: расширение для k6, реализованное для взаимодействия с Picodata через её нативные протоколы (iproto и pgproto).
* Cobra - Go-библиотека для создания CLI-приложений, использованная для создания обёртки вокруг k6.

Основные выводы
* Среди множества утилит для нагрузочного тестирования именно k6 оказался наиболее подходящим благодаря гибкости, расширяемости и поддержке пользовательских сценариев.
* Наиболее интересные особенности k6: интеграции в CI/CD процессы, создание сложных сценариев тестирования на JavaScript, поддержка постоянной нагрузки (constant throughput load) с учётом проблемы coordinated omission.
* Разработка собственного модуля: В Picodata был создан xk6-модуль для взаимодействия с нативными протоколами системы, что позволило реализовать нагрузочное тестирование, учитывающее специфику распределённых систем.
* Автоматизация и адаптивность: Picostress, основанный на k6, стал не только инструментом тестирования, но и ключевым элементом мониторинга и оптимизации производительности для каждого релиза продукта.

System Design & Highload (Alexey Rybak)

01 Dec, 10:05


Highload 2024 в Сколково. Выход MyDB из сумрака

Завтра в 11:00 в конгресс-холле мой доклад, “Можем ли мы с базой, но без кэш-слоя в 2024 году?”. Он про то, как современные “классические” базы ликвидируют “гэп” с KV/NewSQL и кто сейчас может эффективно отдать миллион PRS на кэш-нагрузке, c какими ограничениями. В исследовании участвовали Redis, Valkey, Memcached, PostgreSQL, MySQL/MyDB. Будет много performance-диаграмм и два сюрприза.

Первый сюрприз не то чтобы полный сюрприз – про Valkey уже многие слышали. Мы начали тестировать ещё пока этот самый многообещающий клон Redis был в RC-стадии. Расскажем, действительно ли он лучше, и в какой мере оправился от родовых травм Redis.

А вот второй сюрприз - сюрприз полный. По MyDB вы скорее всего слышите в первый раз. Это - первый в истории российский клон MySQL, в реестре, с саппортом, всё как положено. Фаундер этого проекта, Лёша Копытов, внёс неоценимый вклад в наши исследования. Он будет на Хайлоаде, и в нетворк-зоне, и в нашем девруме у кластера Индия (ищите название devhands.io) – можно будет обо всём расспросить его лично.

Кто будет на конференции – приходите знакомиться. Кластер Индия, комната 1.5, рядом с Пикодатой. Кто не будет – кажется, VK организует прямую трансляцию из основного зала.

P.S. Никаких образом не связан с запуском проекта MyDB, но знаю ребят как супер-профи, и надеюсь на разнообразное сотрудничество, в частности мы планируем совместный образовательно-практический воркшоп.

System Design & Highload (Alexey Rybak)

22 Nov, 15:17


PHP performance & observability

Привет!
Стартуем стрим, приходите
Zoom: https://us06web.zoom.us/j/81914182860?pwd=t5ukRE67IJKlk4BH9Wwc62Mencsb9r.1
YouTube: 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).

System Design & Highload (Alexey Rybak)

22 Nov, 10:48


Ошибки измерений

Рабочие будни исследований. Смотрите, вот график числа reads в секунду, которые выполняет 2 сетапа
* ванильный Memcached 1.6.32 (самый новый)
* Memcached Plugin поверх MySQL 8.0.39

По оси Y тысячи RPS, то есть это всё числа порядка миллиона запросов в секунду. 6.4 млн ключей, всё в памяти, xeon gold с 48 cpu при включенном гипертрединге и 128 гигами памяти.

Всё бы ничего, но график ошибочный. То, что мы видим на графике - это не столько как скейлится KV-база при количестве соединений, но и как скейлится сама стрелялка (это отдельный сервер, но стреляем локально, чтобы не тестировать сеть и инфру провайдера).

Стрелять одновременно и в мемкеш, и в редис стандартный redis-benchmark не умеет, поэтому я взял прежнюю “редисовскую” стрелялку, memtier-benchmark. И к сожалению, по аналогии с sysbench увеличивал число тредов стрелялки, а не число соединений на тред (такой функционал memtier поддерживает).

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

Очень жаль, что Оракл его выпилил в 8.4, надеюсь, он там появится снова - у самого Оракла, или у форков. А про первый российский форк MySQL ещё напишу - там обещали Memcached-плагин сохранить ;)

System Design & Highload (Alexey Rybak)

21 Nov, 09:45


Ребята, внезапно завтра в 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) в целом влияет на перфоманс и какие обзервабилити-артефакты для современных рантаймов нужны.

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

System Design & Highload (Alexey Rybak)

21 Nov, 08:36


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

System Design & Highload (Alexey Rybak)

18 Nov, 08:47


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

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

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

System Design & Highload (Alexey Rybak)

12 Nov, 13:15


Про 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, но только потому, что пока не упёрся ни в какие лимиты. Иногда он мне пишет, что было слишком много запросов, и он будет делать запросы к модели более низкой версии и качества, но на моих запросах я разницы не замечаю.

System Design & Highload (Alexey Rybak)

11 Nov, 07:56


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

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

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

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

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

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

System Design & Highload (Alexey Rybak)

30 Oct, 07:34


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

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

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

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

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

System Design & Highload (Alexey Rybak)

29 Oct, 11:24


Расписание комнаты 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: принципы организации данных в кластере, масштабируемость, отказоусточивость

System Design & Highload (Alexey Rybak)

29 Oct, 11:24


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).

System Design & Highload (Alexey Rybak)

29 Oct, 07:57


Ребят, осталось 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.

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

System Design & Highload (Alexey Rybak)

25 Oct, 13:55


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

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]/

System Design & Highload (Alexey Rybak)

25 Oct, 07:48


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

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

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

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

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

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

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

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

System Design & Highload (Alexey Rybak)

24 Oct, 12:26


Всем привет!

Уже сегодня, меньше чем через три часа, 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!

System Design & Highload (Alexey Rybak)

21 Oct, 12:19


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

System Design & Highload (Alexey Rybak)

20 Oct, 08:59


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

System Design & Highload (Alexey Rybak)

18 Oct, 15:18


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

System Design & Highload (Alexey Rybak)

18 Oct, 12:28


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

До встречи!

System Design & Highload (Alexey Rybak)

17 Oct, 07:27


ScyllaDB в Medium

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

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

System Design & Highload (Alexey Rybak)

11 Oct, 06:18


Про 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: см 🔥 комменты

System Design & Highload (Alexey Rybak)

09 Oct, 08:05


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

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

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

System Design & Highload (Alexey Rybak)

09 Oct, 06:15


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.

System Design & Highload (Alexey Rybak)

08 Oct, 13:11


Несерьёзный оффтоп-пост восторгания нейронками и про нобелевскую

Когда я был студентом МГУ, я увлёкся нелинейной динамикой. Это такая область науки, в которой изучают настолько нелинейные системы, что закон движения хоть и определен, но просчитать движения этих систем теоретически сложно либо просто невозможно, проще моделировать. Но в результате имеем кучу невероятной красоты: фракталы, экспоненциальное разбегание траекторий, хаос, самоорганизацию и вот это всё.

Много нелинейной динамики было в оптике (нелинейная оптика была моей специальностью), и однажды мне попался сборник статей, в котором помимо чисто оптических тем вдруг описывался метод коррекции изображений, из которого я узнал о существовании нейронных сетей. Я мало чего понял, только подумал, что понадобится немало счетного времени нашей альфа-станции, чтоб такое рассчитать даже на сетке 256x256. В это время в лабах стояли 486е и первые “пни”, и 8 мегабайт ОЗУ было роскошью.

И вот в этот момент, когда DEC альфа-станция была предметом гордости, нейронной сети Хопфилда уже было 15 лет! Вот как это пришло в голову людям в конце 70-х, и как они это всё проверяли - для меня загадка. Было понятно, что нейросети это круто, но мало кто понимал - насколько. Вот я вообще не понимал, например. Потом нейросетями стали активно заниматься математики, но если честно, у меня всегда было ощущение, что математики там мало - чистое такое инженерно-физическое моделирование, выход отсюда на вход сюда, о, круто, теперь попробуем это объяснить (или нет). Я и сейчас не очень в этом разбираюсь, но… будто бы всё встало на свои места, когда за нейронки премию дают Хопфилду, физику. Морали никакой нет, просто наблюдение. Ну и за физиков приятно.

System Design & Highload (Alexey Rybak)

07 Oct, 08:25


Uber’s 40M reads/sec: ByteByteGo постит интересную инфографику

Свежая статья ByteByteGo на самом деле рерайт старой большой статьи убера про то, как они сделали свой Integrated Cache / CacheFront на базе MySQL/Redis и еще каких-то мне неясных зверей.

Инсайдер в Убере говорит, что никакой больше публичной информации об этом нет. Интересно, что
- моя наглая критика паттерна кеширования read/write-through этим решением разбивается напрочь (но понятно почему - ведь это не кеш, а комплексное решение)
- если вы не знакомы с CDC (change data capture), обратите внимание, как решается проблема устаревших данных. Какой-то зверь Flux слушает бинлог и трёт кеш (trx log capture – это «ленивая» альтернатива решениям через trx db queue). Сам Flux я слышу впервые, что-то гуглится про Кубер. Знаю про Debezium, про Flux нет.

Вопрос к знатокам: что из CDC сейчас самое топовое, что умеет забрать поток и с MySQL, и с PosgtreSQL?

System Design & Highload (Alexey Rybak)

05 Oct, 15:41


System Design & Highload (Alexey Rybak) pinned «Пост-знакомство Привет! За последнее время в канал пришли много новых ребят. Расскажите в комментариях, кто вы и что вам интересно? А пока о себе: - CTO, предприниматель. Начинал программистом. Окончил физфак МГУ. - 12 лет проработал в Badoo/Bumble (глобальный…»

System Design & Highload (Alexey Rybak)

05 Oct, 15:41


Пост-знакомство

Привет! За последнее время в канал пришли много новых ребят. Расскажите в комментариях, кто вы и что вам интересно?

А пока о себе:
- CTO, предприниматель. Начинал программистом. Окончил физфак МГУ.
- 12 лет проработал в Badoo/Bumble (глобальный и единственный серьёзный конкурент Tinder). С Badoo прошел путь от стартап-камикадзе до CTO. За это время мы выросли до проекта с миллиардной капитализацией, с нуля до 200 млн пользователей.
- Был генеральным директором Московского офиса и активно занимался тех-пиаром Badoo.
- Несколько лет проработал CIO в такси-сервисе “Везёт” (Лидер, Ру-Такси), до самой продажи в Яндекс.Текси, организовал технологическую составляющую сделки. В разные годы работал в Pizza Hut Technology Ventures, Constructor Group, Мамба.

Сейчас работаю над Ed&R&D-платформой devhands.io.
- Запустил несколько супер-продвинутых образовательных треков для программистов, архитекторов и инженеров инфраструктуры.
- Сотрудничаю с венчурными фондами, аудирую, помогаю продавать, покупать и интегрировать стартапы и зрелые компании.
- Слежу за технологиями и продолжаю работать руками (производительность, хайлоад, облака, распределенные системы). Член программного комитета конференции Highload.

Devhands.io: потоки, на которые ещё можно успеть:
- онлайн Итенсив по очередям: Kafka и NATS с Владимиром Перепелицей старт 13-го ноября 2024
- онлайн Системный дизайн высоко-нагруженных проектов
- онлайн хайлоад-буткемп с инфрой Производительность и масштабируемость

Devhands также предоставляет другие услуги:
- CTO-in-residence, Независимый Директор, CEO/CTO адвайзинг
- Запуск бизнесов/подразделений по модели Build-Operate-Transfer
- Аудит и оптимизация стоимости инфраструктуры (для проектов с костами от $300K/год)
- Аудит и внедрение performance review (продуктово-инженерные компании от 100 чел)

Избранные посты для IC:
- Карьера в хайлоад-проекте: часть 1 и часть 2
- Highload: cписок литературы
- CAP-теорема простыми словами
- Разбираем книгу про системный дизайн: часть 1, часть 2
- Как расти бекендеру и как подготовиться к интервью

Избранные посты для MС:
- СТО и CIO
- Удержать нельзя отпустить: часть 1 и часть 2
- CTO не CTO: часть 1 и часть 2
- Вечный вопрос про зарплаты и справедливость
- На чьём плече обезьяна
- О сроках

System Design & Highload (Alexey Rybak)

04 Oct, 11:38


Запись стрима с разбором книги про системный дизайн #2

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

Гости:
- Олег Волчков (Yandex, Ozon, ЖКХ-стартап)
- Михаил Курмаев (Badoo/Bumble, Т-Банк).

В этот раз дошли до 6-й главы и обсудили стратегии кеширования, проектирование ограничителя трафика, консистентное кеширование. В конце немного поездили по “косякам”, поспорили о полезности книги и методу подачи.

https://www.youtube.com/watch?v=ZxG1r5dxcKM
Можно ставить на скорость 1.5 и посмотреть всё за 40 минут.
Комментарии к формату, дополнения, пожелания - горячо привествуются!

Предыдущее видео с разбором первых глав (от нуля до миллиона пользователей, методика оценок посещяемости и нагрузки, общие принципы прохождения интервью) тут: https://www.youtube.com/watch?v=PoS5z9UrPO4

System Design & Highload (Alexey Rybak)

03 Oct, 06:48


Век живи, как говорится. У htop есть realtime-monitor загрузки ядер, который по умолчанию выглядит как эквалайзер: горизонтальный бар переменной длины слева направо.

Если у тебя 48 ядер, это неудобно, ничего не видно. Но можно переключиться вот в такой режим, как на картинке. Псевдо-графика, рисуется «график» нагрузки в области всего 3x4 символа (спасибо за уточнение, Булат)!

Достигается это за счёт всего нескольких готовых символов типа вот таких: ⠉⠛⠿⣿, но сходу в таблицах drawing characters я их почему-то не нашел (https://en.wikipedia.org/wiki/Box-drawing_characters). Кто балуется консольной графикой - можете взять на вооружение.

На графике можно видеть valkey, котрый пытается отдать под миллион RPS в solo-режиме. Как valkey скейлится по ядрам - в следующих постах.

System Design & Highload (Alexey Rybak)

02 Oct, 07:46


BFF: новое или хорошо забытое старое?

В какой-то момент чуваки, которые посчитали, что изоляция важнее всего на свете и решает просто все проблемы, вдруг обнаружили, что женить фронт с труъ-микросервисами, мягко говоря, не очень удобно. И переизобрели технологию, которой лет 20, но, как и принято, дали ей своё новое название – BFF, Backend For Frontend. Ведь бекенд и фронтенд - словно Болик и Лёлик, Вахмурка и Кржмелик (ой, палюсь) - лучшие друзья навсегда, да!

Что это за хрень BFF? Cобирательный образ, который означает следующее: вот всё то говнище, которое “приехало” во фронт из-за МСА, теперь уезжает назад на бекенд, но в отдельный слой, потому что нахер оно в Сияющем Фронте не сдалось, там и так программировать надо слишком много извилин иметь. Ну привет, ребята, вы изобрели архитектуру больших проектов 20-летней давности: внутренние высокопроизводительные сервисы, не торчащие “наружу”, в обвязке из “клея” (обычно скриптового), который довольно жёстко “сцеплен” с фронтом. И ничего плохого ни в этой сцепке, ни в самом клее нет. Просто это теперь как бы так вам сказать … это, граждане, немножочко монолит (но мы это не признаем, потому что уже сильно потратились на этот ярлык, и откатываться нельзя).

Значит, теперь на секциях сисдиза надо заучить и рисовать вот чего: фронт -> SLB -> GW -> BFF -> {MS}. А не, резонный вопрос: нафига нам теперь GW, давайте его сделаем единым с BFF! Вот, оставляю вас теперь с раздумьями, а нужен ли JWT и так ли плохо сессионное хранилище (как часть BFF).

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

System Design & Highload (Alexey Rybak)

30 Sep, 07:23


Devhands Labs: результаты тестирования Redis.

Развенчиваем миф про Redis, который “не скейлится” по ядрам - на картинке.

Скейлится, но так себе. Миллион RPS с Redis-а не в кластерном режиме не отдать. Valkey, PostgreSQL (и надеюсь MySQL, но пока не проверили) – миллион получается. Но об этом – чуть позже :)

Xeon Gold 6312U 24/48vCPU, 128G, (10mln keys) x 256 bytes, redis-benchmark.

А кто хочет получить практику нагрузочного тестирования – приходи на буткемп.

System Design & Highload (Alexey Rybak)

28 Sep, 09:26


Devhands Open Sessions: Cистемный дизайн #2 - теперь с гостями!

Cледующий стрим по системному дизайну уже в следующий четверг, 3-го октября, в 18:00.

Мы продолжим разбирать книжку Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.
Вместе со мной на стрим придут замечательные гости:
◾️Михаил Курмаев. 15 лет развивал платформу в Badoo/Bumble, сейчас в Т-Банке. И скоро выпустит отличный курс на devhands!
◾️Олег Волчков. Работал программистом в Яндексе и тимлидом в Озоне. Сейчас в ролях продукт-менеджера, разработчика и devops'а поднимает ЖКХ-стартап.

В этот раз рассмотрим темы:
◾️Стратегии кеширования и key-value хранилища
◾️Согласованное хэширование
◾️Проектирование хранилища типа “ключ-значение”"
◾️Проектирование ограничителя трафика

Запись, как обычно, через наш бот @devhands_meetup_bot (https://t.me/devhands_meetup_bot). Чтобы записаться, нужно либо нажать на кнопку “Start” в переписке (если только что добавили бота), либо просто написать “/start” (если бот уже в контактах). Важно: если вы уже записывались на наши встречи через бота - обязательно нужно его рестартовать через “/start”, иначе он не пришлёт вам ссылку на комнату и стрим.

До встречи!

P.S. Первый стрим в этой серии: https://www.youtube.com/watch?v=PoS5z9UrPO4
Предыдущие стримы см на YouTube-канале: https://www.youtube.com/@AlexeyRybak
Последний в этом году набор в осенний поток Devhands (системный дизайн, производительность, масштабирование), старт 22-го октября 2024.

System Design & Highload (Alexey Rybak)

27 Sep, 06:52


Видео стрима “Cистемный дизайн” #1

Запись вчерашнего стрима: https://www.youtube.com/live/PoS5z9UrPO4. Осенью разбираем книги (кстати, если вы вдруг что-то не читали – это отличный способ прочитать то, что откладывали). Начал с книги Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.

В этот раз разобрали главы:
* Масштабирование от нуля до миллиона пользователей
* Приблизительные оценки
* Общие принципы прохождения интервью

Комментарии, замечания, пожелания по формату и предложения по дальнейшим книгам - горячо привествуются (пока хочу взять самую базу-базу хайлоада, сюя, кабанчика, видимо и книжку по ахритектурам баз и наверное database internals петрова, но, может быть, старую более фундаментальную – стоунбрейкера, и может быть что-то по производительности Linux Грегга либо старую Мисумеси-Лукидеса например - если это вообще кому-то сейчас интересно).

System Design & Highload (Alexey Rybak)

25 Sep, 10:09


Ребята, редко такое публикую, но вот это – бомба. Яндекс.Облако завезло bare metal. Раньше из больших это делал только Selectel ЕМНИП плюс несколько движовых облаков поменьше типа Таймвеба. Я почему-то был уверен, что крупные гиперскейлеры такое никогда не сделают - был не прав. Возможно, тарифицируется не совсем как dedicated? Изучим.

https://yandex.cloud/ru/blog/posts/2024/09/bare-metal

System Design & Highload (Alexey Rybak)

25 Sep, 08:03


Ещё мифы о хайлоаде

По мотивам споров в комментариях к уютному. Есть ещё два распространенных “мифа” хайлоада.

Первый: коммерческие СУБД значительно превосходят производительность “свободных”. Это очень давно, мягко говоря, не совсем так. Да, есть миллион кейсов, и жаль, нет простого способа это проверить. Может быть, не всегда удобно. С косяками на enterprise-масштабах (сервера по ляму грина за 2-4 юнитовый бокс). С недостаточными гарантиями (спасибо АГ за комментарий). Но если говорить про производительность, то на большинстве OLTP-задач свободные СУБД работают так же производительно, как коммерческие. Если кого-то есть стенды типа моих (Xeon Gold 24/48C, 128G, NVMe) и вы готовы честно “погонять” тесты для современных версии MSSQL/Oracle - напишите, у нас может получиться интересный коллаб.

Второй: те, кто пишут на питоне (любом другом некомпилируемом языке) вообще смешно когда рассуждают о хайлоаде, потому что перейдите сначала на java, c#, c, c++, rust, golang. Верно, что производительность рантаймов компилированных приложений на синтетике может превышать на порядок python/php/ruby. Разберем, однако, что получается в реальности.

Во-первых почти везде уже JIT, или есть или будет, неважно насколько крутой, вода камень точит, поэтому разница на реальном приложении будет уже не порядок просто уже из-за этого. Вон v8 и nodejs так вообще сделал javascript внезапно супер-производительным языком (речь только про производительность, не про экосистему, удобство и тд).

Во-вторых, в современной инфре не-CPU-bound часть кластера (не сервера приложений с вашим кодом) - это грубо примерно 80% костов (в ML-задачах и того выше - спасибо за комментарий АК). То есть большинство оптимизаций всегда приходится на оптимизацию архитектуры и вспомогательных готовых кубиков - СУБД, кешей, очередей. Если вдруг так сошлись звезды и есть два проекта, один на C# другой на PHP и производительность кода вдруг отличается в три раза - это не значит, что инфра для второго будет стоить в 3 раза больше, первый будет “весить” 0.8xCost + 0.2xCost, второй 0.8xCost + 0.6xCost и в результате дельта будет 40%, а не 200%.

Использование же пары языков (второй на наиболее критичные сервисы/модули) или решений типа redis/tarantool, позволяющее в том числе писать достаточно производительные сервисы - и вовсе нивелируют эту разницу.

Это очень грубые прикидки для иллюстрации, пропорции могут быть чуть другими. Посчитайте, поспрашивайте или просто поверьте людям с опытом работы с $-миллиоными костами.

System Design & Highload (Alexey Rybak)

24 Sep, 11:39


Channel name was changed to «System Design & Highload (Alexey Rybak)»

System Design & Highload (Alexey Rybak)

23 Sep, 07:56


Очередной онлайн-стрим: системный дизайн здорового человека

Осенью в Devhands.ru пройдет несколько открытых онлайн-встреч. Назвали это “Системный дизайн здорового человека”. В рамках этих встреч я хочу посмотреть на системный дизайн с очень разных углов – начиная с различных аспектов и акцентов прохождения интервью и заканчивая критикой “инфобиз-движухи” вокруг темы системного дизайна и о влиянии planet-scale клаудов и микросервисного движа на архитектурные способности инженеров и ожидания компаний.

Первая встреча пройдет уже в следующий четверг, 26-го сентября, начало в 18:00. Запись, как обычно, через наш бот @devhands_meetup_bot. Чтобы записаться, нужно либо нажать на кнопку “Start” в переписке (если только что добавили бота), либо просто написать “/start” (если бот уже в контактах). Важно: если вы уже записывались на наши встречи через бота - обязательно нужно его рестартовать через “/start”, иначе он не пришлёт вам ссылку на комнату и стрим.

В четверг мы начнём наши встречи с беспристрастного разбора и даже некоторой критики спорной, но безусловно очень полезной для всей индустрии книжки Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”, ну и вообще затрём за дизайн-сессии на интервью. Записывайтесь через бот - он напомнит и пришлёт все ссылки. Рекомендую приходить в Zoom, потому что сам больше люблю формат беседы, а не вещания.

Встречи провожу в рамках продвижения последнего в этом году набора в DevHands.

Devhands.ru - мой образовательный проект, якорной идеей которого является практика: живые архитектурные брейн-штормы и работа в “self-managed” клауде.

Хардкорная программа с практикой называется онлайн-буткемп “Производительность и масштабируемость”. Вы получаете в собственное управление базовую инфраструктуру для своего стэка, пробуете “выжать” из неё 100.000+ RPS, параллельно знакомитесь с теорией и практикой построения больших проектов и различных “кластерных” решений от простейших схем масштабирования приложений через апстримы прокси до распределенных кешей/СУБД. У нас есть nginx, envoy, angie и haproxy, мы поддерживаем почти любой апп-сервер/рантайм, а в качестве стораджей вы можете развернуть свои или взять предустановленные PostgreSQL-кластер, Redis-кластер и CockroachDB-кластер. И мы на этом не остановимся и в ближайшее время втащим другие популярные продукты. Вы также освоите мониторинг с Prometheus/Graphana и подходы к выявлению “узких” и “тормозящих” мест в вашей системе.

А если совсем нет времени на практику с инфрой - есть трек “Системный дизайн высоко-нагруженных проектов”, где мы разбираем принципы построения больших проектов и проектируем системы на 100 миллионов daily active users (DAU): социальные сети, дейтинг-сайты, маркет-плейсы, мессенжеры, системы доставок и райд-шеринга, фото и видео хостинг, CDN и многие другие - чтобы слушатели на практике научились основным подходам к выявлению и формализации функциональных и нефункциональных требований, проектированию, планированию мощностей.

Если планируете участвовать – не откладывайте, в этом году набора больше не будет. Старт нового потока - в 15-е октября.