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

> Источник: 404 Media. Канонический URL: https://404-media.ru/tehnologii/github-perenesla-pochti-vse-repozitorii-v-azure-iz-za-rosta-agentnogo-trafika

GitHub разместила 99,99999% репозиториев одновременно в собственных дата-центрах и Azure, перераспределив нагрузку и изменив архитектуру записи и чтения.

- Рубрика: Технологии (https://404-media.ru/tehnologii)
- Опубликовано: 2026-10-23T16:00:32+03:00
- HTML: https://404-media.ru/tehnologii/github-perenesla-pochti-vse-repozitorii-v-azure-iz-za-rosta-agentnogo-trafika
- Markdown: https://404-media.ru/tehnologii/github-perenesla-pochti-vse-repozitorii-v-azure-iz-za-rosta-agentnogo-trafika.md
- llms.txt: https://404-media.ru/llms.txt

![GitHub перенесла почти все репозитории в Azure из-за роста агентного трафика](https://storage.yandexcloud.net/404-media/media/2026/10/Bj2aAT51h26xxZfhlm4KioJ9KvRr2xsoXI71xuRB.jpg)

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

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

## Зачем GitHub понадобилась новая схема репликации

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

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

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

## Разделение операций чтения и записи

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

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

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

Для чтения GitHub может создавать любое количество виртуальных реплик. Каждая из них заполняет собственный кеш данными из Azure Blob Storage и начинает обслуживать запросы, не участвуя в кворуме. Однако синхронизация таких реплик выполняется в фоновом режиме, поэтому они подходят не для всех сценариев чтения. Для рабочих нагрузок, требующих более строгих гарантий, синхронизацию нужно перевести в синхронный режим.

## Главное ограничение — масштабирование записи

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

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