18개월 만에 Zilliz Cloud 구축하기: 퍼블릭 클라우드에서 확장 가능한 벡터 검색 서비스를 만들며 배운 교훈
서문
벡터 데이터베이스는 2023년 데이터베이스 업계의 주요 트렌드로 부상했습니다. 이 글에서는 가장 널리 채택된 오픈 소스 벡터 데이터베이스인 Milvus를 기반으로 하는 완전 관리형 서비스 Zilliz Cloud를 18개월에 걸쳐 처음부터 개발한 과정을 자세히 설명합니다. 이 기간 동안 우리는 처음부터 포괄적인 클라우드 서비스를 개발했으며, Large Language Models (LLM)의 급속한 확장에 힘입어 트래픽이 10배 급증하는 상황을 헤쳐 나갔습니다. 이 회고는 그 여정에서 얻은 중요한 설계 선택과 귀중한 통찰을 공유하는 데 중점을 둡니다.
Zilliz Cloud Dedicated Cluster - 여정의 시작
시계를 2022년 5월로 되돌려 보면, 오픈 소스 벡터 데이터베이스 Milvus 2.0은 여러 차례의 주요 반복을 거친 끝에 마침내 안정화되기 시작했습니다. 사용자들과의 대화를 통해 안정적이고 상업적으로 호스팅되는 버전에 대한 필요성이 반복적인 요청으로 드러났습니다. Milvus를 배후에서 지원하는 상업 기업인 Zilliz에게는 상용화에 착수하기에 완벽한 시점처럼 보였습니다. 경험 많은 엔지니어 팀, 성숙해져 가는 제품, 그리고 긴급한 요구를 가진 헌신적인 사용자 기반을 갖추고 있었기 때문입니다. 이를 염두에 두고 우리는 야심 찬 목표를 세웠습니다. 6개월 안에 제품을 출시하는 것이었습니다.
프로젝트를 시작하면서 우리는 현재의 역량과 목표를 평가했습니다:
- 우리의 핵심 기술은 스토리지-컴퓨팅 분리와 마이크로서비스 프레임워크로 설계된 클라우드 네이티브 오픈 소스 벡터 데이터베이스로, Kubernetes (K8s) 클러스터에 원활하게 통합되도록 설계되었습니다. 이 클라우드 네이티브 프레임워크는 우리가 클라우드 프로덕션 환경에 빠르게 적응할 수 있게 해줍니다.
Figure 1: Milvus 아키텍처
Kubernetes Operator를 활용했기 때문에 AWS 및 GCP와 같은 주요 퍼블릭 클라우드 플랫폼 전반에 서비스를 빠르게 배포할 수 있는 역량을 갖추고 있었으며, 이는 퍼블릭 클라우드에서 프로덕션 서비스를 성공적으로 구현한 여러 사용자들에 의해 확인되었습니다.
우리 플랫폼에는 모니터링 및 로깅과 같은 기본적인 관측 가능성 기능이 포함되어 있었지만, 프로덕션을 위한 중요한 알림 기능이 필요했습니다.
앞서 언급한 요소들 외에도, 서비스로서 우리는 사용자 로그인 인증, 계량 및 과금, 결제 메커니즘, 네트워킹, 보안, Web 콘솔, OpenAPI 지원, 리소스 스케줄링, 워크플로 관리 등을 포함하되 이에 국한되지 않는 여러 핵심 구성 요소가 부족했습니다.
6개월 안에 어떤 필수 모듈을 구축할지 범위를 좁히는 것은 만만치 않은 과제였습니다. 이에 대응하여 우리는 중요한 자기 평가에 착수했습니다. 사용 가능한 리소스를 어떻게 가장 효율적으로 활용할 수 있을까? 린하면서도 완전한 기능을 갖춘 버전을 만들기 위해 우리의 접근 방식을 정제할 수 있을까? 이러한 핵심 질문들은 우리의 고민을 이끌었고, 궁극적으로 일련의 기본 설계 원칙을 형성했습니다:
바퀴를 다시 발명하지 않기 위해 성숙한 타사 제품의 사용을 극대화:
신속한 시장 준비를 강조하며, 우리는 검증된 클라우드 및 타사 서비스에 전략적으로 의존했습니다. 우리는 AWS 관리형 Kafka 및 RDS와 함께 EKS, EC2, S3, EBS, ALB와 같은 AWS의 핵심 서비스를 인프라 백본으로 활용했습니다. 이 접근 방식은 우리의 즉각적인 요구를 충족시켰을 뿐만 아니라, 이러한 구성 요소들이 향후 멀티 클라우드 환경에 적응하기 위한 비용 효율적인 경로를 제공함으로써 우리의 혁신 속도를 높일 수 있음을 보여주었습니다. GCP/Azure 메시징 큐와 관리형 Kafka 서비스 간의 호환성 문제에 직면하여, 우리는 Apache Bookkeeper를 기반으로 하는 자체 분산 로그 시스템을 개발했습니다. 신뢰할 수 있고 오픈 소스이거나 클라우드 네이티브인 분산 로깅 솔루션의 부재가 이 시도를 이끌었습니다. 이러한 공백에 동기를 얻어, 우리는 우리의 솔루션을 오픈 소스화하는 것을 고려하고 있으며, 이것이 다른 이들이 클라우드 서비스를 구축하는 데 도움이 되기를 바랍니다.
타사 SaaS 제공업체들은 우리 플랫폼 개발을 가속화하는 데 중요한 역할을 했습니다. 예를 들어, 복잡한 계량 및 과세 요구사항을 해결하기 위해 결제 처리를 관리하는 데 Stripe를 도입했습니다. 멀티 클라우드 마켓플레이스와의 연결을 용이하게 하기 위해 Sugar.io를 통합했습니다. 또한 청구 운영을 개선하기 위해 Orb 및 Metronome과 같은 청구 서비스 플랫폼을 평가했습니다. Auth0는 계정 관리 및 로그인 기능을 위한 우리의 선택 제품이었으며, 우리는 인증 및 로그인 기능을 더욱 확장하여 Google 로그인 지원을 포함했습니다. 운영 알림 시스템은 PagerDuty 기반으로 구축했으며, 기존 모니터링 도구와의 빠른 통합성과 알림 규칙을 사용자 지정할 수 있는 다재다능함 때문에 이를 선택했습니다.
개체는 불필요하게 증가되어서는 안 된다
오컴의 면도날 철학에 따라, 우리는 제품의 다양한 측면에서 드러나는 미니멀리스트 설계 접근 방식을 채택했습니다:
아키텍처 단순성: 초기 설계에는 60개가 넘는 마이크로서비스가 포함되어 있었고, 이는 개발 및 테스트 조율에 상당한 어려움을 초래했습니다. 아키텍처를 단순화하기 위해 사용자, 청구, CloudService, 리소스, 메타데이터, 스케줄링을 포함한 핵심 마이크로서비스 수를 10개 미만으로 간소화했습니다. 이러한 축소는 의존성을 명확히 하고 테스트 부담을 줄였습니다.
기능적 단순성: 초기 반복 단계에서 Zilliz Cloud의 중점은 등록, 클러스터 배포, 청구와 같은 핵심 사용자 기능에 두었으며, 워크로드를 완화하기 위해 스케일링 및 백업과 같이 덜 긴급한 기능은 의도적으로 연기했습니다. 주목할 만한 점은 강력한 피드백 루프를 구축하려는 우리의 노력으로, 처음에는 이메일 기반 피드백을 지원하고 이후 Zendesk 통합으로 이를 보강하여 신속하고 고품질의 피드백이 추가 개선을 이끌 수 있도록 했다는 것입니다.
설계 단순성: 우리의 클라우드 서비스 설계는 효율적인 커뮤니케이션과 사용자 참여 잠재력을 우선시했으며, 이를 위해 절제되고 집중된 접근 방식이 필요했습니다. 빠른 A/B 테스트를 활용함으로써 기능을 신속하게 검증하고 사용자 참여 지표를 기반으로 조정할 수 있었습니다.
1일 차부터 2일 차 과제를 예상하라:
클라우드 서비스의 역동적인 환경에서 사용자 인터페이스와 서비스의 신뢰성을 희생하지 않으면서 빠르게 진화할 수 있는 능력은 무엇보다 중요합니다. 이러한 정교한 조작은 "공중에서 제트 엔진을 교체하는 것"과 유사합니다. 외부 관찰자에게 서비스는 완벽하게 작동하는 것처럼 보이지만, 내부에서는 혁신과 개선의 활발한 주기가 진행 중입니다. 최종 상태를 염두에 둔 개발 접근 방식을 수용하는 것이 중요합니다.
멀티 클라우드 지원: 처음에는 AWS에 집중했지만, 우리의 접근 방식은 항상 클라우드 중립성을 우선시해 왔습니다. 우리는 퍼블릭 클라우드 전반의 호환성을 보장하기 위해 GCP 및 Alibaba Cloud와 같은 제공업체를 광범위하게 평가했습니다. 오픈 소스 프로젝트 Crossplane에 대한 맞춤화를 통해 '클라우드 어댑터' 계층을 개발하여 멀티 클라우드 지원과 관련된 비용을 줄였습니다. 이 설계는 단 한 달 만에 GCP와의 신속한 통합을 가능하게 했고, 다른 퍼블릭 클라우드 제공업체와의 통합을 간소화했습니다.
보안: AIGC 애플리케이션 개발자들은 보안 이외의 것을 우선시할 수도 있지만, Zilliz Cloud Services는 데이터 보안을 최우선으로 둡니다. 클라우드 IAM 표준을 엄격히 준수하며, 데이터 접근 권한을 세심하게 제어하고 전송 중 및 저장 중인 모든 데이터에 암호화를 적용합니다. 최적의 성능을 위한 네트워크 격리를 강조하면서, 우리는 효율성과 사용자 친화성 때문에 AWS의 EKS 네트워크 애드온을 선택했습니다. 데이터 계층과 제어 계층 간의 상호작용 경계를 명확히 한 결과, BYOC 제품 출시 과정에서 상당한 비용 절감이 이루어졌습니다.
리소스 풀링: Zilliz Cloud Services는 "클라우드 교환 법칙"을 채택하여 리소스 풀링을 통한 탄력적 확장성을 우선시합니다. 스토리지와 컴퓨팅을 분리하고 동적 로드 밸런싱을 적용함으로써 클라우드 리소스를 효율적으로 활용하도록 보장합니다. 이 접근 방식은 필요한 경우에만 리소스를 예약할 수 있게 해주어, Spot Instances와 Lambda 함수의 활용률을 크게 개선하는 동시에 비용을 절감합니다.
운영 친화적: Zilliz Cloud는 다른 벡터 데이터베이스와 달리 개발자와 운영 인력을 염두에 두고 설계되었습니다. 포괄적인 GUI와 정교한 모니터링 기능을 갖춘 이 플랫폼은 트리플 AZ 재해 복구를 제공하고 엄격한 SLA를 준수하여, 프로덕션 환경의 안정성과 신뢰성을 보장합니다.
핵심 설계 철학에 따라, 우리는 단 6개월 만에 상용 벡터 검색 제품을 출시하는 이정표를 달성했으며, 그 과정에서 초기 시드 고객 그룹을 확보했습니다. 아래에서 첫 번째 릴리스의 아키텍처 다이어그램을 확인할 수 있습니다.
그림 2- Zilliz Cloud 아키텍처
Serverless: 신규 사용자 획득 비용 $300에서 $5로
성장은 종종 예상치 못한 순간에 발생합니다. SaaS 서비스에서 3개월 동안 꾸준한 성장을 경험한 후, AutoGPT의 폭발적인 인기에 힘입어 Zilliz Cloud의 성장은 정점에 도달했습니다. 벡터 데이터베이스를 Large Language models의 장기 메모리로 보는 관점이 점차 받아들여지면서 Zilliz의 사용자 기반이 빠르게 증가했고, 매일 새로 추가되는 클러스터 수가 빠르게 수백 개에 이르렀습니다.
그러나 이러한 성장은 Zilliz에 안정성과 비용이라는 두 가지 주요 과제를 가져왔습니다. 우리는 항상 확장성에 집중해 왔지만, 갑작스러운 높은 트래픽 급증은 핵심 데이터베이스만 무사히 남긴 채 거의 모든 서비스를 마비시켰습니다. 클라우드 서비스 제공업체가 제공하는 API는 스로틀링되었고, 우리의 로그 스토리지 시스템인 Loki는 단 며칠 만에 두 번이나 가득 차, 리소스 부족으로 인해 많은 서비스가 중단될 수밖에 없었습니다.
또한 Zilliz Cloud가 채택한 초기 무료 체험 전략은 신규 사용자에게 모든 기능을 경험할 수 있도록 $300 Credits를 제공했는데, 사용자 수가 급증하면서(대부분 서비스를 시험해 보는 사용자였습니다) 비용이 급격히 증가했고, 우리는 비즈니스 모델을 재고할 수밖에 없었습니다. 이러한 문제점들은 우리가 더 유연하고, 진입 장벽이 낮으며, 벡터 데이터베이스 여정을 막 시작하는 AIGC 사용자에게 더 적합한 제품인 Zilliz Cloud Serverless를 출시하도록 이끌었습니다.
성배는 아직 저 너머에 있습니다: RAG 애플리케이션 개발을 위한 확장성, 비용, 지연 시간 다루기
Retrieval-Augmented Generation (RAG) 사용 사례의 경우, 이상적인 무료 티어 솔루션은 다음을 고려해야 합니다:
그림 3: RAG 애플리케이션에서 확장성, 비용, 지연 시간 다루기
확장성 — 이는 두 가지 핵심 측면을 포함합니다:
개별 테넌트 수준에서, 시스템은 데이터를 효과적으로 처리하기 위해 동적으로 확장되어야 합니다. 이러한 동적 확장은 벡터 데이터베이스가 다양한 테넌트의 변동하는 데이터 볼륨에 맞게 조정할 수 있을 만큼 다재다능해야 함을 요구합니다. 테넌트가 소규모 데이터셋을 처리하든 대규모 데이터셋을 처리하든 관계없이, 처리 중인 데이터의 크기와 무관하게 일관되고 안정적인 쿼리 응답 시간이 유지되어야 합니다.
많은 테넌트를 관리할 때, 시스템은 최대 수백만 테넌트까지의 확장성을 효율적으로 지원해야 합니다. 구체적으로, '핫'(매우 활발한) 및 '콜드'(덜 활발한) 사용 패턴을 지능적으로 구분하고 수용하여, 전반적으로 최적의 리소스 할당과 성능 일관성을 보장해야 합니다.
비용 — 무료 티어의 비용 관리는 매우 중요합니다. 이상적으로는 100만 개의 768차원 벡터를 지원할 수 있는 충분한 리소스를 제공하면서 비용을 $1 미만으로 유지해야 합니다. 그러나 인메모리 벡터 인덱싱에 의존할 경우, 100만 개의 768차원 벡터를 처리하는 비용은 쉽게 $10를 초과할 수 있습니다. 이 비용은 엔터프라이즈 서비스를 대상으로 하는 SaaS 기업에는 허용 가능할 수 있지만, 소비자 대상 ToC 애플리케이션에는 과도합니다.
낮은 지연 시간 — RAG 사용 사례는 검색 및 추천 도메인만큼 지연 시간에 민감하지 않을 수 있지만, 벡터 검색의 성능은 "Time-to-first-token"에 상당한 영향을 미칩니다. 따라서 낮은 지연 시간을 유지하는 것은 사용자 경험과 시스템 응답성을 향상시키는 데 매우 중요합니다.
Zilliz Cloud의 초기 제품은 대량의 데이터를 처리하고 낮은 지연 시간을 달성하는 데 뛰어난 확장성을 보여주며 사용자 기대를 뛰어넘었습니다. 그러나 수많은 테넌트 관리와 비용 통제를 고려하더라도, 전용 클러스터 솔루션은 사용자 요구를 완전히 충족하기에는 부족했습니다. 이를 해결하기 위해, 우리는 개별 AIGC 사용자의 진입 장벽을 낮추도록 특별히 설계된 서비스 모델인 'Zilliz Serverless Tier'를 개발했습니다. 이 티어는 위에서 언급한 과제를 효과적으로 해결하기 위해 가장 비용 효율적인 스토리지 솔루션과 확장성을 제공합니다.
Zilliz Cloud Serverless 아키텍처
그림 4- Zilliz Cloud Serverless 아키텍처
Zilliz Cloud Serverless는 논리적 클러스터 개념을 도입하며, 각 논리적 클러스터는 물리적 클러스터의 데이터베이스에 해당합니다. 우리는 데이터베이스 및 API 키 기반 인증 메커니즘을 통해 단일 물리적 클러스터 내 모든 테넌트에 대한 논리적 격리를 달성합니다. 쿼리 중에는 시스템이 API 키를 기반으로 요청을 라우팅하여 사용자가 접근해야 하는 데이터를 결정하며, 라우팅에는 프록시 노드를 사용합니다.
데이터 쓰기 작업은 처음에 로그 노드 풀로 전송되며, 로그 노드는 데이터를 Write-Ahead Logging (WAL) 서비스에 기록하고, 주기적으로 데이터를 재구성하여 객체 스토리지로 플러시합니다. CompactionService는 더 작은 데이터 세그먼트를 더 큰 세그먼트로 통합하고 삭제된 항목을 제거하여 스토리지 공간과 접근 속도를 최적화하는 풀링 서비스입니다. Index Service는 원시 데이터에 대한 인덱스를 구축하는 역할을 하며, 이 인덱스는 쿼리 효율성을 보장하기 위해 쿼리 노드에 의해 로드됩니다.
쿼리 작업 중 우리의 전략은 모든 데이터를 Query Nodes의 로컬 디스크에 캐싱하고 메모리-디스크 스와핑을 로컬에서 실행하는 것입니다. 이 방법론은 메모리 기반 인덱싱과 비교해 Serverless 사용자의 스토리지 비용을 10배 이상 크게 줄입니다. 그러나 주요 과제는 테넌트 핫스팟 문제와 노이지 네이버로 인해 발생하는 쿼리 노드 과부하를 방지하기 위해 리소스를 효과적으로 관리하는 데 있습니다. 이는 각 Query Node가 여러 테넌트의 데이터 로딩을 처리해야 하므로 특히 중요합니다.
시스템 안정성을 향상시키기 위해, 우리는 다음 세 가지 중요한 메커니즘을 도입했습니다:
분산 Quota: 중앙 집중식 quota 서비스를 기반으로 하는 이 메커니즘은 리소스 quota를 동적으로 할당하고 쿼리 노드의 부하에 따라 조정합니다. 이러한 동적 할당은 각 테넌트의 공정한 리소스 소비를 보장하는 데 도움이 됩니다.
분산 Quota: 중앙 집중식 quota 서비스를 기반으로 하는 이 메커니즘은 리소스 quota를 동적으로 할당하고 쿼리 노드의 부하에 따라 조정합니다. 이는 각 테넌트의 공정한 리소스 소비를 보장하는 데 도움이 됩니다.
Metrics 기반 동적 리소스 확장: 우리는 메모리, 디스크, CPU 부하 및 요청 큐잉을 종합적으로 관리하는 Cloud Resource Scheduler 모듈을 통합했습니다. 이를 통해 다양한 시나리오에서 변화하는 리소스 수요를 충족하기 위해 물리적 리소스를 동적으로 확장할 수 있습니다.
다계층 스케줄링: 우리는 다양한 수준에서 작동하는 리소스 스케줄링 프레임워크를 구축했으며, 여기에는 리소스 그룹화를 통한 물리적 격리, 이러한 리소스 그룹 내의 로드 밸런싱, 노드 수준에서의 쿼리 큐 및 캐시 스케줄링 관리가 포함됩니다. 이 접근 방식은 여러 테넌트 간의 공정한 리소스 할당을 보장하는 동시에 단일 테넌트가 리소스를 독점할 위험을 완화합니다.
Serverless 서비스를 통해 개인 사용자의 체험 비용을 $5로 성공적으로 낮추어 수만 명의 AIGC 개발자를 지원했습니다. 곧 출시될 Zilliz Cloud 릴리스에서는 Serverless 솔루션을 더욱 비용 효율적이고 탄력적으로 개선하고 있습니다. 이 새 버전에서는 각 Serverless 사용자가 단일 컬렉션에서 수백만 테넌트의 데이터를 처리할 수 있으며, 데이터 격리를 달성하는 동시에 현재 솔루션에 비해 스토리지 비용을 10분의 1로 크게 절감할 수 있습니다. 향후 글에서 Zilliz Cloud Serverless의 기술적 세부 사항을 계속 깊이 다루겠습니다.
오픈 소스 VectorDB로 클라우드 서비스를 구축하며 배운 여섯 가지 교훈
클라우드 한계 인식: Milvus와 같은 클라우드 네이티브 시스템이라도 클라우드 SaaS로 전환하는 데에는 상당한 어려움이 따릅니다. 이는 EC2와 EBS에 단순히 배포하는 것 이상입니다. 오픈 소스 데이터베이스 영역에서는 사용자가 세심한 knob 튜닝을 통해 수평 확장, 장애 복구, 성능 최적화를 달성하기 위해 제품의 복잡한 내부 구조를 깊이 이해해야 합니다. 클라우드 서비스의 진정한 과제는 높은 안정성과 탄력성을 유지하면서 운영을 간소화하는 데 있습니다. S3 속도 제한 및 OpenAPI 호출 빈도 제한과 같은 클라우드 환경의 특정 제약을 해결하는 것은 클라우드 컴퓨팅의 탄력성과 확장성 잠재력을 충분히 활용하는 데 매우 중요합니다.
신중한 기능 출시: 제품 초기 단계에서 고객을 유치하기 위해 새로운 기능을 지속적으로 추가하는 것이 매력적으로 보일 수 있지만, 사용자의 실제 pain point를 해결하는 것이 우선되어야 합니다. 오픈 소스 제품 기능이 SaaS 버전보다 약 6개월 정도 앞서도록 리드 타임을 유지하는 것은 좋은 절충안입니다. 이 리드 타임은 이러한 기능이 서비스 제공을 위해 출시되기 전에 충분한 테스트와 개선을 거치도록 보장합니다.
적절한 제한 설정: 완벽한 제품은 없습니다. S3를 예로 들어 보겠습니다. 세련된 인터페이스와 광범위한 개선에도 불구하고, 개발자는 특정 상황에서만 그 가치를 극대화할 수 있습니다. 오픈 소스 제품이 누릴 수 있는 자유와 달리, SaaS 제품은 스스로를 보호하기 위해 더 엄격한 제약이 필요합니다. 이러한 제약은 제품의 필수적인 부분을 이루며 사용자에게 안내와 교육 역할을 합니다. 합리적인 제한은 사용자가 제품을 더 현명하게 사용하도록 유도하여 전반적인 가치와 사용자 경험을 향상시킬 수 있습니다.
클라우드 애그노스틱 종속 서비스 선택: 주요 클라우드 플랫폼 전반에서 널리 제공되는 S3, EC2, K8s 관리형 서비스와 같은 클라우드 애그노스틱 종속 서비스의 채택을 고려하면 비용 절감과 멀티클라우드 도입 복잡성 단순화 측면에서 상당한 이점을 얻을 수 있습니다. 또는 멀티클라우드 사용을 본질적으로 지원하는 SaaS 서비스를 선택하면 프로세스를 간소화할 수 있습니다. 서로 다른 클라우드 서비스 제공업체 간 구현에 잠재적인 차이가 있을 수 있지만, 멀티클라우드 적응 계층을 조기에 구축하면 중복 개발 노력을 효과적으로 최소화하고 전반적인 효율성을 향상시킬 수 있습니다.
Cloud FinOps에 집중: 퍼블릭 클라우드에서는 겉보기에는 저렴해 보이는 리소스가 예상치 못하게 높은 비용으로 이어질 수 있습니다. 예를 들어, 청구서 분석을 수행하기 전에는 ALB 네트워크 대역폭 비용이 전체 비용의 상당 부분을 차지할 수 있다는 점을 예상하지 못했습니다. 비용을 최적화하고 성능 최적화를 극대화하려면 다양한 인스턴스 유형과 서비스의 성능을 철저히 이해하는 것이 필수적입니다. 예를 들어, 각 GP3 클라우드 디스크는 3000 IOPS를 제공합니다. 단일 머신에 여러 디스크를 묶고 RAID를 구성하면 디스크 처리량을 크게 늘릴 수 있으며, 이를 통해 추가 IOPS에 대한 막대한 청구를 피할 수 있습니다.
Open API의 중요성 인식: Agent의 도입이 증가함에 따라 Open API와 관련 문서의 역할은 점점 더 중요해지고 있습니다. 기존 클라우드 서비스는 기능을 제공하기 위해 웹 콘솔과 그래프 인터페이스에 의존하지만, 클라우드 서비스의 향후 상호작용과 통합은 점점 더 OpenAPI에 의존하게 될 것입니다. 서비스 자동화 수준, Agent 친화성, 관측 가능성은 미래 클라우드 서비스를 평가하는 핵심 기준이 되었습니다.
에필로그
지난 18개월을 돌아보면, 우리는 시간이 세 배 빠르게 흐르는 것처럼 느껴질 만큼 매우 짜릿하고 도전적인 여정을 시작했습니다. 이러한 빠른 진전은 몇 가지 핵심 요인에 기인합니다. 첫째, LLM의 등장은 우리의 코딩 효율성을 극적으로 향상시켰습니다. 둘째, RAG 사용 사례의 가치에 대한 사용자들의 빠르고도 만장일치에 가까운 인정은 벡터 검색이 신규 사용자를 확보하는 주요 사용 사례가 되게 했습니다. 마지막으로, 우리가 의존하는 모든 오픈 소스, SaaS, 클라우드 서비스 제공업체에 감사해야 합니다. 그들의 뛰어난 서비스가 이 여정을 가속화하는 데 도움이 되었습니다.
Zilliz Cloud와 Milvus의 충성도 높은 사용자들에게 특별한 감사를 전합니다. 여러분의 세심하고 인내심 있는 피드백은 우리에게 매우 귀중한 조언과 지침을 제공해 주었습니다. SaaS든 Serverless든, 우리는 지금까지 우리가 해온 모든 것이 시작에 불과하다고 굳게 믿습니다. 비용 효율성, 성능, 확장성, 사용자 친화성에 대한 추구에는 끝이 없습니다.
감사의 말
Zilliz Cloud의 개발에 중요한 역할을 해주신 헌신적인 사용자 여러분께 진심 어린 감사를 전하고 싶습니다. 여러분의 격려는 Zilliz Cloud를 구축해 온 우리의 여정을 공유하는 데 매우 중요했으며, 이는 자체 클라우드 서비스를 개발하고자 하는 다른 이들에게도 도움이 될 수 있는 통찰을 제공합니다. 300명 이상의 Milvus 커뮤니티 기여자들의 지칠 줄 모르는 노력과, 우리의 혁신적인 기술적 시도를 변함없이 지지해 준 CEO Charles에게 특별한 감사를 표합니다.
벡터 검색 서비스를 탐색하는 데 관심이 있으시다면, Zilliz Cloud에 가입해 보시기 바랍니다. 신규 등록자에게는 시작할 수 있도록 무료 크레딧 $100가 제공됩니다.
계속 읽기
Introducing Zilliz CLI and Agent Skills for Zilliz Cloud
Manage your vector database from your terminal or AI coding agent. Zilliz CLI and Agent Skills work with Claude Code, Cursor, Codex, and Copilot.
Democratizing AI: Making Vector Search Powerful and Affordable
Zilliz democratizes AI vector search with Milvus 2.6 and Zilliz Cloud for powerful, affordable scalability, cutting costs in infrastructure, operations, and development.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.