클라우드 네이티브 벡터 데이터베이스 관리 시스템의 구조
우리의 최신 논문인 "Manu: A Cloud Native Vector Database Management System"이 데이터베이스 연구 분야의 최고 국제 학회인 VLDB'22에 채택되어 영광입니다. 이 글에서는 Manu (Milvus 2.0의 프로젝트명), 즉 벡터 데이터 관리를 위해 특별히 구축된 클라우드 네이티브 데이터베이스의 핵심 설계 철학과 원칙에 대해 논의하겠습니다. 더 자세한 정보는 우리의 이전 논문과 GitHub 저장소를 참고하실 수 있습니다.
배경
Milvus 1.0을 설계할 때 우리의 주요 목표는 단순히 벡터 관리를 지원하고 벡터 검색 성능을 최적화하는 것이었습니다. 하지만 수년에 걸쳐 더 많은 사용자와 교류하면서, 초기 프레임워크로는 해결하기 어려운 벡터 데이터베이스에 대한 몇 가지 공통적인 비즈니스 요구사항을 발견했습니다.
이러한 요구사항은 끊임없이 변화하는 요구사항, 더 유연한 일관성 정책, 컴포넌트 수준의 탄력성, 그리고 더 단순하고 효율적인 트랜잭션 처리 모델이라는 범주로 그룹화할 수 있습니다.
끊임없이 변화하는 요구사항
벡터 데이터 처리와 관련해서는 비즈니스 요구사항이 아직 완전히 정의되지 않았습니다.
초기에는 K-최근접 이웃 검색이 가장 많이 필요했습니다. 하지만 이후 범위 검색, 다양한 사용자 지정 거리 척도 지원, 하이브리드 검색, 멀티모달 쿼리, 그리고 점점 더 다양해지는 기타 쿼리 의미론을 포함해 점점 더 많은 요구사항이 등장했습니다.
이를 위해서는 벡터 데이터베이스의 아키텍처가 새로운 요구사항을 빠르고 민첩하게 지원할 수 있을 만큼 유연해야 합니다.
더 유연한 일관성 정책
콘텐츠 추천을 예로 들면, 이 시나리오는 적시성에 대한 요구가 높습니다. 새로운 콘텐츠는 몇 분, 심지어 몇 초 내에 사용자에게 추천되어야 하므로, 시스템이 추천을 업데이트하는 데 하루 이상 걸릴 수는 없습니다. 이러한 시나리오에서는 최종적 일관성만 제공해서는 비즈니스 결과를 보장하기 어렵지만, 강한 일관성을 고수하면 시스템 오버헤드가 커집니다.
이 문제를 해결하기 위해 우리는 다음과 같은 솔루션을 제안합니다. 비즈니스 요구사항에 따라 사용자는 삽입된 데이터를 쿼리할 수 있기 전까지 허용 가능한 최대 지연 시간을 지정할 수 있습니다. 그러면 시스템은 비즈니스의 최종 결과를 보장하기 위해 특정 데이터 처리 메커니즘을 조정합니다.
컴포넌트 수준의 탄력성
리소스 요구사항과 부하 강도는 서로 다른 애플리케이션에서 벡터 데이터베이스의 각 컴포넌트마다 크게 다릅니다. 예를 들어 벡터 검색 및 쿼리 컴포넌트는 성능을 보장하기 위해 대규모 연산 및 메모리 리소스가 필요하지만, 데이터 아카이빙과 메타데이터 관리는 작동하는 데 몇 가지 리소스만 필요합니다.
애플리케이션 측면에서 추천 시스템의 가장 중요한 요구사항은 대규모 동시 쿼리를 수행할 수 있는 능력이므로, 이러한 시스템에서는 쿼리 컴포넌트만 더 높은 부하를 받습니다. 반면 분석 애플리케이션은 대량의 오프라인 데이터를 가져와야 하는 경우가 많기 때문에, 부하 압력은 서로 관련된 두 컴포넌트인 데이터 삽입과 인덱스 구축에 가해집니다.
리소스 활용도를 높이기 위해서는 각 기능 모듈이 독립적이고 탄력적인 확장성을 가져야 하며, 이를 통해 시스템의 리소스 할당이 애플리케이션의 실제 요구에 더 긴밀하게 맞춰질 수 있어야 합니다.
더 단순하고 효율적인 트랜잭션 처리 모델
엄밀히 말하면, 트랜잭션 모델은 비즈니스 요구사항이라기보다 시스템 설계에서 활용할 수 있는 최적화의 여지입니다.
머신 러닝이 기술적 표현력 측면에서 발전함에 따라, 기업들은 단일 엔터티의 여러 차원에서 나온 데이터를 융합하여 이를 하나의 통합 벡터로 표현하는 경향이 있습니다. 예를 들어, 사용자 프로파일링에서는 개인 프로필, 선호도, 사회적 관계와 같은 정보가 함께 융합됩니다. 그 결과, 벡터 데이터베이스는 기존 데이터베이스에서 흔히 사용되는 JOIN과 유사한 연산을 구현할 필요 없이 단일 테이블만으로 유지될 수 있습니다. 이러한 방식으로, 시스템은 단일 테이블에서 행 수준 ACID만 지원하면 되며 여러 테이블을 포함하는 복잡한 트랜잭션 없이도 동작할 수 있어, 시스템에서 컴포넌트 분리와 성능 최적화를 위한 큰 여지를 남깁니다.
목표
Milvus의 두 번째 주요 릴리스로서, Manu는 클라우드 네이티브 분산 벡터 데이터베이스 시스템으로 자리매김합니다.
Manu를 설계하기 시작했을 때, 우리는 위에서 언급한 다양한 비즈니스 요구사항을 고려하고 이를 분산 시스템의 일반적인 요구사항과 결합했습니다. 그 결과 Manu의 다섯 가지 포괄적인 목표가 도출되었습니다: 장기적 진화 가능성, 조정 가능한 일관성, 우수한 탄력성, 고가용성, 그리고 고성능.
장기적 진화 가능성
기능이 발전하는 동안 시스템의 복잡성을 관리 가능한 수준으로 제어하기 위해서는, 개별 컴포넌트가 다른 컴포넌트에 대한 간섭을 최소화하면서 독립적으로 진화하거나 추가되거나 교체될 수 있도록 시스템을 잘 분리해야 합니다.
조정 가능한 일관성
시스템은 사용자가 새로 삽입된 데이터에 대한 쿼리 가시성 지연을 지정할 수 있도록 델타 일관성을 지원해야 합니다. 델타 일관성은 모든 쿼리가 최소한 델타 시간 단위까지의 모든 관련 데이터를 반환할 수 있어야 함을 요구하며, 이 값은 비즈니스 요구사항에 따라 사용자 애플리케이션에서 지정할 수 있습니다.
우수한 탄력성
리소스 활용 효율성을 향상시키기 위해, 시스템은 컴포넌트 수준에서 세분화된 탄력성을 달성해야 하며, 컴포넌트의 다양한 하드웨어 의존성을 고려하는 리소스 할당 정책도 필요합니다.
고가용성과 성능
고가용성은 모든 클라우드 데이터베이스의 기본 요구사항으로, 몇몇 서비스 노드나 컴포넌트에 장애가 발생하더라도 다른 서비스가 영향을 받지 않아야 하며, 시스템이 효과적인 장애 복구 능력을 갖추어야 함을 요구합니다.
고성능은 벡터 데이터베이스에서 진부할 정도로 자주 언급되는 요구사항입니다. 설계 과정에서, 우리는 우수한 성능을 보장하기 위해 시스템 프레임워크 수준에서 발생하는 오버헤드를 엄격하게 제어해야 합니다.
Manu 아키텍처
Manu는 읽기와 쓰기, 무상태와 상태 유지, 저장소와 컴퓨팅의 분리를 가능하게 하는 4계층 아키텍처를 채택합니다.
아래 그림에 표시된 것처럼, 위에서 아래로 Manu는 네 개의 계층, 즉 액세스 계층, 코디네이터 계층, 워커 계층, 저장소 계층을 갖습니다. 또한 Manu는 분리된 컴포넌트들을 연결하는 백본으로 로그 시스템을 사용합니다.
Manu 아키텍처.
액세스 계층
액세스 계층은 사용자 엔드포인트 역할을 하는 무상태 프록시들로 구성됩니다.
이러한 프록시들은 클라이언트로부터 요청을 수신하고, 해당 요청을 대응하는 컴포넌트로 분배하며, 결과를 수집한 뒤 클라이언트에 반환합니다. 또한 프록시들은 검색 요청의 적법성을 확인하기 위해 메타데이터의 사본을 캐시합니다(예: 검색할 컬렉션이 존재하는지 여부).
코디네이터 계층
코디네이터 계층은 시스템 상태를 관리하고, 메타데이터를 유지하며, 작업 처리를 위해 시스템 컴포넌트들을 조정합니다.
네 가지 유형의 코디네이터가 있으며, 각각은 서로 다른 기능을 위해 독립적으로 설계되었습니다. 이러한 방식으로 시스템 장애를 격리할 수 있고 컴포넌트들은 별도로 진화할 수 있습니다. 신뢰성 측면을 고려하여, 각 코디네이터는 여러 인스턴스를 가질 수 있습니다(예: 메인 하나와 백업 둘).
루트 코디네이터
루트 코디네이터는 컬렉션 생성/삭제와 같은 데이터 정의 요청을 처리하고, 컬렉션의 메타 정보(예: 컬렉션의 속성, 각 속성의 데이터 유형)를 유지합니다.
데이터 코디네이터
데이터 코디네이터는 데이터의 영속성을 다룹니다. 데이터 노드를 조정하여 데이터 업데이트 요청을 binlog로 변환하고, 컬렉션의 상세 정보(예: 각 컬렉션의 세그먼트 목록, 각 세그먼트의 스토리지 경로)를 기록합니다.
인덱스 코디네이터
인덱스 코디네이터는 데이터 인덱싱을 관리합니다. 인덱싱 작업을 위해 인덱스 노드를 조정하고 각 컬렉션의 인덱스 정보(예: 인덱스 유형, 관련 매개변수, 스토리지 경로 등)를 기록합니다.
쿼리 코디네이터
쿼리 코디네이터는 쿼리 노드의 상태를 모니터링하고, 로드 밸런싱을 위해 세그먼트(관련 인덱스와 함께)의 쿼리 노드 할당을 조정합니다.
워커 계층
워커 계층은 시스템 내의 여러 작업을 실행합니다.
모든 워커 노드는 상태 비저장입니다 - 작업을 수행하기 위해 데이터의 읽기 전용 복사본을 가져오며 서로 조정할 필요가 없습니다. 따라서 워커 노드의 수는 부하에 따라 유연하게 조정할 수 있습니다. 또한 Manu는 작업마다 서로 다른 워커 노드를 사용하므로, 각 노드 유형은 실제 부하와 QoS 요구 사항에 따라 독립적으로 확장될 수 있습니다.
스토리지 계층
스토리지 계층은 시스템 상태 정보, 메타데이터, 컬렉션 및 관련 인덱스를 영구적으로 저장합니다.
Manu는 etcd와 같은 고가용성 분산 KV(키-값) 저장소를 사용하여 시스템 상태 정보와 메타데이터를 저장합니다. 메타데이터가 업데이트되면 데이터는 먼저 KV 저장소에 기록된 다음 관련 코디네이터와 동기화됩니다. 컬렉션 및 인덱스와 같이 용량이 큰 데이터는 AWS S3와 같은 객체 스토리지 서비스로 관리됩니다. 객체 스토리지에 수반되는 높은 지연 시간은 성능 병목이 되지 않는데, 이는 워커 노드가 데이터를 처리하기 전에 객체 저장소에서 데이터의 읽기 전용 복사본을 가져와 로컬에 캐시하므로 대부분의 데이터 처리가 로컬에서 이루어지기 때문입니다.
로그 백본
로그 백본.
시스템 구성 요소(예: WAL, binlog, 데이터 노드, 인덱스 노드 및 쿼리 노드)를 더 잘 분리하여 각각 독립적으로 확장하고 발전시킬 수 있도록, Manu는 "log as data" 패러다임을 따르며 분리된 시스템 구성 요소를 연결하는 백본으로 로그 시스템을 사용합니다. Manu에서는 로그를 서로 다른 시스템 구성 요소가 지속적으로 구독할 수 있으므로, 이러한 구성 요소를 로그의 구독자라고 부릅니다.
Manu의 로그는 write-ahead log(WAL)와 binlog로 나눌 수 있습니다. WAL은 시스템 로그의 증분 부분이고 binlog는 기본 부분입니다. 이 둘은 지연, 용량 및 비용 측면에서 서로를 보완합니다.
위 그림에서 보듯이, 로거는 로그 시스템의 진입점이며 데이터를 WAL에 게시합니다. 데이터 노드는 WAL을 구독하고 행 기반 WAL을 열 기반 binlog로 변환합니다. 인덱스 노드와 쿼리 노드와 같은 모든 읽기 전용 구성 요소는 최신 상태를 유지하기 위해 로그 서비스의 독립적인 구독자입니다.
로그 시스템은 구성 요소 간 메시지를 전달하는 역할도 합니다. 다시 말해, 구성 요소는 로그를 통해 시스템 이벤트를 브로드캐스트할 수 있습니다. 예를 들어, 데이터 노드는 어떤 세그먼트가 객체 스토리지에 기록되었는지 다른 구성 요소에 알릴 수 있고, 인덱스 노드는 새 인덱스가 빌드되는 즉시 모든 쿼리 코디네이터에 알릴 수 있습니다. 또한 서로 다른 유형의 메시지는 서로 다른 채널에 구성됩니다. 각 구성 요소는 모든 브로드캐스트 로그를 수신하는 대신 해당 채널만 구독하면 됩니다.
데이터 처리 워크플로
이 섹션에서는 Manu 내부의 데이터 처리 워크플로를 자세히 설명하고 데이터 삽입, 인덱스 빌드 및 쿼리 실행 과정을 소개합니다.
데이터 삽입
데이터 삽입 워크플로.
위 그림은 Manu에서의 데이터 삽입 워크플로와 관련 구성 요소를 보여줍니다.
프록시에 의해 처리된 후, 데이터 삽입 요청은 해시 알고리즘을 기반으로 여러 버킷에 분산됩니다. 일반적으로 Manu 시스템에는 일관 해싱을 기반으로 각 해시 버킷의 엔티티를 처리하는 여러 로거가 있습니다. 각 해시 버킷의 엔티티는 이 버킷에만 매핑되는 write-ahead log(WAL) 채널에 기록됩니다. 로거가 데이터 삽입 요청을 받으면, 이 요청에 전역적으로 고유한 로그 시퀀스 번호(LSN)를 할당하고 해당 WAL 채널에 기록합니다. LSN은 중앙 시간 서비스 오라클(TSO)에 의해 생성됩니다. 각 로거는 정기적인 간격으로 TSO로부터 LSN을 받아 로컬에 저장해야 합니다.
로그 pub/sub가 낮은 지연 시간을 갖고 세분화되도록 하기 위해, Manu에서는 엔티티가 WAL 에 행 기반 방식으로 저장되며, WAL을 구독하는 각 구성 요소는 스트리밍 방식으로 데이터를 읽습니다. 대부분의 경우 WAL은 Kafka 또는 Pulsar와 같은 클라우드 기반 메시지 큐를 통해 구현될 수 있습니다. 데이터 노드는 WAL을 구독하고 행 기반 WAL을 열 기반 binlog로 변환합니다. binlog의 열 기반 특성은 데이터를 쉽게 압축하고 접근할 수 있게 해줍니다. 이러한 효율성의 예는 인덱스 노드에서 볼 수 있습니다. 인덱스 노드는 인덱스 구축을 위해 binlog에서 필요한 벡터 열만 읽으므로 읽기 증폭에서 자유롭습니다.
인덱스 구축
Manu에는 배치 인덱싱과 스트림 인덱싱이라는 두 가지 인덱스 구축 시나리오가 있습니다. 배치 인덱싱은 사용자가 전체 컬렉션에 대한 인덱스를 구축할 때 발생합니다(예: 모든 벡터가 새 임베딩 모델로 업데이트되는 경우). 이 경우 인덱스 코디네이터는 데이터 코디네이터로부터 컬렉션의 모든 세그먼트 경로를 얻고, 인덱스 노드에 각 세그먼트에 대한 인덱스를 구축하도록 지시합니다. 스트림 인덱싱은 사용자가 새 엔티티를 지속적으로 삽입할 때 발생하며, 검색 서비스를 중단하지 않고 인덱스가 비동기적으로 즉석에서 구축됩니다.
데이터 노드가 새 세그먼트를 binlog에 기록하면, 데이터 코디네이터는 인덱스 코디네이터에 알림을 보내 인덱스 노드가 새 세그먼트에 대한 인덱스를 구축하는 작업을 생성하도록 합니다. 배치 및 스트림 인덱싱 시나리오 모두에서, 세그먼트에 필요한 인덱스가 구축된 후 인덱스 노드는 이를 객체 스토리지에 영구 저장하고 저장 경로를 인덱스 코디네이터에 보내며, 쿼리 코디네이터에 알림을 보내 쿼리 노드가 쿼리 처리를 위해 인덱스를 로드할 수 있도록 합니다.
쿼리 실행
Manu는 컬렉션을 세그먼트로 분할하고 세그먼트를 쿼리 노드에 분산하여 쿼리 요청을 병렬로 실행합니다. 프록시는 쿼리 코디네이터에 조회하여 쿼리 노드의 세그먼트 분포 사본을 캐시하고, 검색 요청을 검색 대상 컬렉션의 세그먼트를 보유한 쿼리 노드로 전달합니다. 쿼리 노드는 로컬 세그먼트에서 벡터 쿼리를 수행하고 결과를 병합한 뒤 프록시에 반환합니다. 프록시는 각 쿼리 노드의 결과를 추가로 집계하고 최종 결과를 클라이언트에 반환합니다.
쿼리 노드는 WAL, 인덱스 파일, binlog라는 세 가지 소스에서 데이터를 얻습니다. 과거 데이터의 경우, 쿼리 노드는 객체 스토리지에서 해당 binlog 또는 인덱스 파일을 읽습니다. 반면 증분 데이터의 경우, 쿼리 노드는 스트리밍 방식으로 WAL에서 직접 읽습니다. binlog에서 증분 데이터를 가져오면 데이터 가시성에 지연이 발생하며, 이는 특히 대규모 검색 요청에서 더욱 그렇습니다. 즉, 새로 삽입된 데이터는 오랜 시간이 지난 후에야 쿼리에 사용할 수 있게 되어, 일부 시나리오에서 높은 일관성에 대한 요구를 충족하지 못합니다.
앞서 언급했듯이, Manu는 사용자가 일관성 수준을 더 유연하게 조정할 수 있도록 델타 일관성 모델을 채택합니다. 델타 일관성은 데이터 업데이트 요청이 Manu에 수신된 후 최대 델타 시간 단위 이내에 업데이트된 데이터(삽입 및 삭제된 데이터 포함)를 쿼리하고 검색할 수 있도록 보장합니다.
Manu는 모든 데이터 삽입 및 쿼리 요청에 타임스탬프를 담은 LSN을 추가함으로써 델타 일관성을 달성합니다. 쿼리 요청을 실행할 때 쿼리 노드는 요청의 타임스탬프(Lr)와 쿼리 노드가 처리한 최신 데이터 업데이트 요청의 타임스탬프(Ls)를 확인합니다. 쿼리 요청은 Lr과 Ls 사이의 간격이 델타보다 작은 경우에만 실행됩니다. 그렇지 않으면 쿼리 요청은 WAL에 기록된 데이터 업데이트가 처리될 때까지 실행을 기다립니다. 그러나 장기간 데이터 업데이트가 없으면 Ls와 현재 시스템 시간 사이의 시간 간격이 매우 작아져 쿼리가 차단됩니다. 이러한 문제를 방지하기 위해 Manu는 정기적으로 제어 정보를 WAL에 삽입하여 쿼리 노드가 타임스탬프를 업데이트하도록 강제합니다.
성능 평가
논문에서는 Manu를 실제 애플리케이션에 통합하고 전체 시스템 성능 평가도 수행했습니다. 다음은 평가 결과의 일부입니다.
Manu 및 기타 벡터 검색 시스템의 쿼리 성능.
위 그림은 쿼리 성능 측면에서 Manu를 다른 네 가지 익명 오픈 소스 벡터 검색 시스템과 비교합니다. SIFT 및 DEEP 데이터셋에서 쿼리를 수행할 때 Manu가 다른 벡터 검색 시스템보다 명백히 뛰어난 성능을 보인다는 것을 알 수 있습니다.
서로 다른 노드 수에서의 Manu 쿼리 성능.
위 그림은 쿼리 노드 수가 달라질 때 Manu의 쿼리 성능을 보여줍니다. 서로 다른 유사도 메트릭으로 서로 다른 데이터셋을 쿼리할 때, Manu의 쿼리 성능은 쿼리 노드 수와 대략 선형 관계를 보인다는 것을 알 수 있습니다.
서로 다른 일관성 수준에서의 Manu 쿼리 성능.
위 그림들은 서로 다른 일관성 수준에서 Manu의 쿼리 성능을 보여줍니다. 가로 좌표는 델타 일관성에서의 델타 값을 나타냅니다. 각 그림은 쿼리 노드가 시간을 동기화하도록 강제하는 제어 정보가 WAL에 전송되는 빈도를 반영합니다. 그림에서 델타 값이 증가함에 따라 Manu의 쿼리 지연 시간이 급격히 감소한다는 것을 알 수 있습니다. 따라서 Manu 사용자는 성능과 일관성에 대한 필요에 따라 적절한 델타 값을 선택해야 합니다.
결론
이 논문에서는 벡터 데이터베이스에 대한 실제 요구사항을 기반으로 Manu의 설계와 주요 기능의 워크플로를 소개했습니다. 간단히 말해, Manu의 두 가지 주요 특징은 다음과 같습니다:
Manu는 로그 백본을 사용하여 시스템 구성 요소를 연결하며, 이를 통해 각 구성 요소의 독립적인 확장과 발전을 가능하게 하고 리소스 할당 및 장애 격리를 용이하게 합니다.
로그 시스템과 LSN을 통해 Manu는 일관성, 비용 및 성능 간의 유연한 절충을 가능하게 하는 델타 일관성 모델을 채택합니다.
요약하면, 우리 VLDB 논문의 주요 기여는 벡터 database 에 대한 실제 수요의 소개와 클라우드 네이티브 벡터 데이터베이스의 기본 아키텍처 설계에 있습니다. 현재 이 아키텍처는 아직 완벽과는 거리가 멀며, 향후 방향 중 일부는 다음과 같습니다:
멀티모달 콘텐츠에서 추출된 벡터를 검색하는 방법;
로컬 디스크, 클라우드 드라이브 및 기타 스토리지 서비스를 포함한 클라우드 스토리지 서비스를 더 잘 활용하여 데이터 검색을 더 효율적으로 만드는 방법;
FPGA、GPU、RDMA、NVM 、RDMA와 같은 새로운 컴퓨팅, 스토리지 또는 통신 하드웨어의 도움으로 인덱싱 및 검색 성능을 극대화하는 방법.
미주
1년 전, 저는 Zilliz의 CEO인 Charles Xie와 함께 시안에서 열린 ACM SIGMOD 2021에 참석했습니다. 이 논문을 쓰자는 아이디어는 Milvus 2.0의 GA 릴리스(Manu)를 위해 상하이로 돌아오는 길에 떠올랐습니다. Charles와 저는 모두 클라우드 네이티브 데이터베이스가 학계의 새로운 화두가 되고 있다고 느꼈습니다. Manu가 정확히 대규모 벡터를 위한 클라우드 네이티브이자 목적 특화형 데이터베이스 시스템이라는 점은 정말 우연이었습니다. 그 결과, 우리는 Manu와 클라우드 네이티브 데이터베이스 관리 시스템에 관한 이 논문을 쓰게 되었습니다.
우리의 논문이 클라우드 네이티브 벡터 데이터베이스 관리 시스템을 탐구하고 연구하는 데 더 많은 학자와 업계 동료들이 함께하도록 약간의 통찰을 제공하고 관심을 끌 수 있기를 바랍니다.
또한 Bo Tang 조교수, Xiao Yan 연구조교수, Long Xiang의 기여에 감사를 표하고 싶습니다. 이 논문은 Zilliz 팀과 Southern University of Science and Technology의 Database Group이 공동으로 작성했습니다.
계속 읽기
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Zilliz Cloud Launches in AWS Australia, Expanding Global Reach to Australia and Neighboring Markets
We're thrilled to announce that Zilliz Cloud is now available in the AWS Sydney, Australia region (ap-southeast-2).