블로그
Milvus 스토리지 시스템 개요 및 성능 평가와 최적화를 위한 기법

Milvus 스토리지 시스템 개요 및 성능 평가와 최적화를 위한 기법

Apr 24, 20247 min read

Milvus에 대한 탐구에 오신 것을 환영합니다. Milvus는 인상적인 수평 확장성과 번개처럼 빠른 성능으로 알려진 오픈 소스 벡터 데이터베이스입니다. Milvus의 핵심에는 안정적인 데이터 영속성과 저장을 위한 중요한 기반인 견고한 스토리지 시스템이 있습니다. 이 시스템은 메타 스토리지, 로그 브로커, 객체 스토리지라는 여러 필수 구성 요소로 이루어져 있습니다.

이 가이드에서는 Milvus의 아키텍처를 깊이 살펴보고, 주요 스토리지 구성 요소를 분석하며, 그 성능을 평가하는 효과적인 기법을 살펴봅니다.

Milvus 아키텍처 개요

Milvus는 스토리지와 컴퓨팅의 분리를 보장하고 컴퓨팅 노드의 수평 확장성을 지원하는 분산 아키텍처를 채택합니다. 이 구성은 액세스 계층, 코디네이터 서비스, 워커 노드, 스토리지라는 네 가지 핵심 계층으로 구성되며, 각 계층은 독립적으로 확장 가능하고 재해 복구에 최적화되어 있습니다.

Milvus Architecture Overview.png

액세스 계층: 이 프런트엔드 계층은 사용자 요청을 처리하고 응답을 최적화하는 상태 비저장 프록시로 구성되며, 시스템의 주요 사용자 인터페이스 역할을 합니다.
코디네이터 계층: 시스템의 중앙 명령부 역할을 하는 코디네이터 서비스는 워커 노드 전반에서 작업 분배, 클러스터 토폴로지, 로드 밸런싱, 데이터 관리를 담당합니다.
워커 노드: 이들은 코디네이터 서비스의 지시에 따라 데이터 조작 언어(DML) 명령을 처리하는 실행자입니다.
스토리지: 데이터 영속성의 근간이 되는 이 계층에는 메타 스토리지, 로그 브로커, 객체 스토리지가 포함되어 데이터 무결성과 가용성을 보장합니다.

Milvus 스토리지 구성 요소

Milvus는 데이터 무결성과 가용성을 보장하기 위해 메타 스토리지, 객체 스토리지, 로그 브로커라는 세 가지 주요 스토리지 구성 요소를 사용합니다.

메타 스토리지

Milvus의 메타 스토리지는 컬렉션 스키마, 노드 상태, 메시지 소비 체크포인트와 같은 메타데이터 스냅샷을 저장합니다. 높은 가용성, 강력한 일관성, 트랜잭션 지원이 필요하기 때문에 Milvus는 etcd를 메타 스토리지 솔루션으로 사용합니다. Etcd는 Milvus 내 분산 시스템에 중요한 견고한 분산 키-값 저장소입니다. 메타데이터 보존과 함께 서비스 등록 및 상태 확인 같은 작업을 처리합니다.

객체 스토리지

Milvus의 객체 스토리지는 로그 스냅샷 파일, 스칼라 및 벡터 데이터용 인덱스 파일, 중간 쿼리 결과의 저장을 처리합니다. Milvus는 높은 성능과 Kubernetes와의 호환성 때문에 객체 스토리지로 MinIO를 통합하여 AWS S3 및 Azure Blob Storage와 같은 클라우드 환경에서 원활한 운영을 지원합니다.

로그 브로커

Milvus의 로그 브로커는 재생 기능을 갖춘 pub-sub 시스템을 채택합니다. 이는 스트리밍 데이터 영속성, 안정적인 비동기 쿼리 실행, 이벤트 알림, 쿼리 결과 반환에 필수적입니다. 또한 시스템 장애로부터 워커 노드를 복구하는 동안 증분 데이터의 무결성을 보장합니다. 배포 방식에 따라 Milvus는 서로 다른 로그 브로커 도구를 사용합니다. Milvus Cluster 구성에서는 Pulsar 또는 Kafka를 사용하며, Milvus 독립 실행형 버전에서는 일반적으로 RocksDB를 사용합니다.

