● 대충 훑어보는 Node.js
- Node.js
- Express
- MongoDB in Node.js
- Socket.IO
- Long Polling.
- RedisStore를 지정하면 레디스를 통해서 클러스터링이 가능하다.
- 흠… @_@) 신기하게 보는구나…. 그렇게 해야 이 바닥에서 신기술들을 더욱 긍정적으로 받아들일 수 있게 되겠지…
- 비동기 코딩패턴
- Node.js 는 잘 죽는다.
- V8 엔진 메모리 릭memory leak
- Catc가 안되는 에러가 나면 죽어버린다.
- 해결책 1 - 다시 시작
- forever
- Supervisor
- nodemon
- PM2
- 2개 이상의 node.js를 구동시키고 죽었을 때 알림을 보내도록 하고, 살릴 수 있을까?
- 해결책 2 - process.o(‘ncaughtException’, )
- 죽을 때 어떤 원인으로 죽었을지 모른다.
- domainAPI를 사용한다.
- Mocha test framework
- 자바스크립트 테스트 프레임웤(웹/node.js 지원)
- TDD 및 BDD 양쪽 지원
- NewRelic
- Passport
- Winstone
- Vert.x 는
- 개념
- JVM에서 동작
- 고성능 네트워크 IO 서버인 netty 를 기반
- 비동기는 지원하지만 Non blocking은 지원하지 않음
- 동작구조는 싱글스레드(멀티스레드 지원)
- 다양한 WAS에 Embedded 가능
- Verticle
- Vert.x Instance
- 멀티스레드를 지원하기 때문에 성능이 뛰어날까?
- 주의사항
- HazelCast를 남용하면, Full GC Time 문제가 발생가능
- Vert.x vs Node.js
- 에러 추적 되고 안되고
- 안정성이 좋고 V8 엔진 자체가 불안함
- 웹개발 없고 express 등 웹 프레임워크 풍부함
- 프로그래밍 언어가 다양하고 javascript
- 비동기를 쓰레드풀을 이용해서 지원 싱글 스레드
- 결론
- Startup 이나 B2C 서비스는 Node.js로 시작
- 자료 찾기 편리함
- 자주 죽어서 문제가 될 때면 돈 벌었음
- 기술력이 충분하고, 고성능, 고안전 서비스가 필요한 경우 Vert.x 고려
- 기반 엔진 자체가 튼튼하여 성능과 안정성
- 모듈 등이 적고 자료부족, 자체 기술력 높아야 함.
● 서버 사이드 레벨에서 자바 스크립트 엔진 Node.js 의 가능성과 한계성
- 발표자 : 김호광(보이드 소프트)
- 모바일 게임세계
- Node.js: 게임업계 열광의 이유 -> 개발속도가 빠르다.
- Unity3D script로 node.js 통합 개발(웃음이 함께하는 발표)
- 웹 프로그래머가 서버 프로그래머가 될 수 있다.
- 카카오톡 게임도 이젠 월매출 50만원 시대!!
- 시장이 ‘모’ 아니면 ‘도’
- 개발기간은 짧아지고
- 마케팅비용은 상승(평균 5억)
- Protytyping이 빠른 Node.js 포텐셜 폭팍!!
- 현실은…?
- Node.js Live case
- 개발환경
- 사용자 증가
- 서버 증설 - 인프라 증설 비용
- 운영 헬게이트!!
- Node.js가 이유없이 죽기 시작 - 랜덤 다운 - 가장 큰 문제구나.
- 아이템이 다운과 함께 사라지다.
- 새벽에 소환-라이브 디버깅 진행.
- 튜닝포인트 1
- 기존
- 변경
- 4 vCore, 2 nodeJS Server
- 다운 21.5% 감소
- vCore는 Hyper Thread 여러 개를 섞어 1 vCore
- Thread 교착
- 튜닝포인트 2: 마공의 등장
- 이기적인 클라우드 버그 이용
- VM 생성시 Max Core 생성 후 4 vCore 생성
- Max Core를 하면 물리서버 CPU를 차지
- 클라우드 리소스 할당 소스 확인하여 찾은 것, OpenStack은 더 안좋다?
- Hidden API Script
- vCore를 2thread에서 4개로 변경
- 급격한 리소스 사용률을 방지가능
- 다운 15.5% 감소
- 튜닝포인트 3
- DB 이존성 줄임: IIS 아웃풋 캐시 (Ranking 등의 정적 데이터 처리)
- 서비스단에서 캐싱 할건지 커널에서 캐싱할건지… 커널에서 캐싱하면 빨라짐
- 다운 3.5% 감소
- 삶이 지혜
- Node.js 는 서비스 레벨에서 사용하려면 위험하다.
- 게임 등 복잡한 로직에서는 어렵다.
- 자신이 잘하는 언어를 사용해라.
- 날림 Open금지
- 디버깅
- 플레잉 테스트 많이 해야함
- 패키지 분석에 대한 처리
- 서비스 운영 시나리오
- 프로토타이핑이 빠르다는 것에 중점을 두고 사용하자.
- Node.js 극복해야할 문제와 비전
- 생태계는 풍성하고 좋음 -> 대세가 되어 인기가 상승, 트렌드
- 근본적인 한계를 파악하고 사용하자.
- Node.js와 우분투는 친분하지만 그 사이에서 생기는 상황들을 고려해야함
- 방어직인 코딩을 해야한다.
- 가능하면 예상한 것보다 많은 서버와 자원을 준비해둘 것.
- 애저에서 Node.js를 잘 지원한다.
- 잘 쓰면 성공하고, 못쓰면 주화입마.
- 트랜잭션 처리에 대해서 미숙하다.
- 게임에서는 DB에 요청을 많이 날린다.
- 몽고DB는 로그 저장용으로만 사용.
- 다운로드 받아서 그대로 사용하지 말고 IntelCompiler를 이용해서 컴파일해보라. 20% 정도 빨라짐.
- 결론: 초딩은 무섭다!
● Socket.io 를 활용한 분산 채팅 서버 개발사례 공유
- 발표자: 김요한 차장(LG CNS)
- Transaction
- 해이 사례
- 링크드인: 모바일
- 그루폰: CDN
- 페이팔: 펑셔널 그리고 비동기 코딩
- 이베이: 프론트는 노드, 백엔드 서비스는 그대로 유지
- 언어적인 패러다임의 변환: 객체지향 -> Functional programming
- 작은 부분부터 천천히 진행
- 페이팔 적용 사례
- 동시젒속자가 적은 초반에는 자바가 성능이 좋지만, 리퀘스트가 많을수록 효과적
- vert.x 나 톰캣이 더 빠르기도 하다. CPU나 OS에 따라 다르기도 하다.
- 싦무에서 성능에 민감한 부분은 C 코드로 개발한다.
- 자바와 Node.js의 성능비교는 MySQL과 NoSQL 비교와 같다.
- 250-500ms node process start/stop time
- 장애가 발생하면 다시 시작
- 배포시간이 줄어드는 건 상당한 장점이지만, 소프트 셧다운을 고려해서 개발해야 한다.
- 100% 트랜잭션을 보장해야하는 경우에는 고려하지 마.
- UI의 템플릿을 보여주는 경우
- 프레임워크
- Kraken.js -> Express 확장
- Mean.io
- Framework가 항상 좋은 것은 아니다.
- 비즈니스를 먼저보고 프레임워크 적용을 고려
● Node.js 로 해보는 클라우드 서비스
- 발표자: 김영욱 차장(한국 마이크로소프트 기술 에반젤리스트)
마이크로 소프트에서 Node.js를 통해서 클라우드 시작에 대한 점유율을 높이려고 하는 것으로 보인다.
.Node.js를 IntelCompiler로 재컴파일 하면 성능이 20% 정도 상승한다는 이야기가 이전 시간에 있었다.
.Azure를 앞세워 클라우드 시장에 본격적으로 진입한 마이크로소프트의 앞날은 과연 어떨까?
20140522_마소_멜팅팟_세미나_nodejs_인_클라우드.md
