데이터 센터의내용은 자사제품

Twitter는 주로 2008년에 실시된 인프라 부분의 쇄신에 의해서 「빈번히 다운타임에 빠지는 신흥 서비스」에서 「가끔 다운타임에 빠지는 Web서비스」로 다시 태어났다. 유저 수의 급격한 증가에 인프라가 따라 잡았다고 말할 수 있을 것이다.

 

실제 Web사이트 감시 서비스를 다루는 스웨덴의 핑담의 관측에 의하면 Twitter의 연간 가동률은 2007년의 98.08%에 비해 2009년은 99.76%이라는 2% 가깝게 개선. “쓰리 나인에 가까워지는 곳까지 왔다.

 

우선 데이터 센터와 통신회선은 2007년에 NTT 미국의 기업용 서비스를 계약. 서버는 미 썬마이크로시스템의 랙 마운트형 서버 「Sun Fire X4100」를8,  데이터베이스 용으로 8 CPU코어의 서버를 이용중인 것을 2007년 개발자를 위한 회의에서 분명히 하고 있다.

 

그 후 CPU코어 수의 증강 등을 실시하여 데이터 센터에 있어서의 전력 이용 효율 향상이나 점유 면적의 삭감을 실현했다고 한다. 현재의 구체적인 구성은 비공개이지만 Web서버에 염가의 범용 서버를 다수 늘어놓고 데이타베이스의 운용에는 비교적 고성능 서버를 사용한다고 하는 Web 서비스의 연구 최종 단계로서는 일반적인 구성을 뽑고 있다.

 

 

 

데이타베이스에 분산 캐쉬를 다용

유저수의 증가에 수반해 데이터 센터나 네트워크를 강화하는 한편 방대한 유저의 트윗을 읽고 쓰기 하기 위한 기반 소프트웨어의 신규 개발을 병행해서 진행해 왔다.

Twitter의 구조에서는 어느 유저의 기사 투고가 수백, 수천의 유저의 타임 라인의 갱신을 수반한다

단순한 블로그이면 유저가 기사를 추가했다고 해도 고쳐 쓰는 것은 그 유저의 페이지 뿐이다. 그런데 Twitter에서는 구독 관계에 있는 유저 모든 홈 화면을 갱신할 필요가 있다.

 

Twitter의 최초의 시스템은 마츠모토 유키 히로씨가 개발한 프로그램 언어 「Ruby」를 베이스로 한 Web어플리케이션 체제 「Ruby on Rails(RoR)를 사용해 개발 되었다. RoR은 개발 환경을 포함한 종합적인 생산성이 매우 좋다. 그러나 RoR은 대규모 서비스를 유지하는 성능을 노린 체제는 아니다. 거기서 Twitter에서는 데이타베이스의 부하를 경감하는 캐쉬 기구에 개선을 더했다.

 

RoR를 기반으로 Twitter를 시작한 당초는 Twitter용 서비스의 개발자 전용으로 공개했던 API로부터의 호출 순서(API)만을 캐쉬하고 있었다. 데이타베이스는 비교적 성능이 높은 서버 1대로 운용하고, 데이타베이스의 내용을 꺼내고 싶은 형태로 하여 서버의 메모리상에 두는 분산형 캐쉬 서버 소프트 「Memcached」로 고속화하고 있었다. 데이타베이스로부터 꺼내는 데이터를 미리 읽기가 고속인 메모리에 놓아두고, 또한 복수의 캐쉬 서버로 병렬처리 하는 것으로 응답 속도를 높이는 것이다.

 

한편 API의 액세스와는 달리 Web 브라우저로부터의 이용은 그때마다 데이타베이스로부터 읽어내고 있었다. 거기서 모든 액세스를 복수의 Memcached 서버로 처리하는 구성으로 변경. TwitterWeb페이지나 Twitter 클라이언트가 자주 이용하는 데이터에 맞추고, 데이타베이스의 구성이나 색인부 방법을 재검토했다.

 

