Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-19

1 <blockquote>Никита Галушко, разработчик подразделения Online Shop Lamoda, в онлайн-гостях у учебного центра Слёрм поделился своими впечатлениями от<a>курса по Kafka</a>, рассказал, как используют эту технологию и какие проблемы решают в отделе R&D (Research and Development).</blockquote><blockquote>"Как быстро мы упремся в сетевой канал, который использует Kafka - через года два или раньше?"</blockquote>Lamoda - один из крупнейших интернет-магазинов в России и СНГ. Чтобы покупатели пользовались сайтом без проблем и радовались быстрой отгрузке и доставке, IT-системами в Lamoda занимаются 340 сотрудников: разработчики, QA-инженеры, аналитики, DevOps-специалисты, продуктовые менеджеры, дизайнеры. Узнаем, как в этой системе крутятся винтики.<h2><strong>Расскажи немного о себе. Чем ты занимаешься в Lamoda и сколько уже там работаешь?</strong></h2>

2 Как я люблю говорить: "Я нажимаю на кнопки, и мне за это платят деньги". Нажимаю я на кнопки уже лет шесть. Все это время я пишу на Go. В Lamoda я не так давно, с октября 2020 года, но успел уже выпустить свои щупальца во многие сервисные проекты.<p>Я работаю в отделе RnD (Research and Development) - это отдел, где на одной неделе ты пишешь сервис на Kafka и решаешь вопрос, как сделать распределенную транзакцию между Kafka и PostgreSQL, а на следующей пишешь кодогенератор для Aerospike. Это очень интересная работа.</p>

3 <h2><strong>Я правильно понимаю, что R&D сильно подвязан под аналитику?</strong></h2>

4 Да, мы работаем в тесной связке с дата-сайентистами. Они проводят аналитику, обучают и строят модели, а потом приходят к нам с запросом встроить эти модели в работу приложения или сайта. Например, модель, которая показывает пользователям персонализированный список рекомендаций или подсказывает, какой размер одежды или обуви, скорее всего, подойдет покупателю.<h2><strong>А что из задач тебе нравится в работе? Что для тебя в отделе R&D интересного?</strong></h2>

5 Наверное, это свобода. Ты не ограничен каким-то одним доменом знаний, сервисом или небольшим набором сервисов. В R&D ты можешь делать изменения в сервисе на Go, а на следующий день - изменение на Java. Для кого-то, возможно, это недостаток, так как при таком подходе сложно сфокусироваться на одном сервисе. Но для меня это возможность попробовать свои силы в разных областях, посмотреть, какие подходы разработчики использовали для решения разных задач, почерпнуть для себя что-то новое.<p>Мы совсем недавно начали делать кодогенератор для парсинга результатов работы Aerospike. Так как он отдает сырые данные, то постоянно приходится разбирать их руками. А это потенциальные ошибки и трата драгоценного времени: ты что-то забыл или не проверил, и выходит не тот результат, который ожидаешь. Поэтому мы подумали и решили написать свой кодогенератор. Пока он работает в тестовом режиме, но я надеюсь, что в скором времени мы его заопенсорсим.</p>

6 <h2><strong>А Lamoda часто делает опенсорс-проекты?</strong></h2>

7 У Lamoda есть относительно известный опенсорс-проект <a>Gonkey</a>. Подробнее о нем можно почитать в нашей <a>статье</a>.<p>Gonkey - это стандартизированный набор решений, который позволяет легко писать автотесты на языке разметки Yaml. Это удобно тем, что такие тесты могут писать как разработчики, так и тестировщики, тем самым увеличивая процент покрытия тестами.</p>

8 <p>Сейчас этот инструмент развивается в пределах компании не так стремительно, как хотелось бы, но мы планируем в будущем контрибьютить в него больше времени: закрывать пакеты, которые открывают на github, отвечать на вопросы, улучшать.</p>

9 <p><strong>Скорее всего, для этого надо обладать широким стэком знаний, учиться в два раза больше чем обычно. Так ли это?</strong></p>

10 <p>Я бы сказал, что надо просто обладать широким кругозором.</p>

11 <p><strong>Поверхностно?</strong></p>

