야후가 1조원 건넨 텀블러 "아키텍처 때문"

야후는 최근 마이크로블로그서비스 텀블러를 11억달러(1조1천억원)에 인수하기로 했다. 야후가 텀블러에 건넨 11억달러란 거액은 사업적 가능성과 별개로 우수한 아키텍처 역량을 높게 평가한 것이란 분석이다.

최근 하이스케일러빌리티닷컴은 작년 텀블러에서 공개한 내부 아키텍처를 다시 한번 소개하며, 텀블러의 기술적 역량을 재조명했다.

텀블러는 한달동안 150억건의 페이지뷰가 일어나는 블로그 서비스다. 단순하면서도, 아름답고, 집중하기 좋은 사용자 경험이 인기요인으로 꼽힌다.

빠른 성장 속에서 텀블러의 인프라 규모는 매달 30%씩 커지고 있다. 텀블러는 서비스 성장속도에 맞춰 거대해진 인프라를 관리하는 새로운 방법을 필요로 했다. 이는 인터넷서비스 스타트업이 대중적 인기를 얻게 되며 겪는 일반적인 상황이다.

스타트업이 예상을 뛰어넘는 속도로 성장하면, 해당 회사는 사람을 더 채용하고, 인프라를 진화시키며, 레거시 인프라를 유지하면서, 매달 급격한 트래픽 증가를 관리해야 한다. 보통 4명 정도의 엔지니어가 중차대한 책임을 떠안는 모양이다.

이런 상황에서 스타트업은 인프라에 대대적인 변화를 꾀하기 힘들다. 텀블러는 20명의 엔지니어를 통해 아키텍처에 변화를 주면서 관련 문제를 해결했다.

텀블러는 널리 사용되는 LAMP 애플리케이션을 사용해 만들어졌다. 리눅스, 아파치웹서버, 마이SQL, PHP 등이 텀블러 서비스의 근간을 이룬다. 텀블러 엔지니어들은 LAMP 환경에서 벗어나 분산형 서비스 모델로 변화를 추구했다. 스칼라, H베이스, 레디스, 카프카, 핀에이글(Finagle) 등이 이용됐다.

텀블러는 하루 5억 페이지뷰, 초당 4만 리퀘스트 피크치 등이 1천여대의 서버에서 벌어진다. 매일 3테라바이트(TB)의 신규데이터가 하둡 클러스터에 저장되고, 수TB 데이터가 매일 마이SQL과 HBASE, 레디스, 멤캐시 등에 쌓인다.

포스트는 매일 50GB씩 늘어나는데, 팔로워 리스트 업데이트는 매일 2.7TB 규모로 일어난다. 텀블러의 특징인 대시보드는 초당 수백만건의 쓰기가 이뤄지며, 초당 5만건의 읽기가 일어난다. 그 양은 갈수록 늘어나고 있다.

소프트웨어 개발은 OS X 환경에서, 프로덕션은 센트OS 및 사이언티픽 리눅스에서 작동한다. 아파치, PHP, 스칼라, 루비, 레디스, H베이스, 마이SQL, 바니시(Varnish), HA프록시, 엔진X(nginx), 멤캐시, 기어맨, 카프카, 스리프트(thrift), HTTP Func, Git, 카피스트라노, 퍼펫, 젠킨스 등이 사용됐다.

하드웨어는 500대의 웹서버와 200대의 데이터베이스(DB) 서버(47풀, 30샤딩), 30대 멤캐시 서버, 22대 레디스 서버, 15대 바니시 서버, 25대 HA프록시 노드, 8 엔진X, 14 잡큐서버 등으로 구성된다.


▲ 텀블러 대시보드
텀블러에 따르면, 다른 소셜네트워크 서비스와 다른 사용자 패턴이 나타난다. 매일 5천만개의 새 글이 올라오는데, 평균적인 포스트는 수백명의 사람들에게 전해진다. 한두명의 사용자가 수백만 팔로워에게 글을 뿌리는 타 SNS와 다른 부분이다.

텀블러는 미국 사용자가 두 번째로 많은 시간을 들이는 SNS다. 콘텐츠는 참여를 기반으로 하면서, 이미지와 동영상 중심으로 만들어진다. 동시에 깊이 있는 콘텐츠 중심으로 이뤄져 독자를 오랜시간 해당 페이지에 머물게 하는 특성을 갖고 있다. 수백명의 독자를 보유한 사용자는 일반 사용자보다 훨씬 더 많은 글을 업데이트한다.

