← 기술 목록으로
ForgejoRAID10PostgreSQLXFSpull-mirrorLACPBroadcom 9560
0작업자의 메모
git 서버 설계에서 가장 하고 싶었던 유혹은 "2대니까 HA"였습니다. 그런데 Forgejo는 네이티브 샤딩이 없고, 진짜 HA는 공유 스토리지와 외부 DB 클러스터, Redis까지 필요합니다. 로컬 RAID를 가진 서버 2대로 그걸 흉내 내면 어중간한 복잡도만 남습니다. 그래서 팀 단위로 repo를 나눠 담는 독립 2포지로 갔습니다.
열려 있는 선택지는 전부 별점 비교표로 만들고 기각 사유를 남겼습니다. CacheVault 유무처럼 확인이 필요한 항목은 결정 표에 "확인"으로 표시해 회의에서 닫도록 했습니다.
1배경
IDC의 git 미러 서버 2대에 8TB HDD를 서버당 8개씩 증설하면서, 기존 구성을 Forgejo 기반 사내 git 포지로 재구성하게 됐습니다. 원본 repo가 이 포지에만 존재하게 되므로 저장·백업 설계가 핵심이었습니다.
- 서버당 EPYC 64코어 · 128GB RAM · 8TB HDD ×8 · 10GbE ×2(LACP)
- 확정 전제: 하드웨어 RAID, 사내 전용(외부 미공개), 업스트림 자동 pull-mirror, SSO 없이 built-in 계정
2설계 판단
① 배포 모델HA 후보 검토 → 독립 2포지(팀 샤딩) 채택
→
② 스토리지RAID 레벨 별점 비교 → RAID10 유력
→
③ DB 배치PostgreSQL을 HDD 볼륨에 repo와 동거
→
④ 백업 정책원본만 dump + 상대 서버 push-mirror
- 독립 2포지 — Forgejo/Gitea는 하나의 포지가 자기 DB에 모든 repo·계정을 갖는 구조라 서버 간 repo 샤딩이 없습니다. 진짜 HA(공유 RWX 스토리지 + 외부 DB 클러스터 + Redis + LB)는 로컬 RAID 2대와 맞지 않아, 팀 단위로 repo를 나눠 담는 독립 2포지를 택했습니다.
- RAID10 유력, RAID5·ZFS 기각 — DB를 SSD에 두지 못하는 전제에서 랜덤 쓰기에 유리한 RAID10(서버당 가용 32TB)을 유력안으로. 8TB 디스크의 RAID5는 리빌드 중 URE로 어레이가 전멸할 위험이 있어 기각, ZFS는 하드웨어 RAID 위에 얹으면 자가치유가 무력화되는 안티패턴이라 기각했습니다. 컨트롤러 캐시(CacheVault)가 확인되면 RAID6(48TB)도 후보로 남겼습니다.
- 백업은 원본만 — 미러 repo는 업스트림에서 재-fetch로 복구되므로 제외하고, 원본 repo만
forgejo dump + 상대 서버 push-mirror(라이브 DR)로 다중 사본을 만듭니다. RAID는 디스크 고장만 막고 오삭제·파일시스템 손상은 못 막는다는 전제를 문서에 명시했습니다.
- 인증은 built-in 계정 — 사내 전용 + 미러 소비 중심이라 SSO는 과한 선택지로 판단해 기각했습니다.
3임팩트
결정 가능한 설계서 — RAID·DB·인증·백업 등 10개 항목을 별점 비교와 기각 사유로 정리해 회의에서 바로 닫을 수 있게 준비
용량 계획 — RAID10 기준 서버당 가용 32TB, 12베이 만재 시 48TB까지 확장 여지 산정
위험 명시 — 8TB RAID5 리빌드 위험, HWRAID 위 ZFS 안티패턴, 폐쇄망에서의 pull-mirror 아웃바운드 경로를 사전에 문서화
4역할
하드웨어 사양 검토부터 배포 모델·스토리지·백업 정책 비교, 설치 체크리스트 작성까지 설계를 직접 진행했습니다. CacheVault 장착 여부처럼 결정에 직결되는 미확인 항목은 확인 목록으로 분리했고, 최종 채택은 팀 회의로 확정하도록 문서에 명시했습니다.
오브젝트 스토리지 구축(SeaweedFS + ZFS/Forgejo 분리 설계)의 git 쪽 후속 작업. 설계 단계 문서임을 그대로 남김.