Платформа GitHub столкнулась с беспрецедентным ростом интенсивности операций в системе Git, вызванным распространением программного обеспечения и ИИ-агентов (AI Agents), которые генерируют непрерывные и плотные потоки правок и обновлений. Чтобы преодолеть физические ограничения по энергоемкости в традиционных центрах обработки данных и цепочках поставок, компания раскрыла архитектурный план, в результате которого копии 99,99999% ее репозиториев уже были перенесены для совместного размещения между ее собственными ЦОД и облаком Microsoft Azure.
Препятствие в виде задержки и полной блокировки репозитория
В GitHub пояснили, что наиболее часто используемые и модифицируемые репозитории на платформе — на которые приходится оставшаяся мизерная доля (0,00001%) — столкнулись с техническим барьером в виде сетевой задержки. При передаче данных в регион Azure Central US, расположенный примерно в тысяче миль от дата-центров платформы, каждое сетевое соединение добавляет около 25 миллисекунд задержки на круговой маршрут (RTT).
В старой архитектуре системы синхронизации и консенсуса Spokes любая новая операция записи требовала наложения глобальной блокировки на уровне всего репозитория (Repository-wide lock) до тех пор, пока реплики (Replicas) не ответят. Из-за удержания глобальной блокировки самая медленная в сетевом плане реплика определяла время отклика и максимальный предел пропускной способности всего репозитория, что приводило к образованию узких мест в активных репозиториях, непрерывно получающих код от разработчиков и ИИ-агентов.
Консенсус на уровне отдельных ссылок
Для устранения этого узкого места GitHub переработала механизм консенсуса, применив свой первый архитектурный принцип: «сокращение координации и устранение ненужных блокировок». Вместо блокировки репозитория целиком во время обновления область консенсуса и блокировки стала применяться исключительно к отдельным ссылкам (Per-reference serialization), таким как ветки (Branches) или теги (Tags).
Поскольку большинство параллельных операций записи, выполняемых разработчиками или ИИ-агентами, направлены на разные ветки, изменениям больше не приходится ожидать друг друга в общей очереди. Внутренние тесты компании в условиях реальных нагрузок показали увеличение пропускной способности операций записи в 3–4 раза при заметном снижении задержек.
Разделение хранения и вычислений и переход на объектное хранилище
Второй этап включает применение второго архитектурного принципа: «разделение хранилища и вычислительных мощностей» (Decoupling storage from compute). Большинство Git-репозиториев характеризуются преобладанием операций чтения над записью: соотношение составляет от 100 до 1 000 операций чтения на каждую операцию записи. В прежней архитектуре чтение и запись конкурировали за одни и те же ресурсы и память.
Чтобы решить эту проблему, GitHub включила объектное хранилище (Azure Blob Storage) в качестве виртуального участника в совет консенсуса под названием «виртуальная реплика записи» (Virtual Write Replica). Эта реплика работает как временный конвейер, который группирует транзакции и непрерывно передает изменения в облачное хранилище. Как только сохранение подтверждено, платформа может запускать неограниченное количество виртуальных реплик чтения (Virtual Read Replicas), масштабируемых по требованию; эти реплики обновляют свой кэш в фоновом режиме, не влияя на скорость записи данных или синхронизации.
Что на практике меняется для инфраструктуры разработки ПО?
Данная инженерная трансформация в GitHub отражает то, как масштабные распределенные системы перерабатываются, чтобы выдерживать автоматизированные рабочие нагрузки на базе ИИ. Основные практические результаты можно свести к следующему:
- Повышение предела пропускной способности: предоставление ИИ-агентам и разработчикам возможности выполнять интенсивные одновременные отправки изменений (push) без блокировки крупных репозиториев.
- Гибкость масштабирования чтения: возможность независимо наращивать серверы чтения и выделять им кэш-память без необходимости прохождения тяжелых процедур консенсуса.
- Непрерывность работы базовой системы: модернизация внутренних компонентов системы Spokes, обрабатывающей более 100 миллиардов операций ежедневно, без необходимости остановки сервиса или риска для целостности данных.