Milvus 스토리지 성능을 평가하고 최적화하는 방법

스토리지 성능을 지속적으로 평가하고 개선하는 것은 매우 중요합니다.

Etcd: Milvus의 메타데이터 저장소

Etcd는 분산 시스템을 위해 설계된 견고한 분산 키-값 저장소입니다. Milvus에서 etcd는 컬렉션 스키마, 노드 상태, 메시지 소비 체크포인트와 같은 필수 데이터를 저장하는 메타데이터 저장소입니다.

디스크 쓰기 지연 시간은 etcd의 성능에 매우 중요합니다. 느린 디스크 속도는 요청 지연 시간을 크게 증가시키고 시스템 안정성에 위험을 초래할 수 있습니다. 프로덕션 환경에서 최적의 성능을 위해 최소 500 순차 IOPS(초당 입출력 작업 수)를 지속적으로 유지하여 fdatasync 지속 시간의 99%가 10밀리초 미만으로 유지되도록 하는 것을 권장합니다. etcd는 일반적으로 중간 수준의 디스크 대역폭만 요구하지만, 이 대역폭을 늘리면 복구 시간을 현저히 줄일 수 있습니다. 따라서 프로덕션 환경의 기준 디스크 대역폭으로 최소 100MB/s를 권장합니다.

스토리지 솔루션이 이러한 기준을 충족하는지 확인하려면 디스크 벤치마킹 도구인 Fio를 사용하여 성능 평가를 수행하는 것을 고려해 보세요. 아래는 Fio를 사용하여 스토리지 성능을 평가하는 방법에 대한 가이드입니다.

먼저 시스템에 Fio가 설치되어 있는지 확인합니다. 그런 다음, 스토리지가 마운트된 디렉터리를 test-data 디렉터리로 지정하여 다음 명령을 실행합니다. 이 디렉터리는 스토리지 연결 지점 아래에 있어야 합니다.

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

결과를 확인하여 fdatasync 지속 시간의 99%가 10ms 미만이고 쓰기 IOPS가 500보다 높은지 확인합니다. 이러한 조건이 충족되면 스토리지가 충분한 성능을 제공합니다.

아래는 출력 결과의 예시입니다:

Jobs: 1 (f=1): [W(1)][100.0%][w=1771KiB/s][w=788 IOPS][eta 00m:00s]
mytest: (groupid=0, jobs=1): err= 0: pid=703: Mon Jul 25 08:36:48 2022
 write: IOPS=967, BW=2173KiB/s (2225kB/s)(220MiB/103664msec); 0 zone resets
   clat (nsec): min=1903, max=29662k, avg=287307.76, stdev=492386.04
    lat (nsec): min=1981, max=29662k, avg=287583.67, stdev=492438.10
   clat percentiles (usec):
    |  1.00th=[    3],  5.00th=[    4], 10.00th=[    4], 20.00th=[    5],
    | 30.00th=[    6], 40.00th=[    9], 50.00th=[  233], 60.00th=[  343],
    | 70.00th=[  437], 80.00th=[  553], 90.00th=[  701], 95.00th=[  742],
    | 99.00th=[ 1172], 99.50th=[ 2114], 99.90th=[ 6390], 99.95th=[ 8455],
    | 99.99th=[15533]
  bw (  KiB/s): min= 1630, max= 2484, per=100.00%, avg=2174.66, stdev=193.65, samples=207
  iops        : min=  726, max= 1106, avg=968.37, stdev=86.19, samples=207
 lat (usec)   : 2=0.03%, 4=16.49%, 10=27.68%, 20=3.21%, 50=0.71%
 lat (usec)   : 100=0.27%, 250=2.65%, 500=24.64%, 750=20.40%, 1000=2.57%
 lat (msec)   : 2=0.82%, 4=0.30%, 10=0.18%, 20=0.03%, 50=0.01%
 fsync/fdatasync/sync_file_range:
   sync (usec): min=309, max=21848, avg=741.93, stdev=489.64
   sync percentiles (usec):
    |  1.00th=[  392],  5.00th=[  437], 10.00th=[  474], 20.00th=[  529],
    | 30.00th=[  578], 40.00th=[  619], 50.00th=[  660], 60.00th=[  709],
    | 70.00th=[  742], 80.00th=[  791], 90.00th=[  988], 95.00th=[ 1369],
    | 99.00th=[ 2442], 99.50th=[ 3523], 99.90th=[ 6915], 99.95th=[ 8586],
    | 99.99th=[11994]

