Home
Blog
MinIO, 커뮤니티 변경 사항 수락 중단: Milvus를 위한 실행 가능한 S3 호환 오브젝트 스토리지 백엔드로서 RustFS 평가하기

MinIO, 커뮤니티 변경 사항 수락 중단: Milvus를 위한 실행 가능한 S3 호환 오브젝트 스토리지 백엔드로서 RustFS 평가하기

Tutorials

January 14, 2026

Min Yin

이 게시물은 Milvus의 가장 활발한 커뮤니티 기여자 중 한 명인 Min Yin이 작성했으며, 허가를 받아 여기에 게시되었습니다.

MinIO는 AI/ML, 분석 및 기타 데이터 집약적인 워크로드에 널리 사용되는 오픈 소스 고성능 S3 호환 객체 스토리지 시스템입니다. 많은 Milvus 배포의 경우, 객체 스토리지의 기본 선택이기도 했습니다. 그러나 최근 MinIO 팀은 이 프로젝트가 더 이상 새로운 변경 사항을 수용하지 않는다는 내용의 GitHub README를 업데이트했습니다.

실제로 지난 몇 년 동안 MinIO는 점차 상업용 제품으로 관심을 전환하고 라이선스 및 배포 모델을 강화했으며 커뮤니티 리포지토리에서의 활발한 개발을 축소해 왔습니다. 오픈소스 프로젝트를 유지 관리 모드로 전환하는 것은 이러한 광범위한 전환의 자연스러운 결과입니다.

기본적으로 MinIO를 사용하는 Milvus 사용자에게는 이러한 변화를 무시하기 어렵습니다. 객체 스토리지는 Milvus의 지속성 계층의 중심에 있으며, 시간이 지남에 따라 그 안정성은 현재 작동하는 것뿐만 아니라 시스템이 지원하는 워크로드와 함께 계속 발전하는지에 따라 달라집니다.

이러한 배경에서 이 글에서는 잠재적인 대안으로 RustFS를 살펴봅니다. RustFS는 메모리 안전성과 최신 시스템 설계를 강조하는 Rust 기반의 S3 호환 객체 스토리지 시스템입니다. 아직 실험 단계에 있으며 이 논의는 프로덕션 권장 사항이 아닙니다.

Milvus 아키텍처와 객체 스토리지 구성 요소의 위치

Milvus 2.6은 완전히 분리된 스토리지-컴퓨팅 아키텍처를 채택하고 있습니다. 이 모델에서 스토리지 계층은 세 개의 독립적인 구성 요소로 구성되어 있으며, 각 구성 요소는 고유한 역할을 수행합니다.

Etcd는 메타데이터를 저장하고, Pulsar 또는 Kafka는 스트리밍 로그를 처리하며, 객체 스토리지(일반적으로 MinIO 또는 S3 호환 서비스)는 벡터 데이터와 인덱스 파일에 대한 내구성 있는 지속성을 제공합니다. 스토리지와 컴퓨팅이 분리되어 있기 때문에 Milvus는 안정적인 공유 스토리지 백엔드에 의존하면서 컴퓨팅 노드를 독립적으로 확장할 수 있습니다.

Milvus에서 오브젝트 스토리지의 역할

오브젝트 스토리지는 Milvus의 내구성 있는 스토리지 계층입니다. 원시 벡터 데이터는 binlog로 유지되며, HNSW 및 IVF_FLAT과 같은 인덱스 구조도 여기에 저장됩니다.

이 설계는 컴퓨팅 노드를 상태 비저장형으로 만듭니다. 쿼리 노드는 데이터를 로컬에 저장하지 않고 필요에 따라 오브젝트 스토리지에서 세그먼트와 인덱스를 로드합니다. 따라서 노드는 스토리지 계층에서 데이터 리밸런싱 없이도 자유롭게 확장 또는 축소하고, 장애로부터 신속하게 복구하며, 클러스터 전체에서 동적 로드 밸런싱을 지원할 수 있습니다.