12 <p>Не совсем так. Есть такое понятие, как T-shape разработчик. Он очень хорошо, даже отлично, понимает в какой-то одной области, но при этом более или менее разбирается еще в ряде других областей. Я уже сказал, что сейчас пишу на Java, но все же 99% кода я пишу на Go. Поэтому, когда ты очень хорошо знаешь Go-шный стек и при этом умеешь смотреть по сторонам, это хорошо не только при работе в R&D, но и в целом. Ты можешь почерпнуть какие-то идеи и подходы из других технологий и языков.</p>

13 <p>Я знаю людей, которые какое-то время писали на Python, а потом перешли на Go - им понравилось, как этот язык подходит к обработке ошибок. Теперь они пытаются привнести такой же подход и в те проекты, которые пишут на Python.</p>

14 <p>Наверное, у каждого разработчика, который хочет развиваться, нет другого выбора - нужно прокачиваться в разных областях. Вечно сидеть разбираться только в одной узкоспециализированной области у тебя не получится. Если ты хоть где-то работаешь, то нужно развиваться.</p>

15 <h2><strong>Как я понимаю, задачи в R&D разноплановые. Приходилось ли тебе что-то изучать в процессе?</strong></h2>

16 Обучение и развитие со мной, с тех пор как я познакомился с программированием в 10 классе лицея. Я получаю удовольствие, когда узнаю что-то новое или когда о чем-то новом рассказываю остальным. До Lamoda я работал во ВКонтакте и точно так же развивался, читал статьи, проходил курсы, смотрел выступления с конференций.<p>Я не призываю бежать читать книги и самозабвенно развиваться - каждый решает сам для себя. Даже если взять пример одной из моих прошлых работ: мы писали все на Go, а я параллельно смотрел в сторону Rust. Тогда он еще не был таким популярным, а статьи на тему "Go против Rust" из тех далеких времен были мне очень интересны. При этом мне это было не нужно по работе.</p>

17 <h2><strong>Если говорить про работу в Lamoda, то что тебе понадобилось прокачать за последний год, кроме Kafka?</strong></h2>

18 Работа с Kubernetes и написание helm-чартов. Кстати, проходил курс по Kubernetes у вас, потому что до этого я с ним не работал. Обычно это были либо виртуалки, либо физические железки, и все проходило либо через админов, либо ты сам имел доступ, чтобы выкатить deb-пакет. Поэтому пришлось освоить Kubernetes: не на уровне "через kubectl посмотреть состояние pod-a", а на уровне правильного написания helm-чарта и понимания, как оно работает внутри.<h2><strong>Раз уж заговорили о курсах, давай поговорим о Kafka. Зачем ты пошел на курс по Kafka?</strong></h2>

19 Я увидел на сайте баннер: "<a>Скоро курс по Kafka</a>". И подумал: "Надо идти!"<p>Как я уже упоминал, я просто люблю познавать что-то новое. Не надо быть семи пядей во лбу, чтобы на минимальном уровне отправить или прочитать сообщение в Kafka. Но в целом в Lamoda Kafka используется давно и прочно. Поэтому глубокое погружение в эту технологию было для меня неизбежным.</p>

20 <h2><strong>А что для тебя Kafka?</strong></h2>

21 Для меня это распределенный, отказоустойчивый лог с простым интерфейсом взаимодействия, который может прокачать через себя невероятно большой объем данных.<h2><strong>Как Kafka применяется в Lamoda?</strong></h2>

22 Мне кажется, что найти сервис, который не использует как-то Kafka в Lamoda очень сложно. На ней у нас реализован <a>event-bus</a> - это такая шина событий всей Lamoda. Кто-то пишет какие-то события, и любой другой участник, который подсоединен к этой шине, может читать их и как-то на них реагировать.<p>Если говорить про новые проекты, то недавно мы запустили сервис по сбору аналитических данных с бекендов xlog (это его внутреннее название). Тоже через Kafka, так как там требуется высокая пропускная способность всей системы.</p>

23 <p>Еще Kafka нужна для работы с ClickHouse, в котором есть Kafka-engine. То есть мы просто пишем в Kafka, а ClickHouse считывает и записывает к себе данные. Это очень удобно, потому что мы работаем над одним из проектов, где записи в ClickHouse надо делать много и часто. И как мы знаем, ClickHouse не умеет этого делать хорошо из коробки - ему нужен подходящий прокси. Сейчас на рынке есть решение от Яндекса и ВКонтакте, но так как в Lamoda и так хорошая экспертиза в Kafka, мы решили использовать именно ее для связи с ClickHouse.</p>

