블로그 이미지
JEEN

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

Rss feed Tistory
IT/Perl 2011.09.01 01:09

ISUCON 관련 소감문...

  [ 이 기사는 #perl-kr 에서 ISUCON 을 소개해줬을 때, @aer0 님을 비롯한 여타 세력의 압박으로 인해 자의반 타의반으로 작성하게 되었으며, 퀄리티는 보증할 수 없습니다(언제는 했다고...) ]

 
  언젠가 Bookmark 해둔 Livedoor Techblog 를 보면서 ISUCON 이라고 Iikanji Speed Up Contest(좋은 느낌으로 SPEED UP) 를 개최한다는 뉴스를 들었습니다. 재미있겠다! 한국에서도 이런 거 했으면 좋겠다!(나는 안나가겠지만...) 이라는 생각을 하면서 있었는데...

  이게 8/29일에 있었습니다. 일본에서요... 전 그냥 블로그 글만 보고 대충 상황을 알게 되었습니다.

  우선 주최측인 Livedoor 의 엔지니어가 제공해준 기본 어플의 소스가 Perl, Ruby, Node 세가지 언어로 제공되고 이 중 하나를 골라서 최고의 퍼포먼스를 끌어내도록 하는 게 이 대회의 목적입니다. 대회는 7시간에 걸쳐서 진행되구요. 7시간동안 작업한 것을 서로 벤치마크해서 최고점이 나오는 팀이 이기는 것입니다.

  * http://blog.livedoor.jp/techblog/archives/66784747.html
  * 기본 어플 : https://github.com/tagomoris/isucon

   21 개 팀이 참가를 했고, 1위를 한 팀이 27만req/3min 으로 우승했습니다.
   여기서는 1위팀이 어떤 생각과 시행착오와 작업을 통해서 개선해나갔는 지를 소개해볼까 합니다.
   기본적으로는 아래의 블로그의 번역 요약입니다.

   * http://d.hatena.ne.jp/sfujiwara/20110827/1314460582
   * http://d.hatena.ne.jp/sfujiwara/20110829/1314597283

  • 맨처음은 환경설정
    •  IP 로 접근은 귀찮으니 hosts 에 각 서버들(db, app, frontend...)을 추가
    • 서버간 ssh key 인증 설정
    • 모든 서버에 epel
    • /etc/sysconfig/network 에 HOSTNAME 설정
    •  SELinux off
    •  iptables off
  • 초기 스코어는 800req/min
  • 몇 번의 벤치마크를 통해서 초기상태의 보틀넥은 MySQL
    • Query Cache 설정으로 일단 1200req/min
    • DB 컬럼을 추가해서 쿼리를 가볍게 만드는 작업
      • 이걸로 20,000req/min
  • Front-end 서버를 Apache 에서 Nginx 로 전환
    •  Nginx 에서 keepalive off
    • Nginx -> memcached 의 로컬포트 고갈문제
      • net.ipv4.ip_local_port_range 범위를 늘려줌
      • net.ipv4.tcp_fin_timeout 의 값을 줄여줌
      • 혹은 memcached 접속을 영속화하는 옵션이 있을지도?
  • ip_conntrack off
  • 이후의 보틀넥은 DB 서버에서 App 서버의 CPU
    • nginx memcached plugin 을 사용해서 memcached 에 존재하는 컨텐츠는 App 서버를 통해서가 아니라 nginx 에서 직접 뽑아내도록
    •  특정 처리에 있어서의 memcached 의 저장 시점을 조정
    • 이렇게 해서 30,000req/min 까지 
  • 좀 더 cache 타이밍을 조정했지만 cache hit 가 감소하기에 cache 수명을 5초로 조정 / 10초 정도에서는 hit 율이 낮아져서 뭔가 fail 이 발생했다는 군요.
  • 결과 90,000req/min -> 1,500req/sec
  그 이외에 nginx 에서 SSI 를 사용하면 어땠을까 하는 생각도 해봤다는 군요.

  ISUCON 의 기본 앱의 소스(Perl)를 살펴본 결과, ORM 은 당연히 없고 DBI 로 그대로 Query 를 뽑아쓰고 있습니다. 또한 템플릿 엔진도 Template Toolkit 이 아니라 처음부터 Text::Xslate 로 정해져 있으며 Route Dispatch ing 역시 경량모듈로 사용하고 있어서 어플 소스단에서 쉽게 개선할 방법은 찾기 어려웠다는군요.  (그래서 어떤 팀은 템플릿엔진 사용자체를 배제시켜버리고 html 을 직접 써놓도록 했지만 결국 기대했던 퍼포먼스는 나오지 않았다고 합니다)

 아무튼 우승팀은 27만req/3min, 준우승 팀은 8만req/3min 정도로 ... 뭔가 압도적인 차이입니다.
 우승팀 하나, 준우승팀 둘인데... 재미난 건 수상권은 전부 Perl 을 골라서 썼다고 하네요 :-)

  아무튼 실 서비스를 올리는 데 있어서 많은 참고가 될지도 모르겠지요. 
신고
TOTAL 483,604 TODAY 63

티스토리 툴바