초당 120 만 트윗을 처리하는Twitter 시스템

마이에트 엔터테인먼트 Server Programmer

최흥배

Microsoft Visual C++ MVP

Twitter : @jacking75

Twitter 의 시스템 · 아키텍트 Nick Kallen 씨

Twitter 의 서비스는 문자로 처리 하므로 매우 간단 .하지만 배후에는 매우 큰 기술적 도전이 가로 놓여 있다 .

월간10억 건을 돌파, Twitter 를 흐르는 메시지 수는 초당 120 만유저끼리의 연결을 나타내는 소셜 그래프조차 메모리에 실리는 양을 넘음

터무니없는 스케일의 데이터를 잇고 있는 것에도 불구하고 0.1 초 이하로 Web 페이지의 표시를 완료시키지 않으면 안됨 . 그 때문에 각 데이터 스토리지는 1~5ms 정도로 응답해야 한다 .

단순한 파티셔닝으로는 해결되지 않는다

• 서비스의 구조가 심플한 Twitter 는 서비스 개시 당초에는 구현도 간단했음

• 각 트윗의 ID 를 프라이머리 키로서 유저 ID 나 텍스트 , 시각 등을 하나의 테이블에 보존 .

• 이것을 마스터 · 슬레이브 구성으로 하는 것으로 read 의 성능을 올린다고 하는 스트레이트한 스캐일링을 실시하고 있었다고 한다 .

단순한 파티셔닝으로는 해결되지 않는다

memcached 에 의한 고속화도 했지만 처음 직면한 과제 - 의외로 디스크 용량의 상한이었다고 한다 .

트윗의 수가 30 억에 가까워져 800 GB 라고 하는 디스크 용량의 상한의 9 할까지 넘었던 시기가 있었다고 한다 . 「 800GB 를 넘는 사이즈의 디스크 어레이를 도입하는 것은 피하고 싶었다」(Kallen 씨 ) 라고 하는 것은 Web 계 기업인 것 같은 발상으로 이것에 대처하기 위해서 파티셔닝을 실시했다고 한다 .

파티셔닝이란 예를 들면 유저 ID 를 짝수 , 홀수로 나누어 2 개의 DB 로 나누어 보존하는 테크닉 . 특정 유저의 트윗을 표시하는 경우 ID 가 짝수인가 홀수인가로 문의해야 할 DB 가 정해지기 때문에 분할하면 할수록 응답성이 올라 하나 하나의 DB 사이즈도 억제 .

• 단지 유저 ID 에 근거한 파티셔닝에서는 특정 ID 를 가지는 트윗을 찾아낼 수 없게 된다 . - 그 ID 의 트윗을 누가 했는지를 모르기 때문이다 .

• 이 때문에 모처럼 파티셔닝 한 복수의 DB 를 모두 검색하지 않으면 안되게 된다 .

• 트윗의 ID 로 파티셔닝 해도 반대의 문제가 일어난다 . 특정 ID 를 가지는 트윗이 어느 파티션에 있을지는 알지만 어느 유저 ID 에 reply한 트윗의 ID 는 결국 모든 파티션을 검색하지 않으면 모르기 때문이다 .

단순한 파티셔닝으로는 해결되지 않는다

시 계열로 파티셔닝

현재의 Twitter 에서는 시 계열의 파티셔닝을 실시하고 있다고 한다 . - 1 월의 트윗 , 2 월의 트윗 , 3 월의 트윗 , 이번 달 (4 월 ) 의 트윗 과 같이 시간 축으로 따라 데이터를 분할하고 있는 것이라고 한다

이 분할 전략은 「당초는 간지 나지 않는 구현이라고 생각되었다」 (Kallen 씨 ) 라고 한다 . - n 개의 파티션에 분할하면 그 액세스 시간의 평균은 O(n) 이 되기 때문이다 . - 그런데 Twitter 라고 하는 서비스에는 Kallen 씨가 「시간적 국소성」 (tempo-ral locality) 이라고 부르는 독특한 액세스 패턴이 있다 . - 「실제로는 대부분의 쿼리는 보다 새로운 정보로의 바이어스가 걸려 있다」 .

대부분 사람의 리퀘스트는 최신의 파티션에 대한 쿼리로 완결한다 . - 모든 유저가 액티브한 것은 아니기 때문에 「어느 유저의 바로 옆의 트윗 20 건」은 복수의 파티션에 거슬러 올라가게 되지만 - 그런데도 이 전략에 의해 액세스 시간의 평균은 사실상 O(1) 이 되고 있는 것이라고 한다 .

향후는 Facebook 에서 개발된 오픈 소스의 Cassandra 를 사용하여 트윗의 ID와 유저 ID 의 각각을 프라이머리 키로 한 테이블을 사용할 계획이라고 한다 .

시 계열로 파티셔닝

메일 ( 이메일 ) 배송과 비슷한 비동기의 구조 「 fan out 」

Twitter 에서 다음으로 큰 문제가 되는 것은 타임 라인이다 .

서비스 개시 당초의 간단한 쿼리 . 화살표로 나타내 보인 부분이 메모리상에 실리지 않게 되어 매우 늦어졌다고 한다

메일 ( 이메일 ) 배송과 비슷한 비동기의 구조 「 fan out 」

