Разработчики, недавно пострадавшие от сбоев в работе GitHub, должны знать, что существуют и другие способы управления Git в масштабе. Один из подходов, недавно реализованный Cursor, заключается в построении распределенной системы контроля версий на основе объектного хранилища.
В недавнем посте главного системного инженера Cursor Висента Марти объясняется, как дочерняя компания SpaceX решала проблемы масштабирования с помощью notoriously fickle распределенной системы контроля версий Git.
В посте объясняется, как Cursor пришел к архитектуре собственного сервиса репозиториев на базе Git под названием Origin, который работает на внутреннем движке Continuity. Бета-версия сервиса доступна в платных тарифах Cursor.
«Агенты фундаментально изменили то, как мы работаем с программным обеспечением, и во многих отношениях они усугубили эту ситуацию. Больше кода, больше PR, больше запусков CI. Контроль версий лежит в основе всего этого, и это, возможно, самое сложное, что можно изменить в одночасье», — написал Марти.
Марти говорит, основываясь на опыте: он проработал в GitHub большую часть последнего десятилетия, когда компания пришла к своей нынешней архитектуре управления Git.
Синхронизация — это сложно
Создатель Git Линус Торвальдс спроектировал свое программное обеспечение как контентно-адресуемое хранилище данных, где все объекты хранятся и индексируются по SHA-1-хешу их содержимого.
Git рассматривает репозиторий как направленный ациклический граф (DAG), где каждый коммит является узлом в графе узлов, соединенных указателями. Сервер Git может найти объект напрямую по его SHA, но если у него нет SHA, то «он должен фактически обходить DAG шаг за шагом», отметил Марти.
Клиент может просто захотеть получить или клонировать консолидированный packfile репозитория или даже получить список последних изменений, но для выполнения этих запросов сервер должен обойти весь граф, чтобы собрать необходимые объекты.
А теперь представьте, что нужно предоставлять такой сервис для более чем 400 миллионов репозиториев, и вы получите представление о масштабах, в которых работает (или с трудом справляется) GitHub.
После некоторых экспериментов инженеры GitHub остановились на том, что они назвали Spokes, что в основном подразумевает хранение как минимум трех тесно синхронизированных копий каждого репозитория на быстрых NVMe-дисках.
Этот подход стал отраслевым стандартом, хотя со временем его ограничения стали очевидны; главное из них заключается в том, что чем больше реплик вы создаете, тем дольше занимает синхронизация. И Git плохо сочетается с «конечной согласованностью», объяснил Марти.
К тому же в наши дни агенты вносят свой хаос.
«Когда агенты работают с репозиториями Git в масштабе, они часто действуют вне монорепозитория, создавая огромное количество маленьких репозиториев, многие из которых одноразовые, и большинство из них едва тронуты», — написал Марти.
Объектные хранилища приходят на помощь
Когда Cursor приступил к созданию собственного Git-репозитория, он обратился к объектному хранилищу. В отличие от файлового или блочного хранилища, объектное хранилище присваивает каждому блоку битов свой уникальный идентификатор и помещает его вместе со всеми остальными в единое пространство имен (без каталогов).
Самым популярным объектным хранилищем на сегодняшний день является Simple Storage Service (S3) от Amazon Web Services, который все чаще используется в качестве базового уровня для корпоративного программного обеспечения, такого как базы данных, реестры контейнеров и брокеры сообщений, благодаря низкой стоимости, встроенной избыточности и, для всех практических целей, бесконечной масштабируемости.
В Origin пуши загружаются в S3 в виде упреждающего журнала (WAL), фиксирующего все изменения как неизменяемые объекты. Там, где это возможно, изменения объединяются для повышения пропускной способности.
Одновременно пуши записываются в локальную «эталонную» копию репозитория (обычно на NVMe-диск). После завершения обоих действий другие реплики репозитория могут загрузить изменения по мере необходимости.
«Поскольку единственным требованием является синхронизация эталонной транзакции с одним локальным репозиторием вместо кворума реплик, мы получаем систему, способную принимать пуши так быстро, как позволяет наш диск», — написал Марти.
Git по-прежнему будет выполнять обход DAG для многих операций, но лучше делать это локально на быстром твердотельном накопителе, чем по сети.
«Где живет каждый репозиторий? Ответ — „где угодно“. Это не имеет значения! Мы рассматриваем репозитории как теплый кеш на диске, но источником истины всегда является упреждающий журнал», — отметил Марти.
Мы увидим, насколько хорошо этот подход сработает, когда Origin перейдет в статус production-сервиса. Но если мы не увидим историй о сбоях Origin, то Git-администраторы будут знать, что стоит серьезно присмотреться к объектным хранилищам. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Joab Jackson
