Alexey Rybak

TL,DR: DevHands расширяется и продолжает отстраиваться от “EdTech”. Сегодня – важный день: на образовательной платформе DevHands стартует первый трек, где я выступаю в роли продюсера и организатора, а не тренера. Это – курс Владимира Перепелицы “Введение в очереди”. И мы продолжаем расширяться: готовятся ещё несколько новых, таких же уникальных треков от крутейших экспертов. Моя цель – сделать ведущий образовательный центр для уже работающих программистов, с упором на практику, на быстрое практическое погружение в конкретный современный стэк, c хорошим R&D и фокусом на исследования и сравнение open source решений. Именно поэтому в курсе Владимира участники на практике знакомятся сразу с 6 различными брокерам сообщений: от мейнстримовых Kafka/RabbitMQ/SQS/Redis до нишевых NATS и Tarantool. Я не позиционировал этот проект так амбициозно с самого начала. Когда я рассказывал друзьям о том, что делаю, я ощущал скепсис: о, и ты подался в инфобиз, был CTO а теперь – препод. Пусть покажет результат 🙂 Сейчас у меня нет сомнений, что именно DevHands становится моей работой “второй половины жизни”. DevHands – не классический EdTech и не хочет им быть. Подавляющее большинство наших курсов – практические, мы выдаем доступ к инфраструктуре в первый же день, и как недавно сказал Олег Бунин, ваш курс – не видео, а контейнер. Отличий от классического EdTech много. Продуктом рулят инженеры. Мы являемся облачным реселлером. Мы сами вкладываемся в open source. В ближайшее время мы запустим настоящий исследовательский трек, где будем публично “выжимать” сотни тысяч и миллионы запросов в секунду из всяко-разного и сравнивать подходы и решения. DevHands – не инфобиз, не “войти в айти”, не продажа видео. Мы – микс R&D, клауд-провайдера и образовательной организации, и насколько я знаю, таких продуктов на рынке сейчас нет: ни на российском, ни на зарубежном. Тем интереснее. Mount /dev/hands!

Saint Highload 2024: Доклад VK про Exim Доклад Максима Уймина - бесспорная жемчужина, идеальный доклад для Highload, чистейший R&D, как сказал ведущий и наш коллега по ПК Саша Белоцерковский. В мейлру почтовый сервер - Exim. У него очень много фичей, которые повторить сложно. Внутри Exim есть очередь, и если ЦОД ляжет - мы можем потерять письма. Решили сделать распределенную очередь: один Exim сохраняет в очередь в разных ДЦ, и другой Exim будет выбирать. Распределенную очередь написали на Тарантуле. Почему не Кафка? В Тарантуле есть приоритеты доставки. Для антиспам-карантина можно реализовать логику «придержи минут на 10», плюс кастомный мониторинг очереди. Итак, очередь - на Тарантуле, а сами письма хранят в zepto - это проприетарная технология VK.. Exim-консумер берет лок на очередь (ренту). После этого процессит: выгружает из zepto само письмо, далее обрабатываем. Если неуспешно - локальную копию убиваем и пробуем через какое-то время. Теперь нужно поменять клиента, чтобы класть данные в очередь. Не стали линковаться со своей либой - не хочется разьезжаться с апстримом и разработкой самого exim, плюс коннекты держать сложно (exim форкается на каждое письмо). Внезапная альтернатива: давайте заменим файловую систему (ФС)! Минус: надо писать ФС, но преимущества: drop-in реплейс, независимый цикл разработки, разруливание конкурентного доступа POSIX-блокировками (просто должны реализовать POSIX-локи в свое ФС). Как писать ФС? Берем фреймворк FUSE (пожертвуем производительностью; FUSE - это прослойка которая инкапсулирует любую ФС через единый API в код user space, не в ядро). Свою ФС тоже решили писать на Тараниуле, рассматривая Тарантул уже как удобный “движок” для С-приложений. Готовые структуры, линеаризованный доступ исключающий гонки, можем на lua, асинхронная многозадачность и демонизация из коробки. Получили ФС как приложение, которое работает по API на базе Тарантула. Теперь в случае отказа делается фейловер. Всего 6 ЦОД - перераспределяем 1/6 нагрузки. Всё это запихнули в Кубер (были определенные тонкости с persistent volumes и правами - это ниже). Мониторинг: почти запросы FUSE укладываются в 100 микросекунд, за исключением некоторых, где мы ходим в сеть, причем по несколько раз. FUSE достаточно быстрый. Итого: - изолировали логику Exim и отделили от него сторадж, стали более надежными - FUSE работает в проде достаточно надежно и быстро - tarantool отличный и как СУБД и как движок для приложений - unshare в Кубере позволил привелегированный сискол использовать в непривелигерованном контексте, не выдавая рута CAP_SYS_ADMIN - что не пропустит ни одна ИБ Пишу этот текст как для посетителей и почитателей любимой конференции Highload, так и с целью промоушена курса “Введение в очереди” Владимира Перепелицы (Владимира, кстати, упомянул Максим в своем докладе, сославшись на его публикации по очередям).

