1. 초당 120만 트윗을 처리하는Twitter 시스템 마이에트 엔터테인먼트 Server Programmer 최흥배 Microsoft Visual C++ MVP Twitter : @jacking75

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

3. Twitter의 서비스는 문자로 처리 하므로 매우간단. 하지만 배후에는 매우 큰 기술적 도전이 가로 놓여 있다. 월간10억 건을돌파, Twitter를 흐르는 메시지 수는 초당 120만 유저끼리의 연결을 나타내는 소셜 그래프조차 메모리에 실리는 양을 넘음 터무니없는 스케일의 데이터를 잇고 있는 것에도 불구하고 0.1초 이하로 Web 페이지의 표시를 완료시키지 않으면 안됨. 그 때문에 각 데이터 스토리지는 1~5ms정도로 응답해야 한다.

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

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

10. 시 계열로 파티셔닝 이 분할 전략은 「당초는 간지 나지 않는구현이라고 생각되었다」(Kallen씨)라고 한다. - n개의 파티션에 분할하면 그 액세스 시간의 평균은 O(n)이 되기 때문이다. - 그런데 Twitter라고 하는 서비스에는 Kallen씨가 「시간적 국소성」(temporal locality)이라고 부르는 독특한 액세스 패턴이 있다. - 「실제로는 대부분의 쿼리는 보다 새로운 정보로의 바이어스가 걸려 있다」. 대부분 사람의 리퀘스트는 최신의 파티션에 대한 쿼리로 완결한다. - 모든 유저가 액티브한 것은 아니기 때문에 「어느 유저의 바로 옆의 트윗20건」은 복수의 파티션에 거슬러 올라가게 되지만 - 그런데도 이 전략에 의해 액세스 시간의 평균은 사실상 O(1)이 되고 있는 것이라고 한다. 향후는 Facebook에서 개발된 오픈 소스의 Cassandra를 사용하여 트윗의ID와 유저 ID의 각각을 프라이머리 키로 한 테이블을 사용할 계획이라고 한다.

11. 메일(이메일) 배송과 비슷한 비동기의 구조 「fan out」 Twitter에서 다음으로 큰 문제가 되는 것은 타임 라인이다. 서비스 개시 당초의 간단한 쿼리. 화살표로 나타내 보인 부분이 메모리상에 실리지 않게 되어 매우 늦어졌다고 한다

12. 메일(이메일) 배송과 비슷한 비동기의 구조 「fan out」 이와 같은 스트레이트한 구현에서는 팔로워 수가 증가하면 바로 그때 스케일 하지 않게 된다. - 메모리에 올라가지 않아서 디스크 액세스가 발생하여 응답성이떨어지기 때문이다. - 디스크 액세스의 패널티는 크고, 1초 이하로 끝나야 할 페이지의 렌더링이 몇 초 걸리는 것이 된다. 한층 더 Twitter의 기술상의 과제를 크게 하고 있는 것은 리스트나 블록 관계, 혹은 「@someone」라고 하는 리플라이에 의해서 메세지의 전달처가 바뀌는 것이다. 이것은 매우 큰 계산 처리인 한편 「Hadoop을 사용하여 50분이나 걸려서처리하는 타입의 문제는 아니다」(Kallen씨). 어디까지나 수 ms라고 하는 저 지연으로 실시하지 않으면 안 된다.

13. 메일(이메일) 배송과 비슷한 비동기의 구조 「fan out」 - 해결 1 「fan out」라고 부르는 메일 배송을 닮은 아키텍쳐를 사용하는 것(fan out은 한자로 쓰면 “선출”. 바람으로 단번에 흩뿌리는 이미지). 각 유저의 타임 라인을 메일의 수신상자와 같이 진단하고, 거기에 메세지를전달. 트윗은 일단 memcached에 보존되어 그것이 각 수신상자(타임 라인)에 보내지지만 그 배송 처리는 비동기의 오프 라인 처리라고 한다. 단지 오프 라인이라고 해도 야간 배치와 같은 반나절 단위라는 것이 아니고 초 단위의 지연을 상한으로 한 것 이라고 한다.

14. 메일(이메일) 배송과 비슷한 비동기의 구조 「fan out」 - 해결 2 팔로워와피 팔로워 관계를 각각 다른 데이터로 가지는 것. - 논리적으로는 다른 한쪽향의 그래프만 가져 오면 충분하지만, 굳이 「누구를 팔로워하고있을지」 「누구에게 팔로워 되고 있을지」로 나누어 데이터화해 둔다. - 데이터의 정합성에 조심할 필요는 있지만 이렇게 해 두면 쿼리는 특정 파티션으로의 액세스로 완결하기 때문에 메모리에 실리지 않는다고 하는 문제도 해소하는 것이라고 한다. 이러한 구조에 의해 기입측의 데드락(모든 트윗은 거대한 단일의 데이터 셋에 던진다)을 해소하면서 소셜 그래프가 메모리에 올라가지 않는다고 하는 과제를 넘어서 리얼타임 성 높은 서비스를 실현할 수 있고 있다.

15. 메일(이메일) 배송과 비슷한 비동기의 구조 「fan out」 2008년 시점과 현재의 Twitter의 통계 정보. 초 평균 30이었던 트윗 생성 속도는 700 가까이 올라, 그 결과 최대로 초간 120만 정도의 메세지를 배송하고 있다고 한다

16. 현재 Twitter가 안고 있는 기술적 과제 예를 들면 검색 인덱스에 대해서도 시 계열의 파티셔닝을 실시하고 있기 때문에 검색되는 빈도가 낮은 단어 등에서는 최신 파티션에 인덱스가 없기 때문에 아무것도 히트 하지 않는다고 하는 것이 일어난다. - 이 때문에 현재 MySQL 베이스로 가고 있는 검색 인덱스를 시 계열의 파티셔닝 뿐만이 아니라 문서 단위로 파티셔닝 하는 방법이나, - MySQL 대신에 풀 텍스트 검색 엔진의 「Lucene」를 사용한다고 하는 방법을 검토하고 있다고 한다.

17. 원리는 자명해도 정석이 없는 세계 여담이지만 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를 닮았고, 조건을 메소드 체인으로서 연결해 갈 수 있다.

18. 원리는 자명해도 정석이 없는 세계 Arel라고 하는 쿼리의 추상화를 실시하는 구현을 실시했던 Kallen씨이지만 Twitter와 같은 실 서비스에서 중요한 것은 오히려 파티셔닝이나로컬리티의 이용 방법론에는 이렇다 할 단일의 어프로치가 존재하지 않는다고 하는 인식을 가지는 것이라고 지적한다. 「모든 엔지니어링 상의 해결책이라고 하는 것은 일시적인 것이다」(Kallen씨).

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