블로그 이미지
JEEN

서울에 사는 꽃청년의 IT찌질모험기

Rss feed Tistory
IT/Perl 2010.03.26 12:13

[ DeNA Tech ] 에 다녀왔습니다.

  원래 어제 써야되는 데, 할 일이 있어서 못 쓰고 오늘 퇴근길에 맞춰서 이렇게 써봅니다.

  DeNA 는 일본 모바일 게임의 양대산맥 중에 하나라고 말할 수 있는 규모의 회사이며... 그런 규모의 플랫폼을 Perl 로 만들었다는 얘기가 이 Tech Seminar 의 주된 이야기라고 할 수 있습니다.

  # Inside mbga Open Platform API // zigorou

  우선 Catalyst 를 쓰고 있다는 얘기. 하지만 Catalyst 는 단순히 Dispatcher 로만 쓰고 있으며, Catalyst::Plugin::* 은 거의 사용하지 않는다고 합니다. 역시 대규모 시스템 상에서 Moose 는 어울리지 않는답니다.
  lighttpd + FastCGI 로 로 동작하며, FastCGI 는 daemontools 로 띄우고 있다고 합니다. 
 stage, sandbox,service 등등의 개발환경, product 모드 전환등을 이를 통해서 하고 있다고 하는 군요.
 MySQL Storage 는 기본적으로 InnoDB 를 사용하고 있으며, 검색계통의 데이터가 담긴 애들은 MyISAM 을 사용하고 있답니다. DB 구성은 Master x 1, Slave x 3, Backup x1 로 하나의 클러스터를 구성하고 있다고 하네요.
  Memcached 데이터 업데이트를 위한 Trigger 전용 슬레이브가 있다고 하네요. 특정 slave 에만 Trigger 를 집어넣고 데이터갱신이 발생했을 시에 그 데이터만 테이블로 뽑아내며 memecahed 에 집어넣는다고 들었습니다.
  일부분에서 Shard 도 하고 있다네요.

  소스는 SVN 을 사용하고 있지만, 브랜치 관리 등이 난잡해지기 시작해서 슬슬 git 으로 옮길거라고 합니다.
  어플 테스트는 Test::mysqld, Test::TCP 같은 것을 통해서 테스트를 거치고, 테스트가 무사히 마치면 각 단계별로 Deploy, Deploy, Deploy 한다고 합니다. 이때 Deploy 툴로 Archer 를 사용하구요.

  CPAN 모듈관리는  rpm +  yum repository 로 한다고 합니다. 어떤 장점이 있는지는 모르겠지만 이것은 한번 조사해봐야되겠네요.  그리고 서비스 감시는 nagios, 로그는 syslog-ng 를 사용한다고 하네요.

  그리고 이에 대한 Architecture 에 관한 내용으로, Message, People, Appdata, Activity, Avatar 등의 수많은 API 가 존재하고 이때 참조가 많은 API 는 여러가지로 DB 에 부하가 많이 걸려서 이것저것 고생했다는 얘기가 주입니다. 
  이때 Query 를 분할할 수 있다면 분할하며, 그렇지 못하면 CREATE TEMPORARY TABLE 로 데이터를 한번에 bulk insert 한다고 하네요. 물론 이때 유저별 쓰기권한 문제등이 있어서 이건 여차저차 조정하고 있다는 얘기
  Message API 의 경우는 SPAM 이 죽을 정도로 많아서 적당한 빈도로 제한을 걸고 있다네요. 내부 API 로 Q4M에 하루 2000만 정도의 insert 가 발생한다고 합니다. 
  Q4M 에서는 Message Worker 와 Message Cache Worker 가 동작한다고 합니다. 이때 Worker 는 Pararrel::Prefork 를 사용하며 이 Worker 프로세스 역시나 daemontools 로 관리하고 있답니다.

  DB Profiling 으로는 스스로(zigorou) 만든 DBIx::ProfileManager 모듈을 사용하며, 이때 일정 실행시간이 경과된 것만을 로그에 남긴다고 합니다. 

  MySQL Partitioning 에 대한 얘기도 나왔네요. 1일단위로 분할을 한다고 합니다. 유효기간이 지나버리면 DROP PARTITION 해버린다는 뭐 그런 얘기였습니다.
  사실 슬라이드를 보면서 이래저래 움직임을 설명해야 되는데, 글만으로는 역시 뭔가 설명하기 미묘합니다.;;;

 # Inside Mixi Platform // webloo

  DeNA Tech Seminar 에 Mixi 사람이 발표하러 왔습니다. 아무래도 동종업계의 비슷한 시스템의 이야기니까 참고가 많이 되었습니다. :-)  Mixi 라면 일본 최고의 SNS 사이트로 유명하죠. 그만한 규모만큼이나 내부 시스템도 수많은 부하에 견뎌내게 설계해야 되니...

 OpenSocial 에 관한 이야기입니다. PC 에서는 OpenSocial JS API를 사용하는데, Mobile 상에서는 JS 를 못쓰니 RESTful API 를 통해서 Gadget 을 받아오는 그런 구조랍니다. 
  Gadget XML, People & Friends, Activities, Persistence, Album, LifeCycle API 등이 존재하며 이것들은 OpenSocial 스펙을 따른것이라고 합니다(현재 0.8의 스펙이라고 하더군요)
  거기에 Mixi 의 API 를 더 투입해서 GPS 나 결제기능을 추가했다고 합니다. 

  맨 앞의 프론트엔드 서버는 Apache 로 Reverse Proxy 로 사용하며 Mixi 의 Proxy App 서버를 통해서 파트너 어플개발 회사와 통신을 하며 이때는 Squid 를 사용한다고 합니다. 이미지 캐쉬하는데 쓰인답니다.

  Mixi 측의 Proxy 서버에서는 UID나 쿠키정보를 없애거나 Image/Flash 등의 작업을 하는 등등의 작업을 파트너 어플 서버들과 통신을 통해서 처리한다고 하네요. 그외 Request/Response 정보를 이래저래 필터링 한다거나...

  AppData API의 write 는 DB 가 아니라 Tokyo Tyrant 를 사용한다고 합니다. 
  Devel::NYTProf 를 통해서 Profiling 을 하고 있구요. 대개 Perl 을 잘 활용하는  회사들이 하는 것들은 아무튼 다 합니다;

  재미난 부분은 파트너 어플을 제작하는 회사의 서버인데. 대부분이 PHP 나 Java 로 작동하며, MySQL 을 사용하며 memcached 같은 것을 사용하지 않는다고 하네요. 거기에 뭐 이런저런 무리수를 둬서 응답이 늦어지거나 해서 타임아웃되어버리는 경우가 있다고 합니다. 

 Plack::Server::AnyEvent::Prefork + Coro::AnyEvent 를 통해서 내부 API 를 비동기적으로 처리한다고 합니다. 아파치에 mod_perl 을 붙여서 사용하는데 이때 block 이 잦아서 금방금방 시스템의 부하가 커진다고 해서 이부분을 바꿔가고 있답니다. 거의 65대 정도의 서버가 앞단에서 apache + Plack 으로 움직인다고 합니다.

  CDN 도 한답니다. 정적인 파일을 고대로 쓰자니 이래저래 타임아웃되는 경우도 있고 해서, 필요한 파일은 그냥 업로드해서 그걸 사용하도록 유도한답니다. 이때 Varnish 를 프론트엔드에 둬서 마찬가지로 캐쉬처리를 한다고 하네요.

  하루에 수천만 에서 수억의 접속을 견디며 이 수치는 보통 1초에 천단위의 접속이 이루어지고 있다고 하네요. 최대 5-6천가는 듯...
  Mixi 플랫폼 상에서 게임을 개발해서 꽤 많은 수입을 파트너회사들이 거두고 있다고 합니다. 어떤 파트너사는 100대의 서버를 사용하며 어플을 돌리는 규모라고 하니... ㄷㄷㄷ


  # Inside MBGA Open Platform - Gadget Server - // hide-k

  뭐 내용은 위랑 대동소이합니다.
  재미난 점은 작년 11월 한달도 안되는 작업기간에 어떻게 완성시켰다고 하네요.

  역시 Plack 얘기입니다.
  lighttpd + Plack::Server::FCGI 를 사용한답니다. 서버당 300개의 프로세스를 띄워놓는다네요.
  그래서 하루에 한대의 서버에 대략 5-6백만 Request 가 발생한답니다.
  Class::Trigger 를 사용해서 Pluggable 하게 만들었고, 
  Text::MicroTemplate , HTTP::MobileAgent , HTTP::StickyQuery::DoCoMoGUID, OAuth::Lite, HTML::Filter::Callbacks,  DBIx::DBHResolver , Log::Dispatch , Test::TCP 같은 모듈을 사용했다고 합니다. 

  Performance Check 는 Unix::Getusage 같은 걸 사용한다고 하네요.
  그리고 lighttpd 운영상 여러가지 문제가 있어서 버젼업했다는 얘기. FastCGI 로부터의 Request 를 걍 쌩까버리는 경우가 있었답니다. (사실 저희 서비스에서도 발생했었는데.. 2년묵은 버그였는데 알고보니 어플 섭 문제였기도 했지만...)

  아무튼 이게 결론은 Perl 얘기입니다. 일본 모바일업계의 대표적인 두 기업이 Perl 을 이렇게 사용하고 있고, 작년 YAPC 무렵부터 스펙정하고 만들기 시작한 PSGI/Plack 은 이미 실전에서 이렇게 잘 사용하고 있다는 것.
 

// 뭐 대략 어제 가서 보고 들은 것과 메모한 것을 참고로 해서 끄집어낼 수 있는 건 모조리 끄집어 내 봤습니다.
어차피 이게 맞는 얘긴지 틀린 얘긴지 판별해줄 수 있는 한국인은 @pure**** 님밖에 없겠지만요. =3==3
 아무튼 간만에 큰 자극을 받았습니다. .... 공부해야지! 

** (3/26) - 발표자료와 영상이 공개되었습니다.
신고
, ,
TOTAL 483,363 TODAY 14

티스토리 툴바