123RF가 Zilliz Cloud로 비주얼 검색을 2억 개 이상의 자산으로 확장한 방법
<50ms 지연 시간
프로덕션에서 ~100 ms에서 감소
50% 비용 절감
OpenSearch에서 마이그레이션한 후
2억 개 이상의 벡터
전체 이미지 라이브러리 전반에 걸쳐
대량 인덱싱
수백만 개가 몇 시간 내에 가져와졌습니다
The biggest immediate impact for the company would be the cost side of things. We were able to bring the estimated cost of our search cluster from above five digits a month to a significantly lower figure. That would be the biggest improvement for our company.
Su-Meng Yong
123RF 소개
Inmagine Group의 일부인 123RF,는 세계 최대 규모의 스톡 콘텐츠 플랫폼 중 하나로, 2억 개 이상의 이미지, 비디오, 오디오 파일 라이브러리를 통해 수백만 명의 크리에이티브 전문가에게 서비스를 제공합니다. 검색은 123RF 경험의 핵심입니다. 모든 쿼리는 방대하고 지속적으로 성장하는 카탈로그에서 가장 관련성 높은 시각 콘텐츠를 표시해야 합니다. OpenSearch의 비용 상승과 불안정한 성능이 이러한 경험을 위협하자, 123RF는 Zilliz Cloud로 전환하여 인프라 비용을 50% 이상 절감하고, 쿼리 지연 시간을 절반으로 줄였으며, 이전 설정을 괴롭히던 인덱싱 실패를 제거했습니다.
과제
이전에는 123RF가 주요 검색 인프라로 OpenSearch에 의존했습니다. 이 플랫폼은 원래 전체 텍스트 키워드 검색을 중심으로 구축되었지만, AI 시대가 도래하면서 팀은 더 관련성 높은 결과를 제공하기 위해 임베딩 기반 의미 검색을 실험하기 시작했습니다. 그들은 처음부터 다시 구축하는 대신 기존 OpenSearch 클러스터에 KNN 플러그인을 추가했습니다.
그 결정에는 점점 커지는 비용이 따랐습니다. 세 가지 상호 연결된 문제가 결국 기존 상태를 더 이상 유지할 수 없게 만들었습니다:
비용 급증: 2억 개 이상의 벡터 규모에서 KNN이 활성화된 OpenSearch 클러스터를 운영하면서 월 운영 비용이 다섯 자릿수 수준으로 치솟았고 계속 증가했습니다.
불안정한 성능: 실제 프로덕션 트래픽에서 지연 시간과 쿼리 처리량이 예측 불가능해져 최종 사용자의 검색 경험이 저하되었습니다.
인덱싱 불안정성: 123RF의 라이브러리는 매일 성장하기 때문에 새 에셋을 지속적으로 인덱싱해야 합니다. OpenSearch 클러스터는 이러한 인덱싱 작업 중 빈번한 노드 장애를 겪었고, 지속적인 DevOps 개입이 필요했습니다.
OpenSearch는 벡터 유사도 검색을 위해 특별히 설계된 것이 아니었습니다. KNN 플러그인은 우회 방법을 제공했지만, 이를 대규모로 관리하는 것은 팀이 지속적으로 감당할 수 없는 운영 오버헤드를 초래했습니다.
Zilliz Cloud를 선택한 이유
Su-Meng Yong과 그의 팀이 대안을 찾기 시작했을 때, Pinecone 및 Weaviate와 같은 여러 전용 벡터 데이터베이스 옵션을 평가했습니다. 세 가지 기준이 결정을 이끌었습니다:
규모: 솔루션은 성능 저하 없이 수억 개의 벡터를 안정적으로 처리해야 했습니다.
비용 효율성: 일부 대안은 123RF가 요구하는 규모에서 운영 비용이 더 많이 들기 때문에 제외되었습니다.
성숙도와 커뮤니티 피드백: Zilliz Cloud는 활발한 커뮤니티를 보유한 오픈 소스 Milvus 벡터 데이터베이스를 기반으로 구축된 완전 관리형 서비스입니다.
솔루션
123RF는 두 가지 상호 보완적인 검색 워크플로를 구동하기 위해 Zilliz Cloud를 배포했습니다:
텍스트-이미지 검색: 사용자 쿼리는 벡터 임베딩으로 변환된 다음, 벡터 유사도를 사용하여 인덱싱된 이미지 라이브러리와 매칭되어 의미적으로 관련성 높은 결과를 반환합니다.
역이미지 검색: 사용자가 이미지를 업로드하면, 시스템이 해당 임베딩을 생성하고 전체 라이브러리에서 시각적으로 유사한 에셋을 검색합니다.
임베딩 계층은 오픈 소스 멀티모달 임베딩 모델인 CLIP을 사용하며, 팀은 Zilliz 솔루션 팀의 지원을 받아 두 가지 모델 버전에 걸쳐 이를 반복 개선했습니다. 지정된 벤더 모델이 아닌 어떤 임베딩 모델이든 사용할 수 있는 유연성은 의미 있는 장점으로 언급되었습니다.
일일 배치 파이프라인은 모든 신규 기여자 제출물을 임베딩으로 변환하고 이를 Zilliz Cloud 클러스터에 수집하여, 수동 개입 없이 인덱스를 최신 상태로 유지합니다.
배포 중 특히 가치 있는 것으로 입증된 세 가지 플랫폼 기능은 다음과 같습니다:
동적 확장: 클러스터는 예상 쿼리 부하에 따라 확장 또는 축소할 수 있으며, 이는 이전 OpenSearch 설정에서는 사용할 수 없었던 기능입니다.
대량 가져오기 작업: Zilliz Cloud의 가져오기 작업 기능을 통해 수백만에서 수천만 행을 몇 시간 내에 인덱싱할 수 있어, OpenSearch에서 노드 장애를 일으켰던 만성적인 인덱싱 병목 현상을 해결했습니다.
Boost Ranker(맞춤 기능): 123RF는 검색 순위 지정에 맞춤형 비즈니스 로직이 필요했습니다. Zilliz 엔지니어링 팀은 이 사용 사례를 위해 특별히 Boost Ranker 기능을 개발했으며, 현재 프로덕션 환경에서 실행 중입니다.
결과 및 이점
>50% 비용 절감
가장 즉각적인 영향은 재정적인 부분이었습니다. Zilliz 팀의 도움으로 123RF는 월간 검색 인프라 비용을 원래 지출의 일부 수준으로 낮췄으며, 이는 50% 이상의 절감에 해당합니다.
"검색은 우리 플랫폼의 핵심입니다. 수백만 명의 사용자가 적절한 콘텐츠를 찾는 방식이기 때문입니다. Zilliz Cloud로 이전한 것은 인프라 비용을 크게 줄였을 뿐만 아니라, 검색이 우리 비즈니스의 발목을 잡는 대신 함께 확장될 것이라는 확신을 엔지니어링 팀에 주었습니다."
— Su-Meng Yong, 엔지니어링 팀 리드, 123RF
< 50ms 지연 시간 달성
Zilliz 팀과 여러 차례 최적화 반복을 거친 후, 123RF는 프로덕션 수준의 처리량과 일일 트래픽 부하를 유지하면서 평균 쿼리 지연 시간을 100ms에서 30-50ms로 줄였으며, 이는 약 50%의 개선입니다.
무중단 인덱싱
일일 콘텐츠 수집 중 OpenSearch를 괴롭혔던 노드 이탈 문제가 완전히 사라졌습니다. 이전에는 팀이 라이브 사용자에 대한 검색 성능을 저하시키지 않으면서 새 이미지를 클러스터에 충분히 빠르게 인덱싱할 수 없었습니다. Zilliz Cloud의 대량 가져오기 기능을 사용하여, 팀은 이제 쿼리 성능에 전혀 영향을 주지 않고 수백만에서 수천만 개의 새 행을 몇 시간 내에 인덱싱합니다. 일일 자동화 파이프라인은 새로 제출된 스톡 콘텐츠를 임베딩으로 변환하고 이를 클러스터에 수집하여, 수동 개입 없이 검색 인덱스를 최신 상태로 유지합니다.
운영상의 자유
완전 관리형 서비스인 Zilliz Cloud는 DevOps 팀의 시간을 소모하던 클러스터 관리 부담을 없앴습니다. 엔지니어링 팀은 인프라 문제를 해결하느라 바쁘게 대응하는 대신 제품 기능을 구축하는 데 집중하게 되었습니다.
"이는 제 팀과 개발자 모두가 많은 문제와 클러스터의 많은 자체 관리 작업을 처리해야 하는 시간을 크게 절약해 줍니다." — — Su-Meng Yong, 엔지니어링 팀 리드, 123RF
다음 단계
이미지 검색이 완전히 마이그레이션되어 안정화됨에 따라, 123RF는 비디오 및 오디오 검색 워크플로를 Zilliz Cloud로 가져올 계획입니다. 또한 팀은 향후 플랫폼의 검색 기능을 확장하기 위해 LangChain 또는 LlamaIndex 통합을 검토하는 데에도 열려 있습니다.
The fully managed version really saves both my team and the developers a lot of time from having to deal with a lot of problems, a lot of self-managing of the cluster. And regarding latency — we went from an initial 100 milliseconds to now sub 30 to 50 milliseconds, a roughly 50% reduction while being able to maintain production throughput.
Su-Meng Yong