캐쉬 기구는 MemcachedRoR용으로 자사개발 한 「cache-money」라는 복수의 캐쉬용 소프트웨어를 조합해 기본적으로 모든 입출력을 메모리상에서 실시하는 구성으로 바꾸고 있다. 액세스를 받아들이는 부분에 대해서는 세지 의 소프트웨어를 자사에서 개발 하여 대처했다.

 

그 후 트위터는 RoR로 구축하고 있던 부분의 대부분을 「Scala」라고 하는 프로그램 언어로 고쳐 썼다. ScalaJava 가상 머신을 실행 환경으로 한다. 병렬처리에 향하는 프로그램 언어로서의 특성과 대규모 시스템으로 실적이 있는 Java 가상 머신의 신뢰성을 동시에 시스템에 받아들여진다.

 

 

팔로어 수의 상한으로 시스템 부하를 조정

 

트위터는 시스템의 개선에 의해서 유저수의 증가에 의한 시스템이나 네트워크의 부하를 경감하면서 각종 설정치의 상한치를 바꾸는 것으로 부하 그 자체를 내리려고 시행 착오 하고 있다. 그 대표 예는 보충수의 상한이다. 보충 관계의 수가 적으면 타임 라인을 고쳐 쓰는 부하가 줄어 들기 때문이다.

 

최초의 보충수 제한을 시작한 것은 2008 8. 트위터는 상한을 2000 유저로 설정했다. 2000 이상의 보충수가 있는 어카운트에서는 「팔로어수×1.1」에 제한, 1일 상한치를 1000으로 변경했다. 보충수를 상한치 가득까지 급격하게 늘리는 어카운트는 Twitter의 자원을 낭비하는 스팸 메일 행위라고 보고 감시 · 삭제하고 있다.

 

스팸 메일과 같이 트위터를 괴롭힐 수 있는 것이 Twitter에 대한 DDoS(distributed denial of service) 공격이다. 최근에는 2009 8월에 3시간에 걸쳐서 다운하는 사태에 빠졌다. NTT 미국과 공동으로 대상 트래픽을 차단하는 등의 대책을 강구했지만 근본적인 해결은 어렵다.

 

 

개발자에 API를 개발, 인증도 간략화

트위터는 Twitter의 기능을 외부에서 호출하는 API를 넓게 공개하고 있다. 이 결과 많은 Twitter용 클라이언트 소프트웨어 등이 태어난 것은 상술한 대로다. 이것이 유저수의 증가에도 기여하고 있다.

 

공개되고 있는 API는 어느 유저의 타임 라인을 취득하는 것, 트윗을 투고하는 것, 풀 텍스트 검색을 실시하는 것 등 많다. 수천만 유저가 날마다 낳는 Twitter 내의 데이터를 외부의 Web 서비스나 클라이언트 소프트로부터 완전하게 활용할 수 있다.

 

2010 1 6일에는 20094월부터 베타 테스트를 계속해 온 「Streaming API」라고 부르는 새로운 API를 공개했다. API는 접속을 유지한 채로 갱신 데이터를 푸쉬 하는 것으로 정기적으로 Twitter API를 호출할 필요가 없어진다.

 

또 통상의 API와 달리 Streaming API에서는 호출 회수에 제한을 마련하지 않았다. 통상의 API에서는 시스템 부하를 억제하기 위해 API의 호출 회수를 1분간 당 100회 전후에 제한하거나 트윗 투고 회수를 1 1000건으로 제한하는 등으로 시스템에 부하를 조절하고 있다.

 

 

API 접근 제한에 OAuth 사용

API와 대등하게 그 액세스 제어 구조도 클라이언트 소프트웨어 등의 다양화를 지지한다. Twitter 상에서 액세스에 제한이 있는 데이터나 기능은 유저 마다 인증이 필요하게 된다. Twitter 유저라면 어카운트나 패스워드의 입력이 필요로 한 적이 있을 것이다.

 

