허니몬(Honeymon)의 자바guru

그동안 사용하던 계정정보가 XUBUNTU 3.04 에서 XUBUNTU 14:04 LTS로 업그레이드 되면서 그래픽 설정과 관련된 정보가 훼손되어서 정상적으로 나타나지 않는 문제가 있었다. 그래서 계정을 새롭게 만들고 기존의 계정정보는 모두 소거시켰다. 그러고 나니, 이전에 마운트가 잘 되던 추가 HDD들의 정보를 볼 수 없는 문제가 발생했다.

해결은 간단하게 되었다.

$ cd /media
$ sudo chown {username}:{group} /media/{username}

명령을 내리는 것으로 처리완료!

결국은 내 계정이 마운트된 미디어들에 대한 접근권한이 없었기 때문에 발생한 문제다.

디렉토리에 대한 권한을 내 계정으로 변경하는 것으로 문제해결!

20140527 Jenkins 재시작 후 데이터 초기화 증상 해결

사내에서 사용하던 Jenkins가 구동되고 있는 서버가 정전으로 재가동 후 최초 설치상태로 초기화되는 현상이 나타났다.

멘붕!!!

Jenkins의 이런 증상을 처음 경험한 나로서는 어찌해야하는 물어볼 사람도 없고 인터넷 검색으로 뒤지기 시작한다.
그러다가 [Jenkins 관리 - 환경설정] 부분 상단에 HOME Directory 라는 항목의 값이 눈에 들어온다.

/{USER_HOME}/.hudson

이녀석! 이상하다! 내가 쓰고 있는 건 jenkins 인데!?

라는 생각과 함께 JENKINS_HOME 과 관련된 검색에 들어간다. +_+) 그러다가 아래 녀석을 찾았다.

• JENKINS_HOME directory

여기서 말하는 JENKINS_HOME은 젠킨스가 실행되는 경로가 아닌, 젠킨스가 사용자 디렉토리에 생성한 ~/.jenkins 폴더를 가리키는 것이었다.
이후 이를 해결하는 방법은 어려움이 없었다. 환경설정에서 ‘홈 디렉토리Home Directory’ 항목의 오른쪽 물음표(?)를 클릭하면 JENKINS_HOME을 WAS에 설정하라는 안내를 한다.

Jenkins stores all the data files inside this directory in the file system. You can change this by either:
    1. Using your web container's admin tool to set the **JENKINS_HOME** environment entry.
    2. Setting the environment variable **JENKINS_HOME** before launching your web container.
    3. (Not recommended) modifying web.xml in jenkins.war (or its expanded image in your web container).
This value cannot be changed while Jenkins is running. This entry is mostly for you to make sure that your configuration is taking effect.

이후 문제는 쉽게해결 가능하다. 톰캣 서버의 ‘./bin’ 폴더에서 catalina.sh를 열어서

set JENKINS_HOME=/{USER_HOME}/.jenkins

항목만 추가해주고 톰캣을 구동시켜주면 끝이났다. +_+)b That's OK~!

이 문제를 해결하면서 젠킨스의 버전도 스리슬쩍 1.564 버전으로 변경했다.

데이터가 분리되어 있으니 젠킨스를 업그레이드 해도 별문제가 없을 거라고 생각했다.

찍었는데 맞았다!

• 
  20140522_마소_멜팅팟_세미나_nodejs_인_클라우드.md
• 
  
• 
  
• 장소: 판교 테크노벨리 글로벌R&D센터 대강당

● 대충 훑어보는 Node.js

• Node.js
• Express
• MongoDB in Node.js
• Socket.IO
  • Long Polling.
  • RedisStore를 지정하면 레디스를 통해서 클러스터링이 가능하다.
• 흠… @_@) 신기하게 보는구나…. 그렇게 해야 이 바닥에서 신기술들을 더욱 긍정적으로 받아들일 수 있게 되겠지…
• 비동기 코딩패턴
  • CallBack
• 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 의 가능성과 한계성

• 발표자 : 김호광(보이드 소프트)
• 모바일 게임세계
  • Java 세상과 다른 히피 생태계
• Node.js: 게임업계 열광의 이유 -> 개발속도가 빠르다.
  • Unity3D script로 node.js 통합 개발(웃음이 함께하는 발표)
  • 웹 프로그래머가 서버 프로그래머가 될 수 있다.
  • 카카오톡 게임도 이젠 월매출 50만원 시대!!
  • 시장이 ‘모’ 아니면 ‘도’
  • 개발기간은 짧아지고
  • 마케팅비용은 상승(평균 5억)
  • Protytyping이 빠른 Node.js 포텐셜 폭팍!!
  • 현실은…?
• Node.js Live case
  • 개발환경
  • 사용자 증가
  • 서버 증설 - 인프라 증설 비용
  • 운영 헬게이트!!
  • Node.js가 이유없이 죽기 시작 - 랜덤 다운 - 가장 큰 문제구나.
  • 아이템이 다운과 함께 사라지다.
  • 새벽에 소환-라이브 디버깅 진행.
    • javascript V8 원래 서버엔진 아님
• 튜닝포인트 1
  • 기존
    • 4 vCore, 4 nodeJS Server
  • 변경
    • 4 vCore, 2 nodeJS Server
    • 다운 21.5% 감소
  • vCore는 Hyper Thread 여러 개를 섞어 1 vCore
    • 리얼 CPU와는 다름
  • Thread 교착
    • 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
  • 장애가 발생하면 다시 시작
    • Forever
  • 배포시간이 줄어드는 건 상당한 장점이지만, 소프트 셧다운을 고려해서 개발해야 한다.
    • 100% 트랜잭션을 보장해야하는 경우에는 고려하지 마.
  • UI의 템플릿을 보여주는 경우
• 프레임워크
  • Kraken.js -> Express 확장
  • Mean.io
  • Framework가 항상 좋은 것은 아니다.
• 비즈니스를 먼저보고 프레임워크 적용을 고려

● Node.js 로 해보는 클라우드 서비스

• 발표자: 김영욱 차장(한국 마이크로소프트 기술 에반젤리스트)