저장소
저장소는 CephFS 기반의 공유 볼륨입니다. EC2(또는 Lambda)에 붙이면(attach) /mnt/<저장소이름>에 마운트되고, 여러 EC2에 동시에 붙여서 같은 파일을 함께 읽고 쓸 수 있습니다 — EC2들이 서로 다른 노드(사용자가 등록한 컴퓨터 포함)에서 돌아도 마찬가지입니다.
왜 CephFS인가
원래 저장소는 EC2 디스크와 같은 Ceph RBD(블록 장치, ReadWriteOnce)였습니다. RBD 위의 ext4는 한 노드에서만 읽기/쓰기로 마운트할 수 있어서, 여러 EC2가 공유하는 게 "전부 같은 노드(worker-1)에서 돌 때만 우연히" 됐습니다. 사용자 노드가 붙어서 EC2가 다른 노드에 뜨는 순간 깨지는 구조라, 여러 노드가 동시에 마운트할 수 있는 CephFS(ReadWriteMany)로 바꿨습니다 (AWS로 치면 EBS → EFS).
| EC2 디스크 | 저장소 | |
|---|---|---|
| 방식 | Ceph RBD (블록, ext4) | CephFS (분산 파일시스템) |
| 동시 마운트 | 그 EC2 하나 | 여러 EC2, 여러 노드 |
| 속도 | 빠름 (로컬 파일시스템) | RBD보다 느림 — 파일 열기/권한 확인이 메타데이터 서버(MDS)를 거치고, 여러 클라이언트 간 캐시 일관성을 맞추는 비용이 있음. 큰 파일을 쭉 읽는 건 차이가 작고, 작은 파일을 많이 여닫는 작업에서 체감됨 |
| 용량 | 생성 시 지정 | 생성 시 지정한 크기가 CephFS 쿼터로 강제됨 |
대안으로 RBD 볼륨 하나를 NFS 서버 파드로 다시 내보내는 방식도 검토했지만, 그 NFS 파드 하나가 단일 장애점이자 병목이 돼서 CephFS를 택했습니다. 기존 RBD를 "확장"하는 방법은 없습니다 — ext4/xfs 자체가 여러 노드의 동시 쓰기 마운트를 지원하지 않기 때문입니다.
실측 (2026-09-26)
worker-1에서 같은 파드에 RBD 볼륨과 CephFS 볼륨을 붙이고, 측정마다 노드 페이지 캐시를 비운 뒤 2회씩 측정 (일반 컨테이너 기준, 파일 5,000개 × 4KiB / 파일 1개 1GiB).
| 작업 | RBD (EC2 디스크 방식) | CephFS (저장소) | 차이 |
|---|---|---|---|
| 큰 파일 쓰기 (fsync까지) | 118–123 MB/s | 110–116 MB/s | 거의 같음 (~5%) |
| 큰 파일 읽기 | 136–164 MB/s | 153–167 MB/s | 같음 |
| 작은 파일 5,000개 생성 | 1.45–1.70초 | 1.78–1.85초 | 10–25% 느림 |
| 작은 파일 5,000개 읽기 | 0.89–1.28초 | 1.77–1.86초 | 약 1.5–2배 느림 |
| 폴더 목록 + stat | 0.04–0.06초 | 0.03초 | 같음 (MDS가 메타데이터를 한 번에 줌) |
| 작은 파일 5,000개 삭제 | 0.08초 | 0.60초 | 약 7배 느림 |
- 큰 파일은 둘 다 디스크 속도가 병목이라 차이가 거의 없음
- 작은 파일을 많이 열고 닫는 작업(읽기, 삭제)에서 차이가 큼 — 파일을 열 때마다 MDS에 권한(capability)을 받아오는 왕복이 있기 때문.
node_modules처럼 작은 파일이 수만 개인 작업은 EC2 디스크에서 하고, 저장소는 데이터/결과물 공유용으로 쓰는 게 유리 - EC2 안(Kata)에서는 virtiofs를 한 번 더 거치므로 절대 속도는 이보다 조금 낮을 수 있음 (RBD 기반 EC2 디스크도 마찬가지)
연결 / 해제
- 연결/해제할 때 EC2의 Deployment를 패치해야 해서 EC2가 잠시 재시작됩니다 (Lambda는 다음 호출 때 새 설정으로 뜸)
- attach 직후 곧바로 다시 attach를 시도하면 k8s의 낙관적 동시성 충돌(409, resourceVersion 불일치)이 날 수 있어서, 실패 시 자동으로 재시도합니다
- 새로 만든 저장소는 완전히 빈 폴더입니다 (RBD/ext4 시절의
lost+found없음)
공유
저장소 목록의 공유 버튼으로 다른 사용자에게 저장소를 쓰게 할 수 있습니다.
| 소유자 | 공유받은 사용자 | |
|---|---|---|
| 내 EC2/Lambda에 연결·해제 | ✅ | ✅ (자기 것만) |
| 파일탐색 | ✅ | ✅ |
| 남이 만든 연결 해제 | ✅ (자기 저장소의 모든 연결) | ❌ |
| 삭제, 공유 관리 | ✅ | ❌ |
- 공유받은 사용자에게는 저장소 탭 아래 공유받은 저장소에 보이고, "내 연결"에는 자기 EC2/Lambda와의 연결만 보임
- 소유자 쪽 "연결된 EC2"에는 다른 사람의 EC2가
이름 (사용자)로 표시되고, 이름 옆에 "공유 N명" - 공유를 해제하면 그 사용자의 EC2/Lambda(파일탐색 포함)에 연결된 것도 모두 끊김 (해당 EC2는 잠시 재시작). 끊는 도중 오류가 나면 공유를 유지하고 다시 시도하게 함 — 공유는 풀렸는데 마운트는 남는 상태를 만들지 않기 위해
- 저장소를 삭제하려면 모든 연결(다른 사용자 것 포함)이 먼저 해제돼 있어야 함. 소유자가 관리 화면에서 직접 해제 가능
- 연결 경로는
/mnt/저장소이름— 저장소 이름은 전체 사용자 사이에서 고유해서 겹치지 않음 - 코드:
StorageShare모델,services/storage.py의get_for_use(소유자 또는 공유받은 사용자),share,unshare(콘솔과 API가 같이 씀)
인프라
CephFilesystemceph-fs(메타데이터 풀 + 데이터 풀, MDS 1개, worker-1), StorageClassceph-fs, PVC 이름은fsvol-<저장소 id>- MDS 메모리 상한 1Gi (기본 캐시 목표 4GiB는 EC2 옆에서 감당이 안 돼서 제한)
- EC2는 Kata(경량 VM)로 도는데, 호스트가 마운트한 CephFS를 virtiofs로 VM 안에 넘겨줌 — 일반 컨테이너와 Kata 컨테이너가 같은 볼륨을 동시에 쓰는 것, 다른 노드(jimmy-master)에서 동시에 마운트하는 것까지 검증
- 설치 매니페스트:
infra/ceph/cephfs.yaml(이 Rook 버전은 CSI Driver/ServiceAccount를 자동으로 안 만들어서 직접 선언 —infra/ceph/README.md참고)
2026-09-26 마이그레이션 기록
기존 RBD 저장소 5개를 CephFS로 옮겼습니다. 저장소 id/이름/마운트 경로는 그대로라 사용자 입장에서는 같은 저장소입니다.
- 저장소마다 CephFS PVC(
fsvol-<id>)를 새로 만들고, 기존 RBD PVC(vol-<id>)에서cp -a로 권한·소유자·수정 시각까지 복사 - 양쪽의 파일 목록(경로/종류/크기/권한/소유자/수정 시각/링크 대상)과 모든 파일 내용 해시를 비교해서 동일한지 검증
- 쓰기 도중 복사되는 걸 막으려고, 실행 중이던 EC2(
chat-test)만 복사 동안 약 1분 정지. 정지 상태였던 EC2/파일탐색 EC2는 그대로 둔 채 Deployment만 새 저장소를 보도록 변경 - 기존 RBD PVC(
vol-<id>)는 롤백용으로 남겨둠 — 저장소를 삭제하면 같이 지워짐