GitHub의 새 Git 스토리지 아키텍처 - 저장소 하나에서 초당 7,200회 푸시를 처리

GitHub의 새 스토리지 아키텍처 Rubicon은 단일 저장소에 에이전트 5,000개가 초당 7,200회 푸시하는 동안 읽기 지연 시간을 낮게 유지함 불변 Git 객체는 Azure Blob Storage에 병렬로 저장하고, 브랜치가 가리키는 커밋처럼 갱신 순서를 조정해야 하는 참조는 Ref-CAS에서 관리함 Ref-CAS는 각 푸시가 바꾸는 참조만 잠그고, 로그 복제본 과반수가 기록하면 변경을 확정. 에이전트가 각자 다른 브랜치에 푸시하면 대부분 서로 기다릴 필요가 없으며, 읽기 시 참조 상태가 최신이면 버전 비교 한 번으로 확인을 마침 요청 처리와 팩 병합을 별도 노드에 맡겨 각각 필요한 만큼 확장함. 백그라운드에서 여러 샤드의 팩을 병렬로 합쳐 푸시가 늘어도 조회할 팩 수를 거의 일정하게 유지함 개발자의 push/fetch/브랜치 작업과 기존 보호 장치는 그대로 유지하며 현재 제한적 비공개 프리뷰로 2027년 초 확대 배포 예정 후속 기능으로 저장소 전체를 클론하지 않고 필요한 파일만 읽는 작업 방식과 여러 파일을 한 번에 반영하는 커밋 API를 계획중 에이전트 규모를 위한 설계 요구사항 설계의 출발점은 조정 최소화와 스토리지와 컴퓨팅의 분리임 첫 번째 글에서 두 원칙을 정립함 이전 단계에서는 저장소 99.99999%를 Azure로 옮기고, 쓰기 쿼럼을 개별 참조 단위로 좁혔으며, Azure Blob Storage 기반 가상 복제본을 도입함 가상 복제본은 저장소를 새 아키텍처로 편입하는 수단이기도 함 Git 객체는 불변이며 내용으로 이름이 결정되므로, 여러 작성자가 서로 합의하지 않고 동시에 저장할 수 있음 푸시에서 합의가 필요한 부분은 객체 데이터에 비해 매우 작은 참조 업데이트뿐임 확장성은 두 축으로 나눔 수평 확장은 여러 저장소에서 작업하는 개발자와 에이전트의 수를 늘리는 것으로, 기존 테넌트 분할, 트래픽 격리와 공정성 보장, 부하 기반 라우팅을 계승함 수직 확장은 하나의 저장소에서 작업하는 개발자와 에이전트의 수를 늘리는 것으로, 에이전트에 따른 저장소 크기와 활동량 증가를 예상해 새 요구사항 대부분을 이 축에서 도출함 현재 가장 바쁜 저장소도 짧은 순간에 초당 수십 회 쓰기가 발생하는 수준이지만, GitHub는 병렬로 상시 실행되는 에이전트 때문에 향후 1년 안에 이것이 지속적인 처리율이 될 것으로 예상함 푸시마다 CI, 배포 시스템, 다른 에이전트의 fetch가 뒤따르므로 읽기 요청이 분기되며...