https://milvus.io/docs/four_layers.md
Milvus는 Cloud native application 으로 Cloud 환경에서 동작하는데 최적화되어있다. 확장성과 유연성을 위해서 control plane 과 data plane을 분리하고 storage layer와 computing layer를 분리했다. 이로 인해서 Milvus는 Access Layer, Coordinator Service, Worker nodes, Storage 총 4개의 컴포넌트로 구성되어 있으며 확장성과 유연성을 갖출 수 있다.
Access Layer
가장 기본적으로 유저가 Milvus를 사용하기 위해 접근하는 Layer 이다. Milvus 는 Massive Parrallel Processing (MPP) 을 사용하기 때문에 client에 최종 결과를 보내기 전 결과를 집계하고 후처리한다. 병렬처리를 위해 곧바로 요청에 대한 응답을 보내기보다는 배치형태로 일괄적으로 응답에 대한 결과를 반환하는 것 같다. 이러한 역할을 Access Layer의 Proxy에서 담당하고 있다.
Coordinator Service
받은 요청을 Worker node들에 분담하는 역할과 시스템의 뇌 역할을 담당한다. 클러스터 토폴로지 관리, 로드밸런싱, 타임스탬프 생성, 데이터 선언(DDL), 데이터 관리등을 수행한다. Coordinator Service는 root coord, data coord, query coord 세가지로 구성되어있다.
Root coordinator
Root coord는 다음 역할을 한다.
1. DDL, DCL 을 수행. collection, partition, index 등을 생성
2. TSO( timestamp Oracle) 이나 time ticker issuing을 관리
Query coordinator
query coord는 다음 역할을 한다.
1. 토폴로지 관리
2. 쿼리를 query nodes에게 로드밸런싱
3. growing segments를 sealed segments로 변경
Data coordinator
Data coord는 다음 역할을 한다.
1. data nodes, index nodes의 토폴로지 관리
2. 메타데이터 관리
3. 데이터 flush
4. 데이터 compaction
5. index 빌드
6. 백그라운드에서 데이터 오퍼레이션 수행
Worker nodes
팔, 다리 역할을 한다. Worker node는 Coordinator Service로부터 지시받은 일을 하거나 Proxy로부터 받은 DML만을 바보같이 수행한다. storage 와 computing 을 분리하기 때문에, Worker nodes는 stateless 하고 이를 통해 쉽게 Scale-out이 가능하며 DR 구현이 가능하다. ( k8s 상에 배포되었을 때 )
Worker node는 다음 3가지의 분류가 있다.
Query node
Query node는 다음 역할을 한다.
1. log brokers를 구독하여 incremental log data를 가져오고 이를 growing segment로 변환한다.
2. object storage 에서 historical data 를 가져온다.
3. vector 나 scalar data 들 간의 hybrid search를 ㅅ수행한다.
Data node
Data node는 다음 역할을 수행한다.
1. log brokers로부터 incremental log data를
가져온다.
2. mutation request들을 처리한다.
3. log data를 log snapshot으로 만든 뒤 object storage에 보관한다.
Index node
Index 를 만드는 역할을 한다. Index node는 메모리에 상주할 필요가 없다. Serverless 프레임워크로도 구현될 수 있다.
Storage
시스템의 뼈대역할을 하며 데이터의 영속성에 대한 책임을 갖는다.
Meta storage
Meta storage 는 collection schema 나 message consumption checkpoint와 같은 메타데이터들을 저장한다. 메타 데이터를 저장하는 저장소는 고가용성, 강한 일관성, 트랜잭션 등을 지원해야하기 때문에 Milvus는 메타 저장소로 etcd를 사용한다.
Object storage
object storage는 log, index, 쿼리 실행의 결과 들을 보관한다. Milvus는 MinIO를 사용하며 AWS S3나 Azure blob도 지원한다. 하지만 Object storage는 매우 많이 접근되며 latency 가 중요하기 때문에 Milvus에서는 hot-cold 데이터를 나눈 뒤 메모리 또는 SSD 기반의 cache pool을 사용하는 것을 계획하고 있다.
Log broker
Log broker는 이벤트에 대한 replay를 지원하는 pub-sub 시스템이다. Log broker는 streaming 데이터의 영속성과 event notification에 대해 책임을 갖는다. 또한, worker node에서 문제가 발생한 뒤 재기동할 때 incremental data의 무결성을 보장한다. Milvus 클러스터는 Pulsar를 Log broker로 사용하지만, Kafka 같은 시스템도 사용할 수 있다.
Milvus는 Log broker를 중심으로 설계되었으며 "log as data" 원칙을 따른다. Milvus는 물리적인 테이블을 유지하지 않고 logging persistence와 snapshot log를 통해 데이터 안정성을 보장한다.
Log broker는 Milvus의 백본이다. Log broker는 pub-sub 매커니즘을 기반으로 데이터 영속성과 read-write 분리를 담당한다. 위 그림은 log broker와 log subscriber로 나뉘어져 있는 로그 매커니즘을 간단하게 잘 표현하고 있다. 전자는 collection의 상태를 변경하는 모든 연산들을 기록하고, 후자는 log sequence를 구독하여 로그 데이터를 업데이트하고 read-only 복제본의 형테로 제공한다. pub-sub 매커니즘은 CDC(Change Data Capture)와 globally-distributed deployment의 관점에서 확장성을 위한 여유 공간을 제공한다.