GitHub, 저장소 하나에 동시 에이전트 5,000개와 초당 7,200 푸시를 처리하는 새 Git 저장 아키텍처 공개

이번 주에 푸시할 때 500 에러 왕창 봤는데 이거 때문이었나. 요즘 장애가 많아서 GitHub 편들기 힘들었는데 나아지면 좋겠다.

잘 읽어보면 이건 미래 대비고 지금 장애를 고치는 건 아닌 것 같은데? 수평 확장 기법은 기존 아키텍처에서 그대로 가져온다고 하고 이건 저장소 내부 확장 얘기잖아. 오늘 가장 바쁜 저장소도 초당 수십 건 버스트라고 인정하고. 지금 문제 해결용은 아니라는 게 맞지?

오히려 비활성 저장소를 디스크에 안 들고 있어도 되니까 컴퓨트랑 디스크 용량이 줄어서 수평 확장 문제도 같이 풀릴 거라고 봄.

개인적으로는 푸시보다 액션 쪽에서 문제가 더 많은 것 같더라.

초당 7,200 푸시라니 저장소 하나에? 그 정도면 에이전트 설정이 완전히 잘못된 거 아님? GitHub는 끝난 작업을 올리는 곳이지 실시간 에이전트 채팅 채널이 아닌데. 차라리 레이트 리밋을 걸어서 PR 단위로만 올리게 하는 게 낫겠음.

포크가 백엔드 저장소를 공유하니까 커널 같은 데는 초당 수천 커밋도 말이 안 되는 얘기는 아님. 봇이 LKML 보고 패치를 각 포크에 적용한다고 생각해봐.

이건 그냥 슬롭임. 코드가 슬롭이면 굳이 커밋할 이유가 있나. 주요 마일스톤에서만 푸시해도 되는데.

내가 상상 가능한 시나리오는 큰 클러스터용 GitOps 저장소뿐임. 서비스마다 이미지 태그 갱신 커밋이 쌓이는 구조인데, 지구상 어떤 프로젝트도 초당 수십 커밋을 정당화하지 못함.

스팸 보내는 계정을 밴하거나 서버 시간을 돈으로 받으면 될 텐데.

분산 소스 관리의 복잡성을 다 떠안고 중앙화의 단점까지 다 가진 게 아이러니하네.

아이러니는 아님. 저장소를 클론하고 그걸 중심으로 또 클론해서 에이전트를 풀면 충분히 분산적임. 끔찍했던 서브버전이랑 비교하면 훨씬 낫지.

대부분 enroute.sh가 이미 한 것과 비슷해 보임. 그쪽 블로그에서 S3 위에 Git 올리는 방법을 다뤘는데.

그럼 GitHub가 Enroute 팀을 그냥 스카우트하는 게 낫겠다.

에이전트 규모 문제는 업계 전체가 고민하는 주제인데 Anthropic의 소스 컨트롤 재설계 글에 GitHub가 뭐라고 답할지 궁금함.

하루에 수천 개 변경이면 사람이 다 못 읽음. 보안 문제가 진짜 생기고 블랙박스가 블랙박스를 만드는 셈임.

Azure 기반이라니. 시장에서 그렇게 안정적이지 않은 클라우드 아님?

무슨 기준으로 불안정하다는 건지. Azure는 역사적으로 99.97% 업타임이고 AWS는 99.95%임. 점유율 2위고. 내부 정치 얘기가 외부 안정성과 같지는 않음.

커졌다는 그 저장소가 어디인지 궁금한데. nixpkgs가 GitHub 입장에서 스트레스 테스트였다고 들었음.

에이전트들이 한 덩어리 저장소에서 협업한다면 Perforce가 더 나을 수도 있음. 테라바이트도 문제없고 파일 단위 배타적 락에 부분 체크아웃도 됨. 에이전트 무리 상대로는 락이 꽤 매력적임.

Git이 아닌 다른 걸 에이전트용으로 준비하는지도 궁금하네.