트위터가 어떻게 개발되었을 까? 아래는 타임지에 실린 트위터의 기사이다. 타임지에서 트위터가 우리의 삶을 어떻게 바꾸어 놓을 것인가 에 대한 기사를 실었다. 이처럼 현재 트위터같은 실시간 웹은 온-오프라인을 넘나들면서 새로운 문화를 만들어 가고 있다.

사용자 삽입 이미지

개인적으로도 맥장비에는 Twitterrific 을 설치하고 윈도우의 FireFoX에는 Twitter Extension을 설치하여 사용하고 있다. 분명한 것은 트위터가 폭발적으로 성장하고 있고 앞으로도 성장할 것이라는 것이다. 개인적으로는 무선 환경 특히 , SMS 서비스로 길들여진 실시간 정보 교환 문화가 140개의 문자로 소통하는 트위터를 성장시킨 밑거름이 아닐까 싶다. 지금도 인터넷에서는 트위터로 , 현실에서는 핸드폰 문자와 포스트잇으로 의사를 교환하곤 한다. 

사회.문화적 관점을 떠나 개발자 입장에서 트위터가 어떻게 개발이 되었을까 고민을 하며 그 기술을 추적을 해보았다. 특히, 트워터는 실시간에 대용량 데이타에 대한 Push 서비스를 제공해야 하기 때문에 서비스의 구조와 운영 기술은 아주 중요하다. 

먼저 트위터의 아키텍쳐에 대한 전반적인 소개 자료를 보면 트워터는 아래와 같은 기술을 사용하여 개발되었다.

-개발 언어 : Ruby on Rails , 자바 , Scala
-시스템 관리 : Puppet , 오픈소스 서버 관리 툴
-Cache : Memcache , 오픈소스 분산 객체 캐쉬 시스템(트워터의 성능을 위해 중요한 역할을 한다.)
-H/W : X86 기반 리눅스
-DBMS : MySQL
-Web Server : Apache
-서비스 특징 :  일반 웹 서비스처럼 웹 페이지를 중심으로 서비스를 제공하는 것이 아니라 트워터 서버에서 API를 제공하고 이를 통해 웹과 디바이스등 다양한 생태계를 구성하고 있다.

트위터의 경우 웹 프론트는 성능의 이유때문에 Ruby on Rails를 사용하고 백엔드는 자바를 사용한다. 특히, 자바를 사용할 때 Scala 를 함께 사용한다.  Scala는 자바 등의 언어와 함께 사용하여 보다 코드는 간결하게 만들어주는 개발 언어이다. 간략히 테스트 코드는 보면 스칼라 코드에서 직접 자바 라이브러리를 호출하여 사용할 수 있다. 이렇게 자바와  Scala , Memcache 를 사용하여 초기 서버를 구축하여 2008년까지 사용하였다.

이렇게 개발된 시스템의 현재 상황은 다음과 같다.

- 초당 600개의  Request를 처리함
- 초당 평균 200-300 커넥션( 초당 800 커넥션 까지 확장 가능함 )
- MtSQL 은 초당 2,400 Request를 처리함
- 웹 서버는 Mongrel 이고 180개의 레일스 인스턴스를 운용
- 8 코어 하드웨어 박스에 1 MySQL 서버와 1 슬래이브 구성( 슬래이브는 통계 및 레포팅용으로 데이타 마트 구성 )
- 예외 상황에 대비하여 30개 이상의 추가 프로세스를 운영중
- Sun X4100 모델, 8대
- 평균 DB에서 처리 시간 : 50-100 밀리초
- 16GB Memcached

트위트 사이트보다 트위트의 API가 10배 이상 호출이 많다고 한다. 이러한 상황에서 최대한의 성능을 내기 위해 당연히 DB를  denormalization하여 테이블간의 죠인을 줄이고 , 메모리 캐쉬에 모든 데이타를 올려놓아서 성능을 보장한다.

과거 DBMS 수업시간에 DBMS Normalization을 배우고 오라클에 종속적인 지식을 갖고 있는 DA(Data Architecture)가 테이블과  SQL을 설계하고 곳에서는 상상할 수 없는 일이다. 왜 Normalization을 안하냐고 당장 공격이 들어올니까.. 그게 그 분들의 밥줄이기도 하지만... 얼추 계산해 보니 하드웨어와 기타 라이센스 해서 2억 정도면 서비스를  구축하지 않을까 싶다. 나머지 상용제품은 눈을 씼고 찾아볼 수 없다... 쩝.. 외국 회사의 장비와 소프트웨어를 구매해야 데 많은 비용을 써야 하는 입장에서는 가슴이 아프다..

