링크드인은 어떻게 데이터 제국을 건설했나

국내 인터넷서비스업체 대다수는 인프라에 힘을 싣기보다 아이디어와 비즈니스 감각으로 승부를 보려는 경향이 강하다. 이들 업체 비즈니스 모델은 대부분 대규모 가입자를 모아 그것을 활용할 수 있는 사업 다각화다. 시간이 흐르면서 서로 닯아갈 수 밖에 없는 구조다. 사업 다각화에 따라, 곳곳에서 진흙탕 싸움이 벌어진다. 십수년째 같은 상황이 반복되고 있다.

최근 회자되는 빅데이터를 이용한 비즈니스는 국내에 널리 퍼진 인터넷 사업모델과는 다르다. 미국 인터넷 서비스업계의 경우 확보된 가입자 규모 속에서 모든 사용자 활동을 데이터로 만들고, 세밀하게 분석하면서 더 많은 사용자 활동을 유도한다. 가입자 행동이 비즈니스 자산으로 직결되고, 다시 더 많은 행동을 만들어냄으로써 사업 규모를 늘려가는 선순환 구조로 이어진다.

2억5천900여명의 가입자를 보유한 세계 최대 비즈니스 소셜네트워크서비스(SNS) 링크드인은 이같은 사용자 행동을 데이터로 만들어 분석함으로써 성공한 대표적인 사례다. 링크드인은 빅데이터 핵심 기술은 하둡을 기반으로 경쟁력있는 사용자 분석 인프라를 구축했다.

리처드 박 링크드인 스태프 소프트웨어 엔지니어는 19일 서울 잠실 롯데호텔에서 열린 ‘제10회 어드밴스드컴퓨팅컨퍼런스(ACC)’ 마지막 발표자로 나서 링크드인의 하둡 도입초기부터 최근까지 실패와 극복의 경험을 공유했다.


▲ 링크드인 리처드 박 엔지니어
그에 따르면 링크드인은 다양한 빅데이터 분석을 통해 더 정확한 구인구직 추천시스템을 만들었고, 링크드인에 가면 쉽게 좋은 직장과 좋은 직원을 만날 수 있다는 인식을 각인시켰다. 이같은 인식을 만들고, 사람까지 끌어모으는 시스템에 돈이 몰리는 건 당연하다.

하지만 링크드인이 역량있는 분석을 할 수 있었던 배경엔 고도화된 인프라 아키텍처가 자리하고 있다. 데이터 과학자가 언제든 자유롭게 데이터로 이것저것 시도할 수 있는 복잡한 인프라를 만들어내고 관리하는 역량이 성공의 열쇠인 것이다.

링크드인 추천 기능은 크게 4가지로 나눠진다. 친구추천, 스킬앤드인도어스먼트, 추천채용공고, 뉴스추천이 바로 그것이다. 이들 서비스에 녹아든 추천의 폭과 깊이는 아직도 진화에 진화를 거듭하고 있다. 이것은 사용자 경험(UX) 향상으로 이어진다.

링크드인은 하둡을 비롯한 오픈소스 데이터관련 소프트웨어 기술을 총망라해 활용하면서, 자신들의 사업방향에 적합하도록 직접 아키텍처와 솔루션을 설계했다.

이런 추천시스템을 이루는 건 내부에서 데이터 제품이라고 불린다. 하루에도 수 테라바이트씩 쌓이는 고품질 데이터를 분석가가 떠먹기 좋게 잘 차려놓는 역할이다. 그러나 링크드인이 구사하는 능수능란한 빅데이터 관리는 하루아침에 얻어진게 아니었다.

사실 링크드인은 2006년 창업 당시만 해도 아키텍처가 다른 회사와 비슷했다. 모든 서비스가 오라클 DB위에서 돌아갔다.

리처드 박 엔지니어는 링크드인의 ‘알 수도 있는 사람(PYMK, People You May Know)’ 서비스를 예로 들었다. PYMK는 가입자 출신학교, 회사 등의 정보에 기반해 사람과 사람이 서로 아는 사이일 것이란 결론을 만들어낸다. A와 B가 서로 알고, B와 C가 알고 있을 때 A와 C도 알고 있는 사이라는 결과를 얻어내는데, 이를 트라이앵글 클로징이라 부른다.

2009년 링크드인은 가입자가 4천만~5천만명으로 늘면서 문제점에 봉착했다. 사람이 많아지자 관계도 함께 복잡해졌다. 데이터는 빠르게 늘었고, 장애도 더 자주 일어났다. 