my-milvus-bucket/
├── files/                          # rootPath (default)
│   ├── insert_log/                 # insert binlogs
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Field_ID}/
│   │                   └── {Log_ID}     # Per-field binlog files
│   │
│   ├── delta_log/                  # Delete binlogs
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Log_ID}        
│   │
│   ├── stats_log/                  # Statistical data (e.g., Bloom filters)
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Field_ID}/
│   │                   └── {Log_ID}
│   │
│   └── index_files/                # Index files
│       └── {Build_ID}_{Index_Version}_{Segment_ID}_{Field_ID}/
│           ├── index_file_0
│           ├── index_file_1
│           └── ...

Milvus가 S3 API를 사용하는 이유

Milvus는 사용자 정의 스토리지 프로토콜을 정의하는 대신 S3 API를 오브젝트 스토리지 인터페이스로 사용합니다. S3는 사실상 오브젝트 스토리지의 표준으로 자리 잡았으며, AWS S3, Alibaba Cloud OSS, Tencent Cloud COS와 같은 주요 클라우드 제공업체에서 기본적으로 지원하며, MinIO, Ceph RGW, SeaweedFS, RustFS 같은 오픈 소스 시스템과도 완벽하게 호환됩니다.

S3 API로 표준화함으로써 Milvus는 각 스토리지 백엔드에 대해 별도의 통합을 유지하는 대신 성숙하고 충분한 테스트를 거친 Go SDK에 의존할 수 있습니다. 이러한 추상화는 또한 사용자에게 배포 유연성을 제공합니다: 로컬 개발에는 MinIO, 프로덕션 환경에는 클라우드 오브젝트 스토리지, 프라이빗 환경에는 Ceph 및 RustFS를 사용할 수 있습니다. S3 호환 엔드포인트만 있으면 Milvus는 그 밑에 어떤 스토리지 시스템이 사용되는지 알 필요도 없고 신경 쓸 필요도 없습니다.

# Milvus configuration file milvus.yaml
minio:
 address: localhost
 port: 9000
 accessKeyID: minioadmin
 secretAccessKey: minioadmin
 useSSL: false
 bucketName: milvus-bucket

Milvus를 위한 S3 호환 오브젝트 스토리지 백엔드로서 RustFS 평가하기

프로젝트 개요

RustFS는 Rust로 작성된 분산형 객체 스토리지 시스템입니다. 현재 알파 단계(버전 1.0.0-alpha.68)에 있으며, MinIO의 운영 단순성과 메모리 안전 및 성능에 대한 Rust의 강점을 결합하는 것을 목표로 합니다. 자세한 내용은 GitHub에서 확인할 수 있습니다.

RustFS는 아직 활발히 개발 중이며 분산 모드는 아직 공식적으로 출시되지 않았습니다. 따라서 현 단계에서는 프로덕션 또는 미션 크리티컬 워크로드에는 RustFS를 권장하지 않습니다.

아키텍처 설계

RustFS는 개념적으로 MinIO와 유사한 설계를 따릅니다. HTTP 서버는 S3 호환 API를 노출하고, Object Manager는 오브젝트 메타데이터를 처리하며, Storage Engine은 데이터 블록 관리를 담당합니다. 스토리지 계층에서 RustFS는 XFS 또는 ext4와 같은 표준 파일 시스템을 사용합니다.

계획된 분산 모드의 경우, RustFS는 메타데이터 조정을 위해 etcd를 사용하며, 여러 RustFS 노드가 클러스터를 형성합니다. 이러한 설계는 일반적인 오브젝트 스토리지 아키텍처와 밀접하게 연계되어 있어 MinIO를 경험한 사용자에게 친숙하게 다가갈 수 있습니다.

Milvus와의 호환성

대체 오브젝트 스토리지 백엔드로서 RustFS를 고려하기 전에 Milvus의 핵심 스토리지 요구 사항을 충족하는지 평가해야 합니다.