24 <p>Также мы активно ее используем для разного рода аналитики.</p>

25 <h2><strong>А как команда R&D использует Kafka? Если ты говоришь, что Kafka для тебя - это логи, правильно ли я понимаю, что ты разрабатываешь с помощью нее сервисы, то есть ты работаешь с Kafka Streams?</strong></h2>

26 У нас есть своя обертка над библиотекой по работе с Kafka, которая дает некую абстракцию. А по факту в Go есть каналы: разработчики читают из канала и пишут туда. Они могут даже не задумываться о том, Kafka это или нет.<h2><strong>С какими проблемами в работе с Kafka сталкивался ты и твоя команда? Как пытались их решать?</strong></h2>

27 Сейчас у нас стоит вопрос, как быстро мы упремся в сетевой канал, который использует Kafka - через года два или раньше? И за ним встает другой вопрос: какое сжатие надо включить и для каких топиков в Kafka, чтобы отсрочить эту историю?<p>Условно тот же сервис по сбору аналитических данных - первый кандидат на сжатие. Но мы же не можем просто взять и включить сжатие, потому что это некоторый trade-off между использованием CPU на продьюсерах и консьюмерах.</p>

28 <p>Сейчас я пытаюсь подготовить документ с тестами и анализом. Кстати, в этом мне очень хорошо помог ваш курс, потому что там есть отдельный урок, как бенчмаркать Kafka. В этом документе я хочу отразить, есть ли сейчас необходимость включать на этот сервис компрессию. Если да, то какую именно включать, ведь есть разные алгоритмы сжатия. Мне кажется, это самая явная тема для улучшений.</p>

29 <h2><strong>А текущих горящих проблем с Kafka нет?</strong></h2>

30 Когда мы настраивали работу ClickHouse с Kafka, была проблема в том, что права на describe в группе, которую мы использовали, были выставлены не совсем правильно.<p><strong>Это выглядит менее страшно, чем план упереться в пропускную способность.</strong></p>

31 <p><strong>Спрошу тебя и о том, что я недавно узнал. С версии Kafka 2.8 вышел KIP500 по отказу от ZooKeeper. И я так понимаю, что Kafka упиралась в наличие ZooKeeper, его ограничения. Обещают, что при отказе от ZooKeeper количество партиций увеличится до двух миллионов.</strong></p>

32 <p><strong>Это как-то решает вашу проблему?</strong></p>

33 <p>Если отвечать прямо, то нет, не решает, потому что мы упираемся не в работу Kafka, а в тот сетевой канал, который мы используем до нее. Она легко справляется с тем объемом данных, который мы на нее шлем - канал от этого не меняется.</p>

34 <p>Если говорить про KIP500, то там сделали первый шаг к отказу от ZooKeeper, Но пока это не выглядит надежным решением: резко отказываться от ZooKeeper и переходить на 2.8, наверное, все же не стоит для каких-то более или менее нагруженных продакшен-систем.</p>

