페이스북 타임라인은 규모가 아주 크다. 사진, 위치, 상태 업데이트, 비디오와 같은 당신이 하는 모든것을 통해 당신의 인생을 한 화면에 담고자 한다. 즉 그건 언제든지 신속하고 빠르게 접근할 수 있는 수 십년의 데이터를 의미한다. 빅데이터 전문가들이 있는 페이스북에서도 이건 큰 기술적인 도전이었지만, 6개월만에 완성시켰다.
페이스북의 Ryan Mack이 타임라인 구현 스토리대해 말한 기고문이 있다. 해당 기고문에서 크게 5가지만 뽑자면 다음과 같다.
1. 새로운 것을 구축하는 대신 기존 인프라를 활용해라
당신은 페이스북이 타임라인을 위해 새로운 구조를 구축했을거라고 생각할 수 있지만, 그들은 이미 구축 되 있는 인프라를 사용했다.
- MySQL
- Multifeed(가까운 친구들의 업데이트 상황을 받아 볼 수 있는 시스템)
- Thrift
- Memcached
- Operations
기존 인프라위에서 그들은 오직 비즈니스 로직만 집중했고, 결국 6개월만에 완성 될 수 있었던 것이다.
2. 비정규화. 필요한 형태로 데이터를 포맷팅 해라
-
비정규화, 즉 필요해 맞는 테이블 생성(중복이 될지라도)으로 조인 쿼리의 감소와 데이터베이스 I/O를 최소화 시킬 수 있다. 비정규화 대신 캐싱을 사용할 수 도 있지만, 타임라인의 데이터는 방대하고 해당 데이터의 라이프 사이클을 측정할 수 없는 상황에서는 바람직하지 않다.
-
타임라인은 데이터를 메타데이터 토대로 랭킹을 매겨 순서에 따라 보여줘야 한다. 비정규화 프로세스는 모든 메타 데이터를 하나의 형태로 모아, 적은 I/O로 랭킹을 계산하고 PK range 쿼리로 데이터를 효율적으로 스트리밍 할 수 있다.
-
타임라인은 데이터웨어 하우스에 데이터마트와 같다. 수십 개의 서로 다른 시스템에서 데이터를 슬러핑 하여 정리하고 합쳐 새로운 표준 형식으로 다시 포맷해야 한다. 페이스북은 페이스북 방식으로 이것을 해냈다.
사용자 정의 데이터 변환 언어를 만들고, 기존 시스템에서 빠르게 데이터를 가져오기 위해 수백 대의 MySQL 서버를 배치하고 조인 속도를 높이기 위해 플래시 스토리지를 배치하고, 쿼리 프록시를 병렬화 시키고 향후 유연성을 위해 표준 Multifeed 데이터 포맷을 만들었다.
3. 다른 종류의 캐시를 이용해라
-
Short term cache. 타임라인의 최근 활동은 계속해서 바뀐다. 이 캐시는 플래시 캐시 커널 드라이버를 사용하여 OS캐시를 플래시 장치로 확장하는 InnoDB내의 RAM row 캐시이다.
-
Long term cache. 쿼리 캐시는 맴캐시에 저장된다. 2010년 활동의 랭킹을 보여달라는 빅 쿼리 같은 케이스는 결과가 거의 바뀔리가 없기 때문에 캐싱하면 효율적이다.
4. 지역적으로 운영해라
타임라인 집계기는 각각의 데이터베이스에서 돌아가기 때문에 디스크를 최대화 할 수 있다. 표시할 데이터만 네트워크를 통해 전송해라
5. 병렬적으로 개발해라
개발팀은 디자인, 프론트 앤드, 인프라, 데이터 마이그레이션으로 나누어 작업을 진행했다. 이와 동시에 테스트 백엔드의 UI 프로토타입, 시뮬레이션 백엔드의 프로덕션 UI, 확장 가능한 백엔드, 탈규격화 프레임워크, 데이터 웨어하우스 및 시뮬레이션 로드 테스트와 같이 구축되었다.
원문: 링크
