허깅페이스 허브 확장 전략: 모델 300만 개 검색을 지탱하는 MongoDB·쿠버네티스 설계

핵심 메시지

• 허깅페이스는 사용자 1400만 명, 공개 모델 300만 개, 데이터셋 100만 개, 조직 5만 곳을 서비스하고 있으며 포춘 500대 기업의 30% 이상이 AI 워크플로에 활용한다.
• 모델 수가 몇 년 사이 2만 개에서 300만 개로 약 150배 늘면서, 작은 규모에서는 아무 문제가 없던 정규식 기반 검색이 지연 문제를 일으켰다.
• 검색어 토큰을 조회 시점이 아니라 저장 시점에 미리 만들어 두고, 읽기 전용 컬렉션과 아파치 루씬 기반 전문 검색으로 옮겨 문제를 해결했다.
• 모델 파일 자체는 오브젝트 스토리지에, 모델에 관한 메타데이터는 MongoDB에 나눠 담아 각 계층을 독립적으로 확장한다.
• 확장은 파드와 노드 두 계층의 쿠버네티스 오토스케일링으로 이뤄지며, 다음 단계는 데이터베이스 샤딩과 이벤트 기반 오토스케일링이다.

쉽게 이해하기

허깅페이스에서 머신러닝 플랫폼과 데이터베이스를 담당하는 아렉 보루츠키(Arek Borucki)가 AI 엔지니어 행사에서 허브 인프라가 어떻게 커졌는지를 설명했다. 그가 제시한 현재 규모는 사용자 1400만 명, 공개 모델 300만 개, 데이터셋 100만 개, 조직 5만 곳이다. 취미 개발자와 연구자만의 공간이 아니라 포춘 500대 기업의 30% 이상이 업무 흐름에 끼워 쓰는 인프라가 됐다는 것이 그의 설명이다.

성장 속도가 문제의 출발점이었다. 몇 년 전 2만 개였던 모델은 300만 개로 약 150배가 됐고, 데이터셋도 2022년 1만 개에서 2024년 10만 개를 거쳐 100만 개에 도달했다. 모델이 2만 개일 때는 색인이 없어도 어떤 질의든 빨라 아무도 불편을 느끼지 않지만, 300만 개에서는 같은 방식이 통하지 않는다. 그래서 팀은 평균인 P50보다 꼬리 지연인 P99를 훨씬 중요하게 보는데, 사용자 1400만 명 기준으로는 1%만 느린 검색을 만나도 14만 명이 불편을 겪기 때문이다.

해법은 연산을 조회 시점에서 저장 시점으로 옮기는 것이었다. 모델 이름을 등록할 때 잘게 쪼갠 토큰을 배열로 함께 저장해 두고, 검색은 본래 저장소 컬렉션이 아니라 읽기와 목록 조회만을 위해 비정규화한 별도 컬렉션에서 처리한다. 과거에는 이 배열을 정규식으로 훑은 뒤 트렌딩 점수 순으로 정렬했는데, 데이터가 급증하자 정규식이 발목을 잡았다. 지금은 아파치 루씬을 내부에서 사용하는 아틀라스 검색의 자동완성 기능으로 바꿔 지연 문제가 사라졌다.

데이터 계층은 역할별로 쪼개져 있다. MongoDB에는 사용자·저장소·모델·데이터셋·설정·과금·접근 제어 같은 메타데이터가 들어가고, 실제 모델 아티팩트와 토크나이저 파일, 설정 파일은 AWS S3 같은 오브젝트 스토리지에 따로 둔다. 클러스터는 7개 노드로 구성돼 쓰기는 프라이머리가 전담하고 읽기는 여러 세컨더리로 분산되며, 애플리케이션에는 보이지 않는 숨겨진 노드 하나가 리포팅과 무거운 임시 질의를 받아 준다. 최신 데이터가 꼭 필요하지 않은 질의, 대량 스캔이 필요한 집계, 캐시 무효화나 레드시프트 동기화에 쓰이는 체인지 스트림은 모두 프라이머리 바깥으로 밀어낸다.

허브 자체는 쿠버네티스 위에서 돌아간다. 수평 파드 오토스케일러가 트래픽에 따라 파드를 10개에서 500개까지 늘렸다 줄이고, 노드 여유가 없어 파드가 대기 상태가 되면 Cast AI가 노드를 추가한다. 앞으로는 CPU와 메모리만 보는 방식 대신 초당 요청 수나 이벤트 루프 사용률 같은 실제 애플리케이션 지표로 움직이는 KEDA로 옮길 계획이다. 데이터베이스 쪽 다음 수순은 데이터를 조각내 여러 샤드에 나눠 담는 샤딩이다.

주요 인사이트

• 규모가 커지면 평균 응답 시간이 아니라 꼬리 지연이 이탈을 결정한다. 사용자가 1400만 명이면 1%도 14만 명이다.
• 검색을 확장하는 가장 실용적인 방법은 더 센 장비가 아니라 연산 시점을 옮기는 것이다. 저장할 때 토큰을 만들어 두면 조회는 단순한 조회가 된다.
• 메타데이터와 바이너리를 분리하면 메타데이터 저장소, 파일 저장소, 연산 계층을 각각의 부하 특성에 맞게 따로 키울 수 있다.
• 프라이머리 노드는 프라이머리만 할 수 있는 일에 집중시키고 나머지는 세컨더리와 숨겨진 노드로 옮긴다는 단순한 원칙이 클러스터 설계를 지배한다.
• 자원 사용률 기반 오토스케일링은 CPU가 낮은데도 요청이 밀려 있는 상황을 보지 못한다. 그래서 스케일링 기준을 애플리케이션 지표로 옮기려는 것이다.

자주 묻는 질문

관련 AI 소식