🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개) · 출처: 설계 문서 2026-05

오픈소스 RAW 데이터 오브젝트 스토리지 (SeaweedFS, 2026-05 ~ 06)

데이터파트 RAW 데이터 미러 인프라를 새 팀원이 이해할 수 있는 수준의 온보딩 상세

0한눈에

목적: 오픈소스 생태계의 메타정보(npm·PyPI·Maven·Go 패키지, CVE·OSV·SPDX 라이선스), 바이너리(tarball·wheel·jar 등), Git 원본(RAW repo)을 대규모로 수집·보존하는 자체 미러.
왜: 외부 레지스트리·GitHub API rate limit 종속 제거 + 수집 시점 데이터를 재현 가능하게 장기 보관.
규모: 총 30억~60억 건 — 작은 메타 파일만 수억~십억 개(JS 생태계만 약 6천만 개). 디스크는 서버당 7.3TB×4, 2서버 = 58TB raw (증설 예정), 메모리 128GB/서버.
채택안(방안 3 = 분리): 메타·바이너리는 SeaweedFS(S3, 볼륨 FS XFS), git은 ZFS 위 bare repo + Forgejo Mirror.
메타DB: PostgreSQL (SeaweedFS filer 매핑 + Forgejo DB 분리 공유, streaming replication HA).
분산: 온프레미스 2서버(labrador, labrador-2)로 repo 영역 분산, SeaweedFS는 EC(6+2) 서버 간 복제.
일정: 2026-05 설계 문서화, 6월 구축 착수.
근거 문서: Confluence [ENHC|OBJ] 오브젝트 스토리지 구축 방안 · [ISSU|DBPT] 기존 ETL 데이터 수집 플로우 문제점

1아키텍처 — 저장소 분리

수집메타 · 바이너리 · git

→

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

git repoForgejo Mirror + ZFS

메타DBPostgreSQL

핵심 원칙은 데이터의 "수정 패턴"으로 저장소를 나눈 것이다.

한 번 쓰고 key로 읽음(메타·바이너리) → 오브젝트 스토리지(SeaweedFS).
잠금·부분수정·ref 갱신·index 재작성이 잦음(git) → 파일시스템(ZFS bare repo).

2왜 이 조합인가 (선택 근거)

SeaweedFS: 수억~수십억 개의 작은 파일을 Haystack 패킹으로 효율 저장. 후보 비교(MinIO·Ceph·Garage·클라우드 R2/B2)에서 — MinIO는 객체당 파일 1개라 inode 폭발, Ceph는 2서버엔 과한 운영 복잡도, 클라우드는 egress 비용·데이터 주권 문제로 제외. 라이선스도 Apache 2.0(MinIO는 AGPL v3, 2025 변경 이슈).
XFS: 오브젝트 볼륨 파일시스템. Allocation Group 구조가 SeaweedFS의 멀티스레드 볼륨 쓰기와 잘 맞고 GB급 볼륨 파일에 강함 — 운영 사례 다수가 XFS 가정. ext4는 inode 사전할당 낭비·거대 파일 random write 약점.
ZFS: git bare repo 저장. checksum/scrub으로 bit rot 자동 감지·복구, LZ4 압축(git loose object/text에 효과적), 스냅샷(force-push 사고 복구), send/recv(zrepl) 복제가 강점.
Forgejo Mirror: 대규모 repo 미러 자동화(fetch 스케줄링·재시도·인증·모니터링)를 위임. Gitea와 거의 동일하나 거버넌스(커뮤니티 vs 영리) 차이로 Forgejo. GitLab CE는 미사용 기능이 과함.
PostgreSQL: filer의 5억~10억 row "경로→객체ID" 매핑 + Forgejo DB를 한 클러스터에서 DB만 분리 공유(운영 컴포넌트 절약), streaming replication HA + WAL 백업(PITR). 공식 권장 TiKV는 분산 KV 운영 부담으로 미채택.
EC(6+2): SeaweedFS 서버 간 복제. 2서버 온프레미스 분산 — 서버1 a~m repo + PG MASTER, 서버2 n~z + PG REPLICA, nginx가 repo 이름 기준 분기.

미채택 — 방안 비교 3안 중: ① JuiceFS 완전 통합(git까지 오브젝트 스토리지 안에)은 git의 다수 작은 객체 워크로드에서 clone/fetch 성능 저하와 추상화 3중첩(git→JuiceFS→SeaweedFS→디스크, 디버깅 난이도)으로 제외. ② 분리 + cron 자체 미러는 동시성·재시도·인증·모니터링을 전부 직접 구현해야 하고 repo가 늘수록 부담이 가속되어 제외. 채택안은 방안 3 (분리 + Forgejo Mirror 위임).

3진행 순서

데이터를 "수정 패턴"으로 분류 (write-once read-by-key vs 잦은 갱신)
메타·바이너리 → SeaweedFS(S3) + 볼륨 FS XFS 결정 (Haystack, MinIO inode 폭발 회피)
git → ZFS bare repo + Forgejo Mirror 결정 (무결성·미러 자동화)
메타DB PostgreSQL 단일 클러스터에 filer 매핑 + Forgejo DB 분리 공유, streaming replication HA
2서버 분산 + SeaweedFS EC(6+2) 서버 간 복제 설계
설계 문서화(2026-05) → 구축 착수(2026-06)

4온보딩 포인트

저장소를 고를 땐 데이터 크기보다 수정 패턴을 먼저 본다.
작은 파일이 수억~수십억 개면 객체당 파일 1개 모델(MinIO)은 inode가 터진다 → Haystack 패킹의 SeaweedFS.
git은 잠금·부분수정이 잦으므로 오브젝트 스토리지에 직접 얹지 않는다 → ZFS bare repo, 미러는 Forgejo Mirror에 위임.
장기 보존은 ZFS scrub(bit rot) + SeaweedFS EC(6+2)로 무결성·내구성을 확보한다.

5공개(포트폴리오)와의 차이

공개 버전(human/portfolio/items/object-storage-seaweedfs.html)은 내부 식별자(티켓 ID·내부 호스트명 labrador/labrador-2·IP·내부 테이블/뷰명·고객사명·동료 이름)를 제거하고 문제·접근·임팩트 중심으로 일반화했다. 오픈소스/기술명(SeaweedFS·ZFS·XFS·Forgejo·PostgreSQL·JuiceFS·S3·Haystack·EC)은 공개본에서도 유지한다.

이 내부 문서는 본인 참고/온보딩용으로 내부 식별자를 포함한다.

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