오픈소스 RAW 데이터 오브젝트 스토리지 구축 (SeaweedFS)
Deprecated된 RAW 저장소 구성안입니다. 데이터별 저장 방식과 후보 비교 과정을 기록으로 보관합니다.
보관 기록
Deprecated · 저장소 비교와 설계 기록 보관
Deprecated된 프로젝트입니다. 아래 내용은 당시의 검토와 설계 기록입니다.
저장해야 할 데이터가 서로 달랐습니다
오픈소스 메타데이터와 tarball·wheel·jar 같은 바이너리, Git 저장소 원본은 크기와 수정 방식이 전혀 다릅니다. 외부 API와 저장소에 계속 의존하면 rate limit이나 원본 삭제가 생겼을 때 같은 시점의 데이터를 다시 만들 수 없었습니다.
한 저장소에 모두 넣지 않은 이유
메타데이터·바이너리
대부분 한 번 쓰고 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가 제공해 채택했습니다.
용량과 운영 조건
- 장기 목표 데이터는 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를 골랐습니다.
제가 맡은 부분
데이터 유형과 증가량을 정리하고 저장소 후보를 비교한 뒤, 오브젝트 스토리지와 Git 저장 영역을 나누는 아키텍처를 설계했습니다. 이 프로젝트는 Deprecated됐으며, 데이터별 저장 방식과 후보 비교 과정은 당시 작업 기록으로 보관합니다.
근거 자료
아래 기록에 근거해 정리했습니다. 내부 원문 경로를 표시하며, 비공개 원문 파일은 이 페이지에서 제공하지 않습니다.
ai/sources/career/interviews/2026-09-03-general-numbers-01.mdai/wiki/people/career-timeline.mdai/wiki/projects/data-platform-systems-engineering.mdai/sources/career/2026-09-09-portfolio-project-status-correction.md