GitHub объявила о переносе 99,99999% репозиториев в Azure

GitHub объявила о переносе 99,99999% репозиториев в облако Azure. Платформа объяснила свой переход «агентным сдвигом», когда рост трафика, генерируемого программными агентами, повысил нагрузку на критически важные сервисы.

«За последний год, на фоне экспоненциального роста трафика Git, 99,99999% репозиториев GitHub стали размещаться одновременно в двух местах: в наших собственных дата‑центрах и в Azure. Оставшиеся репозитории — одни из самых активно используемых на платформе, и их переносу мешает лишь один фактор: задержка в 25 мс при обмене данными (round trip)», — сообщила компания.

Первую копию репозитория разместили в регионе Azure Central US в августе 2025 года. Теперь у большинства репозиториев две из пяти реплик находятся в Azure, а на долю этой платформы приходится около половины всего трафика Git. 

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

Если одна из реплик оказывается в целевом регионе Azure — на расстоянии около 1600 км от дата‑центров GitHub, — каждый цикл обмена данными по сети (round trip) занимает примерно 25 мс, а для выполнения записи требуется несколько таких циклов.

Запись с привязкой к конкретной ссылке сохраняет порядок операций, требуемый Git. Как только сервер принимает новое значение, клиент видит либо это значение, либо более позднее. Между независимыми ссылками требования к согласованности отсутствуют.

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

По данным внутреннего тестирования было зафиксировано, что при записи в разные ссылки пропускная способность возрастает в 3–4 раза, а задержки снижаются.

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

На первом этапе объектное хранилище включается в состав кворума в качестве «виртуальной реплики записи» — временного узла, который передаёт входящие данные записи в Azure Blob Storage, но не обслуживает запросы на чтение. Spokes включает этот узел в кворум и отправляет подтверждение записи клиенту после того, как данные будут сохранены в объектном хранилище.

Виртуальная реплика записи также объединяет транзакции, затрагивающие независимые ссылки, в единый пакет сетевых операций ввода‑вывода при обращении к объектному хранилищу. 

Использование виртуальных реплик записи позволяет по мере необходимости масштабировать систему, создавая любое количество виртуальных реплик чтения. Каждая такая реплика наполняет свой кеш данными из Azure Blob Storage и начинает обслуживать запросы на чтение, не становясь участником кворума. 

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

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

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