블로그 이미지
JEEN

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

Rss feed Tistory
IT 2012.11.29 00:29

JSLounge 세미나에 다녀왔습니다.

 사실 최근에 외부세미나에 잘 안 다녀서 감을 잃었나 싶은 생각도 하고 있고 해서, 마침 타임라인에 JSLounge 세미나라는 걸 한다고 해서 짬을 내서 신청하고 갔다왔습니다. 모임은 지난번 Korean Perl Workshop 2012 가 열렸던 CNN the biz 교육연수센터 강남점입니다.

 뭔가 JS 쪽은 모임도 많고 그룹도 많다는 인상이…

 Typescript , Coffeescript, Google Dart 가 이번 주제였습니다. 중간중간 느낀 점은 Storify 로 풀어낼까 싶습니다.

 뒷풀이 때 뭔가 이것저것 물어봐야지 했는데 하루종일 굶고있어서 탈력… 결국 집에 와버렸습니다. 느낀 점은 JS 를 하시는 분들이 상당히 많구나 라는 것. 요즘은 JS "만" 하시는 분들도 많다고 하는데… 

 오늘의 주제도 언어로써 완전하지 못한 JS 를 보완(?)하고자 이곳저곳에서 들쑤신다랄까 그런 느낌이 드는 게 있죠. -_-; 뭐 나쁜 의미만은 아닙니다만…

신고
JS, JSLounge, Seminar
IT/Perl 2011.08.25 14:11

[ Silex/Perl ] 8월 24일 Silex 사내세미나

  Silex 에서는 매주 수요일 2시간 정도의 시간을 들여서 사내 세미나를 개최합니다.
  여태껏 많은 좋은 내용들이 그냥 지나가는 것 같기도 해서, 적당하게 사내 업무와는 크게 관련없는 내용이라면 한번쯤 외부에 소개해도 좋지 않을까 하는 생각에서...
  어제 있었던 사내세미나를 정리해봤습니다. 
 


  혹시나 관심이 있어서 들어보시겠다거나, 혹은 발표를 해주신다거나 하실 분이 있으면 저에게 컨택해주세요.
  회사간 기술교류회 같은 이벤트를 해보는 것도 어떨까 생각해보기도 합니다. 
신고
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) - 발표자료와 영상이 공개되었습니다.
신고
DeNA, perl, Seminar
TOTAL 488,101 TODAY 38

티스토리 툴바