에이전트 규모의 Git 인프라로 가는 가교 - GitHub의 Azure 이전기

GitHub는 저장소 99.99999%의 복사본을 Azure로 이전했으며, 지역 간 지연 때문에 이전이 막힌 고부하 저장소를 위해 쓰기 직렬화 범위를 저장소 전체에서 개별 참조로 바꾸고 있음 참조별 쿼럼은 같은 참조를 수정하는 쓰기만 서로 기다리게 해 서로 다른 브랜치의 동시 쓰기를 허용하며, 현실적인 트래픽을 사용한 내부 테스트에서 처리량이 3~4배 높아지고 지연은 낮아짐 가상 쓰기 복제본은 Azure Blob Storage에 쓰기가 영속화된 뒤에만 완료를 확인하며, 서로 다른 참조의 트랜잭션을 묶어 네트워크 왕복을 공유함 가상 읽기 복제본은 쿼럼에 참여하지 않고 객체 스토리지에서 캐시를 채워 읽기를 처리하므로 쓰기와 독립적으로 확장할 수 있지만, 초기 동기화 방식으로는 모든 읽기 작업을 지원할 수 없음 이후에도 쓰기 쿼럼이 병목으로 남으므로, GitHub는 합의 없이 저장할 수 있는 불변 Git 객체와 순서 보장이 필요한 작은 상태를 구분해 추가적인 쓰기 확장을 추진하고 있음 데이터부터 옮기고 아키텍처를 바꾸는 이전 전략 차세대 Git 저장소 아키텍처의 두 원칙은 조정 최소화와 스토리지와 컴퓨트의 분리임 에이전트 도입에 따른 트래픽 급증, 자체 데이터센터와 주변 지역의 전력 용량 한계, 물리적 공급망 제약 때문에 이전을 서둘러야 했음 가능한 증설을 모두 고려해도 안전하게 이전할 시간은 있었지만, 느리게 진행할 여유는 없었음 클라우드용 확장 아키텍처를 시제품으로 검증했으나, 급격한 성장 속에서 호스팅 플랫폼과 저장소 아키텍처를 동시에 바꾸는 것은 위험이 너무 컸음 Git 작업은 GitHub의 거의 모든 기능이 의존하는 Tier 0 서비스이므로, 데이터와 서비스, 모든 의존성을 먼저 옮기고 아키텍처를 발전시키는 순서를 선택함 첫 저장소 복사본은 2025년 8월 Azure Central US에 도착했으며, 현재 저장소 대부분은 복제본 5개 중 2개가 Azure에 있음 전체 저장소의 99.99999%가 자체 데이터센터와 Azure 양쪽에 복사본을 두고 있음 Azure는 Git 트래픽의 약 절반을 처리하며, 이전 기간 대부분 동안 자체 데이터센터 규모를 유지한 채 트래픽 증가분을 흡수함 저장소 대부분은 내구성, 가용성, 확장성의 균형을 위해 복제본 5개를 사용함 Spokes는 읽기 지연을 줄이기 위해 요청과 같은 지역 및 가용 영역의 복제본으로 우선 라우팅함 복제본을 Azure로 옮길 때마다 Azure가 처리할 수 ...