Случай на Хайлоаде Вчера на хайлоаде интересный случай произошел. Пошел я слушать доклад про нагрузочное тестирование от Озона. Ребята открыли свой инструмент - с фокусом на gRPC и HTTP/2. Хотел задать им вопрос про coordinated omission и компенсируют ли они его, но меня кто-то опередил сзади (и получил гиковский приз от автора доклада, посколько “оголил его пробелы в знаниях”). Короче, после доклада подошел знакомиться к парню, который задал вопрос - кто это такой, знает про wrk, coordinated omission, может, новое чего расскажет. Оказалось - наши слушатели хайлоад-курсов из корп-трека Авито. Оттуда говорят и знаем - из ваших курсов. Мораль: ходите к нам, мы хорошие и действительно делимся уникальной экспертизой, которой нет почти ни у кого. Кстати, в группу Владимира Перепелицы (курс “Введение в очереди” с практикой Kafka/RabbitMQ/Redis/NATS и др) - уже заканчивается набор, поторопитесь. Старт курса уже 3 июля (асинхронно, совмещая с работой, ”живые” встречи 1 час в неделю).

Saint Highload 2024

Выложили запись стрима с В. Перепелицей про очереди Отличный был стрим, за что большое спасибо Владимиру и всем, кто пришел! Обсудили: * как выбирать систему очередей * как масштабируются очереди * типичные сценарии выхода из строя системы очередей, и что нужно делать, чтобы этого не произошло * плюсы и минусы очередей, построенных поверх традиционных MVCC СУБД * почему всё-таки “единая шина сообщений” это не SPOF и многое другое Смотрите запись стрима: https://www.youtube.com/watch?v=vx4G0vVlnJk&t=265s И напоминаю, что мы с Владимиром запустили новый курс на платформе DevHands.io – “Ведение в очереди”, уникальный курс, где участники смогут познакомиться сразу со всеми наиболее популярными системами очередей: Kafka, Rabbit, NATS, Redis, а также облачные SQS-like решения и решения поверх СУБД. Курс стартует уже в самом начале июля, и пока на него действует 20% скидка по промокоду ARE_YOU_NATS. Подробнее о курсе – тут (не судите строго, часть материалов, как и новый сайт - в разработке): https://devhands.io/ru/queues.html. А ещё у нас есть “флагманские” курсы: хайлоад-буткемп и курс по системному дизайну высоко-нагруженных проектов.

Очередной онлайн-митап по очередям Техдиры, архитекторы, эксперты, синьоры и та молодая шпана, готовая их стереть с лица земли! В следующую среду, 19-го июня в 18:00 MSK в рамках проекта DevHands.io Open Sessions состоится очередной митап с Владимиром Перепелицей (ex-VK, Trantool) с рабочим названием “В очередь!”, посвященная, как вы возможно догадались, очередям. Владимир - эксперт по большим проектам, очередям и Tarantool, регулярный спикер и член ПК конференций Highload, создатель S3 в VK Cloud, главный по обучению очередям в рамках образовательной платформы DevHands.io. Абсолютное большинство высоконагруженных проектов использует какую-то систему очередей. Межсервисное взаимодействие через системы очередей - невероятно широкая тема, и абсолютно обязательная к изучению всем, кто интересуется архитектурой. Популярных продуктов - таких как Kafka, Rabbit, NATS, и даже, извините, Redis - много, все решения чем-то отличаются, и разработчику важно понимать архитектурные особенности, сильные и слабые стороны компонент, на базе которых строится архитектура. Я пригласил Владимира на онлайн-встречу, чтобы в формате беседы расспросить его о следующем: * Можно ли говорить о существовании универсального подхода к выбору системы очередей? Как принимаются решения о выборе систем очередей? * Какие архитектурные паттерны используются разработчиками систем очередей? Какие «ручки» нужно искать в первую очередь для настроек производительности? Как масштабируются эти системы? * Насколько остро у разработчиков и потребителей персистентных очередей стоят вопросы удаления устаревающих данных, и как они решаются? * Чем плохи (и чем хороши) системы очередей, построенные поверх традиционных MVCC СУБД? Есть ли специализированные «движки очередей» в соответствующих эко-системах? * Что это за задача двух (византийских?) генералов, и какое отношение она имеет к разработке систем очередей? Это не полный список, а всего лишь затравка - приходите и задайте свой вопрос Владимиру, или напишите интересующие вас вопросы в комментариях. Чтобы зарегистрироваться и не пропустить встречу, просто добавьте к себе нашего бота @devhands_meetup_bot и нажмите кнопку “Start” либо отправьте ему сообщение “/start”. Если бот у вас уже добавлен - надо так же его стартовать, чтобы он стартовал по новому расписанию. До встречи 19-го июня!