이와 같은 스트레이트한 구현에서는 팔로워 수가 증가하면 바로 그때 스케일 하지 않게 된다 . - 메모리에 올라가지 않아서 디스크 액세스가 발생하여 응답성이 떨어지기 때문이다 . - 디스크 액세스의 패널티는 크고 , 1 초 이하로 끝나야 할 페이지의 렌더링이 몇 초 걸리는 것이 된다 .

한층 더 Twitter 의 기술상의 과제를 크게 하고 있는 것은 리스트나 블록 관계 , 혹은 「 @someone 」라고 하는 리플라이에 의해서 메세지의 전달처가 바뀌는 것이다 .

이것은 매우 큰 계산 처리인 한편 「 Hadoop 을 사용하여 50 분이나 걸려서 처리하는 타입의 문제는 아니다」 (Kallen 씨 ). 어디까지나 수 ms 라고 하는 저 지연으로 실시하지 않으면 안 된다 .

메일 ( 이메일 ) 배송과 비슷한 비동기의 구조 「 fan out 」 - 해결 1

「 fan out 」라고 부르는 메일 배송을 닮은 아키텍쳐를 사용하는 것 (fan out 은 한자로 쓰면 “선출” . 바람으로 단번에 흩뿌리는 이미지 ).

각 유저의 타임 라인을 메일의 수신상자와 같이 진단하고 , 거기에 메세지를 전달 . 트윗은 일단 memcached 에 보존되어 그것이 각 수신상자 ( 타임 라인 ) 에 보내지지만 그 배송 처리는 비동기의 오프 라인 처리라고 한다 . 단지 오프 라인이라고 해도 야간 배치와 같은 반나절 단위라는 것이 아니고 초 단위의 지연을 상한으로 한 것 이라고 한다 .

메일 ( 이메일 ) 배송과 비슷한 비동기의 구조 「 fan out 」 - 해결 2

팔로워와 피 팔로워 관계를 각각 다른 데이터로 가지는 것 . - 논리적으로는 다른 한쪽향의 그래프만 가져 오면 충분하지만 , 굳이 「누구를 팔로워하고 있을지」 「누구에게 팔로워 되고 있을지」로 나누어 데이터화해 둔다 . - 데이터의 정합성에 조심할 필요는 있지만 이렇게 해 두면 쿼리는 특정 파티션으로의 액세스로 완결하기 때문에 메모리에 실리지 않는다고 하는 문제도 해소하는 것이라고 한다 .

이러한 구조에 의해 기입 측의 데드락 ( 모든 트윗은 거대한 단일의 데이터 셋에 던진다 ) 을 해소하면서 소셜 그래프가 메모리에 올라가지 않는다고 하는 과제를 넘어서 리얼타임 성 높은 서비스를 실현할 수 있고 있다 .

메일 ( 이메일 ) 배송과 비슷한 비동기의 구조 「 fan out 」

2008년 시점과 현재의 Twitter 의 통계 정보 . 초 평균 30 이었던 트윗 생성 속도는 700 가까이 올라 , 그 결과 최대로 초간 120 만 정도의 메세지를 배송하고 있다고 한다

예를 들면 검색 인덱스에 대해서도 시 계열의 파티셔닝을 실시하고 있기 때문에 검색되는 빈도가 낮은 단어 등에서는 최신 파티션에 인덱스가 없기 때문에 아무것도 히트 하지 않는다고 하는 것이 일어난다 .

- 이 때문에 현재 MySQL 베이스로 가고 있는 검색 인덱스를 시 계열의 파티셔닝 뿐만이 아니라 문서 단위로 파티셔닝 하는 방법이나 , - MySQL 대신에 풀 텍스트 검색 엔진의 「 Lucene 」를 사용한다고 하는 방법을 검토하고 있다고 한다 .

현재 Twitter 가 안고 있는 기술적 과제

원리는 자명해도 정석이 없는 세계

여담이지만 Nick Kallen 씨는 2008년9월에Twitter에 참가한 이전부터 Ruby on Rails 커뮤니티에서는 널리 알려진 해커 .

Rails 의 ORM 층인 ActiveRecord 보다 추상도 높은 쿼리를 구성할 수 있는 「 Named_scope 」를 구현한 것이 Kallen 씨 .

Named_scope 를 사용하면 예를 들면 「공개 플래그가 서 있는 블로그 엔트리」라고 하는 조건에 이름을 붙여 두는 것으로 적집합의 연산을 단적으로 표현할 수 있게 된다 (참고).

이 Named_scope 의 발상을 한층 더 추천 관계 대수에 근거해 Kallen씨가 구현했던 것이 Ruby 용 범용 데이터 쿼리 라이브러리 「 Arel」로 이것은 곧 정식판이 릴리스 되는 차기 Ruby on Rails 의 메이저 버전 업 Ruby on Rails 3 에도 포함된다 .

Arel 는 C# 등에 있는 LINQ 를 닮았고 , 조건을 메소드 체인으로서 연결해 갈 수 있다 .

Arel 라고 하는 쿼리의 추상화를 실시하는 구현을 실시했던 Kallen 씨이지만 Twitter와 같은 실 서비스에서 중요한 것은 오히려 파티셔닝이나 로컬리티의 이용 방법론에는 이렇다 할 단일의 어프로치가 존재하지 않는다고 하는 인식을 가지는 것이라고 지적한다 .

「모든 엔지니어링 상의 해결책이라고 하는 것은 일시적인 것이다」 (Kallen 씨 ).

원리는 자명해도 정석이 없는 세계

출처 : http://www.atmarkit.co.jp/news/201004/19/twitter.html