클라우드 환경에서 Milvus 클러스터를 배포할 때 etcd는 디스크 성능에 민감하므로 적절한 블록 스토리지 유형을 선택하는 것이 중요합니다. 클라우드 제공업체는 다양한 블록 스토리지 옵션을 제공하며, 각 옵션은 서로 다른 워크로드에 적합한 고유한 성능 특성을 갖습니다.

아래는 다양한 클라우드 제공업체의 권장 볼륨 유형 및 성능 지표입니다.


클라우드 제공업체	볼륨 유형	크기	IOPS	P99 sync
AWS	gp3	20Gi	660	4.3ms
GCP	pd-ssd	20Gi	1262	1.3ms
Azure	PremiumV2	20Gi	705	2.6ms
Aliyun	cloud_essd	20Gi	1137	3.5ms

Fio를 사용하여 선택한 블록 스토리지가 Milvus 배포 내에서 etcd의 최적 작동에 필요한 성능 벤치마크를 충족하는지 확인할 수도 있습니다.

MinIO: Milvus 객체 스토리지 도구

MinIO는 클라우드 네이티브 워크로드에 최적화된 고성능 Kubernetes 네이티브 객체 스토리지 솔루션입니다. Milvus는 MinIO를 사용하여 로그의 스냅샷 파일, 스칼라 및 벡터 데이터의 인덱스 파일, 중간 쿼리 결과를 저장합니다.

MinIO와 같은 객체 스토리지의 성능은 주로 IOPS가 아니라 I/O 처리량으로 평가됩니다. 이 지표는 컬렉션 로드, 인덱스 빌드, 데이터 삽입과 같은 Milvus의 다양한 작업에 큰 영향을 미칩니다. 네트워크 대역폭, Linux 커널 성능 튜닝, 개별 디스크 드라이브의 성능을 포함하여 많은 요인이 MinIO의 처리량 성능에 영향을 줍니다. 디스크 성능은 특히 중요합니다.

dd 명령을 사용하여 단일 드라이브 성능을 측정할 수 있습니다. DD는 한 파일에서 다른 파일로 데이터를 비트 단위로 복사하는 Unix 도구입니다. 각 읽기 및 쓰기의 블록 크기를 제어하는 다양한 옵션을 제공합니다.

아래 예에서 16MB 블록 크기로 단일 NVMe 드라이브를 테스트할 때, 64 카운트에 대한 O_DIRECT 옵션은 드라이브당 초당 2GB를 초과하는 쓰기 성능을 생성합니다.

$ dd if=/dev/zero of=/mnt/drive/test bs=16M count=64 oflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.443096 s, 2.4 GB/s

동일한 예에서 16MB 블록 크기로 단일 NVMe 드라이브를 테스트할 때, 64 카운트에 대한 O_DIRECT 옵션은 드라이브당 초당 5GB를 초과하는 읽기 성능을 생성합니다.

$ dd of=/dev/null if=/mnt/drive/test bs=16M count=64 iflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.187263 s, 5.7 GB/s