Milvus 요구 사항	S3 API	RustFS 지원
벡터 데이터 지속성	`PutObject`, `GetObject`	✅ 완전 지원
인덱스 파일 관리	`ListObjects`, `DeleteObject`	✅ 완벽하게 지원
세그먼트 병합 작업	멀티파트 업로드	✅ 완벽 지원
일관성 보장	강력한 읽기 후 쓰기	✅ 강력한 일관성(단일 노드)

이 평가에 따르면, RustFS의 현재 S3 API 구현은 Milvus의 기본 기능 요구 사항을 충족합니다. 따라서 비프로덕션 환경에서의 실제 테스트에 적합합니다.

실습: Milvus에서 MinIO를 RustFS로 교체하기

이 실습의 목표는 기본 MinIO 오브젝트 스토리지 서비스를 대체하고 RustFS를 오브젝트 스토리지 백엔드로 사용하여 Milvus 2.6.7을 배포하는 것입니다.

전제 조건

Docker 및 Docker Compose가 설치되어 있고(버전 20.10 이상), 시스템이 이미지를 가져오고 컨테이너를 정상적으로 실행할 수 있어야 합니다.
/volume/data/ (또는 사용자 지정 경로)와 같은 로컬 디렉터리를 개체 데이터 스토리지에 사용할 수 있습니다.
호스트 포트 9000은 외부 액세스를 위해 열려 있거나 그에 따라 대체 포트가 구성됩니다.
RustFS 컨테이너는 루트가 아닌 사용자(rustfs)로 실행됩니다. 호스트 데이터 디렉터리의 소유권이 UID 10001에 있는지 확인합니다.

1단계: 데이터 디렉터리 생성 및 권한 설정하기

# Create the project directory
mkdir -p milvus-rustfs && cd milvus-rustfs
# Create the data directory
mkdir -p volumes/{rustfs, etcd, milvus}
# Update permissions for the RustFS directory
sudo chown -R 10001:10001 volumes/rustfs

공식 Docker 컴포즈 파일 다운로드

wget https://github.com/milvus-io/milvus/releases/download/v2.6.7/milvus-standalone-docker-compose.yml -O docker-compose.yml

2단계: 오브젝트 스토리지 서비스 수정

RustFS 서비스 정의

참고: 액세스 키와 비밀 키가 Milvus 서비스에 구성된 자격 증명과 일치하는지 확인하세요.

