OpenAI의 Git 확장: Pando가 페타바이트 규모의 처리량을 달성하는 방법

TL;DR

OpenAI는 표준 Git 클라이언트를 그대로 유지하면서도 푸시 지연 시간을 5배 줄이고 매일 페타바이트 규모의 데이터를 전송할 수 있는 맞춤형 Git 백엔드인 Pando를 구축했습니다. 이는 저장소 전체의 일관성을 완화하고 클라이언트 간에 팩파일(packfile)을 재사용함으로써 가능해졌습니다.

OpenAI가 새로운 Git 백엔드를 필요로 했던 이유

  • Codex를 통해 많은 엔지니어가 병렬로 작업하게 되면서 브랜치, 푸시, 병합, 페치(fetch)의 수가 폭발적으로 증가했습니다.
  • 2023년 말, 모노레포는 느린 푸시, 병합 실패, 90% 미만의 신뢰성 문제로 어려움을 겪었습니다.
  • 기존의 확장 방식(3단계 커밋 또는 공유 쓰기 전 로그)은 여전히 전역 조정이나 단일 매니페스트를 필요로 했으며, 이는 동시 쓰기나 읽기에 병목 현상을 일으켰습니다.
  • OpenAI는 개선 사항이 더 넓은 커뮤니티에 도움이 될 수 있도록 Git 호환 워크플로우를 유지하고자 했습니다.

"우리는 익숙한 워크플로우를 유지하면서도, 서로 다른 브랜치에 대한 푸시를 병렬로 처리하고 동일한 기록을 많은 독자에게 동시에 제공할 수 있도록 백엔드를 재구축하는 방법을 찾았습니다." – OpenAI 블로그

Pando의 핵심 설계 목표

  1. 수평적 쓰기 확장성 – 전역 잠금 없이 많은 브랜치를 동시에 업데이트할 수 있도록 합니다.
  2. 최대 읽기 처리량 – 동일한 팩파일을 많은 클라이언트에 제공하여 네트워크 대역폭을 최대한 활용합니다.
  3. Git 프로토콜 호환성 – 기존 클라이언트 도구에 대한 변경 사항이 필요 없습니다.

아키텍처 혁신

1. 전역 일관성 대신 인과적 일관성(Causal Consistency)

  • 각 브랜치 업데이트는 업로드된 팩파일과 그 종속성을 가리키는 불변의 *참조 버전(ref version)*을 생성합니다.
  • 쓰기는 참조별로 직렬화 가능하며, 동일한 브랜치에 대한 푸시만 충돌합니다.
  • 독자는 인과적으로 일관된 뷰를 봅니다. 서로 다른 브랜치는 서로 다른 시점을 반영할 수 있는데, 이는 개발자가 전역 스냅샷이 아닌 단일 참조에 대한 업데이트 순서를 중요하게 생각하는 실제 사용 사례와 일치합니다.

2. 클라이언트 간 팩파일 재사용

  • 푸시는 확장 가능한 객체 저장소에 불변의 블롭(blob)으로 저장됩니다.
  • 페치는 클라이언트의 have/want 세트를 필요한 객체가 이미 포함된 저장된 팩파일에 매핑합니다.
  • Git 프로토콜의 packfile-uri 확장을 통해 서버는 미리 존재하는 여러 팩에 대한 URL을 반환하여 즉석에서 팩을 생성하는 과정을 피할 수 있습니다.
  • 결과: 읽기 측의 CPU와 I/O가 획기적으로 감소하며, 단일 팩으로 수천 번의 페치를 만족시킬 수 있습니다.

3. 계층적 압축(L0-L4)

  • 모든 푸시는 L0 팩(가장 작은 단위)을 생성합니다.
  • 백그라운드 작업자는 로그 구조 병합 트리(log-structured-merge-tree) 스타일 알고리즘을 사용하여 팩을 더 큰 *커버(covers, L1-L4)*로 병합합니다.
  • 커버는 페치 계획을 위한 스킵 리스트 역할을 하여 log-Δ 메타데이터 조회를 가능하게 합니다. 여기서 Δ는 클라이언트의 현재 팁과 원하는 팁 사이의 거리입니다.
  • 압축은 압축률을 향상시키고 클라이언트가 다운로드해야 하는 팩 URI의 수를 줄입니다.

기존 방식과의 비교

방식 쓰기 병목 읽기 병목 일관성 모델
3단계 커밋 (3PC) 복제본 간 전역 쿼럼; 관련 없는 브랜치에 대한 푸시가 직렬화됨. 읽기는 빠르지만(로컬 복제본), 쓰기 부하가 높으면 복제본 디스크가 포화됨. 모든 참조의 강력한 시점 스냅샷.
쓰기 전 로그 (WAL) 단일 매니페스트 업데이트; 비교 후 교환(CAS) 지연 시간이 푸시 속도를 제한함. 서버가 블롭 저장소에서 팩을 읽고 인덱싱해야 하므로 페치 지연 시간이 증가함. 모든 참조 업데이트의 강력한 순서 지정.
Pando 참조별 원자적 비교 후 교환; 참조 포인터만 경합함. 팩파일 재사용 및 캐시 로컬 전달로 페타바이트 규모에서도 페치 지연 시간이 낮음. 인과적 일관성 – 참조별 직렬화, 전역 스냅샷 없음.