API의 인증을 간략화 하기 위해서 Twitter는 「OAuth(오스)」라고 부르는 프로토콜을 채용하고 있다. OAuth는 개방적인 액세스 제어 프로토콜로 어느 서비스로부터 있는 서비스에 유저의 권한을 이양하는 구조를 가진다. OAuth를 이용한 프로그램은 하나 하나 어카운트와 패스워드를 입력하지 않아도 그 유저의 권한으로 Twitter에 액세스 할 수 있게 된다. 예를 들면 읽고 쓰기의 허가를 얻은 프로그램은 Twitter에 기사 투고나 삭제 등 Twitter 어카운트로 가능한 조작을 모두 실시할 수 있다.

 

제휴 서비스가 독자적으로 인증 기구를 가지지 않고 끝나는 OAuth는 서비스 제공자에 있어서도 유저에 있어서도 인가 발행 조작 허들이 낮다. 특히 읽고 쓰기 권한이 필요로 하는 경우 「악의가 있는 사이트가 아닌가?」 「자신을 대신하여 팔로어에게 다이렉트 메세지를 송신하는 스팸 메일 행위를 하지 않는가?」라는 것을 신중하게 판단하는 것이 요구된다.

 

 

출처 : http://itpro.nikkeibp.co.jp/article/COLUMN/20100602/348760/?ST=network

 

 

 

저작자 표시
신고
by 흥배 2010.08.30 09:00


출처 : http://itpro.nikkeibp.co.jp/article/COLUMN/20100602/348760/?ST=network&P=2  그림 4


OAuth에 대해서 트위터에서 @jgkim999 님이 아래의 정보를 알려주셨습니다.
Daum OAuth 인증  https://apis.daum.net/oauth/main/welcome
OAuth프로토콜 관점에서 본 OAuth 인증과정  http://dev.springnote.com/pages/1083108
OAuth library functions   http://liboauth.sourceforge.net/

저작자 표시
신고
by 흥배 2010.08.27 09:00

Twitter의 특징은 (1) 리얼타임에 가까운 커뮤니케이션에도 어카이브(archive)적으로도 사용할 수 있는 심플함과 유연함 (2) 클라이언트의 다양성이나 외부 서비스와의 제휴가 쉬움.

 

심플, 다양화로 유저를 늘린다

우선 블로그나 SNS(소셜 네트워킹 서비스)등에 비교해 투고의 허들이 낮다. 「타이틀 불요」로 「1 140문자 제한」 때문에 생각한 것을 메모와 같이 자꾸자꾸 써 갈 수 있다. IPv6은 필요한가?」라는 기술론으로부터 「오피스 뒤의 도시락은 맛있다」등 정신 없는 화제까지 지금까지 텍스트 데이터로서 정착하기 어려웠던 군소리를 유저로부터 꺼내는 것에 성공하고 있다.

 

각 유저가 투고한 트윗은 유저끼리의 관계에 의해서 여러 가지 가치를 가지게 된다. Twitter에서는 유저끼리가 「팔로워」라고 부르는 구독관계를 묶는 것으로 팔로워한 유저의 트윗이 자신의 홈 화면에 시계열로 줄 선다. 시계열로 줄선 트윗의 모임을 「타임 라인」이라고 부른다.

 

유연한 사용법을 지지하는 것이 API를 개방해 외부 서비스나 개발자를 불러 들이는 시책이다. Web 브라우저 뿐만이 아니고 전용의 클라이언트 소프트나, iPhone 등의 스마트 폰, 휴대 전화로부터 투고할 수 있다. 행선지 등에서도 용이하게 중얼거릴 수 있기 때문에 투고수가 증가해 그 결과 한층 더 유저가 증가한다고 하는 호순환이 태어나고 있다.

 

여기에서는 전술의 특징에 따라서 Twitter해부해 나간다. 이하에서는 「심플한 서비스를 신속히 전개하기 위한 구조」를 다음 번에는 「급속한 유저수의 증가에 견딜 수 있는 시스템」과 「다양한 클라이언트로부터의 투고의 실현」을 취급한다.

 

 

 

