Milvus로 멀티테넌시 RAG 설계하기: 확장 가능한 엔터프라이즈 지식 베이스를 위한 모범 사례
소개
지난 몇 년 동안 검색 증강 생성(Retrieval-Augmented Generation, RAG)은 대규모 조직이 LLM 기반 애플리케이션, 특히 다양한 사용자를 보유한 애플리케이션을 향상시키기 위한 신뢰할 수 있는 솔루션으로 부상했습니다. 이러한 애플리케이션이 성장함에 따라 멀티테넌시 프레임워크를 구현하는 것이 필수적이 됩니다. 멀티테넌시는 서로 다른 사용자 그룹에 데이터에 대한 안전하고 격리된 액세스를 제공하여 사용자 신뢰를 보장하고, 규제 표준을 충족하며, 운영 효율성을 향상시킵니다.
Milvus는 고차원 벡터 데이터를 처리하도록 구축된 오픈 소스 벡터 데이터베이스입니다. Milvus는 RAG의 필수 인프라 구성 요소로, 외부 소스에서 LLM을 위한 컨텍스트 정보를 저장하고 검색합니다. Milvus는 데이터베이스 수준, 컬렉션 수준, 파티션 수준 멀티테넌시를 포함하여 다양한 요구에 맞는 유연한 멀티테넌시 전략을 제공합니다.
이 글에서는 다음을 다룹니다.
멀티테넌시란 무엇이며 왜 중요한가
Milvus의 멀티테넌시 전략
예시: RAG 기반 기업 지식 베이스를 위한 멀티테넌시 전략
멀티테넌시란 무엇이며 왜 중요한가
멀티테넌시는 "테넌트"로 알려진 여러 고객 또는 팀이 애플리케이션이나 시스템의 단일 인스턴스를 공유하는 아키텍처입니다. 각 테넌트의 데이터와 구성은 논리적으로 격리되어 개인정보 보호와 보안을 보장하는 동시에, 모든 테넌트는 동일한 기본 인프라를 공유합니다.
여러 회사에 지식 기반 솔루션을 제공하는 SaaS 플랫폼을 상상해 보세요. 각 회사는 하나의 테넌트입니다.
테넌트 A는 환자 대상 FAQ와 규정 준수 문서를 저장하는 의료 기관입니다.
테넌트 B는 내부 IT 문제 해결 워크플로를 관리하는 기술 회사입니다.
테넌트 C는 제품 반품을 위한 고객 서비스 FAQ를 보유한 소매 기업입니다.
각 테넌트는 완전히 격리된 환경에서 운영되므로 테넌트 A의 데이터가 테넌트 B의 시스템으로 유출되거나 그 반대의 경우가 발생하지 않도록 보장합니다. 또한 리소스 할당, 쿼리 성능, 확장 결정은 테넌트별로 이루어져 한 테넌트에서 워크로드가 급증하더라도 높은 성능을 보장합니다.
멀티테넌시는 동일한 조직 내 서로 다른 팀에 서비스를 제공하는 시스템에도 적용됩니다. HR, 법무, 마케팅과 같은 내부 부서에 서비스를 제공하기 위해 RAG 기반 지식 베이스를 사용하는 대기업을 상상해 보세요. 이 구성에서는 각 부서가 하나의 테넌트이며 데이터와 리소스가 격리됩니다.
멀티테넌시는 비용 효율성, 확장성, 강력한 데이터 보안을 포함한 상당한 이점을 제공합니다. 단일 인프라를 공유함으로써 서비스 제공자는 간접 비용을 줄이고 더 효과적인 리소스 소비를 보장할 수 있습니다. 이 접근 방식은 또한 손쉽게 확장됩니다. 단일 테넌시 모델처럼 각 테넌트마다 별도의 인스턴스를 생성하는 것보다 새 테넌트를 온보딩하는 데 훨씬 적은 리소스가 필요하기 때문입니다. 중요한 점은 멀티테넌시가 각 테넌트에 대한 엄격한 데이터 격리를 보장하고, 액세스 제어와 암호화를 통해 민감한 정보를 무단 액세스로부터 보호함으로써 강력한 데이터 보안을 유지한다는 것입니다. 또한 업데이트, 패치, 새로운 기능을 모든 테넌트에 동시에 배포할 수 있어 시스템 유지 관리를 단순화하고 관리자의 부담을 줄이는 동시에 보안 및 규정 준수 표준이 일관되게 유지되도록 보장합니다.
Milvus의 멀티테넌시 전략
Milvus가 멀티테넌시를 어떻게 지원하는지 이해하려면 먼저 Milvus가 사용자 데이터를 어떻게 구성하는지 살펴보는 것이 중요합니다.
Milvus가 사용자 데이터를 구성하는 방식
Milvus는 데이터를 넓은 범위에서 세부적인 범위로 이동하며 세 가지 계층으로 구조화합니다: Database, Collection, Partition/Partition Key.
Figure- How Milvus organizes user data .png
그림: Milvus가 사용자 데이터를 구성하는 방식
Database: 이는 기존 관계형 시스템의 데이터베이스와 유사한 논리적 컨테이너 역할을 합니다.
Collection: 데이터베이스 내의 테이블에 해당하며, 컬렉션은 데이터를 관리 가능한 그룹으로 구성합니다.
Partition/Partition Key: 컬렉션 내에서 데이터는 Partitions를 통해 더 세분화될 수 있습니다. Partition Key를 사용하면 동일한 키를 가진 데이터가 함께 그룹화됩니다. 예를 들어 user ID를 Partition Key로 사용하면 특정 사용자의 모든 데이터가 동일한 논리적 세그먼트에 저장됩니다. 이를 통해 개별 사용자와 연결된 데이터를 쉽게 검색할 수 있습니다.
Database에서 Collection, 그리고 Partition Key로 이동할수록 데이터 구성의 세분성이 점진적으로 더 정교해집니다.
더 강력한 데이터 보안과 적절한 액세스 제어를 보장하기 위해 Milvus는 강력한 Role-Based Access Control (RBAC)도 제공하여 관리자가 각 사용자에 대한 특정 권한을 정의할 수 있도록 합니다. 권한이 부여된 사용자만 특정 데이터에 액세스할 수 있습니다.
Milvus는 멀티 테넌시를 구현하기 위한 여러 전략을 지원하며, 애플리케이션의 요구 사항에 따라 유연성을 제공합니다: 데이터베이스 수준, 컬렉션 수준, 파티션 수준 멀티 테넌시.
데이터베이스 수준 멀티 테넌시
데이터베이스 수준 멀티 테넌시 접근 방식에서는 각 테넌트가 동일한 Milvus 클러스터 내에서 자체 데이터베이스를 할당받습니다. 이 전략은 강력한 데이터 격리를 제공하고 최적의 검색 성능을 보장합니다. 하지만 특정 테넌트가 비활성 상태로 남아 있으면 리소스 활용이 비효율적일 수 있습니다.
컬렉션 수준 멀티 테넌시
여기서 컬렉션 수준 멀티 테넌시에서는 테넌트 데이터를 두 가지 방식으로 구성할 수 있습니다.
모든 테넌트를 위한 하나의 Collection: 모든 테넌트가 단일 컬렉션을 공유하며, 테넌트별 필드를 필터링에 사용합니다. 구현은 간단하지만 테넌트 수가 증가함에 따라 이 접근 방식은 성능 병목 현상을 겪을 수 있습니다.
테넌트당 하나의 Collection: 각 테넌트는 전용 컬렉션을 가질 수 있어 격리와 성능이 향상되지만 더 많은 리소스가 필요합니다. 이 설정은 테넌트 수가 Milvus의 컬렉션 용량을 초과하면 확장성 제한에 직면할 수 있습니다.
파티션 수준 멀티 테넌시
파티션 수준 멀티 테넌시는 단일 컬렉션 내에서 테넌트를 구성하는 데 중점을 둡니다. 여기서도 테넌트 데이터를 구성하는 두 가지 방식이 있습니다.
테넌트당 하나의 Partition: 테넌트는 컬렉션을 공유하지만 해당 데이터는 별도의 파티션에 저장됩니다. 각 테넌트에 전용 파티션을 할당하여 데이터를 격리할 수 있으며, 격리와 검색 성능의 균형을 맞출 수 있습니다. 하지만 이 접근 방식은 Milvus의 최대 파티션 제한에 의해 제약됩니다.
Partition-Key-Based Multi-Tenancy: 이는 단일 컬렉션이 파티션 키를 사용하여 테넌트를 구분하는 더 확장 가능한 옵션입니다. 이 방법은 리소스 관리를 단순화하고 더 높은 확장성을 지원하지만 대량 데이터 삽입은 지원하지 않습니다.
아래 표는 주요 멀티 테넌시 접근 방식 간의 핵심 차이점을 요약합니다.
| 세분성 | 데이터베이스 수준 | 컬렉션 수준 | 파티션 키 수준 |
|---|---|---|---|
| 지원되는 최대 테넌트 수 | ~1,000 | ~10,000 | ~10,000,000 |
| 데이터 구성 유연성 | 높음: 사용자가 사용자 지정 스키마로 여러 컬렉션을 정의할 수 있습니다. | 중간: 사용자는 사용자 지정 스키마가 있는 하나의 컬렉션으로 제한됩니다. | 낮음: 모든 사용자가 하나의 컬렉션을 공유하므로 일관된 스키마가 필요합니다. |
| 사용자당 비용 | 높음 | 중간 | 낮음 |
| 물리적 리소스 격리 | 예 | 예 | 아니요 |
| RBAC | 예 | 예 | 아니요 |
| 검색 성능 | 강함 | 중간 | 강함 |
예시: RAG 기반 엔터프라이즈 지식 베이스를 위한 멀티테넌시 전략
RAG 시스템을 위한 멀티테넌시 전략을 설계할 때는 접근 방식을 비즈니스와 테넌트의 구체적인 요구 사항에 맞추는 것이 중요합니다. Milvus는 다양한 멀티테넌시 전략을 제공하며, 올바른 전략을 선택하는 것은 테넌트 수, 요구 사항, 필요한 데이터 격리 수준에 따라 달라집니다. 다음은 RAG 기반 엔터프라이즈 지식 베이스를 예로 들어 이러한 결정을 내리는 데 도움이 되는 실용적인 가이드입니다.
멀티테넌시 전략 선택 전 테넌트 구조 이해하기
RAG 기반 엔터프라이즈 지식 베이스는 종종 소수의 테넌트에 서비스를 제공합니다. 이러한 테넌트는 일반적으로 IT, 영업, 법무, 마케팅과 같은 독립적인 비즈니스 단위이며, 각기 다른 지식 베이스 서비스를 필요로 합니다. 예를 들어, HR 부서는 온보딩 가이드와 복리후생 정책 같은 민감한 직원 정보를 관리하며, 이는 기밀로 유지되고 HR 담당자만 접근할 수 있어야 합니다.
이 경우 각 비즈니스 단위는 별도의 테넌트로 취급되어야 하며 데이터베이스 수준 멀티테넌시 전략이 가장 적합한 경우가 많습니다. 각 테넌트에 전용 데이터베이스를 할당함으로써 조직은 강력한 논리적 격리를 달성하여 관리를 단순화하고 보안을 강화할 수 있습니다. 이 설정은 테넌트에게 상당한 유연성을 제공합니다. 테넌트는 컬렉션 내에서 사용자 지정 데이터 모델을 정의하고, 필요한 만큼 컬렉션을 생성하며, 컬렉션에 대한 액세스 제어를 독립적으로 관리할 수 있습니다.
물리적 리소스 격리로 보안 강화
데이터 보안이 매우 중요하게 여겨지는 상황에서는 데이터베이스 수준의 논리적 격리만으로는 충분하지 않을 수 있습니다. 예를 들어, 일부 비즈니스 단위는 중요하거나 매우 민감한 데이터를 처리할 수 있어, 다른 테넌트의 간섭으로부터 더 강력한 보장이 필요합니다. 이러한 경우 데이터베이스 수준 멀티테넌시 구조 위에 물리적 격리 접근 방식을 구현할 수 있습니다.
Milvus는 데이터베이스 및 컬렉션과 같은 논리적 구성 요소를 물리적 리소스에 매핑할 수 있게 해줍니다. 이 방법은 다른 테넌트의 활동이 중요한 운영에 영향을 미치지 않도록 보장합니다. 이 접근 방식이 실제로 어떻게 작동하는지 살펴보겠습니다.
Figure- How Milvus manages physical resources.png
그림: Milvus가 물리적 리소스를 관리하는 방법
위 다이어그램에 표시된 것처럼, Milvus에는 Query Node, Resource Group, Database라는 세 가지 리소스 관리 계층이 있습니다.
Query Node: 쿼리 작업을 처리하는 구성 요소입니다. 물리적 머신 또는 컨테이너(예: Kubernetes의 pod)에서 실행됩니다.
Resource Group: 논리적 구성 요소(데이터베이스 및 컬렉션)와 물리적 리소스 사이의 다리 역할을 하는 Query Node의 모음입니다. 하나 이상의 데이터베이스 또는 컬렉션을 단일 Resource Group에 할당할 수 있습니다.
위 다이어그램에 표시된 예시에는 X, Y, Z라는 세 개의 논리적 Databases가 있습니다.
Database X: Collection A를 포함합니다.
Database Y: Collections B 및 C를 포함합니다.
Database Z: Collections D 및 E를 포함합니다.
Database X가 Database Y 또는 Database Z의 부하에 영향을 받지 않기를 원하는 중요한 지식 베이스를 보유하고 있다고 가정해 보겠습니다. 데이터 격리를 보장하기 위해:
Database X에는 자체 Resource Group이 할당되어, 중요한 지식 베이스가 다른 데이터베이스의 워크로드에 영향을 받지 않도록 보장합니다.
Collection E도 상위 데이터베이스(Z) 내에서 별도의 Resource Group에 할당됩니다. 이는 공유 데이터베이스 내 특정 중요 데이터에 대해 컬렉션 수준의 격리를 제공합니다.
한편, Databases Y 및 Z의 나머지 컬렉션은 Resource Group 2의 물리적 리소스를 공유합니다.
논리적 구성 요소를 물리적 리소스에 신중하게 매핑함으로써, 조직은 특정 비즈니스 요구에 맞춘 유연하고 확장 가능하며 안전한 멀티테넌시 아키텍처를 달성할 수 있습니다.
최종 사용자 수준 액세스 설계
이제 엔터프라이즈 RAG를 위한 멀티테넌시 전략을 선택하는 모범 사례를 배웠으므로, 이러한 시스템에서 사용자 수준 액세스를 설계하는 방법을 살펴보겠습니다.
이러한 시스템에서 최종 사용자는 일반적으로 LLM을 통해 읽기 전용 모드로 지식 베이스와 상호 작용합니다. 그러나 조직은 여전히 지식 베이스의 정확도 향상이나 개인화된 서비스 제공 등 다양한 목적을 위해 사용자가 생성한 이러한 Q&A 데이터를 추적하고 특정 사용자와 연결해야 합니다.
병원의 스마트 상담 서비스 데스크를 예로 들어보겠습니다. 환자는 “오늘 전문의와 가능한 예약이 있나요?” 또는 "다가오는 수술을 위해 필요한 특정 준비 사항이 있나요?"와 같은 질문을 할 수 있습니다. 이러한 질문이 지식 베이스에 직접적인 영향을 미치지는 않지만, 병원이 서비스를 개선하기 위해 이러한 상호 작용을 추적하는 것은 중요합니다. 이러한 Q&A 쌍은 일반적으로 상호 작용 로깅 전용의 별도 데이터베이스(반드시 벡터 데이터베이스일 필요는 없음)에 저장됩니다.
Figure- The multi-tenancy architecture for an enterprise RAG knowledge base .png
그림: 엔터프라이즈 RAG 지식 베이스를 위한 멀티테넌시 아키텍처
위 다이어그램은 엔터프라이즈 RAG 시스템의 멀티테넌시 아키텍처를 보여줍니다.
System Administrators는 RAG 시스템을 감독하고, 리소스 할당을 관리하며, 데이터베이스를 할당하고, 이를 리소스 그룹에 매핑하며, 확장성을 보장합니다. 다이어그램에 표시된 것처럼 각 리소스 그룹(예: Resource Group 1, 2, 3)이 물리적 서버(쿼리 노드)에 매핑되는 물리적 인프라를 처리합니다.
테넌트(데이터베이스 소유자 및 개발자)는 다이어그램에 표시된 것처럼 사용자 생성 Q&A 데이터를 기반으로 반복적으로 개선하며 지식 베이스를 관리합니다. 서로 다른 데이터베이스(Database X, Y, Z)에는 서로 다른 지식 베이스 콘텐츠(Collection A, B 등)를 가진 컬렉션이 포함됩니다.
최종 사용자는 LLM을 통해 읽기 전용 방식으로 시스템과 상호 작용합니다. 이들이 시스템에 질의하면, 질문은 별도의 Q&A 기록 테이블(별도 데이터베이스)에 기록되어 가치 있는 데이터를 지속적으로 시스템에 다시 제공합니다.
이 설계는 사용자 상호 작용부터 시스템 관리에 이르기까지 각 프로세스 계층이 원활하게 작동하도록 보장하여, 조직이 견고하고 지속적으로 개선되는 지식 베이스를 구축하도록 돕습니다.
요약
이 블로그에서는 멀티테넌시 프레임워크가 RAG 기반 지식 베이스의 확장성, 보안 및 성능에서 어떻게 중요한 역할을 하는지 살펴보았습니다. 서로 다른 테넌트의 데이터와 리소스를 격리함으로써, 기업은 공유 인프라 전반에서 개인정보 보호, 규제 준수 및 최적화된 리소스 할당을 보장할 수 있습니다. Milvus는 유연한 멀티테넌시 전략을 통해, 기업이 특정 요구 사항에 따라 데이터베이스 수준부터 파티션 수준까지 적절한 데이터 격리 수준을 선택할 수 있도록 합니다. 적절한 멀티테넌시 접근 방식을 선택하면 기업은 다양한 데이터와 워크로드를 처리하는 경우에도 테넌트에게 맞춤형 서비스를 제공할 수 있습니다.
여기에 제시된 모범 사례를 따르면, 조직은 뛰어난 사용자 경험을 제공할 뿐만 아니라 비즈니스 요구가 증가함에 따라 손쉽게 확장되는 멀티테넌시 RAG 시스템을 효과적으로 설계하고 관리할 수 있습니다. Milvus의 아키텍처는 기업이 높은 수준의 격리, 보안 및 성능을 유지할 수 있도록 보장하므로, 엔터프라이즈급 RAG 기반 지식 베이스를 구축하는 데 중요한 구성 요소가 됩니다.
멀티테넌시 RAG에 대한 더 많은 인사이트를 기대해 주세요
이 블로그에서는 Milvus의 멀티테넌시 전략이 테넌트를 관리하도록 설계되었지만, 해당 테넌트 내의 최종 사용자를 관리하도록 설계된 것은 아니라는 점을 논의했습니다. 최종 사용자 상호 작용은 일반적으로 애플리케이션 계층에서 발생하는 반면, 벡터 데이터베이스 자체는 이러한 사용자를 인식하지 않습니다.
궁금하실 수 있습니다. 각 최종 사용자의 질의 기록을 기반으로 더 정확한 답변을 제공하려면, Milvus가 각 사용자에 대한 개인화된 Q&A 컨텍스트를 유지해야 하지 않나요?
훌륭한 질문이며, 답은 실제로 사용 사례에 따라 달라집니다. 예를 들어, 온디맨드 상담 서비스에서는 질의가 무작위로 이루어지며, 주요 초점은 사용자의 과거 컨텍스트를 추적하는 것보다 지식 베이스의 품질에 있습니다.
그러나 다른 경우에는 RAG 시스템이 컨텍스트를 인식해야 합니다. 이것이 필요한 경우, Milvus는 애플리케이션 계층과 협력하여 각 사용자의 컨텍스트에 대한 개인화된 메모리를 유지해야 합니다. 이 설계는 대규모 최종 사용자를 보유한 애플리케이션에 특히 중요하며, 이에 대해서는 다음 게시물에서 더 자세히 살펴보겠습니다. 더 많은 인사이트를 기대해 주세요!
계속 읽기
Vector Lakebase: End the AI Data Silo
Learn how Vector Lakebase unifies vector search, data lakes, and AI data operations so teams can serve RAG and agents without copy-and-sync pipelines.
Zilliz Cloud Just Landed in Claude Code
The Zilliz Cloud Plugin brings the full power of Zilliz Cloud directly into your Claude Code terminal as natural-language conversations.
Zilliz Cloud BYOC Upgrades: Bring Enterprise-Grade Security, Networking Isolation, and More
Discover how Zilliz Cloud BYOC brings enterprise-grade security, networking isolation, and infrastructure automation to vector database deployments in AWS