GitHub перенесла почти все репозитории в Azure из-за агентов

GitHub объявила, что 99,99999% её репозиториев теперь одновременно размещены в двух местах: в собственных дата-центрах и в облаке Azure. Компания связывает перенос с «агентным сдвигом»: трафик, который генерируют программные агенты, резко повысил нагрузку на критически важные сервисы платформы.

Первую копию репозитория GitHub разместила в регионе Azure Central US в августе 2025 года. Сейчас у большинства репозиториев две из пяти реплик находятся в Azure, а на эту платформу приходится около половины всего трафика Git. Оставшиеся репозитории относятся к самым активно используемым, и их переносу мешает один фактор: задержка около 25 мс на цикл обмена данными (round trip).

Почему мешает задержка

Для большинства репозиториев создаётся пять реплик в разных регионах и зонах доступности. Сервис Spokes направляет запрос к реплике в том же регионе и зоне, что и источник. Но регион Azure расположен примерно в 1600 км от дата-центров GitHub, а запись требует нескольких циклов обмена, поэтому кворум ожидает ответа от каждой исправной реплики дольше.

Одно из решений — сериализация записи на уровне отдельных ссылок. Порядок операций, нужный Git, сохраняется, а ожидание требуется, только если запись затрагивает одну и ту же ссылку. По внутренним тестам, при записи в разные ссылки пропускная способность растёт в 3–4 раза, а задержки снижаются.

Разделение чтения и записи

В большинстве репозиториев чтение преобладает над записью в пропорции от 100:1 до 1000:1, но сейчас обе операции используют одни и те же ресурсы и конкурируют за память и процессор. Новая архитектура разделяет мощности. На первом этапе объектное хранилище входит в кворум как «виртуальная реплика записи»: она передаёт данные в Azure Blob Storage, не обслуживая чтение, и объединяет транзакции по независимым ссылкам в один пакет операций ввода-вывода.

Затем можно создавать любое число виртуальных реплик чтения, которые наполняют кеш из Azure Blob Storage и не участвуют в кворуме. Поскольку синхронизация идёт в фоне, они подходят не для всех сценариев чтения: для поддержки любых нужен синхронный режим.

Spokes обрабатывает более 100 млрд операций в день, но, по оценке GitHub, его протокол фиксации изменений не рассчитан на рост от миллиарда репозиториев до следующего миллиарда. Следующим ограничением станет пропускная способность записи: каждая операция зависит от реплик с полной копией репозитория, хотя строгого порядка требует лишь малая часть данных.