자체 관리형 Milvus를 Zilliz Cloud로 마이그레이션하여 지연 시간 99% 이상 감소
원래 simonhearne.com에 게시되었으며 허가를 받아 재게시되었습니다.
그래서 여러분은 Standalone 또는 Distributed를 사용해 Milvus를 벡터 데이터베이스로 사용하는 애플리케이션을 구축했습니다. 애플리케이션이 작동하고, 고객들이 사용하고 있으며, 데이터 볼륨이 증가하는 지점에 도달했습니다. 어느 순간 벡터 데이터베이스를 관리하는 데 더 많은 시간이 소요되기 시작하고, pod 장애로 서비스 지터가 발생하며, 서버의 RAM이 부족해지거나, etcd가 고통스러운 병목 지점이 됩니다.
이 단계에서는 운영 부담을 덜어줄 관리형 서비스를 검토하고 있을 가능성이 큽니다. 좋은 소식은 Milvus에서 Zilliz Cloud로 마이그레이션하는 과정이 간단하며, 다양한 옵션이 잘 문서화되어 있다는 점입니다.
제 경우에는 간단한 Wikipedia RAG 애플리케이션을 구축했습니다. Cohere의 Embed v3 다국어 모델을 사용한 1,024차원 임베딩 5천만 개(전체 Wikipedia 영어 말뭉치 포함)였습니다. 처음에는 Milvus Standalone을 사용해 제 노트북에서 호스팅했지만, 컨테이너가 불안정했고 재시작에 약 20분이 걸렸습니다. 데모를 보여주고 싶을 때는 이상적이지 않죠!
잦은 페이징 때문에 쿼리 성능도 저하되고 있었습니다(제 노트북에는 메모리가 충분하지 않아 mmap을 활성화했습니다). 아래는 애플리케이션이 동작하는 모습을 보여주는 짧은 동영상입니다.
3초의 쿼리 시간은 훌륭하다고 할 수 없으므로, 새 노트북을 살 예산이 없는 상태에서 Zilliz Cloud의 관리형 Milvus로 마이그레이션을 계획했습니다. 다음은 제가 따른 단계별 과정입니다. 사용할 수 있는 방법은 여러 가지가 있지만, 저는 단순성을 위해 백업/복원을 선택했습니다.
1. 백업 생성
Zilliz는 milvus-backup 유틸리티를 제공하며, 설치는 brew install milvus-backup만큼 간단합니다.
그다음 config 파일을 만들어야 합니다(milvus-backup은 기본적으로 현재 작업 디렉터리에서 backup.yaml을 찾습니다). 이는 로컬에서 Docker로 실행 중인 Standalone으로부터 백업을 생성하는 최소 예시입니다(전체 yaml options는 GitHub에서 확인하세요).
milvus:
address: localhost
port: 19530
user: "root"
password: "Milvus"
tlsMode: 0
etcd:
endpoints: 127.0.0.1:2379
rootPath: "by-dev"
minio:
storageType: "local"
rootPath: "/../milvus_wikipedia/volumes/milvus/data"
backupStorageType: "local"
backupRootPath: "/../milvus-backup-test/backup"
그런 다음 빠르게 확인을 실행합니다.
$ milvus-backup check
Milvus version: 2.6.2
Storage:
milvus-storage-type: local
milvus-bucket: a-bucket
milvus-rootpath: /../milvus_wikipedia/volumes/milvus/data
backup-storage-type: local
backup-bucket: a-bucket
backup-rootpath: /../milvus-backup-test/backup
Success!
마지막으로 백업을 생성합니다(약간의 시간이 걸립니다).
$ milvus-backup create -n wiki_backup
2. Zilliz Cloud에 대상 인스턴스 생성
먼저 Zilliz Cloud 계정이 있는지 확인한 다음, 로컬 배포의 최소 요구 사항과 일치하는 인스턴스를 생성합니다. Tiered-Storage에서 실행되는 제 5천만 개 x 1,024-D 임베딩의 경우, 공개 계산기는 2개의 Query CU가 필요하다고 추정했습니다.
그래서 클라우드 콘솔로 이동해 "+ Cluster"를 클릭하고 다음 설정을 사용했습니다:
생성되는 동안, 다음 단계에 필요한 API 키를 가져오거나 생성할 수 있습니다:
그리고 새 인스턴스의 클러스터 ID를 기록해 두세요:
3. Zilliz로 마이그레이션
방금 생성/가져온 클라우드 키를 포함하도록 backup.yaml을 업데이트하세요:
cloud:
address: https://api.cloud.zilliz.com
apikey: <your-api-key>
그런 다음 마지막으로 백업 이름과 대상 클러스터 ID를 인수로 전달하여 마이그레이션 명령 하나만 실행하면 됩니다:
$ milvus-backup migrate -n wiki_backup -c <your-cluster-id>
제 경우에는 ~120GB 백업 파일을 Zilliz Cloud의 Volume에 업로드하는 데 몇 시간이 걸렸고, 그런 다음 Volume에서 대상 클러스터를 생성하는 데 약 한 시간이 걸렸습니다. Zilliz Cloud 콘솔의 Jobs에서 마이그레이션 상태를 모니터링할 수 있습니다:
마이그레이션이 완료되면 컬렉션을 클러스터에 로드해야 합니다!
4. 검증
이제 애플리케이션이 새 클러스터 엔드포인트와 자격 증명을 사용하도록 간단히 업데이트할 수 있습니다.
Milvus Standalone과 비교해 성능 향상이 관찰됩니다 — 3,112ms 대비 25ms — 이는 99%가 넘는 지연 시간 감소입니다!. 이는 부분적으로 클라우드 서비스에 할당된 컴퓨팅이 증가했기 때문이며, 또한 Zilliz Cloud의 독자적인 인덱스 엔진인 Cardinal 덕분이기도 합니다. Cardinal은 Milvus OSS와 비교해 쿼리를 10배 더 빠르게 처리할 수 있습니다.
성능 향상도 엄청나지만, 더 좋은 점은 더 이상 컨테이너가 중지될 걱정을 할 필요가 없고, 제 노트북에서 ~20GB RAM을 확보할 수 있다는 것입니다!
5. 기타 고려 사항
- 애플리케이션이 24x7로 실행되지 않는다면, 벡터 데이터베이스도 그럴 필요가 없습니다. 사용하지 않을 때 컴퓨팅 비용을 0으로 낮추려면 비활성 클러스터를 일시 중지하세요.
- Tiered-Storage는 낮은(<10 QPS) 요구사항에 적합한 훌륭한 클러스터 유형이지만, 다른 옵션도 있으며 그 사이에서 데이터를 마이그레이션할 수 있습니다:
- On-Demand — 쿼리가 실행될 때만 컴퓨팅을 사용합니다. 쿼리 빈도에 따라 비용을 99%까지 낮출 수 있지만, 더 높은 콜드 스타트 지연 시간이 발생합니다.
- Capacity-Optimized — Tiered-Storage에 비해 데이터 밀도는 낮지만, 처리량은 10배 더 높고 쿼리는 2~5배 더 빠릅니다. 이 경우 제 예시의 컴퓨팅 비용은 약 60% 증가합니다.
- Performance-Optimized — 데이터 밀도는 더 낮아지는 대신, 훨씬 더 높은 처리량(복제본당 >1,000 QPS)과 성능(10~100배 더 빠름)을 제공합니다.
- Zilliz Cloud는 Google Cloud Storage, Amazon S3, Azure Blob Storage 등의 외부 볼륨 마운트를 지원합니다. 따라서 더 깔끔한 접근 방식은 백업을 클라우드 스토리지에 직접 업로드하고 거기에서 복원하는 것입니다.
- 어떤 이유로든 백업 생성/복원이 불가능하고 Milvus 배포를 공개적으로 접근 가능하게 만들 수 있다면, Zilliz Cloud의 Migrate from Milvus Endpoint 기능을 사용할 수 있습니다.
- 클릭 작업이 선호하는 방법론이 아니라면, Zilliz Cloud에서 수행한 모든 작업은 API 및/또는 Terraform을 통해 관리할 수 있습니다.
계속 읽기
How to Install and Run OpenClaw (Previously Clawdbot/Moltbot) on Mac
Turn your Mac into an AI gateway for WhatsApp, Telegram, Discord, iMessage, and more — in under 5 minutes.
Will Amazon S3 Vectors Kill Vector Databases—or Save Them?
AWS S3 Vectors aims for 90% cost savings for vector storage. But will it kill vectordbs like Milvus? A deep dive into costs, limits, and the future of tiered storage.
Zilliz Named "Highest Performer" and "Easiest to Use" in G2's Summer 2025 Grid® Report for Vector Databases
Zilliz shines in G2's Summer 2025 Grid® Report as both "Highest Performer" and "Easiest to Use," solving the performance-usability dilemma.