오픈소스 RAW 데이터 오브젝트 스토리지 구축 (SeaweedFS)
오픈소스 생태계의 메타·바이너리·Git 원본 30억~60억 건을 외부 의존 없이 재현 가능하게 보존하는 자체 미러 인프라 설계·구축
1저장해야 할 데이터가 서로 달랐습니다
오픈소스 메타데이터와 tarball·wheel·jar 같은 바이너리, Git 저장소 원본은 크기와 수정 방식이 전혀 다릅니다. 외부 API와 저장소에 계속 의존하면 rate limit이나 원본 삭제가 생겼을 때 같은 시점의 데이터를 다시 만들 수 없었습니다.
2한 저장소에 모두 넣지 않은 이유
메타데이터·바이너리
대부분 한 번 쓰고 key로 다시 읽습니다. 작은 파일이 많아 Haystack 방식으로 묶어 저장하는 SeaweedFS를 선택했습니다.
SeaweedFS · S3 API · XFSGit 원본
ref, index, lock 파일이 계속 바뀝니다. 일반 파일시스템 특성이 필요한 영역이라 ZFS 위 bare repository와 Forgejo Mirror로 분리했습니다.
ZFS · Forgejo Mirrorgit 저장 방식은 세 가지 안을 비교 문서로 만들어 결정했습니다. ① SeaweedFS 위에 JuiceFS를 얹어 git까지 완전 통합하는 안은 git clone 성능이 낮아 기각, ② ZFS에 두고 미러를 자체 스크립트로 돌리는 안은 다수 repo의 미러 자동화를 직접 구현해야 해서 기각, ③ ZFS + Forgejo 안은 clone 성능을 유지하면서 pull-mirror 자동화를 Forgejo가 제공해 채택했습니다.
3용량과 운영 조건
- 장기 목표 데이터는 30억~60억 건, 작은 메타 파일만 수억~십억 개 규모로 산정
- 초기 on-premise 구성은 서버 2대, 서버당 7.3TB 디스크 4개로 58TB raw
- SeaweedFS 볼륨은 XFS, Git 원본은 checksum·scrub·snapshot이 필요한 ZFS로 분리
- 메타데이터 경로는 PostgreSQL에 저장하고 streaming replication과 WAL 백업을 적용
MinIO, Ceph, Garage, 클라우드 오브젝트 스토리지도 비교했습니다. 작은 파일 수, 서버 2대라는 제약, 운영 난이도와 egress 비용을 기준으로 SeaweedFS를 골랐습니다.
4제가 맡은 부분
데이터 유형과 증가량을 정리하고 저장소 후보를 비교한 뒤, 오브젝트 스토리지와 Git 저장 영역을 나누는 아키텍처를 설계했습니다. 현재는 수집 플로우와 함께 단계적으로 구축하고 있습니다. 설계 단계와 운영 완료 항목을 섞어 쓰지 않기 위해 현재 상태도 그대로 표시했습니다.