🚀 Реальные инженерные вызовы: создание Cursor (часть 2)

🗄️ 6. Миграции баз данных по необходимости

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

От Yugabyte к Postgres на AWS RDS

На раннем этапе Cursor хранил структуры данных дерева Меркла в Yugabyte, PostgreSQL-совместимой распределенной базе данных. Они выбрали Yugabyte из-за обещания, что база данных будет масштабироваться бесконечно. Суалех делится:

"Когда я был в MIT, я был большим фанатом баз данных. В мире баз данных есть несколько удивительных баз данных, которые вы считаете решением всех ваших проблем:
• Google Spanner: база данных, известная работой в масштабе Google
• FoundationDB: распределенная и высокомасштабируемая база данных
• Key-value хранилища, такие как Redis, которые также известны хорошим масштабированием

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

Я решил выбрать Yugabyte, потому что она была построена на тех же принципах, что и Google Spanner, и предлагает аналогичные возможности масштабируемости."

Однако команда быстро столкнулась с проблемой: Yugabyte не работал, как ожидалось. Суалех:

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

Оказалось, что нам не нужна была глобально распределенная база данных в то время, а что-то гораздо более простое. Поэтому мы перешли на Postgres, размещенный на Amazon Relational Database Service (RDS). Перенос той же рабочей нагрузки внезапно заставил ее работать как по маслу.

Урок жизни в том, что для баз данных вам может быть лучше избегать сложных, по крайней мере изначально. Начните с Postgres, и это приведет вас действительно далеко."

От Postgres на AWS RDS к Turbopuffer

Postgres работал действительно хорошо почти год — пока внезапно не перестал. Однажды в 2024 году система сошла с ума: коэффициенты промахов кеша выросли, рабочие процессы эмбеддингов боролись; все пошло не так. Оповещения базы данных срабатывали направо и налево, предупреждая о достижении лимитов хранилища. Суалех вспоминает:

"Мы были на 22TB данных, хранящихся в AWS RDS, и RDS имел лимит в 64TB. Я предполагал, что у нас есть пара месяцев, пока наша база данных не станет достаточно большой, чтобы нужно было мигрировать. Я имею в виду 20 из 60: это не так уж плохо, верно?

Ну, оказалось, что хранилище отличается для Postgres. Когда пользователь удаляет или изменяет файл в своем рабочем пространстве, мы обновляем запись, хранящую дерево Меркла в Postgres.

Одно из различий между Postgres и MySQL заключается в том, что при обновлении записи: • MySQL обновляет запись на месте • Postgres выполняет отдельную операцию удаления и отдельную операцию добавления

В нашем случае наша рабочая нагрузка — это люди, которые печатают, поэтому мы видим огромное количество обновлений в базе данных. Это переводится в огромное количество удалений и добавлений!"

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

Cursor обратился в службу поддержки AWS, но это никуда не привело. Они все же дошли до архитекторов AWS, которые построили RDS. Суалех продолжает историю:

"Итак, теперь мы говорим с архитекторами AWS, которые построили RDS, которые говорят нам, что мы — единственный самый большой RDS-инстанс, работающий на AWS. Они говорят что-то вроде: 'ну, к сожалению, мы не можем сказать вам ничего, кроме того, что у вас большие проблемы.'

Поэтому мы решили сделать несколько вещей параллельно, чтобы вернуть сервис:

🔸 Один инженер изучает удаление всех Foreign Keys в базе данных: они добавляют "приятные" функции, но добавляют много нагрузки на базу данных

🔸 Другой инженер изучает каким-то образом удаление самой большой таблицы. Из 22TB одна таблица занимает 20TB. Один из наших соучредителей, Арвид, засучивает рукава и изучает перенос этой таблицы из Postgres и пытается переместить ее в object storage

🔸 Больше инженеров пытаются уменьшить нагрузку на базу данных

Затем происходит что-то неожиданное: рабочий поток #2 заканчивается намного быстрее, чем любой из других рабочих потоков. Арвид сумел переместить 20TB рабочей нагрузки с Postgres на Turbopuffer. В этот момент мы примерно 10 часов в SEV [инциденте], и это новое решение, кажется, работает, в то время как наша существующая база данных все еще не работает.

Поэтому мы принимаем решение сделать живую перезапись и начинаем перемещать значительную часть эмбеддингов в blob storage, работающее на Turbopuffer. И это работает! 🎉

Лучший способ масштабировать базу данных — не иметь базы данных — по крайней мере, когда вы работаете в том масштабе, в котором мы работали!"

🏗️ 7. Инженерная культура и процессы

Новый релиз каждые 2-4 недели

Cursor необычен среди стартапов, потому что они делают новый релиз каждые 2-4 недели. Большинство быстро движущихся, высокорастущих стартапов релизят несколько раз в день: так почему не Cursor? Ну, это не веб-приложение, а толстый клиент (кроссплатформенное десктопное приложение). Суалех называет то, что они строят, "локальным программным обеспечением":

"Локальное программное обеспечение, подобное нашему, ощущается как медленно умирающее искусство. Большинство крупных компаний, как правило, управляют сервисами, ориентированными на бэкенд, где они часто выпускают функции.

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

🚩 Консервативное использование feature flags

Cursor использует feature flags в продукте, но довольно отличается от большинства стартапов! Их реализация feature flags была вдохновлена препроцессором Pragma в C, согласно Суалеху. Feature flags, распространенные по их коду, обычно предназначены только для внутреннего использования и сборок.

По умолчанию Cursor удаляет весь код, защищенный feature flags, благодаря ведению их списка. Суалех говорит, что они решили использовать гораздо более консервативный подход к feature flagging, чтобы избежать случайной отправки сломанных функций клиентам.

