Kubernetes에서 EC2 및 S3 기반 영구 스토리지를 사용한 Milvus 오토스케일링
빠르게 증가하는 벡터 데이터(검색, 추천 및 RAG를 위한 임베딩)를 사용하는 AI 플랫폼은 쿼리 로드 및 데이터 볼륨에 따라 Milvus 벡터 데이터베이스가 자동으로 스케일링되도록 필요했습니다. 이들은 Pod가 재시작되거나 노드가 교체되더라도 손실되지 않는 내구성 있고 비용 효율적인 스토리지를 원했습니다.
프로젝트 상담하기
과제
프로덕션 환경에서 Milvus를 대규모로 운영하는 것은 몇 가지 인프라 과제를 제시했습니다:
- 고정 용량 — 정적 Milvus 배포는 피크 시간 동안 10배의 쿼리 로드 급증을 처리할 수 없었습니다.
- 데이터 손실 위험 — 임시 스토리지에서 Pod가 재시작되면 대규모 컬렉션에서 인덱스 재구축에 몇 시간이 걸렸습니다.
- 비용 비효율성 — 피크 로드를 위한 과도한 프로비저닝은 시간의 70% 동안 유휴 컴퓨팅에 대한 비용을 지불해야 함을 의미했습니다.
- 스토리지 비용 — 인스턴스에 연결된 블록 스토리지 볼륨은 수 테라바이트의 벡터 데이터셋에 대해 비용이 많이 들었습니다.
- 인덱스 재구축 — 노드 교체 후 수백만 개의 벡터를 재인덱싱하는 데 몇 시간의 다운타임이 발생했습니다.
- Multi-AZ 내구성 — 단일 AZ 스토리지는 가용성 영역 장애에서 살아남을 수 없었습니다.
우리의 솔루션
쿼리 노드를 위한 Horizontal Pod Autoscaling, 컴퓨팅을 위한 Cluster Autoscaler, 그리고 영구 스토리지 백엔드로 Amazon S3를 사용하여 Kubernetes (EKS)에 Milvus를 배포했습니다. 이를 통해 데이터 손실 위험을 제거하고 스토리지 비용을 약 80% 절감했습니다.
아키텍처
- 오케스트레이션: Amazon EKS (Elastic Kubernetes Service)
- 컴퓨팅: Cluster Autoscaler에 의해 관리되는 EC2 인스턴스 (혼합 인스턴스 유형)
- 벡터 DB: 분산 모드로 Helm 차트를 통해 배포된 Milvus
- 객체 스토리지: 세그먼트 파일, 인덱스 파일 및 바이너리 로그(binlog) 영구 저장을 위한 Amazon S3
- 메타데이터: Milvus 조정 및 메타데이터를 위한 etcd 클러스터
- 메시지 큐: Milvus 로그 파이프라인을 위한 메시지 스트리밍
- 모니터링: Milvus 메트릭 및 오토스케일링 신호를 위한 Prometheus + Grafana
Kubernetes 기반 Milvus 분산 아키텍처
컴포넌트 배포
Milvus는 전용 노드 유형으로 분산 모드에서 실행되며, 각 노드 유형은 독립적인 스케일링을 가진 Kubernetes 워크로드로 배포됩니다:
- 프록시 노드 — 클라이언트 연결 및 요청 라우팅 처리
- 쿼리 노드 — 벡터 검색을 실행하고 세그먼트를 메모리에 로드
- 데이터 노드 — 쓰기 경로를 처리하고 세그먼트를 S3로 플러시
- 인덱스 노드 — 벡터 인덱스를 구축하고 S3에 쓰기
- 코디네이터 — 클러스터 조정 및 타임스탬프 할당
- etcd — 메타데이터 저장소 및 서비스 디스커버리
- 메시지 큐 — 로그 스트리밍 및 선행 기록 로그(write-ahead log)
Horizontal Pod Autoscaling (HPA)
쿼리 노드 오토스케일링
쿼리 노드는 주요 스케일링 대상입니다. 이들은 벡터 세그먼트를 메모리에 로드하고 검색을 실행합니다. 스케일링은 CPU 사용률, 메모리 사용률, 쿼리 큐 깊이 및 P99 쿼리 지연 시간과 같은 여러 메트릭에 의해 구동됩니다. HPA는 적절한 최소/최대 복제본, 급증 처리를 위한 빠른 스케일업, 그리고 플래핑(flapping)을 방지하기 위한 점진적인 스케일다운으로 구성됩니다.
인덱스 노드 오토스케일링
인덱스 노드는 보류 중인 인덱스 빌드 작업에 따라 스케일링됩니다. 빌드 큐에 보류 중인 항목이 있을 때 스케일업하고, 유휴 상태일 때 스케일다운합니다.
EC2 Cluster Autoscaler
인스턴스 전략
- 노드 그룹: 비용 최적화를 위한 다양한 인스턴스 유형을 가진 여러 노드 그룹
- 쿼리 워크로드: 인메모리 벡터 세그먼트를 위한 메모리 최적화 인스턴스
- 인덱스 워크로드: CPU 집약적인 인덱스 구축을 위한 컴퓨팅 최적화 인스턴스
- 스팟 인스턴스: 인덱스 노드 및 비주요 데이터 노드는 상당한 비용 절감을 위해 스팟 인스턴스에서 실행됩니다.
- 온디맨드: 안정성을 위한 온디맨드 인스턴스의 쿼리 노드 및 코디네이터
스케일링 동작
HPA가 스케줄링할 수 없는 새 Pod를 생성하면 Cluster Autoscaler는 적절한 노드 그룹에 새 EC2 인스턴스를 프로비저닝합니다. 새 쿼리 노드는 할당된 세그먼트를 S3에서 메모리로 로드하고 쿼리를 서비스하기 시작하며, 전체 스케일업 프로세스는 몇 분 안에 완료됩니다.
S3 기반 영구 스토리지
블록 스토리지 대신 S3를 사용하는 이유
S3는 Milvus에 블록 스토리지보다 상당한 이점을 제공합니다:
- 대규모 데이터셋의 경우 스토리지 비용 약 80% 절감
- 내장된 multi-AZ 복제를 통한 11-나인즈(nines) 내구성
- 수동 볼륨 크기 조정 없이 무제한 스케일링
- Pod 독립적 — Pod 또는 노드 라이프사이클과 관계없이 항상 데이터 사용 가능
- AZ 종속성 없음 — 모든 가용성 영역에서 데이터 접근 가능
S3를 이용한 데이터 흐름
- 쓰기 경로: 데이터 노드는 삽입을 메모리에 버퍼링한 다음, 봉인된 세그먼트를 S3로 플러시합니다.
- 인덱스 구축: 인덱스 노드는 S3에서 세그먼트를 읽고, 인덱스를 구축하고, 인덱스 파일을 다시 S3에 씁니다.
- 쿼리 경로: 쿼리 노드는 S3에서 세그먼트와 인덱스를 다운로드하고, 메모리에 로드하고, 쿼리를 서비스합니다.
- 복구: Pod 재시작 시, 쿼리 노드는 할당된 세그먼트를 S3에서 다시 다운로드합니다 (데이터 손실 없음).
S3 성능 최적화
- 세그먼트 크기 튜닝은 S3 요청 비용과 데이터 신선도의 균형을 맞춥니다.
- NVMe 인스턴스 스토리지의 로컬 SSD 캐싱은 핫 세그먼트에 대한 반복적인 S3 읽기를 방지합니다.
- 병렬 다운로드는 빠른 쿼리 노드 시작을 가능하게 합니다.
- 수명 주기 정책은 오래된 데이터를 더 저렴한 스토리지 계층으로 아카이브합니다.
모니터링 및 관측 가능성
배포는 Prometheus 및 Grafana를 통한 포괄적인 모니터링을 포함합니다:
- 쿼리 성능 — 지연 시간 분포, QPS, 캐시 적중률
- 클러스터 개요 — 노드 수, Pod 상태, 리소스 활용도
- 스토리지 상태 — S3 사용량, 세그먼트 수, 플러시 속도
- 오토스케일링 이벤트 — HPA 이벤트, 노드 스케일링, Pod 스케줄링 지연 시간
- 경고 — 높은 지연 시간, OOM 위험, 플러시 실패 및 용량 제한에 대한 자동화된 경고
주요 기능
- 쿼리 노드 HPA — CPU, 메모리, 지연 시간 및 큐 깊이에 기반한 자동 스케일링
- EC2 Cluster Autoscaler — 혼합 인스턴스 유형을 사용한 동적 노드 프로비저닝
- S3 영구성 — 11-나인즈(nines) 내구성, 블록 스토리지보다 약 80% 저렴, AZ 장애에도 생존
- 스팟 인스턴스 — 상당한 컴퓨팅 비용 절감을 위한 스팟 인스턴스상의 인덱스 및 데이터 노드
- 로컬 SSD 캐시 — NVMe 캐싱은 핫 세그먼트에 대한 반복적인 S3 읽기를 제거합니다.
- 제로 다운타임 복구 — Pod 재시작 시 S3에서 세그먼트를 다시 로드하여 데이터 손실 없음
- Multi-AZ — S3 스토리지 + Multi-AZ 노드 그룹으로 완전한 AZ 장애 허용
- 관측 가능성 — Milvus 특정 메트릭 및 오토스케일링 가시성을 제공하는 Prometheus + Grafana
결과
기술 스택
caseStudyDetail.more 사례 연구
더 많은 기술 구현 사례를 살펴보세요
자주 묻는 질문
MicrocosmWorks는 Milvus의 내장 메모리 사용량 익스포터에서 가져온 사용자 지정 지표를 사용하여 horizontal pod autoscaling을 구성했습니다. 이는 모든 쿼리 노드의 메모리 사용률이 75%를 초과할 때 스케일 아웃 이벤트를 트리거합니다. 컬렉션 세그먼트는 Milvus의 세그먼트 매니저를 사용하여 새 노드에 자동으로 재배포되며, 이로써 단일 노드가 병목 현상이 되는 것을 방지합니다.
MicrocosmWorks는 스토리지를 컴퓨팅에서 분리하여 새로운 EBS 볼륨을 프로비저닝할 필요 없이 쿼리 노드가 독립적으로 확장할 수 있도록 MinIO를 객체 스토리지 계층으로 사용하는 S3 기반 스토리지를 선택했습니다. 이 아키텍처는 S3에서 100ms 미만의 세그먼트 로드 시간을 유지하면서 gp3 EBS 볼륨과 비교하여 스토리지 비용을 약 60% 절감합니다.
MicrocosmWorks는 쿼리 노드, 인덱스 노드, 데이터 노드를 포함한 각 Milvus 컴포넌트에 대해 배포를 레플리카 세트로 구성했으며, Pod disruption budgets를 통해 롤링 업데이트 중 최소 가용성을 보장합니다. 모든 영구 데이터는 S3에 저장되므로, 장애가 발생한 노드의 대체 노드는 데이터 마이그레이션 없이 즉시 모든 세그먼트에 접근할 수 있습니다.
MicrocosmWorks는 Milvus 쿼리 워크로드에 대해 r6i.2xlarge 인스턴스가 최적의 비용-성능 비율을 제공하며, 경쟁력 있는 스팟 가격으로 인메모리 세그먼트 캐싱을 위한 64GB 메모리를 제공한다는 것을 발견했습니다. GPU 가속 인덱스 빌드의 경우, NVIDIA A10G GPU가 탑재된 g5.xlarge 인스턴스는 CPU 전용 빌드와 비교하여 인덱스 빌드 시간을 8배 단축했습니다.
MicrocosmWorks는 Kubernetes 인프라 프로젝트를 시간당 $30-$50의 요율로 제공하며, Helm chart 사용자 지정, HPA 구성, S3 통합 및 모니터링 설정 등을 포함하는 Milvus autoscaling 배포는 일반적으로 150-250시간이 소요됩니다. 클러스터 최적화 및 업그레이드를 위한 지속적인 관리 지원은 동일한 시간당 요율로 이용 가능합니다.