Uber, 고성능 추측성 머지 큐 'SubmitQueue' 오픈소스로 공개
Uber SubmitQueue: a high-performance speculative merge queue
Uber가 고성능 추측성 머지 큐(Speculative Merge Queue)인 SubmitQueue를 오픈소스로 공개했습니다. 이 시스템은 대규모 저장소에서 트렁크(trunk)를 항상 그린(green) 상태로 유지하기 위해 설계되었습니다. SubmitQueue는 여러 풀 리퀘스트(PR)를 동시에 테스트하고, 충돌 가능성을 추측하여 병합 순서를 최적화함으로써 CI 대기 시간을 줄이고 개발자 생산성을 높입니다. 이 저장소는 최근 402개의 커밋과 다양한 기능 업데이트를 포함하며, GitHub Actions 워크플로우 개선, ValidationFact 엔티티 추가 등이 포함되어 있습니다.
SubmitQueue는 대규모에서 트렁크를 지속적으로 그린 상태로 유지하는 고성능 추측성 병합 큐입니다.
HN 토론
60- esprehn
Airbnb에는 Uber 논문을 기반으로 한 Evergreen이라는 내부 도구가 있었는데 꽤 훌륭했습니다.
더 많은 회사가 모노레포 인프라를 오픈소스로 공개했으면 좋겠습니다. 잘 구축된 모노레포는 대규모 조직에서 엄청난 생산성 배가 요인인데, OSS 세계에는 인프라가 많이 부족해서 모두가 고통스러운 지점에서 시작하거나 모노레포에 대해 나쁜 인상을 갖게 됩니다. Google의 Piper도 오픈소스로 공개하거나 판매했다면 업계에 큰 도움이 되었을 또 다른 예입니다. 에이전트가 매우 빠르게 코드를 배포하는 시대에 Piper는 이미 상상할 수 없는 커밋 속도를 가지고 있었기 때문에 매우 잘 확장되었습니다. 반면 다른 모든 사람들은 따라잡기 위해 소스 제어를 재구축하려고 노력하고 있습니다.
- sdfhbdf
저장소를 읽어보니 혁신이 무엇인지 좀 어리둥절합니다.
> SubmitQueue는 HEAD의 예측된 미래 상태에 대해 여러 변경 사항을 병렬로 추측성 리베이스하고 검증합니다. 검증이 통과하면 변경 사항이 자동으로 적용됩니다. 실패하면 SubmitQueue는 문제가 있는 변경 사항을 격리하고 나머지를 재시도합니다 — 인간의 개입 없이.
이것은 GitHub의 기능인 것 같습니다 (오래된 엔터프라이즈 서버 설치본에 있습니다) 동일한 작업을 수행합니다:
> 풀 리퀘스트가 병합 대기열에 추가되면 풀 리퀘스트의 변경 사항은 base_branch의 최신 버전과 대기열에서 앞선 풀 리퀘스트의 변경 사항과 함께 merge_group으로 그룹화됩니다. GitHub는 base_branch의 분기 보호에 필요한 검사가 통과되면 이 모든 변경 사항을 base_branch에 병합합니다.
https://docs.github.com/en/repositories/configuring-branches...
모든 사람이 GitHub를 사용하는 것은 아니라는 것을 이해하지만 다른 제공업체에도 유사한 기능이 있다고 확신합니다. 예: https://docs.gitlab.com/ci/pipelines/merge_trains/#enforce-m...
그렇다면 Uber의 것은 무엇이 다르거나 특별한가요?
- kccqzy
대규모에서 트렁크를 지속적으로 그린 상태로 유지하는 것은 아마도 비용이 너무 많이 들 것입니다. Google조차도 google3 모노레포를 지속적으로 빌드 가능한 상태로 유지하지 못하며, 그린 상태는 말할 것도 없습니다. 트렁크를 대부분 그린 상태로 유지하고 마지막 0.1%를 쫓는 것을 멈추고, 대신 자동으로 롤백할 범인을 빠르게 식별하는 도구를 개발하는 것이 더 가치 있습니다.
- jedberg
조정 문제에 대한 해결책은 좋은 모노레포 도구(위 글과 같은)와 AI가 전체 코드베이스를 이해하고 엔지니어가 자신의 부분이 어떻게 맞는지 이해하도록 돕는 것이라고 생각합니다.
저는 마이크로서비스의 가장 큰 지지자 중 한 명이었고, 대규모 기술 컨퍼런스에서 기조 연설을 하며 전 세계를 돌아다니며 마이크로서비스의 복음을 전파했습니다. 저는 마이크로서비스가 대규모 개발자 팀을 확장하는 최고의 솔루션이라고 믿었습니다. 작은 팀이 작은 문제를 해결하고 API가 유일한 계약이 되는 방식이었습니다.
하지만 그때도 저는 오버헤드 때문에 소규모 팀에게는 가치가 없다고 경고했습니다. 대규모 조직의 조정 문제에 대한 해결책이라는 것이었습니다. 그리고 Google은 모노레포 도구에 너무 많은 자원을 투자했기 때문에 반례가 아니라고 말했습니다.
하지만 계산을 바꾸는 새로운 요소가 등장했습니다:
AI는 마이크로서비스 클러스터보다 모노레포를 훨씬 쉽게 이해할 수 있습니다. AI는 여기서 계산을 바꿉니다. AI는 개발자가 가장 큰 모노레포에서도 성공적으로 작업할 수 있게 해주며, 모든 코드가 한 곳에 있을 때 AI 자체가 더 나은 결과를 제공할 것입니다.
- medellin
이것의 기원은 Uber ATC 자율 주행 부서에서 시작되었습니다. 우리는 Phabricator 내부에 원래 제출 큐를 작성했고, 결국 분리되어 별도의 제품이 되었습니다.
작업하면서 모든 엣지 케이스를 발견하는 것은 재미있었습니다.