Posted by 알 수 없는 사용자
,

사장님 소개로 Agar.io라는 게임을 해보았습니다.

Javascript와 WebSocket을 이용한 웹게임인데, 간단하면서도 중독성 있는 게임으로 시간가는줄 모르고 하게되었네요.

하지만, 워낙 게임치 인데다가 나이까지 40줄에 들어서니 순발력도 떨어져서 살아남는 것이 쉽지가 않더군요.

그래서 Agar.io Bot이라는 것을 찾아서 설치해 보았습니다.

혼자서 다른 유저들로부터 잘 도망다니면서 쑥쑥 크더군요.그런데, Bot이 자동으로 알아서 게임하는걸 보고만 있자니.... 이건 내가 게임을 하고 있는건지, 게임이 나를 가지고 노는 건지...zzzzzz

그래서 자동사냥 위주의 모바일 게임에서 힌트를 얻어 최소한의 사용자 액션을 Bot에 추가 해보기로 했습니다.


1.Agar.io와 Bot에 대해서

Agar.io(http://agar.io)는 자신보다 큰 세포(세포인지 뭔지 모르겠지만 그냥 편하게 세포하고 합시다.)는 피해 다니면서 작은 세포를 먹어서 자신의 몸집을 키워나가는 게임 입니다.

클라이언트는 모두 javascript로 되어 있으며, 서버와는 WebSocket을 통해 실시간으로 통신하는 것으로 보입니다. 그래서 당연히 Bot도 모두 Javascript로 되어 있으며, 소스도 공개되어 있어서 누구나 수정 가능 합니다.

Agar.io는 그냥 보기에는 굉장히 간단한 게임인 것처럼 보이지만, 게임 감각이 비루하거나 순발력이 심히 떨어지는 사람들은 다른 사람들의 먹이 신세를 벋어나지 못하는 어찌보면 참 슬픈 게임입니다.

Agar.io Bot은 이러한 슬픈 몸뚱이를 가진 사람들을 위한 자동사냥 프로그램입니다. 혼자서 알아서 잘 피해 다니면서 알아서 잘 큽니다.

물론 완벽하지는 않습니다. 가끔 죽음을 피할 수 없는 상황에 놓이기도 하고 어이없는 행동(버그?)으로 죽기도 합니다. 결국 상위랭커로 가기 위해서는 사람의 손길이 필요한 것 같습니다.

그리고 Bot의 최대 단점은..... 당연히 직접 게임을 하는 것이 아니기 때문에 금방 흥미가 떨어집니다.

Agar.io Bot의 소스는 GitHub에 공개되어 있습니다.


2. 추가할 기능에 대해서

자동사냥을 기본으로 하는 요즘 모바일 게임을 보면 대부분의 게임 플레이는 자동사냥 봇이 하면서 사용자는 지루하지 않게 스킬 버튼만 눌러주는 방식이 유행인것 같습니다.

모바일 환경의 특성 때문에 케릭터를 직접 컨트롤하는게 어렵기도 하고 피곤하기도 해서 나온 새로운 게임 플레이 패턴인 듯 합니다.

Agar.io Bot에도 이런 방식을 도입해 보도록 하죠. 조금이나마 다이나믹한 플레이를 위해~~~

우선, Bot의 움직임을 간접적으로 제어할 수 있는 버튼을 하나 추가해 보기로 하죠.

Bot의 기본 움직임을 "수비적"이라고 정하고 여기에 "공격적"으로 움직일 수 있는 옵션을 하나 추가하고, 버튼하나를 추가해서 클릭할 때마다 "수비적 움직임"과 "공격적 움직임"이 서로 스위칭 되도록 해보겠습니다.


[그림 1] Agar.io Original


[그림 2] Agar.io With Bot



3. 1단계 - Agar.io Bot 설치하기


(1) 사용자 스크립트 실행을 위한 브라우저 확장 프로그램 설치

Agar.io Bot을 설치하기 위해서는 브라우저에 추가앱을 설치해야 합니다.

[Firefox를 사용할 경우]

Greasemonkey 설치

https://addons.mozilla.org/ko/firefox/addon/greasemonkey/

위의 링크를 통해서 Firefox의 Add-on인 Greasemonkey를 설치합니다.

[Chrome을 사용할 경우]

Tampermonkey 설치

https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ko

위의 링크를 통해서 Chrome의 확장프로그램인 Tampermonkey를 설치합니다.

참고로 Greasemonkey나 Tampermonkey라는 프로그램은 원하는 웹페이지가 로딩된 후 사용자가 작성한 스크립트 파일이 실행되도록 해주는 Plug-in 프로그램 입니다. (자세한건 구글신에게...)


이 다음부터는 Firefox나 Chrome 모두 진행 과정은 거의 비슷하기 때문에 Firefox를 기준으로 설명해 드리도록 하겠습니다. (IE는 모릅니다. Agar.io Bot 은 Firefox, Chrome, Opera만 지원하는 것 같습니다. 죄송)

사용자 스크립트를 실행시킬수 있는 프로그램이 브라우저에 설치가 되었다면, 이 다음 단계는 Bot 소스를 설치하는 단계입니다.


(2) Agar.io Bot 설치

https://github.com/Apostolique/Agar.io-bot

위의 링크로 들어가면, Agar.io Bot의 자바스크립트 소스가 있는 GitHub 사이트가 나옵니다.

Bot을 실행하기 위해서는 "bot.user.js" 파일과 "launcher.user.js" 파일이 필요합니다.

먼저, "bot.user.js" 파일을 클릭하면 전체 소스가 출력되며, 소스 상단에 있는 3개의 버튼중 "Raw"버튼을 클릭하면 (1)에서 설치한 확장프로그램의 스크립트 설치화면이 출력됩니다.

"install" 버튼을 클릭하면 "bot.user.js" 스크립트 설치가 완료 됩니다.

"launcher.user.js" 스크립트도 같은 방식으로 설치 합니다.

참고로,

"bot.user.js" 파일은 bot의 자동사냥을 위한 공식, 행동 규칙 등이 정의 되어 있는 파일이고, "launcher.user.js"파일은 agar.io의 원래 스크립트 파일에 "bot.user.js"을 이용해 실제 Bot을 띄워줘는 스크립트를 추가한 파일 입니다.

자, 이제 두개의 파일의 설치를 마쳤으면, http://agar.io에 접속하면 서버 접속부터 사냥 까지 모두 자동으로 진행되는 것을 확인 하실 수 있습니다. (닉네임까지도 봇에 정해진 닉네임으로 플레이가 되버립니다.)



4. 2단계 - Agar.io Bot에 새로운 기능 추가하기

새로운 기능을 추가하기 위해서는 (2)에서 설치한 스크립트 파일을 수정해야 합니다.

스크립트 파일을 수정할려면 스크립트를 편집기에 띄워야 겠죠. 스크립트를 편집기에 띄우는 방법은 다음과 같습니다.

[Firefox]

부가기능 => User Scripts(화면 왼쪽 메뉴) => Launcher의 환경설정 => 이 유저 스크립트 편집 클릭(화면 하단)

[Chrome]

Toolbar에서 Tampermonkey 아이콘 클릭 => Dashboard => Launcher 클릭


이제 launcher.user.js 스크립트 파일이 편집기에 출력이 되었을겁니다.

먼저, 코드를 추가할 위치를 찾아야 합니다.

console.log("Running Bot Launcher!");
(function (h, f) {

// 인자 변수인 h, f는 사람들 마다 다를 수 있습니다.

// 원본 agar.io 의 소스는 자바스크립트 압축 프로그램을 거쳐 나온 소스다 보니

// 변수명과 함수명은 1~2글자의 알파벳으로 치환되어 있고, 이마저도 버전따라 다를 수 있습니다.

// ======= 이부분에 추가 코드를 삽입하시면 됩니다. ==============

.......

다음의 라인을 추가해 주세요.

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
  // by yam-Embian start
  var toggleDefence = true;   
  window.getToggleDefence = function() {
    return toggleDefence;
  }
  var toolbox = window.jQuery("<div id='toolbox'></div>");
  toolbox.css({"position":"fixed","width":"100%","height":"90px","bottom":"0px","text-align":"right","padding":"10px"});
  window.jQuery("body").append(toolbox);
 
  var offBtn = window.jQuery("<input type='button' id='offBtn' value='공격적으로 플레이하기' />");
  offBtn.css({"width":"150px","height":"70px"});
 
  offBtn.click(function(){
    toggleDefence = !toggleDefence;
    window.setDarkTheme(!getDarkBool());
    if (toggleDefence) {
        offBtn.val("공격적으로 플레이하기");
    }
    else {
        offBtn.val("수비적으로 플레이하기");
    }
  });
  toolbox.append(offBtn);
  // by yam-Embian end
  //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////


사실 원본 소스를 모두 분석할 수 있으면 참 좋겠지만, agar.io의 원본 소스는 압축프로그램을 거쳐 나온 소스이기 때문에 변수명과 함수명이 모두 의미 없는 알파벳으로 이루어져 있어서 분석하는게 쉽지 않습니다.

하지만, 시간이 된다면 천천히 분석해 가면서 변수명과 함수명을 의미있는 나만의 값으로 치환해 나가는 작업을 해보고 이것도 따로 포스팅 해보고 싶은 욕심이 있습니다......만 할 수 있을 지는 잘 모르겠습니다.


위의 코드를 추가하셨다면 다시 한번 agar.io에 접속해 보세요.

화면 하단에 추가 기능 활성화를 위한 버튼이 출력된것을 보실 수 있습니다. 한번 클릭해 보세요. 화면 테마가 Night 버전으로 바뀌게 됩니다. 오호~~

아직은 Bot의 움직임을 바꿔주는 코드가 들어가지 않아서 테마만 바뀌게 됩니다.

처음에는 움직임 규칙이 바뀔때마다 큰 글씨로 바뀐 규칙을 출력해 줄려고 했으나, 귀찮아서 아에 테마를 바꿔주는 방식으로 수정했습니다.

테마를 바꿔주는 코드는 다음 라인입니다.

window.setDarkTheme(!getDarkBool());


움직임 규칙이 바뀔때 테마를 바꾸는게 아니라 다른 액션을 추하고 싶으시면 저 라인 대신 다른 코드를 직접 적으시면 됩니다.


이제 실제 움직임 규칙을 적용해 보도록 하겠습니다.

세포의 실제 움직임을 결정하는 코드는 "bot.user.js" 파일에 있습니다.

위에 launcher.user.js파일을 열었던것 처럼 bot.user.js 파일을 열어주세요.

수정할 곳을 딱 한군데 입니다.

코드를 추가할 위치는 findDestination 함수입니다.

"function findDestination"으로 검색하시면 한방에 찾으실 수 있습니다.

function findDestination() {
  //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
  // by yam-Embian
  splitDistance = f.getToggleDefence() ? 700: 20;
  //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
  ...
  ...


agar.io bot은 자신을 공격할 수 있는 세포들은 + 710 크기 만큼의 영향력 범위를 추가로 가지도록 해두었습니다.

[그림 3] 나를 공격 가능한 세포의 영향력 범위


그림을 보시면 여러개의 원이 어지럽게 그려진것을 보실 수 있는데, 초록색 운은 내 세포가 도망갈 수 있는 방향을 나타냅니다.

초록색 반대쪽에 있는 주황색 반원은 공격가능한 세포의 범위에 들어왔을 나타나며, 주황색 반원이 없어질때까지 도망을 가게 되어 있습니다.

왼쪽에 태극기 세포가 보이실 겁니다. 태극기 세포 주위에 연한 주황색 원이 있는데, 이 세포는 현재 분열을 할 수 없는 상태로 공격 범위가 주황색 원까지라는 말입니다.(이게 버그인지는 모르겠지만, 가끔 주황색 원을 가지는 세포가 분열해서 저를 먹는 경우도 있었습니다.)

화면에 보이는 빨간색 원이 분열 가능한 세포의 공격가능 범위 입니다. 실제 세포는 보이지 않지만 그 공격 범위에 제 세포가 들어가서 피하는 모습입니다.


위에 추가한 코드는 결국 공격가능 세포의 공격력 범위를 조작하는 코드입니다.

실제로 공격범위에 들어갔다고 해서 모든 세포들이 내 세포를 공격하는 것도 아닌데, 큰 세포들 주위에 있으면, 공격범위에서 벋어나기 위해 회피 기동만 하다가 오히려 코너에 몰려서 죽는 경우를 자주 보게 됩니다.

그래서 정말 피해야 할 상황인지 아닌지 플레이어가 직접 판단해서 결정할 수 있도록 세포들의 공격 범위를 조작할 수 있는 코드를 추가한 것입니다.


이제 필요한 코드 수정은 모드 끝났습니다.

다시 한번 플레이를 해볼까요?


[그림 4] 공격적인 모드를 선택했을 때 화면


공격적인 모드일 떄 화면을 보시면 제 세포 뿐만 아니라 상대방 세포 주위의 원이 아직 작아 진것을 보실 수 있습니다.

공격적인 모드 일때는 상대방 세포가 정말 가까이 접근하기 전까지는 회피 기동을 하지 않고 먹이를 먹는데 집중하게 됩니다.

"수비적으로 플레이하기" 버튼을 클릭하면 [그림 3]처럼 화면 모드나 하얀색으로 다시 바뀌고 원래 방식대로 세포가 움직입니다.


기본은 공격모드로 해서 플레이 하다가 위험할 것 같으면 수비모드로 바꾸는 등 다이나믹한 플레이가 가능해 졌습니다. ㅎㅎㅎ



5. 3단계 - 부가 요소 추가하기

위에 내용까지만 따라 하셔도 충분히 재미 있으실 것 같은데, 그래도 재미를 위해 몇가지 요소를 더 추가해 보도록 하겠습니다.


첫번째는 내 세포의 이름 입니다.

Bot은 무조건 닉네임이 "NotReallyBot"으로 고정이 되어 있습니다. (이름참 넌센스 합니다.ㅡㅡ;;)

Bot의 닉네임을 정해주는 파일은 launcher.user.js 파일 입니다.

"NotReallyBot"이라고 검색하면 딱 한군데 있습니다. 원하는 닉네임으로 수정해 주시면 됩니다.

//names = ["NotReallyABot"],

names = ["배고파 배고파"],


두번째는 "분열 가능 세포 함수 무시하기" 입니다.

앞에서 잠깐 설명 드렸었는데, 세포중 어떤 세포는 일반적인 공격범위를 가지고 있지 않은 세포들이 보이실 겁니다.(노란색 원) 소스 코드를 보면 canSplit 함수에서 false를 리턴받은 세포들은 일정한 크기의 다른 공격범위를 가지게 되는데요.

이게 좀 애매한 부분이 있습니다. 실제로 플레이 해보시면 이런 노란색 원의 공격범위를 가지는 세포들이 실제로 분열을 해서 우리의 세포를 먹어버리는 경우를 자주 격게 되는데요.

그래서 아에 canSplit이 항상 true를 리턴하도록 수정을 해 보았더니, 실제로 생존률이 높아졌습니다.(통계를 내서 내린 결론은 아닙니다.)

bot.user.js파일에서 canSplit 함수를 찾아 항상 false를 리턴하도록수정하시면 됩니다.

function canSplit(player1, player2) {
      return true;
      //return compareSize(player1, player2, 2.30) && !compareSize(player1, player2, 9);
}


지금까지 agar.io bot에 새로운 기능을 추가하는 방법에 대해서 알아보았습니다.

사실 제목에 "공부하기"라고 적어놓고는 공부하고는 거리가 먼 게임 이야기만 했는데, 억지로 공부하는 것보다는 이렇게 재미있는 주제를 가지고 조금씩 지식을 넓혀 가는 것도 좋은 방법이지 않을까 생각합니다.


다음에 시간이 되면 앞에서 말씀 드렸던 agar.io 원본 소스 분석에 대한 글도 적어보도록 하죠. 감사합니다.


Posted by 알 수 없는 사용자
,

최근 프로젝트에서 웹에서 차트를 그릴 일이 있어 javascript library들을 이것 저것 찾아보고 써본적이 있다.

그중 가장 돋보이던 것이 D3.js 였는데, 그동안 항상 보아오던 그래프들 이외에도 정말 다양한 형태의 차트들과 아름답기까지한 실제 적용 사례들을 하루종일 처다본적이 있었다.

지금 당장은 아니더라도 나중에 어딘가에 꼭 써먹을 수 있을 것 같아, 몇가지 차트와 예제들을 정리해 보기로 했다.


1. Box Plots

주식을 하는 사람들에게는 정말 친숙한 차트인것 같다.

Box Plots은 다섯가지의 통계 지표와 양적 분포를 한눈에 쉽게 파악 할 수 있도록 디자인된 그래프로 주식을 하는 사람들에게는 정말 친숙한 그래프인것 같다.

출력되는 정보를 보면 "최대값", "최소값", "평균값", "상위사분위수", "하위사분위수"를 표현할 수 있으며, 간혹 알 수 없는 원인으로 인해 튀는 값으로 인해 최소값이나 최대값의 신뢰도가 떨어지는 경우를 대비해 "튀는 값"들에 대한 디스플레이는 작은 원으로 따로 표시 할 수도 있다.

예제1: Box Plots이 실시간 변동되는 그래프 예제 링크




2. Bubble Chart

수치 데이터를 원으로 표현하는 그래프로 Bar Chart에 비해 데이터에 대한 수치적 표현력은 떨어지지만, 더 작은 공간에 더 많은 데이터를 표현 할 수 있다.

그리고 Bar Chart로 표현했을 때보다 조금 더 감성적으로 데이터를 표현 할 수 있어, 수치 데이터보다 감정적인 측면을 어필 하고 싶을 때 사용하면 좋을 것 같다.

예제2: Box Plots이 Bubble Chart 예제 링크




3. Bullet chart

Stephen Few라는 사람이 작은 공간에 풍부한 데이터를 출력하기 위한 디자인한 차트라고 한다.

전체범위와 분위를 바탕으로 목표치와 현재 달성치, 지난 달성치등을 표시하기에 적합한 차트로, 주로 매출 현황이라던가 프로젝트 진행 상황등을 표현하기에 적합한것 같다.

예제3: Bullet Chart가 실시간 변동되는 그래프 예제 링크



4. Chord Diagram


Chord Diagram은 그룹간의 Relationship을 직접적으로 표현 할 수 있는 그래프로 바로 이전 스템과 현재 스템 사이에서 그룹간에 어떤 변화가 있었는지를 직관적으로 표현이 가능하다. 이건 글로 설명하는 것 보다 직접 예제를 보는 것이 이해가 빠를 것 같다.

예제는 약 2,000명 정도의 스마트폰 유저를 대상으로 현재 사용중인 스마트폰의 제조사와 바로 이전에 사용하던 스마트폰의 제조사를 조사한 결과를 Chord Diagram으로 표현한 것이다.

예제4: Chord Diagram으로 설명하는 스마트폰 제조사간 점유율 추이 링크



5. Treemap


Treemap은 사각형 반복적으로 배치해서 데이터를 그룹핑해 보여주는 그래프로, 여러개의 그룹으로 구성된 구조나, 양파껍질 같은 스택 구조를 표현하기에 적합하다. 가장 쉽게 접할 수 있는 예제가 소프트웨어 스택인데, 위의 그래프는 Flare visulaization toolkit의 package정보를 Treemap으로 보여주는 그래프이다.

예제5: 실시간으로 변동하는 Treemap 예제 링크



6. Sunburst Partition


Treepmap을 원형(해바라기 모양)으로 표현한 그래프가 Sunburst Partition으로 Treemap 보다 시작적으로 더 아름다운 표현이 가능하다. 예제는 쇼핑몰의 웹페이지 Access Log를 바탕으로 사용자의 웹페이지 방문 패턴을 Interactive하게 표현했다.

예제6: Interactive한 Suburst Partition 예제 링크



7. Sankey Diagram

Sankey Diagram은 각 노드 사이의 데이터 흐름을 시각화한 그래프로 예제는 2050년 영국의 에너지 생산과 소비에 대한 예측치를 표현한 것이다. 그래프를 보면 2050년에는 에너지 원료중 핵이 가능 높은 비중을 차지하고 있는 것을 볼 수 있으며, 핵에너지는 모두 열로 변환되고, 변환된 열중 절반정도는 손실되며, 나머지는 거의 대부분 전기로 변환 되는 것을 알 수 있다.

예제7: 2050년도 영국 에너지 생산과 소비 예측 링크



8. The Wealth & Health of Nations

마지막 예제는 Data Visualization을 이야기 할 때 많이 소개되는 그래프로 1800년부터 2009년까지 각 나라의 경제력과 국민들의 평균 수명을 조사한 데이터를 그래프로 설명한 작품이다.

처음 페이지에 접근하면 1800년도부터 2009년까지 그래프가 차츰차츰 변화하면서, 각 나라의 경제력과 수명이 어떻게 변화해 가는지를 시각적으로 잘 표현하고 있다.

우리나라의 데이터를 집중적으로 따라가 보는 것도 재미 있을 것이다.(1800년부터 한국과 북한이 따로 표기되어 있는 점이 좀 이상하긴 하다.)

예제8: The Wealth & Health of Nations 링크


9. 마무리

종이에 이차원으로 표현되던 정적인 데이터가 IT 기술과 미디어의 발달에 힘입어 실시간으로 변화하는 데이터까지 표현할 수 있게 되면서, Data Visualization은 이제 하나의 예술 분야로 까지 인식되고 있는 것다.

비록 아직도 그래프를 그리라고 하면, Bar Chart, Line Chart 같은 클래식한 그래프들을 먼저 생각할 수 밖에 없는 비루한 미적 감각을 가지고 있지만, 이런 다양한 그래프와 작품들을 보다보면, 언젠가는 나도 멋지고 훌륭한 그래프를 그릴 수 있지 않을까 기대해 본다.


*참고사이트

D3.js - http://d3js.org

Mike Bostock - http://bost.ocks.org

VISUAL CINNAMON - http://www.visualcinnamon.com



Posted by 알 수 없는 사용자
,


지난주 생각없이 주 사용 컴퓨터인 Ubuntu 12.04 LTS(64bit)에 apt-get upgrade를 날리면서 Google Chrome이 35 버젼으로 업데이트 되었습니다.


뭐 그냥 그러려니 하고 크롬에서 평소처럼 검색창에 한글을 입력하는데 한글 입력에 문제가 있더군요. 처음에는 Nabi 입력기의 문제인가 싶어 찾아보니 UI를 Aura로 바꾸어 생긴 문제라고 하는데 전혀 Aura가 느껴지지 않습니다...


현재 35버젼은 Stable이고 36, 37 버젼은 Beta, Unstable 버젼인데 뭐가 Stable하다는건지... 라고 생각하며 빡쳐있다가 아래 레퍼런스를 보았습니다.


[빡침 레퍼런스]

우분투 포럼: [질문] 이거 버그인가요? (Google Chrome) 

아무도안님의 구글 크롬 35 뭔가 문제가 많아... 


(더 열받더라구요...)


혹시나 싶어 36, 37 버젼을 모두 설치해보았지만 Nabi로 한글 입력은 잘 되지 않았습니다.

(즉, 향후 버젼 업데이트로 크롬에서 한글 입력 개선을 기대하기는 당분간은 어렵다는 의미이겠군요...)


그렇다고 딱히 FireFox를 쓰고 싶지도 않더군요.

iBus를 사용하면 해결된다고 하는데, 개인적으로는 그렇게 어렵게 살고 싶지 않았습니다.(Nabi만세!!)



해서 결론은... Chrome을 34버젼으로 Downgrade하여 해결하였다는...(쿨럭;;)


방법은 초 간단하며 아래와 같습니다.


1. /var/cache/apt/archive 폴더로 이동

 $ cd /var/cache/apt/archives/


2. 이동한 폴더에서 google chrome 34 버젼 찾기

 $ ls | grep google

google-chrome-beta_36.0.1985.18-1_amd64.deb

google-chrome-stable_34.0.1847.137-1_amd64.deb

google-chrome-stable_35.0.1916.114-1_amd64.deb

google-chrome-unstable_37.0.2008.2-1_amd64.deb


3. 34버젼이 있으면 재설치

 $ sudo dpkg -i google-chrome-stable_34.0.1847.137-1_amd64.deb



Optional> Google Chrome Repository 제거

일단 다운그레이드를 하였으면, 당분간 업데이트가 안되어야 한글 입력이 잘 되겠지요?

그래서 아래와 같이 하시면 됩니다.


1. Repository 폴더로 이동 

 $ cd /etc/apt/sources.list.d


2. list 파일 열기

 $ sudo vi google-chrome.list


3. 아래 내용이 보이면

 deb http://dl.google.com/linux/chrome/deb/ stable main

요렇게 주석처리(#) 후 저장

#deb http://dl.google.com/linux/chrome/deb/ stable main



제가 드린 해결방법은 완전한 해결책(Solution)이 아니라 임시 방편(Temporary Method)이지만,
당분간은 이렇게 기다려 볼 수밖에 없겠네요...  흠..


Posted by 알 수 없는 사용자
,

OOD에서 SOLID Principle...

Misc. 2014. 3. 24. 17:15

객체지향 설계 기법의 많은 부분이 사실 객체들 사이에 Coupling을 줄이고 Coherent을 증가시키는데 집중한다.

이를 위해서 패턴, 리팩토링, TDD 등 여러 이론이나 방법론 혹은 기법을 사용하고 Clean Code를 만들기 위해서 많은 개발자들이 신경쓰고 노력하고 있다. 그럼에도 불구하고, 실제 프로젝트를 진행하다보면 점점 코드는 스파게티 모습으로 변하고 더이상 유지되기 힘든 형태로 쉽게 변질되곤 한다. 그러한 코드를 code review를 통해 다시 보더라도 바쁜 일정과 관대한 타협에 의해 좋은 객체지향 디자인을 포기하곤 한다.


이때 유용하게 적용할 수 있는 하나의 기준이 SOLID이고 각 객체들의 디자인이 SOLID를 위반하면 나쁜 냄새가 나는것을 감지하여 다시 디자인을 수정하는 기준이 될 수 있다.


SOLID는 로버트마틴이 2000년대 초반에 명명한 OOD의 다섯가지 기본원칙 마이클 페더스가 첫글자를 조합하여 알기쉽게 소개한 용어이다. 이는 다음의 다섯가지 원칙을 나타낸다.


  • SRP: Single Responsibility Principle
  • OCP: Open/Closed Principle
  • LSP: Liskov Substitution Principle
  • ISP: Interface Segregation Principle
  • DIP: Dependency Inversion Principle
즉, 위의 원칙에 비추어 설계된 객체의 디자인이 위배됨을 느끼게 되면 리팩토링을 수행해서 코드냄새를 제거해야 한다는 것이다.
이는 위의 내용이 객체지향 설계를 위한 마법의 지팡이를 제공하는것이 아니라 무언가 이상한 낌새(?)를 차리거나 혹은 Code review를 할 경우 어떤 기준과 원칙을 제공하여 자신 혹은 현실에 타협하는 것을 막아주는 효과를 준다.

각각의 원칙을 간단히 설명하면,
  • SRP: 단일 책임의 원칙
    • 한 클래스는 한개의 역할을 가져야한다.
    • 여러 역할을 지니는 클래스는 단일 역할을 갖도록 분리하는게 명확하고 유지보수에 좋다. (방법적인 접근으로는 ISP와 밀접한 관계를 갖는다.)
  • OCP: 개방/폐쇄의 원칙
    • 소프트웨어 요소는 확장에는 열려있어야하고, 변경에는 닫혀있어야 한다.
  • LSP: 리스코프 치환의 원칙
    • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면 하위타입의 인스턴스로 바꿀수 있어야 한다.
  • ISP: 인터페이스 분리의 원칙
    • 클라이언트들을 위한 범용 인터페이스보다는 특정 클라이언트가 사용하는 여러개의 인터페이스가 낫다.
  • DIP: 의존관계 역전의 원칙
    • 추상화에 의존해야지 구체화에 의존하면 안된다.
    • 요즘 Spring Framework를 많이 사용하는데 그 주된 이유는 Container에 의한 IoC(Inversion of Control)를 제공하는 기능 때문이다.
    • 이는 객체의 Dependency Inversion을 비교적 깔끔하게 Framework Level에서 제공하여 객체의 역할에 집중하여 설계할 수 있기 때문이리라...

각각의 원칙들은 그 의미를 이해하기에 좀더 실증적인 의미를 알기 위해서는 약간의 훈련과 노력이 필요하다. 위의 원칙들은 객체설계에서 Coupling을 줄이고 Coherent을 증가하는 방향으로 관통하고 있고 이는 좀더 나은 객체지향 디자인을 위해 도움을 줄 수 있다.


다만, 우선은 위의 원칙에 대해서 개략적인 내용을 알고 있는 것 만으로도 도움이 될 것이라 생각되어 이번 글에서는 소개 정도로 마감하려한다.(다음 포스팅에서는 좀더 자세한 내용을 담아보고자 한다.)


오늘부터 엠비안 블로그에 참가합니다.

기념으로 간단한 글 하나 올립니다.




Posted by 알 수 없는 사용자
,

Scalable CEP System(가칭) 개발

Storm&Esper Team

2014.2.14


2014년 2월 14일에 발표한 자료입니다.


012345678910111213

본 발표에서 논의된 이슈사항으로는
   1. 사용자 시나리오가 부족하거나 또는 없다.
   2. UI를 먼저 고려하는 것보다는 Model을 기술할 수 있는 DSL을 작성하는 것이 선행되어야 한다.
   3. 작업의 우선순위 또는 필요성을 생각한다면, 1) 모니터링, 2) Dashboard, 3) 모델링 순일 것이다.
등이 있었습니다.




'Misc. > Storm&Esper Team' 카테고리의 다른 글

Scalable CEP System개발 중간보고(2014.1.17)  (0) 2014.02.10
Posted by 알 수 없는 사용자
,

Scalable CEP System(가칭) 개발

Storm&Esper Team

2014.1.17


개발 2본부에서 진행하고 있는 Scalable CEP System을 개발하며 산출되는 중간보고 자료 및 이슈사항들을 앞으로 블로그에 공개하려고 합니다.


본 포스트에 공개된 자료는 2014년 1월 17일에 발표한 자료입니다.


012345678



'Misc. > Storm&Esper Team' 카테고리의 다른 글

Scalable CEP System 개발(2014.2.14)  (0) 2014.02.14
Posted by 알 수 없는 사용자
,

현재 서비스 중에 있는 시스템중 전부, 또는 일부를 Amazon AWS(Amazon WebService) 환경으로 이전 할 수 있는지 가능성을 타진하기 위한 프로젝트의 일환으로, 표면적으로 가장 문제가 될것으로 보이는 네트워크 속도에 대한 테스트를 진행했다.

현재 Amazon AWS의 실제 서버가 위치한 곳은 북중미 3곳(Virginia, Oregon, California) 유럽 1곳(Ireland),  남미 1곳(Sao Paulo), 아시아 3곳(Singapore, Japan, Sydney), 총 8곳의 region이 있다.

사용자는 이 8곳 중에서 원하는 곳 어디서든 인스턴스(서버VM)를 생성할 수 있지만, 각 지역마다 네트워크 속도의 편차가 심하기 때문에 주력으로 서비스하고자 하는 곳에서 네트워크 속도가 가장 잘 나오는 곳을 선택해서 사용하는 것이 효율적이다.(region 마다 사용비용은 조금씩 차이가 있다.)

이번 테스트에서는 일본지역을 사용하였는데, 각 지역별로 ping test를 따로 진행한 결과, 일본 지역이 사용하기에 가장 무난한 곳으로 판단되었다.



1. Ping(Network Latency) test


Ping test를 통해 각 지역별 latency를 측정해 보았다.

테스트는 http://cloudping.info(Amazon region별 ping test site) 사이트를 이용해 진행했으며, Client의 회선 제공 업체에 따라 결과가 다를 수 있기 때문에 주위에 테스트 가능한 회선을 최대한 모아서 각각 테스트 해보았다.


KT (전용회선)

KT (LTE)

KT (3G)

SK(LTE)

SK(3G)

LG(전용회선)

US-East (Virginia)

214 ms

450 ms

359 ms

448 ms

471 ms

235 ms

US-West (California)

138 ms

206 ms

246 ms

184 ms

545 ms

141 ms

US-West (Oregon)

154 ms

189 ms

244 ms

211 ms

369 ms

172 ms

Europe (Ireland)

287 ms

448 ms

435 ms

451 ms

490 ms

313 ms

Asia Pacific (Singapore)

214 ms

449 ms

305 ms

449 ms

472 ms

235 ms

Asia Pacific (Sydney)

179 ms

451 ms

267 ms

647 ms

329 ms

156 ms

Asia Pacific (Japan)

150 ms

187 ms

238 ms

89 ms

174 ms

63 ms

South America (Brazil)

334 ms

446 ms

452 ms

543 ms

652 ms

313 ms


[표 1.1] Amazon region 별 latency test 결과 (주황색 셀은 1위 region)

위의 표를 보면 KT(전용회선)을 제외한 모든 곳에서 Japan지역이 가장 빠른 Latency를 보여주는 것으로 나타난다. 

그리고 KT(전용회선)도 Japan 지역이 1위는 아니지만 1위 지역과 차이가 거의 나지 않으며, KT를 제외한 다른 지역은 1위와 2위의 차이가 제법 나는 것을 확인할 수 있다.

한국에서는 테스트를 한 시점(2013년 12월)에서 광범위한 인터넷 서비스를 위해서 Amazon을 사용해야 한다면, 전 세계 8곳의 region 중 Japan을 사용하는 것이 가장 안정적인 Network Latency를 보장 받을 수 있을 것으로 판단된다.





2. HTML page(정적 콘텐츠) loading test


HTML로만 이루어진 정적 페이지의 로딩 속도를 측정해 보았다.


Amazon region은 latency test 결과에 의해 Japan지역을 선택했으며, 비교를 위해 국내 Cloud 서비스중 KT uCloud와 IDC에 있는 실제 서버를 함께 테스트 해보았다.


테스트에 사용한 HTML page의 size는 약 142K 정도이며, KT 전용회선을 사용하고 있는 PC에서 각각 20번씩 페이지를 호출해서 나온 load time과 latency의 평균을 서로 비교하는 방식으로 진행했다.



[그림 2.1] HTML page loading test 결과 그래프


테스트 결과 KT 에서 운영중인 uCloud에 있는 html page를 로딩할 때 속도가 가장 빠른 것으로 나왔다.

실제 IDC(KT영동) 보다 속도가 더 빠른것으로 나온것이 의아하긴 했지만, uCloud 테스트가 목적이 아니기 때문에 일단 패스하고, Amazon과 IDC(실 서비스 환경)의 load time을 비교해 보았다.


두 환경의 load time이 약 120ms 정도 차이가 나는데, 인터넷 전용선을 사용하는 PC에서는 채감상으로는 그렇게 크게 느껴지지 않았으나, 3G 환경에서는 속도의 저하를 확실히 채감할 수 있었다.


속도라는 것이 개인마다 느끼는 편차가 다르기 때문에 단정적으로 결론을 내리기는 애매하지만, 개인적으로는 쓸만한 정도, 다시 말해 빠르지는 않지만 스트래스를 받을 만큼 느리지도 않는 수준인 것 같다.



3. 외부(국내 IDC) 리소스를 경유할 경우에 대한 test


일부 리소스(예를 들어 DB 서버)를 국내 IDC에 두고 메인 시스템을 Amazon에 구축했을 경우, 페이지 로딩 속도가 얼마나 떨어지는지 확인을 위해 관련 테스트를 진행했다.

테스트는 국내IDC의 웹페이지를 읽어들인 다음, 그 내용을 그대로 재출력하는 페이지를 만들고, 정적 페이지 테스트처럼 각각 20번씩 페이지를 호출해서 나온 load time과 latency의 평균값을 비교하는 방식으로 진행했다.




[그림 3.1] 외부(국내 IDC) 리소스를 경유할 경우에 대한 test 결과


그래프를 보면 속도 차이가 확연한 것을 확인할 수 있다.

Amazon을 제외한 uCloud나 IDC의 경우는 직접 호출하는 것과 차이가 거의 나지 않는 것을 볼 수 있다. 즉 다시 말하자면, 외부 리소스에 접근해서 정보를 가져오는데 소모되는 latency가 아주 미미한 수준으로 볼 수 있는데, Amazon의 경우에는 약 2이상 속도 차이가 나는 것을 볼 수 있다.


결국, 국내 IDC에 DB서버를 두고 웹서버는 Amazon에 구축하는 방식의 시스템 구성은 현재로써는 힘들것으로 보인다.


다만 Amazon과 특정 지역의 네트워크를 직접 연결해서 네트워크 속도 및 latency를 줄일 수 있는 서비스 (AWS Direct Connect)가 있는 것 같은데, 이 서비스를 이용하면 되지 않을까 생각되지만, 서비스 이용료로 싸지 않은 듯 하고, 활용 가능성에 대해서는 좀 더 구체적인 리서치가 필요 할 듯 하다.





4. 결론


현재까지 총 3가지의 테스트에 대한 결과를 정리하고 결론으로 마무리 하고자 한다.


첫번째, Ping test에서는 북미나 동남아 서비스를 염두해 둔다면, 테스트를 다시 진행해 봐야 하겠지만, 현재 한국에서는 Japan 지역이 Amazon region중에는 가장 안정적인 네트워크 성능을 보장해주는 것으로 나타났다.


두번째, 정적 페이지 로딩 테스트는 일반적인 서비스 네트워크 품질을 가늠해보기 위한 테스트로 Amazon에서 시스템을 구축했을 때 네트워크 속도 측면에서 국내보다는 확실히 느려지는 것을 확인했지만,  서비스가 불가능한 수준은 아닌것으로 보였다.


세번째, 일부 리소스를 국내에 두었을때 속도 저하 추이를 보기 위한 테스트에서는 Amazon에서 추가적인 서비스(유료)를 받지 않는 이상, 서비스가 불가능한 수준으로 속도가 저하되는 것을 확인 할 수 있었다.  


국내에서 Amazon을 사용할 경우에는 region은 Japan으로 하는 것이 좋고, 모든 데이터 리소스를 Amazon에 함께 구축해 두는 것이 서비스 품질에 좋을 것으로 보인다.



Posted by 알 수 없는 사용자
,

얼마전에 아마존에 테스트 서버팜을 구성해야 될 일이 있어 아마존 서비스를 훓어보다 생각보다 광범위하고 꼼꼼한 서비스 종류에 놀란적이 있다.

그래서 현재 아마존 웹서비스(AWS: Amazon WebServices)에서 제공하고 있는 서비스들에 대해서 간단하게 정리해 보았다.


1. Compute
 
- EC2 (Elastic Compute Cloud)
클라우드 환경에서 서버를 할당 받아 사용할 수 있는 서비스, 서버 호스팅과 비슷한 개념이지만, 실제 물리적인 서버를 할당 받는 것이 아니라 클라우드 환경에서 가상 서버를 할당 받는 것이 다른 점.
 
- Auto Scaling
수요에 따라 EC2의 규모를 자동으로 조절 할 수 있는 서비스. 
예를 들어 web server의 cpu load가 50%가 넘어가면 새로운 web server를 추가하도록 세팅이 가능하다.
 
 
2. Networking
 
- DirectConnect
AWS와 직접 연결된 전용 네트워크 서비스 (AWS 네트워크와 직접 연결을 해주는 네트워크 사업자가 따로 있는듯)
 
- Route 53
DNS 서비스
 
- VPC (Virtual Private Cloud)
사설 네트워크 서비스
 
- Elastic Load Balancing
Load Balancing 서비스
 
 
3. Storage & Content Delivery
 
- Glacier
저비용 데이터 보관 및 백업 서비스. 자주 사용되지 않는 데이터를 보관 및 백업하는데 유용한 서비스 
 
- S3 (Simple Storage Service)
인터넷 스토리지 서비스. 웹에서 바로 접근 할 수도 있고, EC2에서 mount해서 사용할 수도 있다.
 
- EBS (Elastic Block Storage)
EC2 인스턴스에서 사용할 수 있는 블럭 레벨 스토리지. 용량, IOPS 설정등이 가능하다. 
* S3는 네트워크 스토리지, EBS는 서버에 추가할 수 있는 하드웨어 스토리지(SATA 하드 같은)로 이해하면 될듯.  
 
- CloudFront
콘텐츠 전송용 웹서비스. CDN과 비슷한 서비스로, 
EC2나 S3같은 서비스에서 사용시 가장 가까운 엣지로 자동 라우팅되서 콘텐츠 전송 속도를 향상할 수 있다.   
 
- Storage Gateway
aws의 스토리지와 로컬 스토리지를 연동해주는 서비스. 로컬에 있는 DAS, NAS, SAN 과 같은 장비와 S3를 연동해서 메인 데이터는 S3에 두고 접근빈도가 높은 데이터는 로컬 스토리지에 케싱하거나, 모든 데이터는 로컬 스토리지에 두고 일정 시간에 따라 주시적으로 데이터의 스냅샷을 S3에 저장하는 등의 서비스를 구축할 수 있다.
 
- Import / Export
대용량 데이터를 이동식 디바이스에 직접 import / export 해 주는 서비스. 외장 하드같은 디바이스를 Amazon에 우편으로 보낸 다음, 데이터를 Import 또는 Export 후 다시 돌려받는 방식. 
 
 
3. Database (BigData)
 
- RDS (Relational Database Service)
RDBMS 클라우드 서비스. MySQL, PostgreSQL, Oracle, SQL Server 지원. 
* EC2에 새로 Instance를 생성하고 직접 설치해서 사용할 수도 있지만 RDS를 사용할 경우 유지 보수 이슈를 획기적으로 줄일수 있다.(Amazon이 관리해주니까....) 하지만 서버에 직접 접근 권한이 없기 때문에 사용에 제한이 많기 때문에 서비스 종류나 기타 기업의 특성등을 잘 고려해서 선택해야 될 듯 하다. 
 
- DynamoDB
아마존에서 서비스하는 NoSQL 데이터 베이스 
 
-SDB (Simple Database )
비정규방식의 DB 서비스(??)
 
- Elastic Cache
Caching 서비스. Memcached, Redis 지원. 
 
- Redshift *Beta
빅데이터 분석 서비스 인듯. 
 
- EMR (Elastic MapReduce)
AWS상에서 서비스되고 있는 Hadoop 프레임워크 위에서 사용할 수 있는 MapReduce 서비스. 데이터의 종류나 양에 따라 Mapreduce에 필요한 리소스의 가변폭이 큰 경우 아주 유용할 듯.
하지만 사용하기 위해서는 반드시 Hadoop도 AWS상에 구축되어야 한다.
 
- Data Pipeline
서버 또는 스토리지간 주기적인 데이터 이동을 지원하는 서비스.
 
** MySQL, PostgreSQL, Oracle, SQL Server, Redis, Memcached를 제외한 다른 어플리케이션들은 직접 설치하거나 EC2에 새로운 인스턴스를 생성할때 Amazon Marketplace에서 패키징된 OS를 선택해야 함.
 
  
4. Deploy & Management
 
- CloudFormation:
클라우드 서비스를 생성 관리 할 수 있는 서비스. 
예를 들어 LAMP Formation 을 선택하고 생성하면 Linux + Apache + MySQL + PHP 환경에 맞는 클라우드 컴퓨팅 환경을 한번에 생성 할 수 있다.
 
- CloudWatch
클라우드 리소스 및 어플리케이션 모니터링 서비스 
 
- Elastic Beanstalk *Beta
웹 어플리케이션(php, Node.js, Python, Ruby, .Net등등)을 aws에 쉽게 배포할 수 있도록 도와주는 웹서비스
 
- OpsWorks
웹 어플리케이션을 Stack 구조 베이스로 생성 관리 할 수 있고, 어플리케이션을 배포할 수 있는 배포툴 서비스.
예를 들어, 웹서비스 Layer(PHP), HA Proxy Layer, DB Layer(MySQL) 등으로 Layer를 정의한 다음. 각 Layer에 서버를 몇대씩 할당할지 정할 수 있다.
OpsWorks를 사용하면 하나의 인스턴스를 셋팅하는데 들이는 노력으로 1,000대의 EC2 인스턴스에 한번에 어플리케이션 배포가 가능하다. 
 
- SWF (Simple Workflow Service) *Beta
서버단위의 Workflow를 설정 관리 할 수 있는 서비스(??)  
 
 
5. App Services
 
- CloudSearch *Beta
아마존의 서치엔진 서비스.
 
- Elastic Transcoder *Beta
동영상 트랜스코딩 서비스
 
- SES (Simple Email Server)
Email 서비스
 
- SNS (Simple Notification Service)
푸시 메세징 서비스
 
- SQS (Simple Queue Service)
메세지 큐 서비스 
 
 
6. 기타
 
- Mechanical Turk *Beta
무서운 서비스. 인간 지능(물리적인 지적 노동력) 사고 팔기 위한 마켓플레이스. 
쉽게 말해서 인력이 필요한 작업이 있을 경우(예를 들어 비디오 판독, 자막 제작 등등) 그에 대한 결과물의 형태, 보수, 자격 조건 등을 입력 후 마켓플레이스에 등록.
등록자가 제시한 자격 요건 테스트를 통과한 지원자들이 그 일을 해주고 보수를 받는 서비스 ..... 아마존이 노가다 인력 시장까지 진출하려고 한다. (투잡족에게는 좋은 알바소개소?)
 
- CloudHSM (Cloud Hardware Security Module)
보안키 보관 서비스 (??)
 
- Support
아마존의 기술 지원 서비스. 지원 범위가 커질 수록 가격도 올라간다.
 
- Product Advertising API
아마존 배너광고 관련 API


Posted by 알 수 없는 사용자
,

2013.09.26

이주현 (lee@embian.com, leejuhyeon@gmail.com)



I. 서설

 Java VisualVM(이하 VisualVM이라 한다)는 실행 중인 java 프로세스의 상태를 모니터링할 수 있는 좋은 도구이다. 이는 Oracle JDK에 포함되어 있으며, JDK 설치위치의 bin 디렉토리에 jvisualvm이라는 이름으로 존재한다.


 VisualVM은 로컬(VisualVM이 작동되는 머신과 동일한 머신)에서 실행 중인 java 프로세스 뿐만 아니라, 원격(VisualVM이 작동되는 머신과 상이한 머신)에서 실행 중인 java 프로세스 역시 모니터링할 수 있다.

 원격 모니터링의 경우, jstatd*[각주:1] 또는 JMX[각주:2]를 이용하는 두가지 방식을 제공하는데, JMX를 이용하는 것이 더 간단하고, 기능도 많다.


 이 글에서는 JMX를 활용하여 원격호스트의 java 프로세스를 모니터링하는 방법을 설명하고자 한다.




II. 환경설명

 다음과 같이 원격호스트와 로컬호스트가 존재하고, 원격호스트에서 실행 중인 Test라는 java 프로그램의 상태를 로컬호스트에서 VisualVM을 통하여 모니터링하기로 한다.






III. 방법


1. 원격호스트에서 실행될 Test.class 프로그램을 다음과 같은 환경변수와 함께 실행시킨다.




여기서 jvm 파라미터들은 다음과 같다.

-Djava.rmi.server.hostname=<원격호스트의 주소>

-Dcom.sun.management.jmxremote.port=<jmx프로토콜로 접속할 port번호>

-Dcom.sun.management.jmxremote.ssl=<ssl 사용여부>

-Dcom.sun.management.jmxremote.authenticate=<인증사용 여부>

* 여기서 인증사용 여부 등을 true로 하게 되면, jre 측에 별도의 보안 설정 등을 필요로 한다. 내부망이고 별도의 보안 정책이 없는 경우라면, 인증사용을 하지 않아도 충분하다.



2. 로컬호스트에서 VisualVM을 실행한다.



그러면 아래와 같이 VisualVM이 실행된다.





3. Visual VM에서 remote 접속을 수행한다.

 

 화면의 Applications 탭에서 Remote를 클릭하면, "Add Remote Host"라는 팝업이 뜬다. 이 팝업의 "Host name"에 원격호스트의 주소를 적어주고, OK 버튼을 누른다. (여기서는 원격호스트의 주소는 192.168.0.53이라고 가정한다)






그러면, 원격호스트가 Remote 항목 밑에 표시된다.



해당 원격호스트 항목에서 마우스 오른쪽 버튼을 클릭해서 "Add JMX Connection"을 선택한다.



 새로 열린 팝업 메뉴의 "Connection" 란에 원격호스트의 IP와 Port 번호를 적어준다. (본 예제의 원격호스트에서  java 프로세스를 실행할 때 지정한 JMX 포트 번호는 3333)



 그러면, Applications 탭에 원격호스트의 java 프로세스가 등록된 것이 보일 것이다.




 이제 해당 원격 프로세스 표시를 더블클릭하자. 그러면 다음과 같이 해당 java 프로세스의 상태가 표시될 것이다.




4. 이제 원격 java 프로세스의 상태를 모니터링한다.


아래와 같이 "Overview", "Monitor", "Thread", "Sampler" 등의 탭을 통하여 원격호스트 상의 java 프로세스의 상태를 모니터링할 수 있다.







IV. 결론

 원격호스트의 java 프로세스 상태를 모니터링함에 있어 jstatd를 사용하는 방법은, 별도의 rmiregistry를 기동하여야 하는 등 약간 귀찮은 면이 있다.

 이에 비하여 JMX를 활용하여 모니터링 대상의 JVM에 직접 접속하는 방법은 별도의 감시 데몬(jstatd)를 필요로 하지 않으면서도, 오히려 jstatd를 사용할 경우보다 다양한 기능(예를 들어 Heap Dump 등)을 제공하는 장점이 있다.



  1. java 프로세스의 상태를 감시하는 프로그램인 jstat의 데몬 버전 [본문으로]
  2. Java Management Extension [본문으로]
Posted by 쿨링팬
,