Менеджер, 7 лет Разбавлю ленту постом из жизни. Участники: дошкольник Данила и его папа, перешедший на еду с жестким лимитом по калориям (доставляют готовые небольшие порции, поэтому еда измеряется коробками). - Папа, даю тебе десять минут, чтобы ты сьел свою коробку - Отлично, я сьем её за пять минут - Тогда я даю тебе 4 минуты - Данила!… Похоже, ты –прирожденный менеджер.

“Темные Паттерны” Игоря Кузнецова Не реклама - дружеская рекомендация. Если вы интересуетесь продуктовой разработкой, маркетингом, growth-хакингом, то хочу вам порекомендовать канал “Темные паттерны” (@brainshare). Его ведет Игорь Кузнецов, мы вместе работали в Badoo. Сейчас Игорь - CPO в VK.Знакомства. Из последнего у Игоря - отличный пост про книгу Ю-Кай Чоу “Actionable Gamification: Beyond Points, Badges, and Leaderboards”. Темные паттерны - это “провоцирующие паттерны”. Они могут нравится, могут не нравится, но это стандарт индустрии, и почти весь growth hacking и тюнинг конверсий - про это самое. В широком смысле это любые приёмы, которые заставляют юзера совершить действие, нужное бизнесу. В канале у Игоря - сотни примеров разной степени эффективности и “темноты”. Must read, если вы в продуктовой разработке.

Трудовые будни разработки: как выстроить эффективный и безопасный процесс. https://youtu.be/aHXqTHOSbco Недавно записали подкаст у Сергея Зинкевича вместе с Дмитрием Симоновым (@ctorecords). Поговорили про CI/CD, релизные боли и фейлы, и даже немного поговорили про безопасность. Рассказал, как я спал под столом во время одного из первых релизов Badoo, и как я люблю иб-консультантов (это правда, любовь с безопасностью на расстоянии - что может быть лучше в бизнесе без вывода денег ;) Времени не хватило, так что возможно встретимся ещё раз. Вообще будни CTO это тема бесконечная - буду рад услышать ваши комментарии или темы для обсуждений на будущее.

Видео с митапа в Тинькове (Engineering Architecture Meetup) Выступал позавчера в Тинькове - видео ниже. Архитектурный митап, тема - “монолит или микросервисы”. За монолит никто не топил, скорее говорили об “особенностях” МСА (микросервисной архитектуры). Мой доклад последний, про особенности МСА применительно к большим проектам: https://www.youtube.com/watch?v=WtEdxvwivbY&t=5353s. Ещё выступал Тимур Баюров (Тиньков) “Определение границ сервисов” и Фил Дельгядо (Lekton.io) с докладом “Пойди туда, не знаю куда. Особенности взаимодействия в распределенных системах”. Мне очень понравились мысли из доклада Тимура про вредность приставки “микро”, транзакционные границы и бизнес-вертикали. По этому поводу не могу не процитировать один из каментов в треде YCombinator: If the thing can encapsulate an entire transaction, then it's taking care of an entire business vertical. What I do agree, it's one of the best ways to partition your services (just after not doing it). But calling this a "microservice" only serves to confuse people (https://news.ycombinator.com/item?id=37219513).