SeaweedFS 는 Go 로 작성된 Apache 2.0 라이선스의 분산 오브젝트 · 파일 스토리지다. Facebook 의 Haystack 논문에서 출발해 작은 파일을 아주 많이 저장하는 상황을 겨냥해 설계됐다. 파일 하나하나를 파일시스템 엔트리로 두지 않고 큰 볼륨 파일 안에 이어 붙인 뒤 오프셋으로 찾아가기 때문에, 파일 수가 수억 개로 늘어도 메타데이터 부담이 완만하게 증가한다.
MinIO 커뮤니티판이 멈춘 뒤 대체재를 찾는 자리에서 자주 후보로 올라온다. 제품 전반의 비교는 설치형 오브젝트 스토리지 비교 에 있고, 이 문서는 SeaweedFS 자체의 구조와 이관할 때 걸리는 지점을 다룬다.
Master (x3)
볼륨 위치와 클러스터 상태만 관리
|
+------------+------------+
| |
Volume Server Volume Server 실제 데이터
|
Filer (x2) 디렉터리 · 파일 메타데이터
|
+----+-----+
| |
S3 API FUSE / WebDAV / HDFS
| 구성 요소 | 역할 |
|---|---|
| Master | 볼륨의 위치와 할당을 관리한다. 데이터가 통과하지 않는다 |
| Volume Server | 실제 데이터를 볼륨 파일에 저장한다. 클라이언트가 직접 통신한다 |
| Filer | 디렉터리 구조와 파일 메타데이터를 외부 저장소(LevelDB · Redis · PostgreSQL 등) 에 담는다 |
| S3 Gateway | S3 API 를 제공한다. Filer 위에서 돈다 |
Master 가 데이터 경로에 끼지 않는 것이 구조상 중요한 점이다. 클라이언트는 Master 에게 "이 파일이 어느 볼륨 서버에 있나" 만 묻고 그 뒤로는 볼륨 서버와 직접 주고받는다. Master 가 병목이 되지 않는 대신, Master 가 내려가면 새 쓰기의 볼륨 할당이 멈춘다. 그래서 Master 는 홀수로 3대를 둔다.
Filer 는 메타데이터 저장소를 골라 붙이는 구조라, 이 선택이 곧 운영 난이도와 규모 한계를 정한다. 단일 노드 시험이면 LevelDB 로 충분하지만, HA 가 필요하면 외부 데이터베이스나 Redis 를 둔다.
Master x3
Volume xN (복제 정책만큼 서버 수 확보)
Filer x2 (공유 메타데이터 저장소 필요)
S3 GW x2 (앞에 로드밸런서)
복제 정책은 xyz 세 자리 숫자로 표기한다. 각각 다른 데이터센터 · 다른 랙 · 같은 랙의 다른 서버에 둘 복제본 수다. 000 은 복제 없음, 001 은 같은 랙 안에 하나 더, 010 은 다른 랙에 하나 더다. 볼륨 서버 수가 정책이 요구하는 수보다 적으면 쓰기가 실패한다.
| 항목 | 내용 |
|---|---|
| URL 스타일 | 경로 방식(http://endpoint/bucket/key) 을 쓴다. 가상 호스트 방식(http://bucket.endpoint/key) 은 DNS 와 인증서를 따로 준비해야 하므로, 클라이언트에서 path-style 을 켜는 편이 간단하다 |
| IAM · 정책 | MinIO 만큼 세밀하지 않다. 버킷 단위 접근 제어까지는 무리 없지만, 조건부 정책이나 STS 임시 자격증명에 기대는 구성은 재설계가 필요하다 |
| 오브젝트 잠금(WORM) | 상용 기능으로 분리돼 있는 항목이 있다. 규제 대응 요건이 있으면 도입 전에 확인한다 |
| 이관 방법 | rclone 또는 mc mirror 로 버킷 단위 복사가 된다. 메타데이터와 태그 보존 여부를 표본으로 확인한 뒤 전체를 돌린다 |
| 생태계 | 튜토리얼과 운영 사례가 MinIO 보다 적다. 문제를 만났을 때 검색으로 해결되는 비율이 낮다 |
rclone sync minio:bucket seaweed:bucket --progress --checksum
확인 필요 — 오브젝트 잠금과 엔터프라이즈 전용 기능의 범위는 시점에 따라 바뀐다. 도입 전에 공식 문서에서 다시 본다.
MinIO 커뮤니티판을 되살리려는 포크가 여럿 나왔지만, 대부분 초기 단계이거나 관리 UI 복원에 그친다. 보안 패치가 지속되는지, 유지보수 주체가 누구인지 확인하지 않고 운영에 넣지 않는다.