👥 Выделенная инфраструктурная команда

Учитывая массивную инфраструктурную нагрузку, которую видит Cursor, более 1 млн QPS для своей базы данных, и управление десятками тысяч GPU в нескольких облаках, я задавался вопросом, есть ли у компании выделенная инфраструктурная команда. Вот что сказал мне Суалех:

"В инфраструктурной команде 15 инженеров. Команда существует с самого начала компании. Их основные обязанности:
• Базы данных
• Потоковая передача
• Планирование вычислений
• Масштабирование обучения и инференса
• Надежность"

Cursor также нанял сильных инженеров с глубокой экспертизой и интересом к инфраструктуре. Например, Аман Канами был VP Infrastructure в GitHub, прежде чем присоединиться к Cursor в прошлом сентябре в качестве principal engineer.

📞 Дежурство: не жесткий процесс

Я спросил Суалеха, как работает дежурство:

"У нас есть команда высококвалифицированных и совместных инженеров: каждый из нас обрабатывает потребности дежурства как часть наших более широких обязанностей.

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

🧪 Культура экспериментов и повышения продуктивности инженеров

Суалех:

"У нас есть культура экспериментов, где мы поощряем всех придумывать и пробовать новые вещи, и пробовать их внутренне сначала. Поскольку мы тестируем все сами сначала, это нормально, если эксперимент — полная катастрофа!

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

🎯 Интересный инженерный вызов впереди

Я спросил Суалеха, какое проблемное пространство его больше всего волнует решать, и он ответил, что это масштабирование стека обучения Cursor до крупномасштабного обучения с подкреплением (RL). Правильное решение этого потребует много работы.

Для "обычного" обучения модели вы обычно делаете прямой проход и обратный проход через несколько тысяч GPU. Прямые и обратные проходы, как правило, довольно легкие: это тысячи GPU усложняют вещи.

Обучение с подкреплением (RL) не имеет единого "прямого прохода". Вместо этого у него есть среда, которую вы готовите в "горячем цикле". Есть несколько компонентов для настройки:

🔸 Среды: где машина выполняет команды и взаимодействует с кодовой базой 🔸 Цикл вознаграждения: выбор того, как дать вознаграждение агенту, не тривиален! 🔸 Сервер инференса: вам нужно настроить инференс так, чтобы он генерировал траектории из модели 🔸 Сервер обучения: среда для запуска всего этого в цикле

Все четыре компонента сложны и взаимодействуют друг с другом:

• Модель делает шаг обучения
• Эта модель передается на GPU инференса — размер модели может легко составлять 1,5TB! 💾
• Шаги инференса вычисляются GPU для RL промпта
• Шаги инференса передаются в среду, и среда выполняет шаг
• Вознаграждение вычисляется на основе результата из среды
• Результат вознаграждения затем решает следующий шаг обучения
• ...и каждый из вышеперечисленных шагов работает на нескольких тысячах GPU! 🖥️

Суалех резюмирует:

"Крупномасштабное RL — это гораздо более интересная проблема масштабирования, чем пре- и пост-обучение, по моему опыту. Это требует много работы!"

📝 Выводы

Большое спасибо Суалеху за то, что поделился всеми этими деталями о том, как работает Cursor. Траектория роста компании определенно является выбросом, поскольку такой быстрый рост использования и выручки крайне редок. Держа это в уме, есть несколько интересных выводов:

🏆 Маленькие, но опытные команды могут исключительно хорошо выполнять работу

Команда Cursor крошечная по сравнению с ее использованием и выручкой, и этот небольшой размер может объяснить, почему они движутся так быстро и опережают гораздо более крупные организации, такие как GitHub Copilot.

☁️ Используйте облачных провайдеров при быстром масштабировании

Одна из причин, по которой Cursor может поддерживать небольшую инженерную команду, заключается в том, что они "аутсорсят" многие инфраструктурные вызовы облачным провайдерам. Инженерной команде Cursor не нужно иметь дело с шардингом данных, потому что платформы, которые они используют, заботятся об этом за них!

⚠️ Остерегайтесь использования небольших стартапов при быстром масштабировании

Суалех сказал мне, что одним из основных уроков было то, что использование стартапов для инфраструктуры — это огромный риск при быстром росте. Команда Cursor обжигалась несколько раз и научилась доверять предложениям от "гиперскейлеров", таких как AWS, Azure и GCP.

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

🎯 Гораздо легче создать продукт, когда строишь для своих инженеров

Cursor не нужно иметь продакт-менеджеров или бизнес-стратегов пока, потому что их основные клиенты — это те же люди, которые его создают: инженеры-программисты! 👨‍💻

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

🥇 Вы можете превзойти даже самых больших игроков в технологиях

Microsoft имеет огромное преимущество в дистрибуции, корпоративных продажах, финансировании и в количестве опытных инженеров, работающих над продуктами, такими как VS Code и GitHub Copilot.

И все же 50-человеческая инженерная команда Cursor превзошла VS Code и GitHub Copilot за последние два года. Хотя Cursor начинался как форк VS Code, теперь это предпочтительный способ работы для многих инженеров. Cursor достиг этого без какого-либо значительного маркетинга, кроме "сарафанного радио", ставя потребности инженеров-программистов на первое место. 🗣️

Поздравления команде с превосходным выполнением до сих пор; я с нетерпением жду больше инноваций от них! 🎉

Эта статья является частью серии "Реальные инженерные вызовы". Читайте другие, похожие глубокие погружения.

Источник: The Pragmatic Engineer Newsletter

Автор: Gergely Orosz

Дата: 10 июня 2025 г.