Решение⁠, Татарстан ,
0

«Не навреди»: как VK мигрировала на современную архитектуру

Юсуп Изрипов, frontend-разработчик
Юсуп Изрипов, frontend-разработчик
Frontend-разработчик* Юсуп Изрипов рассказал, как создавалась модульная архитектура крупнейшей соцсети России

VK перешла с монолитной архитектуры на современный стек. Как удалось добиться бесшовной миграции, РБК Татарстан рассказал Юсуп Изрипов, frontend разработчик, участвовавший в переносе функционала VK.

Для Юсупа Изрипова VK – не первая крупная платформа, где он проводил миграцию с монолитной архитектуры на современные решения. В 2023 году он переписывал на современный стек визуальную часть интерфейса AliExpress Россия, а затем настраивал для этой платформы систему быстрых платежей. В начале 2024 году Юсупа Изрипова пригласили в VK. Вначале он работал над созданием инженерных решений для интерфейса VK Crowd, где пользователи собирают и систематизируют данные, использующиеся для машинного обучения. Через несколько месяцев Юсуп Изрипов перешел на другие задачи — занялся миграцией главных сервисов VK на новую архитектуру.

— Юсуп, вы специализируетесь на высоконагруженной фронтенд-архитектуре и создаете экосистемы для крупных продуктов. Как вы пришли в команду VK? Какие задачи решали?

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

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

— Если быть точными, в VK Crowd пользователи не обучали нейросети, но они размечали данные, которые использовались для ML-процесса. Сам сервис нужен был для организации машинного обучения, это часть инфраструктуры VK, использующаяся в том числе для рекомендательных сервисов. Моя задача заключалась в том, чтобы превратить этот сложный формат в понятный пользовательский продукт, чтобы человек без специальной подготовки мог быстро разобраться в задании, корректно его выполнить, и сама система могла расширяться.

Версия, созданная с моим участием, оказалась очень удачной. Буквально за несколько месяцев метрики зафиксировали увеличение пользовательской активности в 4-5 раз.

— Как вы пришли в проект по миграции сообществ и ленты VK? Зачем нужна была миграция сообществ и ленты VK на современную архитектуру? Какие боли или ограничения старой системы это решало?

— После запуска версии VK Crowd меня пригласили поработать над другими элементами платформы. К 2024 году стало очевидно, что существовавшая архитектура соцсети начинает сдерживать ее развитие. За 18 лет лента, сообщества и другие привычные элементы VK превратились в высоконагруженные системы. Это естественный этап развития – когда на протяжении многих лет продукт растет, скапливается так называемый технический долг – старые решения, которые были актуальны на момент реализации, но со временем стали неэффективными.

В 2024 году в VK началась масштабная миграция систем с легаси на новый стек. То есть, не было такого, что какая-то система не работает, старая архитектура продолжала функционировать, но для развития требовались новые решения.

 В чем конкретно заключалась сама миграция?

— Фактически шло перестраивание блоков, из которых состоит архитектура проекта. То есть, на современные модули переводились все пользовательские сценарии. Я сам работал в командах двух направлений – мы занимались сообществами и лентой. В каждом из направлений была своя специфика. Например, для сообществ переписывался довольно старый код, я видел в нем даже комментарии Николая Дурова, одного из основателей платформы. А в ленте главной особенностью стала колоссальная нагруженность. Главный принцип, которым я всегда руководствовался, – «не навреди».

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

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

— Какие технические и авторские решения вы применили при реализации проектов? Были ли в проектах инновационные подходы, которые впоследствии стали использовать другие разработчики?

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

То есть, на каждую задачу я смотрел, как на инженерную — с контрактами, зонами ответственности, масштабируемостью.

Работая над лентой, я выявил проблему оптимизации комментариев и обнаружил, что в ряде случаев при минимальном действии пользователя происходит ререндеринг всех комментариев на странице. То есть, пользователь ставит лайк комментарию, и у него полностью обновляются абсолютно все комментарии, что усиливает нагрузку на его браузер, для человека со старым телефоном или плохой связью, это неудобно. Под моим руководством эта опция была оптимизирована, чтобы пользовательский опыт стал более гладким. Подчеркну, что это была командная работа – я выявил проблему, другие разработчики перепроверили мои данные, подтвердили их, я предложил решение, оно также неоднократно перепроверялось и реализация тоже велась совместными усилиями, потому что, когда мы говорим о соцсети, которой ежедневно пользуются более 60 млн человек, каждое движение должно быть выверенным на 100%.

— Какие результаты вашей работы мог заметить каждый пользователь VK? Какие перспективы открываются перед проектами, которые вы реализовали? И как, на ваш взгляд, будет развиваться высоконагруженная фронтенд-архитектура в будущем?

— Пользователи редко видят архитектуру, но очень хорошо ощущают ее последствия. Потому что, если новые функции появляются чаще, разные части продукта ведут себя единообразно. То есть, сложные сценарии становятся стабильнее и понятнее. Это и есть результат качественной инженерной работы.

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

* Frontend-разработчик – фронтенд-разработчик

Автор: Артем Тупичкин