GitHub перевела 99,99999% репозиториев в облако Azure

GitHub официально перевела 99,99999% репозиториев в облако Azure. Цифры говорят сами. Первая копия данных появилась в регионе Central US ещё в августе 2025 года, и сейчас две из пяти реплик большинства проектов живут в облаке, обрабатывая около половины всего Git-трафика платформы.

Фактически причина этого шага кроется в так называемом «агентном сдвиге». Грубо говоря, экспоненциальный рост трафика от программных ИИ-агентов просто продавил старые лимиты. Собственные дата-центры уперлись в жесткие ограничения по энергопотреблению. А цепочки поставок оборудования работали с задержками, вынудив экстренно задействовать мощности стороннего облака для спасения сервисов уровня Tier 0. В GitHub описывают эту масштабную работу как необходимый «мост» между текущей архитектурой Spokes и следующей моделью хранения данных.

Этот процесс не обошёлся без сложностей. Оставшийся крошечный процент репозиториев — это самые крупные и сверхактивные проекты платформы. Физика диктует условия. Их полному переезду мешает задержка около 25 миллисекунд при межрегиональном обмене данными. Расстояние в полторы тысячи километров до целевого региона Azure превращает каждый сетевой цикл в узкое горлышко. Ведь сервис Spokes требует подтверждения от кворума реплик. И самая медленная из них блокирует операции push для всего репозитория, если тот уже работает на пределе своей пропускной способности.

«Оставшиеся репозитории — одни из самых активно используемых на платформе, и их переносу мешает лишь задержка при обмене данными», — пояснили в компании.

Нашли инженеры изящный выход, изменив область действия кворума. Теперь блокировка распространяется не на весь репозиторий целиком, а строго на отдельные ссылки. Git предполагает наличие определённой последовательности событий для каждой ветки или тега, но между независимыми ссылками требования к согласованности полностью отсутствуют. На практике это выглядит так: когда разработчики или боты пушат изменения в разные ветки, их операции больше не ждут друг друга в общей очереди. Внутренние тесты показали, что при записи в разные ссылки пропускная способность взлетает в 3–4 раза, а задержки заметно падают.

Объектное хранилище теперь включается в кворум как «виртуальная реплика записи». Этот временный узел просто сбрасывает входящие данные в Azure Blob Storage, не отвлекаясь на чтение. Более того, виртуальная реплика записи объединяет транзакции, затрагивающие независимые ссылки, в единый пакет сетевых операций ввода-вывода. Такой подход позволяет отделить вычислительные ресурсы от хранилища, создавая по мере необходимости десятки виртуальных реплик чтения, которые наполняют свой кэш в фоновом режиме.

Опиралась платформа ранее исключительно на собственные мощности, выстраивая сложную систему синхронизации. Но соотношение операций чтения к записи в реальных проектах часто достигает 1000:1. Заставлять одни и те же сервера бороться за процессорное время и память при таких нагрузках — прямой путь к деградации производительности. Разделение потоков стало неизбежным эволюционным шагом для сохранения стабильности, поскольку фоновая синхронизация подходит не для всех видов рабочих нагрузок, связанных с чтением. Для поддержки любых операций процесс синхронизации должен быть переведён в строгий синхронный режим.

Руководство компании обещает раскрыть больше технических инсайсов на конференции GitHub Universe. Протокол фиксации изменений Spokes, обрабатывающий сейчас более 100 млрд операций в день, всё равно упрётся в новый потолок пропускной способности. Упорядочить данные максимально быстро, не создав затор в другом звене системы, — задача, которую ещё только предстоит решить.

Никита Карпов

Главный редактор

Пишу о гаджетах, нейросетях и том, как технологии меняют нашу жизнь. Проверяю всё на себе, чтобы вы не тратили деньги зря.