깃허브가 폭증하는 AI 에이전트 트래픽과 데이터센터 전력 한계로 인해 저장소의 99.99999%를 애저 클라우드로 이전하는 작업을 진행 중입니다.
가장 트래픽이 몰리는 0.00001% 저장소의 25ms 지연 병목을 해결하기 위해 쓰기 락 범위를 저장소 전체에서 개별 레퍼런스(브랜치) 단위로 분할했습니다.
이를 통해 브랜치별 쓰기 처리량을 3~4배 높였으며, 향후 스토리지와 컴퓨팅을 분리하는 차세대 아키텍처로 전환할 계획입니다.
요약 깃허브(GitHub)가 최근 급증하는 AI 에이전트 트래픽과 기존 자체 데이터센터의 전력 및 물리적 공급망 한계를 해결하기 위해 전체 저장소를 마이크로소프트 애저(Azure) 클라우드로 이전하는 대규모 인프라 개편을 진행 중이라고 밝혔습니다. 깃허브의 핵심 Git 작업은 시스템 전체가 의존하는 'Tier 0' 서비스인 만큼, 안정성을 위해 데이터와 서비스를 먼저 이전한 뒤 아키텍처를 점진적으로 발전시키는 방식을 채택했습니다. 현재 전체 저장소의 99.99999%는 애저와 기존 데이터센터에 걸쳐 복제본을 두고 있으며, 애저가 전체 트래픽의 절반가량을 처리하고 있습니다.
하지만 가장 트래픽이 집중되는 상위 0.00001%의 저장소들이 문제로 남았습니다. 기존 분산 시스템인 Spokes 아키텍처에서는 저장소 전체 단위로 락(lock)을 걸어 쓰기 작업을 직렬화했고, 정족수(Quorum) 합의 과정에서 가장 응답이 느린 복제본 기준으로 지연 시간이 결정되었습니다. 자체 데이터센터와 애저 간의 물리적 거리(약 1,000마일)로 인해 발생하는 25ms의 왕복 지연 시간 때문에, 쓰기량이 한계에 달한 초대형 저장소들은 이전 시 지연 누적으로 큐가 쌓여 정상 동작이 불가능했던 것입니다.
깃허브는 이를 해결하기 위해 쓰기 직렬화의 단위를 저장소 전체에서 개별 레퍼런스(브랜치 등) 단위로 쪼개는 아키텍처 수정을 도입했습니다. Git 특성상 서로 다른 브랜치에 대한 업데이트는 상호 의존성이 없기 때문에, 개발자나 AI 에이전트가 각자의 브랜치에 푸시하는 대다수의 쓰기 요청을 병렬로 처리할 수 있게 되었습니다. 내부 테스트 결과 서로 다른 레퍼런스에 대한 쓰기 처리량이 낮은 지연 시간에서도 3~4배 향상되었으며, 이를 통해 남은 극소수의 초대형 저장소들까지 애저로 이전할 수 있는 발판을 마련했습니다. 나아가 깃허브는 향후 스토리지와 컴퓨팅을 완전히 분리해 읽기·쓰기 자원을 독립적으로 스케일링하는 차세대 아키텍처로 나아갈 계획입니다.