디스크 드라이브의 읽기 및 쓰기 성능이 높을수록 MinIO의 전체 처리량 성능이 더 좋아집니다. 최적의 결과를 위해 MinIO 설정에서 스토리지 디스크로 SSD 또는 NVMe 유형 드라이브를 사용하는 것을 권장합니다. 이러한 드라이브는 MinIO 작업의 높은 처리량 요구 사항을 효과적으로 지원할 수 있습니다. MinIO 스토리지에 SAN/NAS 어플라이언스를 사용하지 마십시오. 이러한 설정은 종종 동시성 문제와 성능 병목 현상을 유발하여 시스템의 효율성과 응답성을 저하시킬 수 있습니다.

Pulsar/Kafka: Milvus 로그 브로커 도구

위에서 언급했듯이, Milvus는 특정 배포 모드에 맞춘 다양한 로그 브로커 도구를 사용합니다. Milvus Cluster 설정은 Pulsar 또는 Kafka를 사용하며, Milvus standalone 버전은 일반적으로 RocksDB를 사용합니다.

Pulsar와 Kafka는 모두 영구 메시지 스토리지를 지원하고 메시지 소비자에게 높은 처리량을 제공하도록 설계되었습니다. 이들은 순차 디스크 I/O 작업에 의존하므로, 성능은 사용되는 디스크 스토리지 유형에 크게 좌우됩니다.

Pulsar의 경우, 데이터 무결성과 내구성을 보장하기 위해 BookKeeper의 저널 파일에는 고성능 디스크가 필수적이며, 이 목적에는 저지연 SSD가 매우 유용합니다. Pulsar Ledgers와 Kafka는 모두 파일 시스템 캐시를 활용하고 HDD 및 SSD에서 우수하게 작동하도록 디스크 효율성에 최적화되어 있습니다. 그러나 지연 시간에 민감한 애플리케이션이나 대규모 배포의 경우 SSD는 상당한 성능 이점을 제공합니다.

성능을 최적화하려면 Pulsar와 Kafka에 여러 디스크 장치를 사용하십시오. 특히 Pulsar의 경우, 저널과 일반 스토리지에 별도의 디스크를 사용하면 bookies가 쓰기 작업의 지연 시간을 읽기 작업과 분리할 수 있습니다. 최적의 지연 시간을 보장하려면 데이터, 애플리케이션 로그 또는 기타 OS 파일 시스템 활동을 저장하는 데 동일한 드라이브를 사용하지 마십시오. 이러한 드라이브는 RAID를 사용하여 단일 볼륨으로 구성하거나, 각 드라이브를 자체 디렉터리로 포맷하고 마운트할 수 있습니다. 네트워크 연결 스토리지(NAS)는 더 느린 성능, 더 높고 변동성이 큰 지연 시간, 단일 장애 지점이 될 가능성 때문에 피해야 합니다.

요약

Milvus 스토리지 시스템에 대한 심층적인 탐구는 그 아키텍처와 구성 요소에 대한 포괄적인 통찰을 제공하며, 대규모 데이터 관리 및 분석을 지원하는 데 있어 이들의 역할을 강조합니다. 우리는 Milvus의 세 가지 주요 스토리지 구성 요소인 메타 스토리지, 객체 스토리지, 로그 브로커를 분석하고, 이들의 성능을 평가하고 향상시키기 위한 전략을 제공했습니다.

Jul 13, 2026에 업데이트됨

계속 읽기

VDBBench Adds Cost-Aware Benchmarking for Vector Databases

Compare Zilliz Cloud, Pinecone, and turbopuffer with VDBBench cost-aware vector database benchmarks across latency, freshness, multitenancy, and cold starts.

3 Easiest Ways to Use Claude Code on Your Mobile Phone

Run Claude Code from your phone with Remote Control, Happy Coder, or SSH + Tailscale. Comparison table, setup steps, and tools for typing, memory, and parallel tasks.

How to Build RAG with Milvus, QwQ-32B and Ollama

Hands-on tutorial on how to create a streamlined, powerful RAG pipeline that balances efficiency, accuracy, and scalability using the QwQ-32B and Milvus.