Posted by 박재현
,

  서비스 플랫폼 구축을 위한 솔루션은?

새벽에 오랜만에 씩씩거리며 자료를 찾아 보고 정리하는 것 같다^-^.

웹 서비스 플랫폼을 구축할 때 여러분은 어떤 솔루션을 사용할 것인가? 상용 제품 또는 오픈소스. 이 두 대안중 하나를 선택할 때 어떤 기준으로 결정할 것인가? 가격,성능, 그리고 기술지원. 언듯 가격과 성능면에서 보면 오픈소스가 구미에 당겨도 실제 오픈소스 솔루션을 사용한다는 것은 쉽지 않은 결정이다. 왜냐하면 그만큼 오픈소스를 효과적으로 다루는 유능한 개발자가 확보돼야 하기 때문이다. 반대로 이야기하면 기술지원의 문제가 발생하기 때문이다. 그러나 찾아보면 의외로 오픈소스 커뮤니티의 집단지성이 기술지원을 해주고 , 오픈소스 컨설팅 회사와 전문가를 쇼셜 네트웍을 통해 쉽게 만날 수 있다.

현재 성공적으로 서비스를 운영하고 있는 서비스들의 구축 솔루션을 조사해 보았다 - 아마존, 구글, 유투브, 플리커 , 트위터. 이들 업체들이 공통적으로 사용하는 솔루션만 뽑아보면 - Linux , Java , Apache , MySQL ,Memcached 등이 자주 애용된다. 사용제품은 아마존의 DB가 오라클을 사용하고 있는데 아마 상품 DB에 사용되고 SimpleDB서비스에는 MySQL이 사용될 것으로 예상된다.

그리고 아마존 웹 서비스의 API 관리를 위해 Jboss를 사용하고 있는 것이 눈에 띠인다. 아마존의 경우 오픈 API만으로 플랫폼 사업을 하기때문에 오픈 API의 관리와 모니터링용으로 Jboss를 소프트웨어 버스로 이용하는 것으로 보인다.

상황이 이 정도면 오픈소스를 채택하는 데 있어 선입관을 가릴 필요가 없어 보인다. 국내 유력 통신사인 S사를 비롯하여 현재 많은 서비스 회사들이 엄청한 구축 및 유지보수 비용을 줄이기 위해 기존 상용 솔루션을 오픈소스로 전환하고 있다고 한다. 어차피 오픈소스가 피할 수 없는 선택이라면 빠른 도입과 준비야 말로 많은 경쟁력을 확보하는 지름길일 것이다.

마지막으로 첨언하면  기업들은 결사적으로 오픈소스 개발자와 엔지니어를 양성하고 이들에게 좋은 대우를 해주는 것이 바로 IT 관련 비용 절감을 이루는 첫번째 길이라는 사실을 기억하는 것이 좋을 것이다.

1. 아마존
Linux
Oracle
C++
Perl
Mason ( 멀티 에이전트 시뮬레이션 라이브러리)
Java
Jboss ( 서비스 버스 )
Servlets

2. 유튜브
Apache
Python
Linux (SuSe) 
MySQL
psyco(python to C 동적 컴파일러)
lighttpd ( 비디오용 ) 

3. 플리커
PHP
MySQL Shards
Memcached (캐쉬)
Squid ( HTML과 이미지를 위한 리버스 프록시 웹 캐쉬)
Linux (RedHat) Smarty
Perl PEAR (XML 과 Email 파싱용)
ImageMagick(이미지 프로세싱용)
Java(노드 서비스용)
Apache SystemImager (Deployment용)
Ganglia ( 분산 시스템 모니터링)
Sucon ( 손쉬운 Deply를 위해 subversion 레파지토리에 필수적인 시스템 설정 파일들을 저장하기 위해 사용)
Cvsup ( 네트웍상의 파일들을 분산하고 업데이트하기 위해 사용)

4. 구글
Linux
Python, Java, C++

5. 트위터(Twitter)
Ruby on Rails
Erlang
MySQL
Mongrel ( 하이브리드 Ruby/C HTTP 서버 - 작고,빠르고,보안에 중점을 둠)
Munin
Nagios
Google Analytics
AWStats( 실시간 로그 분석용 )
Memcached

'Architecture' 카테고리의 다른 글

IoT 클라우드 레퍼런스 모델  (0) 2014.07.16
Ajax Framewirk Review  (0) 2009.05.02
구글 Gear에 대한 이해를 위한 도움말  (2) 2007.06.09
2007 Web 2.0 korea 발표 후기  (3) 2007.03.29
REST Architecture  (0) 2007.03.25
S/W Development on the Web Platform  (0) 2007.03.25

Posted by 박재현
,