페북, 고단했던 그래프서치 구축 과정 공개

페이스북가 제공하는 소셜 검색 서비스 '그래프서치'를 뒷받침하는 데이터베이스 인프라 관련 내용이 일부 공개됐다. 페이스북 엔지니어링팀은 빠르고 원활한 그래프서치를 지원하는 인프라를 마련하는 것이, 쉽지 않았다는 후문이다.

24일(현지시간) 페이스북은 엔지니어링 블로그를 통해 그래프서치를 구현하기 위한 검색 DB 구축 과정을 공개했다.

페이스북 그래프서치는 사용자 뉴스피드와 상태 업데이트 등의 포스트를 검색하는 자연어 검색엔진이다. 마이크로소프트(MS) 빙 검색엔진을 사용해왔던 페이스북은 2년여 기간에 걸친 개발을 통해 그래프 서치를 개발했고, 일부 사용자들에게 제공해오다 지난 7월부터 일반에 공개했다.


▲ 페이스북 그래프서치
그래프 서치는 첫 공개될 때만 해도 타임라인 내 콘텐츠 검색만 가능했다. 그러나 페이스북은 이달초 업데이트를 통해 상태 업데이트와 사진 캡션, 댓글 등도 검색되도록 했다.

페이스북 블로그에 따르면, 페이스북은 기본적으로 매일 10억개의 새로운 포스트가 등록된다. 그러다보니 엔지니어링팀이 처리해야할 데이터 규모는 수백 테라바이트(TB)에 이른다. 이처럼 어마어마한 규모의 포스트를 인덱싱(색인화)하고 실시간으로 결과를 보여줄 수 있는 시스템을 구축하는 건 용량, 관리, 성능 측면에서 모두 어려운 작업이다.

페이스북은 인프라 구축을 위해 데이터 수집, 인덱스화, 인덱스 업데이트, 인덱스 서비스, 결과에 랭킹 부여 등의 순으로 작업을 진행했다.

이중 데이터 수집이 가장 고단한 작업이었다. 

기존에 페이스북은 데이터 스키마가 고정돼 있었는데, 그래프 서치에서는 데이터스키마도 상황에 따라 그때그때 변화하는 구조를 구현해야 했다. 페이스북은 변화하는 스키마를 쉽게 관리하기 위한 자동화 환경 구현에 중점을 뒀다. 

페이스북은 포스트, 사진, 체크인 등 데이터 유형이 다양하다.페이스북은 현재 70종의 데이터 종류를 분류하고 인덱스하고 있다.  이것은 포스트를 정렬시키기 어렵게 만드는 요인이다.

이들 데이터는 마이SQL(MySQL) 데이터베이스에 저장되는데, 이 상황에서 DB에 로드가 많이 발생한다는게 페이스북 설명이다. 페이스북 엔지니어링팀도 이 부분을 주의깊게 살피고 있다고 강조했다.

인덱스 구축 단계에선 페이스북은 가공 정제한 데이터를 HBASE 클러스터에 저장한다. 페이스북은 하둡 맵리듀스 작업을 통해 인덱스를 구축한다. 인덱스 구축 프로세스는 페이스북 검색 인프라인 유니콘을 활용해 로우 데이터를 검색 인덱스에 컨버팅하는 작업으로 이뤄진다.

데이터는 도큐먼트 데이터와 인버티드 인덱스 두곳에 존재한다. 도큐먼트 데이터에는 랭킹 결과에 사용되는 각 포스트들 정보가 담긴다. 인버티드 데이터는 전통적으로 검색 인덱스로 쓰인다. 

인덱스 업데이트 용량은 700테라바이트(TB) 이상으로 페이스북이 관리하는 다른 검색 인덱스보다 훨씬 크다. 멤캐시드를 사용하는 페이스북의 모든 검색 인덱스는 램(RAM)에 저장된다. 속도와 설적 유지 시간에 있어 램이 이상적이기 때문이다.

그러나 램에 들어가기에는 700TB는 너무 큰 규모다. 멤캐시드를 이용하면서 수많은 서버 랙에 분산되고 관리돼야 한다는 점도 부담이었다.

유니콘팀은 포스트 인덱스를 담당할 성능을 갖추고, 가격도 적당한 솔루션을 찾아 나섰다. 고민끝에 페이스북 엔지니어링팀은  램 대신 솔리드스테이트드라이브(SSD)에 인덱스를 올리기로 결정했다. 성능을 유지하기 위해 자주 접근할 필요가 있는 데이터만 구분해 램에 저장했다. 

SSD는 페이스북 인프라의 핵심으로 자리잡아 가는 모습이다. 지난 1월 페이스북은 SSD를 중심에 둔 올플래시 서버 드래곤스톤을 공개했고, 맥디퍼란 인프라에 드래곤스톤을 투입했다. 이에 힘입어 멤캐시드 레이어는 SSD에 기반한 시스템으로 변신할 수 있었다.

페이스북에 올라와 있는 포스트는 수십조개에 달한다. 그런만큼, 다양한 검색 쿼리와 결과물이 존재한다.

페이스북 엔지니어링팀은 검색 결과를 랭킹으로 보여주도록 설계했다. 사용자에게 적절하고 가치있는 콘텐츠를 보여주기 위해서다. 이를 위해 쿼리 리라이팅과 다이내믹 결과 스코어링 등의 기술이 사용됐다.

페이스북 그래프서치를 위한 모든 엔지니어링은 사내 엔지니어들이 예상했던 것보다 어려운 작업이었다. 이를 위해 해커톤 방식이 도입됐다.  엔지니어와 프로그래머들이 동시다발적인 아이디어 제공을 통해 빠르게 해결책을 찾아나갔다. 그래프 서치팀에서는 12명의 엔지니어가 여기에 참여했다고 한다.