1,000명의 동시 작성자를 대상으로 한 시뮬레이션에서 Pando는 낮은 푸시-투-페치 지연 시간을 유지한 반면, 3PC는 쓰기 지연을 겪었고 WAL은 읽기 지연을 겪었습니다. 실제 운영 환경에서는 수천 건의 동시 푸시가 발생하며 중앙값 지연 시간이 약 80% 감소했음을 확인했습니다.

Pando의 푸시 흐름

  1. 클라이언트가 팩파일을 생성하고 git push를 실행합니다.
  2. Pando는 팩을 블롭 저장소로 스트리밍하는 동시에 한 번의 패스로 검증합니다.
  3. 다중 키 트랜잭션이 새로운 참조 버전(메타데이터)을 기록하고 참조 포인터를 원자적으로 업데이트합니다.
  4. 동기식 메타데이터 쓰기는 자신의 쓰기 읽기(read-your-own-write) 일관성을 보장하며, 비동기 작업(예: 압축 예약)은 백그라운드에서 진행됩니다.

복잡도: 푸시 크기에 관계없이 O(1) 메타데이터 읽기/쓰기.

Pando의 페치 흐름

  1. 클라이언트가 have 및 want ID를 보냅니다.
  2. Pando는 이를 참조 버전 세트에 매핑하고 최소 커버 팩파일을 선택합니다.
  3. 서버는 빈 인라인 팩과 선택된 팩에 대한 packfile-uri 링크를 반환합니다.
  4. 클라이언트는 지역 캐시(Express)에서 직접 팩을 다운로드합니다 – 캐시 적중률 > 99%.

복잡도: O(log Δ) 메타데이터 읽기 (Δ는 클라이언트 상태와 대상 사이의 참조 버전 수).

성능 수치

  • 푸시 지연 시간 중앙값: 이전 시스템 대비 약 5배 낮음 (≈80% 감소).
  • 일일 데이터 제공량: 약 1PB의 Git 객체.
  • 최대 처리량: 한 시간에 57TB 이상의 팩 전송, 99% 이상이 로컬 디스크 캐시에서 제공됨.
  • 네트워크 활용도: 클론/페치 작업이 범용 VM의 10Gbps 링크를 포화시킴.

배포 경험

  • Pando는 Rust를 사용하여 10주 만에 구축되었으며, 핵심 설계는 단일 엔지니어가 작성하고 구현은 Codex가 생성한 코드로 지원받았습니다.
  • 초기 롤아웃은 읽기 통과 프록시를 사용하여 기존 시스템을 동기화 상태로 유지함으로써 무중단 마이그레이션을 가능하게 했습니다.
  • 내부 Git 래퍼가 개발자, CI 및 타사 통합을 위한 마이그레이션 단계를 관리했습니다.
  • Codex 기반 자동화는 개발자가 간단한 명령어로 환경을 마이그레이션하도록 도왔습니다.

Git에 대한 기여

  • packfile-uri에 대한 업스트림 지원을 추가하고 동시 다운로드 처리를 개선했습니다.
  • 서버가 푸시에서 생략될 수 있는 기록과 별도로 브랜치 팁을 광고할 수 있도록 "명시적 haves(explicit haves)"를 구현했습니다.
  • 팩파일 다운로드 및 바이트 수 메트릭에 대한 추적 기능을 추가하여 성능 디버깅을 도왔습니다.
  • 모든 패치는 OpenAI의 공개 Git 포크(https://github.com/openai/git)에서 확인할 수 있으며 https://oai-git.openai.chatgpt.site/에서 추적됩니다.

커뮤니티 맥락

OpenAI의 노력은 다음과 같은 대규모 Git 엔지니어링 게시물들의 흐름을 따릅니다:

  • Cursor의 Git at Any Scale
  • GitHub의 Architecture Optimization 시리즈
  • Anthropic의 Redesigning Source Control
  • East River Source Control의 What Comes After Git

이 작업들은 거대한 모노레포, AI 생성 코드, 고처리량 소스 제어의 필요성이라는 동일한 문제 공간을 공유하지만, 구현 세부 사항(예: Google 스타일 모노레포 서비스 vs Pando의 인과적 일관성)에서는 차이가 있습니다.

핵심 요약

  • Pando는 Git 클라이언트를 변경하지 않고도 백엔드를 근본적으로 재설계하여 페타바이트 규모의 트래픽을 처리할 수 있음을 증명합니다.
  • 인과적 일관성은 대부분의 개발자 워크플로우에 충분하며 전역 순서 지정 지점이 필요하지 않습니다.
  • 팩파일 재사용 및 계층적 압축은 페치 작업을 CPU 집약적인 팩 생성 작업이 아닌 캐시 적중 문제로 전환합니다.
  • 이 설계는 범용 하드웨어에서 수평적으로 확장되므로 유사한 모노레포 성장에 직면한 모든 조직에 실행 가능한 청사진이 됩니다.

향후 계획

OpenAI는 Pando의 일부를 오픈 소스로 공개하고, 더 광범위한 에이전트 중심 사용 사례를 탐색하며, 전체 생태계에 혜택을 주기 위해 Git에 대한 업스트림 기여를 계속할 계획입니다.

Sources