텀블러의 인프라는 현재 한 곳에 구성돼 있다. 장기적으로 지리적으로 분산된 인프라를 구상하고 있다.

텀블러 플랫폼은 두 갈래로 나뉜다. 텀블로그와 대시보드다.

텀블로그는 링크, 인용문, 이미지, 동영상을 간략하게 보여준다. 텀블로그는 캐시하기 쉽지만, 다이나믹하진 않다.

대시보드는 트위터 타임라인과 유사한 형태다. 가입자 대부분은 텀블러를 콘텐츠 소비도구로 사용한다. 약 5억 페이지뷰가 하루에 일어나는데, 그중 70%가 대시보드에서 벌어진다.

사용자는 팔로우한 사람의 업데이트를 실시간으로 보게 되는데, 블로그와 전혀 다른 스케일 특성을 갖는다. 사용자별로 리퀘스트가 다르고, 액티브 팔로워의 활발한 활동으로 캐싱이 유용하지 않다.

때문에 대시보드는 실시간이면서 일관된 지속성을 가져야 한다. 스테일 데이터는 나타나면 안 되고, 많은 양의 데이터가 관리대상이다. 그러므로 포스트는 하루에 50GB밖에 되지 않지만, 팔로워 리스트 업데이트가 2.7TB에 이른다. 모든 미디어는 아마존웹서비스 S3에 담긴다.

텀블러의 옛 아키텍처는 LAMP 구조이며, 대부분 PHP언어로 개발됐다. 거의 모든 엔지니어가 PHP를 사용했고, 그를 바탕으로 규모를 키웠다. 이후 멤캐시를 사용해 규모를 늘리고, 프론트엔드 캐싱을 도입했다. HA프록시는 캐시의 앞단에 들어갔고, 마이SQL 샤딩이 도입됐다.

수년간 텀블러 엔지니어들은 2개의 백엔드 서비스를 개발했는데 레디스 기반의 대시보드 알림 서비스 스테어카(Staircar), ID생성기다. 대시보드는 분산-수집 접근법을 사용했다.

이후 텀블러는 아키텍처를 JVM 중심의 접근법으로 변화시켰다. 개발자 고용과 개발 속도를 높이기 위해서다. 목표는 PHP 애플리케이션을 서비스에서 제거하고, 인증과 프레젠테이션 등의 요구를 위한 얇은 서비스 레이어를 올리는 것이다.

이 과정에서 스칼라와 핀에이글이 선택됐다. 내부적으로 두 기술은 루비, PHP 언어와 유사하다. 트위터가 개발해 배포한 라이브러리인 핀에이글은 분산 트레이싱, 서비스 디스커버리, 서비스 등록 등 분산 이슈를 관리한다. 텀블러 엔지니어는 “핀에이글이 대량의 네트워킹 코드 없이도 잘 작동했다고 평가했고, 확장성에도 유용했다”고 평가했다.

H베이스와 레디스 같은 NoSQL이 도입됐지만 마이SQL을 대체한 건 아니다. 엔지니어의 경험을 쌓기 위해 제한적으로 적용하는 상황이다. H베이스의 경우 쓰기 성능이 필요한 곳과 수십억개 URL을 저장하는 단축URL서비스에 사용된다.

레디스 서버 22대는 대시보드 데이터를 저장한다. 1대의 서버당 8~32개 인스턴스를 생성, 100개의 레디스 인스턴스를 작동시키고 있다. 멤캐시 서버는 레디스로 조금씩 이전되는 중이다.

500대의 웹서버는 아파치와 PHP 애플리케이션으로 작동되고 200대 DB서버는 고가용성의 이유로 코모디티 하드웨어를 사용한다. 고가용성을 위해 여분의 하드웨어가 대량으로 준비된다.

대시보드 인덱스를 위한 셀(cell) 기반 아키텍처도 사용된다. 텀블러는 사용자와 팔로워를 하나로 묶어 대시보드를 구성하는데, 그를 셀 단위로 H베이스에 저장하고, 레디스에 캐싱한다. 이같은 셀 기반 아키텍처는 페이스북 메시지 서비스와 유사하다.