GitHub, 초당 7,200회 push를 감당하는 새 Git 스토리지 아키텍처 공개
GitHub's new Git storage architecture
GitHub가 'Project Rubicon'이라 부르는 새 Git 스토리지 아키텍처를 공개했다. 내부 테스트에서 하나의 저장소에 5,000개의 에이전트가 동시에 작업하며 초당 7,200회 push를 보내는 상황을 처리했다. 핵심은 Git 객체는 불변이므로 쓰기 대부분은 순서가 필요 없다는 관찰이다. 팩 데이터는 Azure Blob Storage에, 참조 상태는 별도의 복제 로그 서비스 Ref-CAS에 두어 저장과 연산을 분리했고, 가상 레플리카는 캐시만 유지해 장애 시 즉시 교체된다.
Git 객체는 불변이고 내용으로 이름이 붙기 때문에, 두 작성자가 아무것도 합의하지 않고 동시에 저장할 수 있다. push에서 합의가 필요한 부분은 참조 업데이트뿐이며, 그 크기는 비교할 수 없이 작다.
HN 토론
32- dwm
이건 Cursor의 Continuity와 꽤 비슷해 보이는데, GitHub는 쓰기 처리량이 한 자릿수 배 더 크다고 보고하고 있네요.
- yakkomajuri
제가 제대로 이해한 거라면, 이건 (정말 탄탄한) 미래 계획이지 현재의 장애에는 도움이 안 되는 건가요?
헤드라인과 초반 내용만 봐서는 그렇게 생각했는데, 그다음에 수평 확장 기법들은 기본적으로 기존 아키텍처에서 그대로 이어지는 거라고 하더군요 (문제가 있는 것처럼 보이는 곳이죠?). 그리고 이건 주로 그들이 "수직 확장"(레포 내 확장성)이라고 부르는 것에 도움을 주기 위한 거라고 합니다. 바로 뒤에서 오늘날 가장 활발한 레포들도 기껏해야 수십 건의 쓰기가 짧게 몰려올 뿐이라고 인정하기도 하죠.
그래서 이건 가까운 미래를 위한 정말 유용한 계획으로, 아마 더 많은 문제를 예방하는 데 도움이 되겠지만 현재의 문제를 돕기 위한 건 아닌 것 같네요. 제가 제대로 읽은 건가요?
물론 이런 개선은 어느 쪽이든 항상 유용하죠. 비꼬는 거 전혀 아닙니다.
- pksunkara
이것의 대부분은 https://enroute.sh가 이미 Git을 확장했던 방식과 비슷합니다. https://enroute.sh/blog/everyone-is-doing-git-on-s3-wrong
- bob1029
한 덩어리의 거대한 저장소 위에서 다수의 자율 에이전트들이 협업하려 한다면 perforce가 더 나은 VCS일지도 모르겠네요.
여러 테라바이트도 별문제 없이 기본으로 지원됩니다. 파일에 대한 배타적 잠금을 얻을 수 있죠. 모놀리식 저장소의 부분 체크아웃도 쉽게 할 수 있습니다. 이 특정한 맥락에서는 중앙집중화가 장점입니다. Git은 조정이 적당히 필요할 때는 훌륭하게 작동하죠. 하지만 쿠키 단지에 손을 뻗은 수천 명의 자동화된 개발자들이 있다면, 배타적 잠금이 정말 매력적으로 보이기 시작합니다. Perforce는 고도로 분산된 팀에서는 형편없지만, AI 에이전트 군집의 경우에는 필요하면 에이전트의 체크아웃을 즉시 날려버릴 수 있는 능력이 있다고 가정할 수 있습니다. 에이전트에게 연락해서 잠자리에서 일어나기를 기다릴 필요가 없으니까요.
- jxramos
에이전트 규모는 확실히 업계 전반에서 화두인데, GitHub 사람들이 https://www.anthropic.com/research/redesigning-source-contro...에 대해 뭐라고 답할지 궁금하네요. 소스 컨트롤을 근본 원리부터 다시 생각해 보고, 이 새로운 체제에서 어떤 특성이 중요한지에 따라 트레이드오프를 재조정해 보는 흥미로운 읽을거리입니다.