System Design & Highload (Alexey Rybak)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Всё это очень интересно наблюдать, конкуренция – почти всегда хорошо.

Кейс использования 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, стал не только инструментом тестирования, но и ключевым элементом мониторинга и оптимизации производительности для каждого релиза продукта.

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

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

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

Рабочие будни исследований. Смотрите, вот график числа 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-плагин сохранить ;)

Ребята, внезапно завтра в 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.

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

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

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

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

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

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

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

А пока о себе:
- 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
- Вечный вопрос про зарплаты и справедливость
- На чьём плече обезьяна
- О сроках

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

Первый: коммерческие СУБД значительно превосходят производительность “свободных”. Это очень давно, мягко говоря, не совсем так. Да, есть миллион кейсов, и жаль, нет простого способа это проверить. Может быть, не всегда удобно. С косяками на 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, позволяющее в том числе писать достаточно производительные сервисы - и вовсе нивелируют эту разницу.

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

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

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

Осенью в 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-е октября.