35 <p>Тут еще дело в том, что обычно с Kafka имеют дело ops`ы, и им надо понимать, как решать возникающие проблемы. Сейчас они знают: если что-то случилось, им надо пойти сделать что-то определенное в Kafka, а в ZooKeeper - что-то другое. А когда его нет, план по решению проблем не работает, и придется наработать экспертизу в этом вопросе.</p>

36 <h2><strong>Я верно понял: вы упираетесь в сеть и горизонтальное масштабирование Kafka не помогает, то есть это проблема только сети?</strong></h2>

37 В целом Kafka сделана так, что ты будешь упираться в сеть или во что-то другое, но не в ее производительность. Я точно помню, что на курсе об этом говорится, и преподаватели подробно объясняют, почему так. Но мы об этом говорить не будем, чтобы те, кому интересно, пошли смотреть курс.<p><strong>По большой задаче все понятно - пропускная способность. И для решения этой задачи ты пошел на курс, чтобы ее погрумить и принести что-то в команду. Это совпадение или осознанно вышло?</strong></p>

38 <p>Совпадение, потому что я изначально пошел смотреть курс, чтобы не просто узнать, как писать в Kafka. Ведь для хорошей и правильной репликации нужно выставлять правильный acks. Курс погружает тебя во внутренности системы и то, как она работает.</p>

39 <p><strong>Если мы говорим про курс, то там нет разделения на разработчиков и админов. Ты проходил все темы или админские пролистывал?</strong></p>

40 <p>Я проходил все темы, потому что мне все интересно. Я получаю кайф от того, что узнаю новое. Обычно я конспектирую, а через какое-то время я возвращаюсь к этим конспектам, перечитываю, что-то выбрасываю. Если что-то неясно, иду пересматриваю часть курса и переписываю часть конспекта.</p>

41 <p><strong>А практику ты проходил? Тебе было тяжело их выполнять, особенно те, что админские?</strong></p>

42 <p>Я прошел, но пока не все. Нет, там было все достаточно хорошо расписано, как и что нужно сделать и какой результат ожидать. Мне было интересно.</p>

43 <p>В начале используется приложение на Java для некоторых практических работ. Мне было интересно не просто выполнить эту работу, а я потратил какое-то время на изучение кода в Java, который работает с Kafka. Надо смотреть чуть глубже и шире, когда ты проходишь такие практические задания.</p>

44 <p><strong>То есть ты смотришь на технологию.</strong></p>

45 <p>Да. Я когда делал работу по партициям - там было про репликацию. И я подумал, а что будет, если я сделаю несколько иначе. Я потратил время, чтобы поиграться и проверить, что будет, если я выключу одну ноду? А если две? А если я еще что-нибудь сделаю? Это хорошо, что есть стенд для практики, тебе не надо поднимать у себя ничего. На это не надо тратить время.</p>

46 <p><strong>Расскажи, что тебе было интереснее всего? О чем таком ты узнал, чему сильно удивился?</strong></p>

47 <p>Например, что по факту Kafka - это in-memory очередь. Мы привыкли, что базы данных не просто пишут на диск, а еще вызывают fsync, чтобы операционная система сбросила данные на диск. Потому что просто позвать write не гарантирует, что данные запишутся.</p>

48 <p>Kafka этого не делает: она просто зовет write, системный вызов, и все. Просто говорит: "Ты операционная система, ты сама реши, когда это сбросить". И по факту надежность Kafka обеспечивается за счет репликации. Я этого не знал. Я думал, что Kafka вызывает fsync и честно персистит все данные на диск. Вот какая она хитрая.</p>

49 <p>Еще было интересно послушать про проблемы нескольких датацентров.</p>

50 <h2><strong>Твои задачи по пропускной способности. Что у тебя получилось вынести с курса для решения будущих задач?</strong></h2>

51 То, как измерять работу Kafka, и то, как она работает со сжатыми данными. Kafka не разжимает их у себя, а пишет их на диск и как есть отдает потребителям. Это дало понимание, что надо смотреть на затраты на CPU не только на продюсере, который пишет в Kafka, но и на консьюмере, который читает из нее. Ну, и как это правильно бенчмаркать.<h2><strong>А может, было что-то сложное в курсе для тебя? Или какая-то практика была особенно сложная?</strong></h2>

52 Такое точно было: какое-то видео я пересматривал несколько раз. Точно пересматривал про ребалансировку консьюмер-группы. С первого просмотра было не совсем понятно, как это происходит. Я говорю не про простую ребалансировку, а про инкрементальную. Это пришлось пересмотреть и перечитать.<p>Тема сложная сама по себе. Ты посмотрел видео и вроде бы отдаленно ясно, но хочется четко понимать все процессы, поэтому надо пересматривать. Просто посидеть с карандашиком порисовать - тогда осознаешь, что вроде бы все стало ясно.</p>

53 <h2><strong>И в заключение спрошу: что у тебя в планах по обучению и работе?</strong></h2>

54 Я начал вести свой блог. Купил домен и бесплатно поднял его на DigitalOcean - они бесплатно раздают статику. Блог дает мне стимул что-то узнавать, записывать и делиться этим с остальными. Ты понял тему тогда, когда можешь это рассказать кому-то, чтобы он тоже понял.<p>И блог как раз дает навык пересказывания. Сейчас разбираюсь с эффективностью работы GIN индексов. Скоро будет статья на эту тему, которая основана на прошлогоднем выступлении на GolangConf.</p>

55 <p>Всегда нужно смотреть по себе: если есть силы, то почему бы не почитать статью, как устроен Go.</p>

56 <strong>Если вы хотите быстро изучить Apache Kafka и получить обширные знания от экспертов в этой области, Слёрм подготовил 2 готовых курса: <a>Apache Kafka База</a>и <a>Apache Kafka для разработчиков</a>.</strong>