Infino, S3 오브젝트 스토리지 기반 전문 검색 아키텍처 공개

AI 에이전트용 검색 엔진 Infino가 로컬 디스크 대신 S3, GCS, Azure Blob 등 오브젝트 스토리지에 전문 검색 인덱스를 직접 호스팅하는 엔지니어링 방식을 공개했다. 로컬 SSD의 랜덤 읽기는 비용이 거의 들지 않지만, 오브젝트 스토리지의 랜덤 읽기는 수십 밀리초의 지연 시간과 요청당 비용이 발생한다. 따라서 이 아키텍처는 CPU나 데이터 전송량 최적화보다 GET 요청 횟수 최소화에 우선순위를 둔다.

스토리지 아키텍처: 슈퍼파일과 매니페스트

시스템은 문서 행, 전문 검색 인덱스, 벡터 인덱스를 포함하는 불변 Parquet 파일인 슈퍼파일로 데이터를 구성한다. Lucene처럼 인덱스 구성 요소를 여러 파일로 나누지 않고 단일 객체로 관리하므로, 인덱스의 모든 섹션을 단일 범위 GET 요청으로 가져올 수 있다.

파일 열기 오버헤드를 줄이기 위해 Infino는 모든 슈퍼파일의 Parquet 푸터와 인덱스 헤더를 인라인으로 저장하는 매니페스트를 사용한다. 매니페스트가 캐시되어 있어 슈퍼파일 열기에 GET 요청이 0회 필요하며, 쿼리의 첫 요청은 실제 필요한 데이터에 대한 것이다. 매니페스트에는 열 통계(최소값, 최대값, null 개수)도 포함되어 필터 조건과 일치하지 않는 슈퍼파일을 완전히 건너뛸 수 있다.

용어 인덱스와 쿼리 최적화

전역 용어 인덱스는 모든 용어를 해당 용어가 포함된 특정 슈퍼파일, 문서 수, BM25 점수 범위에 매핑한다. 이 구조를 통해 쿼리는 다음을 수행할 수 있다:

• 관련 없는 파일 건너뛰기: 'refund' 쿼리는 용어 인덱스를 확인하고 해당 용어가 실제로 포함된 슈퍼파일만 연다.
• Top-K 검색 최적화: 점수 범위 내림차순으로 슈퍼파일을 방문하여 k번째 최상위 점수를 찾으면 검색 경로를 제거한다.
• 카운트 쿼리 즉시 응답: 단일 용어 카운트는 슈퍼파일을 열지 않고 용어 인덱스의 문서 수로 계산할 수 있다. 한 테스트에서 141개의 슈퍼파일이 있는 테이블의 카운트 쿼리는 141개 파일을 여는 대신 0개를 열었다.

캐싱 및 데이터 접근

Infino는 postings, 문서 길이, 위치 등 필요한 특정 바이트 범위만 가져오는 지연 로딩 전략을 사용한다. 지연 시간을 완화하기 위해 시스템은 슈퍼파일을 로컬 디스크에 캐시한다. 쿼리가 처음으로 슈퍼파일에 접근하면 오브젝트 스토리지에서 필요한 범위를 가져오면서 동시에 전체 파일을 백그라운드에서 다운로드한다. 다운로드가 완료되면 파일을 메모리 매핑하여 이후 쿼리에서 추가 GET 요청을 제거한다. 디스크 캐시 기본값은 10 GB이며 설정 가능하다.

이러한 스토리지 계층의 혁신에도 불구하고 postings 리스트, BM25 스코어링, block-max pruning 등 핵심 검색 알고리즘은 Lucene의 기본 아이디어와 일관성을 유지한다.