핵심 요약
- 한 개발자가 오브젝트 스토리지를 백엔드로 사용하는 오픈소스 깃 서버를 구현하는 과정을 공유했습니다.
- 리눅스 커널처럼 방대한 저장소에서는 수많은 깃 객체와 기존 팩파일 구조가 네트워크 지연을 일으켜 심각한 성능 저하가 발생했습니다.
- 결국 클라이언트 수정 없이 성능을 확보하기 위해 컬럼형 저장소를 적용한 오브젝트 스토리지 전용 팩파일 포맷을 새로 설계해 해결했습니다.
요약 클라우드 오브젝트 스토리지(S3 등) 위에 깃(Git) 서버를 직접 구축하려던 한 개발자가 기존 깃의 '팩파일(packfile)' 구조 한계에 부딪혀 새로운 방식을 고안한 개발 일지가 공유되었습니다.
깃은 커밋, 트리, 블롭 등 모든 데이터를 해시 기반의 '객체(Object)' 형태로 저장합니다. 초기에는 이를 오브젝트 스토리지에 1:1로 매핑하거나 파일시스템 변환 계층을 두면 쉽게 해결될 것처럼 보였습니다. 하지만 리눅스 커널처럼 방대한 대형 저장소에서는 수천만 개의 객체가 생겨나므로 단일 파일로 쪼개 저장할 경우 인덱스 한계와 네트워크 지연(GetObject 호출마다 최소 수 밀리초 소요) 때문에 전체 페치에 1시간 이상이 걸리는 등 실질적인 사용이 불가능했습니다.
원래 깃은 이러한 무수한 객체들을 묶어 압축 저장하는 '팩파일(packfile)'을 통해 로컬 디스크의 inode 고갈을 방지합니다. 그러나 기존 팩파일 구조는 로컬 디스크 환경과 mmap(메모리 매핑)을 전제로 최적화되어 있어, 10나노초 수준의 로컬 파일시스템 캐시 읽기와 달리 네트워크 지연이 발생하는 분산 오브젝트 스토리지 환경에서는 심각한 성능 저하를 일으켰습니다.
결국 작성자는 클라이언트 측 변경 없이 깃 객체를 오브젝트 스토리지에 최적화된 형태로 다루기 위해, 컬럼형(columnar) 저장 방식을 접목한 오브젝트 스토리지 네이티브 팩파일 포맷을 새로 설계했습니다. 이를 통해 대규모 프로덕션 저장소에서도 원활하게 동작하는 깃 서버를 구현해냈다는 실험기를 전하고 있습니다.
Sponsored · 광고