기술 포트폴리오 · 슬라이드

오픈소스 RAW 데이터
오브젝트 스토리지 구축

오픈소스 생태계의 메타·바이너리·Git 원본 30억~60억 건을 외부 의존 없이 재현 가능하게 보존하는 자체 미러 인프라

래브라도랩스(LabradorLabs) · 데이터파트 · 2026-05~06 · 데이터파트 파트리더

01 · 배경

무엇을, 왜 보존하나

오픈소스 생태계 메타(npm·PyPI·Maven·Go, CVE·OSV·SPDX) + 바이너리(tarball·wheel·jar) + Git 원본을 대규모 수집·보존
외부 레지스트리 · GitHub API rate limit 종속 제거
수집 시점 데이터를 재현 가능하게 장기 보관이 전제
총 30억~60억 건 — 작은 메타 파일만 수억~십억 개(JS 생태계만 6천만) + 갱신 잦은 git이 한 인프라에 공존
온프레미스 2서버 · 서버당 7.3TB×4 = 58TB raw (증설 예정)

02 · 핵심 설계

수집메타 · 바이너리 · git

→

메타 · 바이너리SeaweedFS S3 · 볼륨 FS: XFS

git repoForgejo Mirror + ZFS

한 번 쓰고 key로 읽기 → 오브젝트 스토리지(SeaweedFS)
잠금·부분수정·ref 갱신 잦음 → 파일시스템(ZFS bare repo)
메타DB PostgreSQL — filer의 5억~10억 row 경로→객체ID 매핑 + Forgejo DB 공유 · 2서버 분산 · SeaweedFS EC(6+2) 복제

03 · 기술 선택 근거

SeaweedFS: 작은 파일 수십억 개를 Haystack 패킹으로 저장 — MinIO(inode 폭발)·Ceph(2서버엔 과한 복잡도)·Garage·클라우드(egress·데이터 주권) 비교 후 선정, 라이선스도 Apache 2.0(MinIO는 AGPL)
XFS: Allocation Group 병렬성이 SeaweedFS 멀티스레드 볼륨 쓰기와 적합 (ext4는 inode 사전할당 낭비) · ZFS: scrub로 bit rot 자동 복구, LZ4·스냅샷·send/recv
Forgejo Mirror: 대규모 repo 미러 자동화(fetch·재시도·인증·모니터링) 위임 · PostgreSQL: filer 5억~10억 row, TiKV는 운영 부담으로 미채택
미채택: JuiceFS로 git까지 통합(추상화 3중첩·clone/fetch 저하) · cron 자체 미러(재시도·인증·모니터링 전부 직접 구현)

04 · 임팩트

외부 의존 제거

레지스트리·API rate limit에 종속되지 않는 자체 미러

재현 가능한 보존

수집 시점 메타·바이너리·git 장기 보관

확장 가능한 기반

작은 파일 대량 + git 갱신을 각각 적합한 저장소로

대규모 수용

30억~60억 건 · 2서버 EC(6+2) · 58TB raw(증설 예정) 설계 — 2026-05 문서화, 6월 구축 착수

05 · 역할 & 배움

📦 데이터 플랫폼 재구축 시리즈 ② — ① ETL 재정립 · ② 오브젝트 스토리지