rustfs:
 container_name: milvus-rustfs
 image: registry.cn-hangzhou.aliyuncs.com/rustfs/rustfs: latest
 environment:
 RUSTFS_ACCESS_KEY: minioadmin
 RUSTFS_SECRET_KEY: minioadmin
 RUSTFS_CONSOLE_ENABLE: “true”
 RUSTFS_REGION: us-east-1
 # RUSTFS_SERVER_DOMAINS: localhost# Optional; not required for local deployments
 ports:
 - “9001:9001”
 - “9000:9000”
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/rustfs:/data
 command: >
 --address :9000
 --console-enable
 /data
 healthcheck:
 test: [“CMD”, “curl”, “-f”, “http://localhost:9000/health"]
 interval: 30s
 timeout: 20s
 retries: 3

구성 완료

참고: Milvus의 스토리지 구성은 현재 MinIO 스타일의 기본값을 가정하며 사용자 지정 액세스 키 또는 비밀 키 값을 아직 허용하지 않습니다. RustFS를 대체로 사용하는 경우 Milvus에서 예상하는 것과 동일한 기본 자격 증명을 사용해야 합니다.

version: ‘3.5’
services:
 etcd:
 container_name: milvus-etcd
 image: registry.cn-hangzhou.aliyuncs.com/etcd/etcd: v3.5.25
 environment:
 - ETCD_AUTO_COMPACTION_MODE=revision
 - ETCD_AUTO_COMPACTION_RETENTION=1000
 - ETCD_QUOTA_BACKEND_BYTES=4294967296
 - ETCD_SNAPSHOT_COUNT=50000
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd
 command: etcd -advertise-client-urls=http://etcd:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd
 healthcheck:
 test: [“CMD”, “etcdctl”, “endpoint”, “health”]
 interval: 30s
 timeout: 20s
 retries: 3
 rustfs:
 container_name: milvus-rustfs
 image: registry.cn-hangzhou.aliyuncs.com/rustfs/rustfs: latest
 environment:
 RUSTFS_ACCESS_KEY: minioadmin
 RUSTFS_SECRET_KEY: minioadmin
 RUSTFS_CONSOLE_ENABLE: “true”
 RUSTFS_REGION: us-east-1
 # RUSTFS_SERVER_DOMAINS: localhost# Optional; not required for local deployments
 ports:
 - “9001:9001”
 - “9000:9000”
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/rustfs:/data
 command: >
 --address :9000
 --console-enable
 /data
 healthcheck:
 test: [“CMD”, “curl”, “-f”, “http://localhost:9000/health"]
 interval: 30s
 timeout: 20s
 retries: 3
 standalone:
 container_name: milvus-standalone
 image: registry.cn-hangzhou.aliyuncs.com/milvus/milvus: v2.6.7
 command: [”milvus“, ”run“, ”standalone“]
 security_opt:
 - seccomp: unconfined
 environment:
 MINIO_REGION: us-east-1
 ETCD_ENDPOINTS: etcd:2379
 MINIO_ADDRESS: rustfs:9000
 MINIO_ACCESS_KEY: minioadmin
 MINIO_SECRET_KEY: minioadmin
 MINIO_USE_SSL: ”false“
 MQ_TYPE: rocksmq
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus
 healthcheck:
 test: [”CMD“, ”curl“, ”-f“, ”http://localhost:9091/healthz"]
 interval: 30s
 start_period: 90s
 timeout: 20s
 retries: 3
 ports:
 - “19530:19530”
 - “9091:9091”
 depends_on:
 - “etcd”
 - “rustfs”
networks:
 default:
 name: milvus

서비스 시작

docker-compose -f docker-compose.yaml up -d

서비스 상태 확인

docker-compose ps -a

RustFS 웹 UI에 액세스

브라우저에서 RustFS 웹 인터페이스 (http://localhost:9001)를 엽니다 .

기본 자격 증명(사용자 이름과 비밀번호는 모두 minioadmin)을 사용하여 로그인합니다.

Milvus 서비스 테스트

from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType
# connect to Milvus
connections.connect(
 alias="default",
 host='localhost',
 port='19530'
)
print("✓ Successfully connected to Milvus!")
# create test collection
fields = [
 FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
 FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=128)
]
schema = CollectionSchema(fields=fields, description="test collection")
collection = Collection(name="test_collection", schema=schema)
print("✓ Test collection created!")
print("✓ RustFS verified as the S3 storage backend!")
### Step 3: Storage Performance Testing (Experimental)
Test Design
Two Milvus deployments were set up on identical hardware (16 cores / 32 GB memory / NVMe SSD), using RustFS and MinIO respectively as the object storage backend. The test dataset consisted of 1,000,000 vectors with 768 dimensions, using an HNSW index with parameters M = 16 and efConstruction = 200. Data was inserted in batches of 5,000.
The following metrics were evaluated: Insert throughput, Index build time, Cold and warm load time, Search latency, Storage footprint.
Test Code
Note: Only the core parts of the test code are shown below.

def milvus_load_bench(dim=768, rows=1_000_000, batch=5000): collection = Collection(...) # 삽입 테스트 t0 = time.perf_counter() for i in range(0, rows, batch): collection.insert([rng.random((batch, dim), dtype=np.float32).tolist()]) insert_time = time.perf_counter() - t0 # 색인 구축 collection.flush() 컬렉션입니다.create_index(field_name="embedding", index_params={"index_type": "HNSW", ...}) # 로드 테스트(콜드 스타트 + 두 번의 웜 스타트) 컬렉션.release() load_times = [] for i in range(3): if i > 0: collection.release(); time.sleep(2) collection.load() load_times.append(...) # 쿼리 테스트 search_times = [] for _ in range(3): collection.search(queries, limit=10, ...)


**Test Command**

python bench.py milvus-load-bench --dim 768 --rows 1000000 --batch 5000
-index-type HNSW --repeat-load 3 --release-before-load --do-search --drop-after

Metric	RustFS	MinIO	Difference
Insert Throughput	4,472 rows/s	2,845 rows/s	0.57
Index Build Time	803 s	562 s	-43%
Load (Cold Start)	22.7 s	18.3 s	-24%
Load (Warm Start)	0.009 s	0.027 s	0.67
Search Latency	7.96 ms	1.85 ms	-330%
Storage Usage	7.8 GB	18.0 GB	0.57

**Performance Results** RustFS Faster writes (+57%), lower storage usage (–57%), and faster warm loads (+67%), making it suitable for write-heavy, cost-sensitive workloads. Much slower queries (7.96 ms vs. 1.85 ms, ~+330% latency) with noticeable variance (up to 17.14 ms), and 43% slower index builds. Not suitable for query-intensive applications. MinIO Excellent query performance (1.85 ms average latency), mature small-file and random I/O optimizations, and a well-established ecosystem. Metric RustFS MinIO Difference Insert Throughput 4,472 rows/s 2,845 rows/s 0.57 Index Build Time 803 s 562 s -43% Load (Cold Start) 22.7 s 18.3 s -24% Load (Warm Start) 0.009 s 0.027 s 0.67 Search Latency 7.96 ms 1.85 ms -330% Storage Usage 7.8 GB 18.0 GB 0.57 RustFS significantly outperforms MinIO in write performance and storage efficiency, with both showing roughly 57% improvement. This demonstrates the system-level advantages of the Rust ecosystem. However, the 330% gap in query latency limits RustFS’s suitability for query-intensive workloads. For production environments, cloud-managed object storage services like AWS S3 are recommended first, as they are mature, stable, and require no operational effort. Self-hosted solutions are better suited to specific scenarios: RustFS for cost-sensitive or write-intensive workloads, MinIO for query-intensive use cases, and Ceph for data sovereignty. With further optimization in random read performance, RustFS has the potential to become a strong self-hosted option. Conclusion MinIO’s decision to stop accepting new community contributions is disappointing for many developers, but it won’t disrupt Milvus users. Milvus depends on the S3 API—not any specific vendor implementation—so swapping storage backends is straightforward. This S3-compatibility layer is intentional: it ensures Milvus stays flexible, portable, and decoupled from vendor lock-in. For production deployments, cloud-managed services such as AWS S3 and Alibaba Cloud OSS remain the most reliable options. They’re mature, highly available, and drastically reduce the operational load compared to running your own object storage. Self-hosted systems like MinIO or Ceph still make sense in cost-sensitive environments or where data sovereignty is non-negotiable, but they require significantly more engineering overhead to operate safely at scale. RustFS is interesting—Apache 2.0-licensed, Rust-based, and community-driven—but it’s still early. The performance gap is noticeable, and the distributed mode hasn’t shipped yet. It’s not production-ready today, but it’s a project worth watching as it matures. If you’re comparing object storage options for Milvus, evaluating MinIO replacements, or weighing the operational trade-offs of different backends, we’d love to hear from you.

Join our[ Discord channel](https://discord.com/invite/8uyFbECzPX) and share your thoughts. You can also book a 20-minute one-on-one session to get insights, guidance, and answers to your questions through[ Milvus Office Hours](https://milvus.io/blog/join-milvus-office-hours-to-get-support-from-vectordb-experts.md).