소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안

76,967 views

Published on

play.node node.js conference

Published in: Technology
22 Comments
232 Likes
Statistics
Notes
No Downloads
Views
Total views
76,967
On SlideShare
0
From Embeds
0
Number of Embeds
16,995
Actions
Shares
0
Downloads
674
Comments
22
Likes
232
Embeds 0
No embeds

No notes for slide

소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안

  1. 1. 1st node.js Korea conference소셜게임 서버 개발 관점에서 본 node.js의 장단점과 대안 블루윈드 백정상 2012.11.20
  2. 2. 발표자 소개예젂엔 PC 온라읶 게임 서버 개발자 Page 2
  3. 3. 발표자 소개지금은 모바읷 게임 서버 개발자 Page 3
  4. 4. 타겟 프로젝트B-TOWER (iOS / Android) Page 4
  5. 5. 서버 요구사항모든 리퀘스트가 3초 안에맊 처리되면 된다http 베이스젂 세계 서비스가 가능해야 함개발 읶력 : 1명 (두둥)시간이 촉박하다! – 3개웏 안에 출시한다! Page 5
  6. 6. 기존에 많이 쓰던 소셜 플랫폼Apache / php – 젂통의 강자 – Zynga 및 맋은 게임에서 사용 – 익숙하고 편한 언어환경 http://www.raphkoster.com/2010/03/12/gdc10-scaling-social-games-robert-zubek/ Page 6
  7. 7. 왜 node.js를 선택했는가퍼포먼스자바 스크립트알찬 기본 라이브러리유용한 써드 파티 모듈들 Page 7
  8. 8. 왜 node.js를 선택했는가퍼포먼스 – node.js = libuv (IOCP) + v8 (JIT) – 느릴 수가 없는 조합 – 온라읶 게임 서버들도 대부분 (IOCP) + (C++) + (lua)조합 – Hello world로 Apache/php와 http 성능비교 • Node.js가 약 10배정도 빨랐음 – 이 정도면 성능은 믿고 가자 • 적젃히 타협 Page 8
  9. 9. 왜 node.js를 선택했는가자바 스크립트 – 자바 스크립트를 한 번도 써보지 않았던 상태 – 생산성 향상에 대한 막연한 기대 • ‘php보다 코딩하기 편하겠지…’ • ‘자바 스크립트를 써서 빛의 속도로 출시한다!’ • 나중에 엄청난 후회… Page 9
  10. 10. 왜 node.js를 선택했는가알찬 기본 라이브러리 – 소셜 게임 개발에 필요한 것은 다 있음 – API 문서도 인기 쉽게 잘 작성됨사용한 기본 라이브러리들 – http, https – url, querystring – util – buffer, stream – fs – crypto – etc… Page 10
  11. 11. 왜 node.js를 선택했는가생산성 향상에 기여한 써드파티 모듈들 – node-tds (MSSQL) – node-vows (BDD) – node-xml2js (XML -> json) – ya-csv (CSV) – node-memcache (memcached) – node-twitter (server crash reporter) – node-mysql (MySQL) – node-apns (Apple Push Notification Service) Page 11
  12. 12. 결론이렇게 된 이상 모든 걸 node.js로 짠다! Page 12
  13. 13. 개발 시작클라이언트 네트웍 라이브러리 : c++ – cURL 이용 – Xcode / ndk 에서 모두 빌드되어야 했음 – 개발하다 보니 windows에서도 빌드서버 : node.js – 개발은 windows 7 에서 짂행 – Windows 2008 Server R2 에서 실행 – 왜? 게임이 잘 되면 개발자 뽑기 쉬우라고… • 근데 Windows 에선 안 되는 것이 맋다! • 나중에 맋이 후회… Page 13
  14. 14. 난관들에디팅 환경npmjavascriptsingle instance = single threadCPS Page 14
  15. 15. 에디터Vim – 늘상 써왔던 그것findStr – windows에서 찾은 grepeclipse – 잠시 썼으나 workspace관리가 불편해 버림 불편하다! Page 15
  16. 16. node.js 디버깅 방법Google Chrome Developer Tools – 서버를 디버그 모드로 띄우고 – eclipse로 붙어서 확읶하는 방법 – 안되쟎아Logging – 늘상 해오던 그것 결론적으로 불편하다! Page 16
  17. 17. 대안WebStorm – http://www.jetbrains.com/webstorm/ – node.js를 지웎 – IDE에서 구현 후 바로 실행 및 디버깅 가능 – 자동 완성 기능 – 적젃한 가격 ($29 ~ $99) Page 17
  18. 18. npm윈도에서는 대부분의 모듈 사용 불가 – unix계열 모듈 의존성 문제가 있음 – 대부분의 써드 파티 모듈을 git-hub에서 직접 다운로드 후 node_modules 폴더에 추가 – 어차피 모듈 버젂을 프리즈 해야 했으므로 큰 문제는 안 됨 Page 18
  19. 19. javascript자바 스크립트로 비즈니스 로직을 잘 짜기 너 무 어렵다해당 구문이 실행되기 젂 까짂 문제가 발생하 지 않음 – 서버가 죽고 나서야 문제를 알게 됨 – QA가 없는 1읶 개발의 슬픈 현실에선 큰 불안요소 Page 19
  20. 20. 너무 암묵적인 게 문제function Obj() {}Obj.prototype.value = function() { return 11;}function calc(obj) { return obj.value - 1; //should throw an exception!} functionif (require.main == module) { var obj = new Obj(); var added = calc(obj) + 1; // NaN + 1 = NaN console.log(result: , added);} Page 20
  21. 21. 타이포var levelTable = { 1:10, 2:20, 3:30};levelTable[1] // 10levelTable[4] // undefinedleveltable[4] // ReferenceError 구문이 실행되는 시점에 죽는 게 함정 Page 21
  22. 22. this가 그 this가 아니군User.prototype.updateRating = function() { //플레이어 Rating 업데이트…};User.prototype.removeRoom = function(roomId, cb) { this.tower.removeRoom(roomId, function() { this.updateRating() //exception cb(); });}; Page 22
  23. 23. this가 그 this가 아니군User.prototype.updateRating = function() { //플레이어 Rating 업데이트…};User.prototype.removeRoom = function(roomId, cb) { var self = this; this.tower.getRoom(roomId, function() { self.updateRating() cb(); });}; Page 23
  24. 24. 대안테스트 주도 개발 (강력 추천) – 클라이언트 사이드 : google test – 서버 사이드 : vows, 자체 개발 tdd 툴 – 3대 크래시 주범이 대부분 테스트 레벨에서 걸러짐 – regression도 방지 – 라이브 때 서버가 거의 안 죽어줘서 고마웠음 Page 24
  25. 25. 대안UncaughtException을 핸들링 – 최소한 서버 크래시는 방지 – Error 오브젝트가 타입이 애매모호한 게 함정 – node-twitter를 사용하여 uncaught exception 핸들 시 트 위터에 알림 (강력 추천) Page 25
  26. 26. Single instance == single threadNode.js는 싱글 스레드 기반 – I/O가 수반되는 작업이나 이벤트는 event loop에서 작업 – 하지맊 비즈니스 로직은 하나의 스레드에서 실행 – 클로져를 젂달한다고 비동기로 처리되는 게 아님 – 멀티코어 환경에서 젂체 CPU를 사용하지 못한다는 문제 가 있었음 Page 26
  27. 27. 대안cluster – 하나의 읶스턴스에서 하나의 포트로 여러 프로세스를 클 러스터링 • child_process.fork() – master -> worker로의 로드 밸런싱 지웎 Page 27
  28. 28. cluster 예제var cluster = require(cluster);var http = require(http);var numCPUs = require(os).cpus().length;if (cluster.isMaster) { // Fork workers. for (var i = 0; i < numCPUs; i++) { cluster.fork(); } cluster.on(exit, function(worker, code, signal) { console.log(worker + worker.process.pid + died); });} else { // Workers can share any TCP connection // In this case its a HTTP server http.createServer(function(req, res) { res.writeHead(200); res.end("hello worldn"); }).listen(8000);} Page 28
  29. 29. CPSContinuation-Passing Style – Closure • 함수 안의 함수 • 윗 함수의 레퍼런스를 참조 가능 – Coroutine • 수행 지점을 설정 가능한 서브루틴 • yield()등으로 수행을 양보하고, resume()등으로 양보한 시점부터 실행이 가능 • yield, resume 시점에 context를 주고받을 수 있음 Page 29
  30. 30. Closure 예제function say11() { var num = 10; var sayAlert = function() { console.log(num); } num++; return sayAlert;} Page 30
  31. 31. Coroutine 예제var coroutine = process.binding(‘coroutine’).coroutine;var co = coroutine.create(function(name) { var questId = 11; console.log(‘My name is‘, name); console.log(‘Do you want to play this quest?’); var selected = coroutine.yield(questId); if (selected == true) { console.log(‘Let’s play!’); } else { console.log(‘See you next time’); }});var qId = coroutine.resume(co, ‘hackest’);console.log(‘qId: ‘, qId);coroutine.resume(co, true); Page 31
  32. 32. Closure, Coroutine한 때 뜨거웠던 토론 주제node.js는 클로져맊 지웎퀘스트 짜다보니 코루틴 필요가 젃실해짐 – 유저 입력 받을때마다 상태 저장하고 if else 떡칠 – 클로져로는 짜는게 너무 괴롭다…근데 코루틴이 없네? Page 32
  33. 33. 찾아본 라이브러리node-fiber – node.js 내에 자체 구현한 코루틴과 파이버를 제공 – 근데 Windows에서 실행이 안 된다!한참을 찾다가 결국 자체 노드 바읶딩을 맊들 어보기로 결심 – js-coroutine에서 모티브를 얻음 – 마침 잉여력도 좀 있었음 http://code.google.com/p/js-coroutine/ Page 33
  34. 34. 붙여볼 코루틴 라이브러리Portable Coroutine Library – 오픈소스 – 기본적읶 execution control environment를 제공 – C API 제공 http://xmailserver.org/libpcl.html Page 34
  35. 35. node.js 프로그램 구조 application code (user implementation) node standard library (socket, os, zlib, etc…) node bindings (node_socket, node_os, node_zlib, etc…) native core (V8, libuv, openssl, zlib, etc…) Page 35
  36. 36. coroutine 추가 application code (user implementation) node standard library (socket, os, zlib, coroutine, etc…) node bindings (node_socket, node_os, node_zlib, node_ coroutine, etc…) native core (V8, libuv, openssl, zlib, libpcl etc…) Page 36
  37. 37. 데모 시연 Page 37
  38. 38. 요약퍼포먼스 때문에 node.js를 선택 – 실제 퍼포먼스 병목은 DB가 될 가능성이 높음써드 파티 모듈들로 읶해 생산성을 향상javascript로는 생산성을 향상시키지 못함 – node.lua도 괜찮을 듯javascript로 안정적 서비스 하려면 무조건 TDD를 도입 – 언어 특성상 프로젝트가 커지면 핸들 하기 어려워집니다코루틴이 필요하면 붙이면 됩니다 – 애드온 형태로 붙이셔도 됩니다 Page 38
  39. 39. 감사합니다문의 사항은 jsbaek@abluewind.com 으로 Page 39

×