왜 스토리지 선택이 문제가 되는가
객체 스토리지는 한번 도입하면 데이터 마이그레이션 비용 때문에 교체가 매우 어렵다. 초기에 "S3 호환이면 다 비슷하겠지"라고 접근하면, 트래픽이 늘거나 수억 개의 소형 파일이 쌓이는 시점에 성능·운영 부하로 발목을 잡힌다. 세 제품은 겨냥하는 워크로드가 다르며, 잘못 고르면 클러스터가 커질수록 손해가 누적된다.
세 제품의 성격 차이
MinIO는 단일 바이너리로 배포하는 S3 호환 객체 스토리지다. 설정이 단순하고 벤치마크가 빠르지만, 코어는 객체 스토리지에 집중한다. Ceph는 RADOS 기반의 통합 스토리지로 객체(RGW)·블록(RBD)·파일(CephFS)을 모두 제공하는 대신 운영 복잡도가 높다. SeaweedFS는 Facebook Haystack 논문에서 출발해 대량의 소형 파일 처리에 최적화된 구조를 가진다.
| 항목 | MinIO | Ceph | SeaweedFS |
|---|---|---|---|
| 주 용도 | S3 객체 | 객체·블록·파일 통합 | 소형 파일 대량 |
| 운영 난이도 | 낮음 | 높음 | 중간 |
| 소형 파일 | 보통 | 약함(메타데이터 부담) | 강함 |
| 확장 방식 | 노드 단위 풀 추가 | OSD 자동 리밸런싱 | volume/master 분리 |
MinIO: 단순함이 무기
디스크 몇 개로 곧바로 분산 모드를 띄울 수 있다. Erasure Coding이 기본 내장되어 별도 튜닝 없이 데이터 보호가 된다.
docker run -d --name minio \
-p 9000:9000 -p 9001:9001 \
-e MINIO_ROOT_USER=admin \
-e MINIO_ROOT_PASSWORD=change-me-please \
-v /data1:/data1 -v /data2:/data2 \
-v /data3:/data3 -v /data4:/data4 \
quay.io/minio/minio server \
http://minio/data{1...4} --console-address ":9001"주의점: 배포 후에는 EC 파라미터(드라이브 수)를 바꾸기 어렵다. 처음부터 노드·드라이브 배치를 설계하고, 용량 확장은 기존 풀 변경이 아니라 새 서버 풀 추가 방식으로 계획해야 한다.
Ceph: 통합 스토리지의 힘과 비용
객체뿐 아니라 VM 블록 디스크, 공유 파일시스템까지 하나의 클러스터로 묶고 싶을 때가 Ceph의 자리다. 대신 MON·MGR·OSD 데몬과 CRUSH 맵을 이해해야 하고, 소형 파일이 많으면 OSD 메타데이터·PG 관리 부담이 커진다.
# 클러스터 상태와 사용량 확인
ceph -s
ceph df
# 복제 풀 생성 (PG 128) 후 크기 3 복제 지정
ceph osd pool create app-data 128 128
ceph osd pool set app-data size 3
# S3 게이트웨이(RGW) 사용자 생성
radosgw-admin user create --uid=svc --display-name="service"주의점: PG 수(pg_num)를 잘못 잡으면 리밸런싱이 폭주하거나 데이터가 편중된다. 최소 3개 MON 노드로 정족수를 확보하고, 운영 인력 없이 소규모로만 쓸 거라면 과한 선택일 수 있다.
SeaweedFS: 소형 파일에 강한 구조
썸네일, 로그, 메시지 첨부처럼 KB 단위 파일이 수억 개 쌓이는 워크로드에서 진가를 발휘한다. master가 볼륨을 관리하고 volume 서버가 실제 데이터를 담아, 파일 하나당 메타데이터 오버헤드를 최소화한다.
# master + volume + S3 API를 한 커맨드로 기동
weed server -dir=/data -master.volumeSizeLimitMB=30000 \
-volume.max=100 -s3 -s3.port=8333
# S3 API로 업로드 (aws cli 그대로 사용)
aws --endpoint-url http://localhost:8333 \
s3 cp thumb.jpg s3://images/thumb.jpg주의점: filer의 메타데이터 저장소(기본 leveldb) 선택이 확장성을 좌우한다. 다중 filer로 HA를 구성하려면 Redis·PostgreSQL 같은 외부 백엔드로 바꿔야 하며, 이를 기본값으로 방치하면 단일 장애점이 된다.
선택 기준 정리
- S3 객체만 필요하고 운영을 단순하게 가져가고 싶다 → MinIO.
- 블록·파일·객체를 하나로 통합하고 전담 운영 인력이 있다 → Ceph.
- 소형 파일이 폭발적으로 늘어나는 워크로드가 핵심이다 → SeaweedFS.
결국 판단축은 세 가지다. 파일 크기 분포, 필요한 스토리지 유형(객체 전용인지 통합인지), 그리고 감당 가능한 운영 난이도. 벤치마크 수치보다 이 세 축을 먼저 정의하면, 나중에 마이그레이션으로 고생할 확률이 크게 줄어든다.