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

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
| 1 |