같은 워크로드를 두 스토리지에 넣고 비교하기

목표

동일한 코퍼스를 파일시스템, S3 호환 스토리지(SeaweedFS S3 게이트웨이), SeaweedFS 파일러 세 곳에 넣고 개수·시간·지연을 직접 재어, 스토리지 선택을 취향이 아니라 숫자로 하는 법을 익힌다.

왜 중요한가

스토리지 선택은 벤치마크 표를 옮겨 적는 것으로 결정되지 않습니다. 같은 제품이 워크로드에 따라 최선이 되기도 하고 최악이 되기도 하기 때문입니다. 4KiB 파일 2,000개에서 갈리는 차이가 200MiB 파일 하나에서는 사라지고, 그 반대도 있습니다. 이 실습은 그 사실을 스스로 측정해 확인하게 합니다. 특히 4번 스텝에서 파일 2,000개가 볼륨 파일 몇 개에 담기는지를 직접 세어 보면, "소파일에 강하다"는 문장이 구체적인 구조 이야기로 바뀝니다. 마지막 결정표는 나중에 실제 선택을 할 때 그대로 꺼내 쓸 수 있는 형태로 만듭니다.

비교 상대에 대해 한 가지 적어 둡니다. 이 실습의 S3 쪽은 원래 MinIO 였습니다. MinIO 는 객체 하나를 디스크의 디렉터리 하나와 메타데이터 파일(xl.meta)로 두기 때문에, 2번 스텝에서 잰 파일시스템의 비용을 객체마다 그대로 집니다 — 소파일 문제의 전형적인 반대편이었습니다. 2025년 커뮤니티 에디션이 바이너리 배포를 끝내 이 이미지에서 빠졌고, 지금 3번 스텝의 S3 서버는 SeaweedFS 의 S3 게이트웨이입니다. 그래서 이제 이 실습이 재는 것은 저장 엔진 두 개의 대결이 아니라 소파일 비용의 두 겹입니다. 파일시스템(2번)은 '디스크 위 파일 개수' 의 비용을, S3(3번)와 파일러(4번)는 같은 SeaweedFS 를 두 입구로 두드려 '요청 개수' 의 비용을 보여 줍니다. S3 로 넣어도 볼륨 파일이 늘지 않는다는 것까지 3번 스텝에서 같이 확인합니다.

단계

/root/cmp/corpus/ 아래에 4096바이트 파일 2,000개를 만든다. 이름은 f0000.bin 부터 f1999.bin 이다.
/root/cmp/fs.txt 에 files=2000, data_bytes=8192000, disk_kb=<du -sk 결과> 세 줄을 적는다. disk_kb 는 데이터 크기보다 커야 한다.
S3 서버(http://127.0.0.1:9000)에 버킷 lab-cmp 를 만들어 코퍼스를 통째로 올리고 /root/cmp/s3.txt 에 objects=2000 seconds=<소수> 를 적는다.
같은 코퍼스를 SeaweedFS 파일러의 /cmp/ 아래에 넣고 /root/cmp/sw.txt 에 files=2000 dat_files=<n> seconds=<소수> 를 적는다. dat_files 는 20 이하여야 한다.
무작위 100개를 각 저장소에서 읽어 /root/cmp/latency.csv 에 store,avg_ms 헤더와 fs, s3, filer 세 행을 적는다.
200MiB 파일 하나를 세 저장소에 넣고 읽어 /root/cmp/bigfile.csv 에 store,put_ms,get_ms 헤더와 세 행을 적는다.
/root/cmp/decision.md 에 마크다운 표를 쓴다. 행 제목은 소파일 대량, 대용량 소수, S3 API 필요, 운영 인력 네 개이고 추천 열이 있어야 한다.

참고

파일 생성: dd if=/dev/urandom of=f0000.bin bs=4096 count=1 또는 python 반복문
디스크 사용량: du -sk /root/cmp/corpus
시간 측정: date +%s.%N 앞뒤 차이 또는 time
S3 쪽: 자격 증명은 /opt/fixtures/s3/creds.env, 프로필은 s3-basics 1번 스텝과 같은 방법으로 local 을 만든다. 올리기는 aws s3 cp --recursive, 읽기는 boto3 가 편하다.
두 SeaweedFS 는 서로 다른 프로세스다. S3 서버는 실습 환경이 띄운 것(데이터 /var/lib/lab-s3/data)이고, 4번 스텝의 마스터·볼륨·파일러(9333·8180·8888)는 직접 띄우는 것이다.
흔한 실수 1: 세 저장소에 서로 다른 데이터를 넣고 비교하는 것.
흔한 실수 2: 캐시가 데워진 상태와 차가운 상태를 섞어 재는 것 — 순서를 일정하게 하세요.

비교용 코퍼스 만들기

/root/cmp/corpus/ 아래에 4096바이트 파일 2,000개를 만든다. 이름은 f0000.bin 부터 f1999.bin 이다.

같은 데이터를 세 곳에 넣어야 비교가 됩니다. 크기와 개수를 정확히 맞추세요.

파일시스템에 넣고 메타데이터 비용 재기

/root/cmp/fs.txt 에 files=2000, data_bytes=8192000, disk_kb=<du -sk 결과> 세 줄을 적는다. disk_kb 는 데이터 크기보다 커야 한다.

데이터 크기와 실제 사용 블록이 다릅니다. 파일 수도 함께 세어 두세요.

S3 에 넣고 소요 시간 재기

S3 서버(http://127.0.0.1:9000)에 버킷 lab-cmp 를 만들어 코퍼스를 통째로 올리고 /root/cmp/s3.txt 에 objects=2000 seconds=<소수> 를 적는다.

객체 하나하나가 요청입니다. 개수가 곧 시간이 되는지, 그리고 S3 서버의 볼륨 파일은 늘어나는지 확인하세요.

SeaweedFS 에 넣고 볼륨 파일 수 재기

같은 코퍼스를 SeaweedFS 파일러의 /cmp/ 아래에 넣고 /root/cmp/sw.txt 에 files=2000 dat_files=<n> seconds=<소수> 를 적는다. dat_files 는 20 이하여야 한다.

앞 실습에서 띄운 데몬을 그대로 씁니다. 볼륨 파일 개수가 핵심 관찰 지점입니다.

무작위 읽기 지연 비교하기

무작위 100개를 각 저장소에서 읽어 /root/cmp/latency.csv 에 store,avg_ms 헤더와 fs, s3, filer 세 행을 적는다.

같은 100개를 무작위 순서로 읽습니다. 세 값을 한 파일에 모으세요.

큰 파일 하나로도 같은 비교 하기

200MiB 파일 하나를 세 저장소에 넣고 읽어 /root/cmp/bigfile.csv 에 store,put_ms,get_ms 헤더와 세 행을 적는다.

소파일에서 갈리던 차이가 큰 파일에서는 어떻게 되는지가 결론의 절반입니다.

선택 기준표 쓰기

/root/cmp/decision.md 에 마크다운 표를 쓴다. 행 제목은 소파일 대량, 대용량 소수, S3 API 필요, 운영 인력 네 개이고 추천 열이 있어야 한다.

워크로드 특성별로 어느 쪽을 고를지 표로 정리합니다. 행 제목이 채점 기준입니다.