클라우드 활용으로 확장성 있게

 

Twitter를 구성하는 서비스랑 소프트웨어를 보면 그 인프라 부분의 대부분이 외부 서비스에 의존하고 있는 것을 알 수 있다. 구체적으로 아이콘 그림이나 JavaScript등 각종 파일을 다루기 위해 아마존닷컴의 자회사인 아마존 웨이브 서비시즈의 클라우드 서비스 ‘Amazon S3’를 활용하고 있다.

 

 

유료 서비스

Amazon S3

온라인 스토리지 서비스

 

Amazon CloudFront

콘텐츠 배신 서비스

무료 서비스

Google Analystics

액세스 분석 서비스

오픈 소스

Apache

HTTP 서버

 

Cache-money

Ruby on Rails용 캐시 서버 자사 개발

 

Kestrel

메시지 캐싱 서버 자사 개발

 

libnencached

Memcached 클라이언트 자사 개발

 

Memcached

분산 메모리 캐시 서버

 

Mongrel

HTTP 서버

 

MySQL

RDB

 

Nagios

운용감시 소프트

 

Ruby on Rails

Web 애플리케이션 프레임워크

 

Valgrind

시스템 분석 툴(디버거)

 

Amazon S3 HTTP/HTTPS로 파일을 다루는 온라인 스토리지 서비스.

용량은 무제한으로 저장한 파일의 데이터 량과 입출력 회수, 네트워크 전송량에 따라서 과금이 발생하는 종량제 요금 서비스이다.

Amazon S3를 사용하는 것으로 매일 증가하는 Twitter 내의 아이콘이랑 배경 그림등을 저장하는 스토리지의 초기 투자를 낮추고 쾌속한 서비스 전개가 가능하게 되었다. 유저 수가 급증하여도 스토리지 기기의 증설에 쫒기는 일은 없다.

 

 

 

아마존의 CDN 서비스로 국내 배신

 

서비스의 쾌속적인 전개만이 아닌 유저에게 사용하기 쉬운 환경을 실현하기 위해서도 외부의 클라우드 서비스를 활용하고 있다. 실은 국내의 유저가 Twitter을 이용할 때 그 트래픽의 대부분은 일본 국내에서 처리하고 있다. 아이콘 그림이나 JavaScript를 둔 장소에 Amazon S3의 옵션 메뉴에 있는 CDN 서비스 ‘Amazon CloudFront’를 시용하여 네트웍 딜레이를 작게한다.

 

CloudFront를 병용하는 것은 데이터의 복사를 보내는 곳의 가까운 곳 이를 테면 유저에게 가까운 장소에 두는 것이 목적이다. 미국의 스토리지와 일본 사이는 약 8000km 정도 떨어져 있다. 빛에 가까운 속도로 전달하는 전기신호라도 일본과 미국을 왕복하는 시간(RTT:round trip time) 180밀리세컨드가 걸린다.

 

CloudFront 2009 12월 시점에서 미국내의 8 지여그 유럽의 4 지역, 아시아의 2 지역(도쿄와 홍콩)에 배신 서버를 두고 있다. Amazon S3 내의 파일에 액세스 하면 유저는 가장 가까운 배신 서버에 안내된다.

 

실제 일본에서 Twitter를 사용할 때 통신 내용을 보면 ‘twimg.com’이라는 도메인에 액세스하는 것을 알 수 있다. RTT 16밀리세컨드 전후.

 

 

 

출처 : http://itpro.nikkeibp.co.jp/article/COLUMN/20100602/348733/?ST=network&P=1

 

 

 

저작자 표시
신고
by 흥배 2010.07.27 09:30
지난주 회사의 팀 스터디에서 발표한 것입니다.




초당 120만 트윗을 처리하는 twitter 시스템
View more presentations from jacking.




저작자 표시
신고
by 흥배 2010.06.28 10:49
회사에서 팀 스터디 때 발표한 것입니다.


저작자 표시
신고
by 흥배 2009.08.14 23:50
| 1 |

티스토리 툴바