그는 “6주에 한번씩 데이터 리프레시를 해야 했고, 심지어 장애가 길어져 6개월동안 데이터를 업데이트하지못하는 상황까지 벌어졌다”라며 “이는 실리콘밸리에선 망한 것이나 마찬가지”라고 말했다. 링크드인은 결국 20노드로 이뤄진 아파치 하둡을 도입했다. 그 결과 PYMK는 3일만에 이뤄졌다.

2010년 들어 또 다른 문제점이 발생하기 시작했다. 단순히 데이터 복제를 2카피로 정했고, 운영미숙으로 하둡 클러스터도 잦은 장애를 일으켰다. 링크드인은 이에 하둡 클러스터 운영 조직을 꾸려 경험있는 하둡시스템 운영자 2명을 채용했다. 2명의 엔지니어(개발)와 2명의 운영자가 하둡 인프라를 맡았다.

링크드인 추천시스템은 사용자의 활동 데이터가 하둡 클러스터에 쌓이고, 그걸 바탕으로 머신러닝 알고리즘을 적용 NoSQL에 결과를 저장한다. 이 결과를 분석가가 분석 모델링 레이어에 적용해 추천 알고리즘을 만들어내게 된다.

데이터가 하둡에 저장되기까지 과정이 조금 복잡하다. 오라클과 NAS를 거쳐 배치 분석을 위한 하둡에 데이터가 쌓이게 되는데, 말로는 단순하게 들리는 이 과정이 그물처럼 복잡한 워크플로우를 형성한다. 만약 워크플로우 중 일부가 문제를 일으키면 전체 추천시스템의 신뢰성이 현저히 떨어지는 현상을 낳는다.


▲ 링크드인 서비스. 파란색 박스가 하둡과 관련된 부분이다.
링크드인은 이 복잡한 워크플로우를 관리할 수 있는 도구로 ‘아즈카반(Azkaban)’을 만들어냈다. 워크플로우 스케줄러와 웹UI, 시각화된 절차 등의 기능이 아즈카반으로 제공된다.

아파치 피그도 동원됐다. 그는 “자바는 쓰기 어렵다는 단점이 있고, 피그를 사용하면 자바의 절반도 안되는 양의 코드로 동일 업무를 짤 수 있다”라며 “지금도 피그는 링크드인에서 가장 널리 사용된다”라고 말했다.

분산형 키벨류 데이터베이스인 아마존웹서비스의 다이나모DB에 기반한 볼드모트(Voldmort)도 이때 개발됐다. 데이터파일을 생성해 하둡에 인덱스를 만든다.

링크드인은 2011년, 아파치 카프카라는 분산형 메시징 엔진을 개발한다. 하이브도 분석가를 대상으로 본격적으로 서비스되기 시작했다.


▲ 링크드인 워크플로우 관리도구 `아즈카반`
2012년엔 하둡1.0을 도입한 새 클러스터를 구성하고 미국 동부에 새 데이터센터를 만들었다. 이 과정에서 보안 기능이 들어가 사용자의 권한관리를 하기 시작했다. 카프카, 아즈카반이 고도화됐다. 아파치 삼자(Samza)란 스트리밍 프로세싱 엔진도 개발해 오픈소스로 풀었다.

현재 링크드인은 하둡 2.0 중에서 얀 아키텍처에 관심을 보이고 있다. 임팔라, 타조 같은 대화형 쿼리분석 엔진 적용도 검토중이다. 

리처드 박은 “오늘날 링크드인 하둡은 5천개이상의 노드 이상이며, 8개 클러스터로 운영되고, 미러링 돼 있다”라며 “하둡 사용자는 1천명인데 하둡 엔지니어 6명, 운영자 8명, ETL 담당 2명이 개발 관리하고 있다”라고 설명했다.

그는 “이제 PYMK는 하루만에 할 수 있게 됐고, 결과가 뛰어나서 사용자에게 이메일을 해킹하는 것 아니냐는 비난까지 들을 정도”라고 덧붙였다.

그는 지난 4년의 경험을 밝히며 하둡은 개발자의 문제가 아니라 운영쪽의 문제라고 지적했다. 그는 “링크드인에게 하둡은 매우 중요하다”라며 “하둡이 없었다면 지금처럼 커지지 못했을 것이다”라고 강조했다.

리처드 박은 링크드인이 하둡 인프라를 개발하던 초창기부터 주도적인 역할을 담당했다. 2009년부터는 하둡 개발자 그룹 멤버로도 활동해왔다. 링크드인 합류전에는 페이팔에서 사기 탐지 업무를 담당했다. 지금도 아즈카반 수석 개발 업무와 함께 아파치 카프카 프로젝트에 기여하고 있다.