GitHub представив Project Rubicon: нову архітектуру сховища Git для ШІ-агентів

На конференції GitHub Universe сервіс презентував нову архітектуру сховища Git під кодовою назвою Project Rubicon. Вона спроєктована для вертикального масштабування окремих репозиторіїв під навантаженням від автономних ШІ-агентів. Під час внутрішніх тестів система забезпечила одночасну роботу 5000 агентів з одним репозиторієм, приймаючи 7200 пушів на секунду з низькою затримкою на читання.

Принципи Rubicon

Архітектура базується на спостереженні, що Git-обʼєкти незмінні та ідентифікуються за вмістом, тому їх можна зберігати паралельно без координації між вузлами. Погодження потребують лише оновлення посилань (references), які мають невеликий розмір. Головні принципи проєкту — мінімізація координації та розділення обчислень і сховища.

Маршрутизацією та балансуванням запитів, як і раніше, займається сервіс Spokes, але рівень даних під ним переробили:

• Віртуальні репліки (Virtual Replicas) — пул взаємозамінних обчислювальних вузлів, локальні диски яких виконують роль кешу. Вони обслуговують читання та запис і масштабуються за потреби.
• Azure Blob Storage — постійне сховище для незмінних даних: паків (packs), індексів, прискорювачів читання (multi-pack indexes, reachability bitmaps) та кешованих відповідей.
• Ref-CAS (Reference Compare-and-Swap) — виділений реплікований сервіс логів консенсусу для оновлення посилань і маніфесту паків. Він фіксує транзакції через кворум за допомогою compare-and-swap, блокуючи лише ті посилання, які змінюються.
• Флот компактифікації (Compaction Nodes) — фонові вузли, які обʼєднують паки безпосередньо в Blob Storage за допомогою механізму оренди (leases) окремих шардів, не навантажуючи віртуальні репліки.

Як працюють запис і читання

Під час запису віртуальна репліка індексує новий пак, завантажує його в Azure Blob Storage і фіксує одну транзакцію в Ref-CAS. Кожна транзакція отримує номер послідовності логу (LSN).

Під час читання репліка перевіряє актуальність версії посилань у Ref-CAS: якщо стан не змінився, відповідь повертається без передачі даних посилань. Якщо репліка відстала, вона завантажує оновлені посилання та потрібні паки з Blob Storage у свій локальний кеш.

Плани розвитку

GitHub планує оптимізувати архітектуру, зокрема впровадити читання поодиноких обʼєктів без завантаження всього паку, розділення паків за типами (commits, trees, blobs), часткові та глобальні репліки, а також scale-to-zero. Крім того, команда розробляє роботу агентів без повного клонування, атомарний API для комітів кількох файлів і стріми подій.

Наразі Project Rubicon перебуває в обмеженому приватному превʼю, а ширше розгортання заплановане на початок наступного року.