Like a hacker

YAJS에서 윈도우 환경의 wrapper.conf 설정시 Yet Another Java Service 자바 어플리케이션을 서비스로 등록하여 쉽게 실행/중단을 할 수 있는 랩퍼 서비스이다. 최근 윈도우에서 디렉토리 설정시 “/”와 “\”를 구분해서 써야 하는 것 때문에 좀 고생을 했다.

자바는 유니코드를 지원하는 프로그램 언어이다. 그렇기 때문에 왠만한 다국어 지원 문제는 별 탈없이 해결된다. 그러나 자바 프로그래머라면 한가지 주의해야 할 점이 있다. 자바의 문자열을 다루는 몇몇 함수들은 “Locale Sensitive”함수라는 것이다. 먼저 유니코드가 무엇인지에 대해서 짚고 넘어가자. 유니코드 > 정  의   유니코드(Unicode)는 전 세계의 모든 문자를 컴퓨터에서 일관되게 표현하고 다룰 수 있도록 설계된 산업 표준이며, 유니코드 협회(Unicode Consortium)가 제정한다. 이 표준에는 ISO 10646 문자 집합, 문자 인코딩, 문자 정보 데이터베이스, 문자들을 다루기 위한 알고리즘 등을 포함하고 있다. > 목  적  유니코드의 목적은 현존하는 수많은 문자 인코딩 방법들을 모두 유니코드로 교체하려는 것이다. 기존의 인코딩들은 그 규모나 범위 면에서 한정되어 있고, 다국어 환경에서는 서로 호환되지 않는 문제점이 있었다. 유니코드가 다양한 문자 집합들을 통합하는 데 성공하면서 유니코드는 컴퓨터 소프트웨어의 국제화와 지역화에 널리 사용되게 되었으며, 비교적 최근의 기술인 XML, 자바, 그리고 최신 운영 체제 등에서도 지원하고 있다. 원본 위치 [Wikipedia](https://ko.wikipedia.org/wiki/유니코드)  UTF-8  UTF-8은 유니코드를 위한 가변 길이 문자 인코딩 방식 중 하나로, 켄 톰프슨과 롭 파이크가 만들었다 UTF-8 인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지를 사용한다. 예를 들어서, U+0000부터 U+007F 범위에 있는 ASCII 문자들은 UTF-8에서 1바이트만으로 표시된다. 4바이트로 표현되는 문자는 모두 기본 다국어 평면(BMP) 바깥의 유니코드 문자이며, 거의 사용되지 않는다. 원본 위치 [Wikipedia](https://ko.wikipedia.org/wiki/UT

  빅데이터에 대해서 말할 때 아직은 모두가 동의하는 정확한 정의는 없습니다. 단순히 이런 것을 빅데이터라고 하면 되지 않을까라고 추상적으로 생각하는 것이 대부분입니다. 빅데이터에 대해서 이해하기 쉽게 설명하기 위해서 빅데이터의 3가지 속성 3V , 여기에 한가지, 두가지를 더해 4V, 5V 라고 정의 해보기도 합니다.    그러나 빅데이터에 대해서 좀 더 쉽게 접근하기 위해 저는 영화 ‘이미테이션 게임’을 예로 들고 싶습니다. 영화 ‘이미테이션 게임’   영화 “ 이미테이션 게임 ”은 컴퓨터의 초기 개념을 제시한 튜링 머신을 고안해낸 수학자, 앨런 튜링에 대한 이야기입니다. 영화에서 튜링이 맡은 임무는 독일군의 암호를 해독하는 것입니다.  독일군 작전 명령은 전파를 통해 장비만 있으면 누구나 들을 수 있었습니다. 하지만 절대 해독이 불가능한 암호라고 칭해지던 ‘에니그마’로 암호화되어 있어서 연합군은 이를 해독할 수 없었습니다.  24시간 마다 1,590억의 10억 배 경우의 수가 생성되는 ‘ 에니그마 ’는 사실상 해독이 불가능하다고 여겨졌습니다. 만약 10명이 하나의 설정을 1분간 확인한다고 하면 매일 24시간씩 일주일 내내 모든 설정을 다 확인하려면 약 2천만 년이 걸리기 때문입니다.. ‘에니그마’ (Enigma; 그리스어로 ‘수수께끼’를 뜻한다)   엘런 튜링은 사람의 머리, 사람의 힘으로는 암호를 재시간에 풀 수 없다는 것을 직감합니다. 그래서 암호를 풀 수 있는 기계를 고안하고, 이를 이용해 암호를 풀려고 한 것입니다. 그러나 완성된 기계만으로 암호를 풀어내는데 실패합니다. 여기에 자주 쓰이는 평문의 목록인 크립을 이용하자는 아주 기가막힌 아이디어가 더해져 결국에는 암호를 풀어낼 수 있게 됩니다. 이로써 연합군은 독일군의 작전 명령을 가로챌 수 있었고, 전쟁에서도 승리할 수 있게 되었습니다. 앨런 튜링은 1,400 만 명의 연합군 목숨을 구한 천재 수학자라는 칭호도 얻게 됩니다.   앨런 튜링과 독일군 암호,

ESP(Event Stream Processing) 센서, CCTV등 다양한 소스(Source)에서 들어오는 실시간 이벤트를 이벤트 스트림 이라고 한다. 그리고 이벤트 스트림을 받아서 이를 실시간으로 처리하는 것을 Event Stream Processing이라고 한다. 처리라는 것은 대부분 특정 이벤트에 대해서 사용자가 원하는 동작 또는 알람을 보내는 작업을 말한다. 이슈 발생 대용량 이벤트 처리 기술은 항상 퍼포먼스와 안정성이 중요하다. 지금은 서버에서 Drools Fusion 을 사용하고 있다. 이전 버전에서 Esper 를 사용하였으나 라이센스 문제로 인해서 Drools Fusion으로 옮겨왔다. 문제는 성능 테스트 중에 발생하였는데 메모리 leak 문제였다. “Always” 문제였기 때문에 문제점 파악은 쉽게 되었다. 테스트 방법 * 5대의 서버를 준비 * JMeter  _를 이용하여 throughput을 조절해가며 이벤트 발생 * 1대의 서버에 서버 App 실행 * JConsole 을 이용하여 JVM Heap 사이즈를 모니터링 결론 최종적으로 이벤트가 고속이든, 저속이든 Heap 사이즈가 늘어난다는 판단 분석 방법 JMap 을 이용하여 Memory Dump하였다. 그리고 메모리 덤프 분석툴인 MAT 를 이용하여 Dump 분석 결과를 확인 분석 결과 모든 이벤트 오브젝트가 Drools hashmap에 reference되어 있었다. 문제 해결 과정(How to solve) 우선은 내 코드들을 의심해봤다. 이벤트 수신, Pooling, 처리, 저장, DB Access 부분을 모두 훓어 보았다. 그러나 문제가 될 만한 부분은 찾지 못했다. 이건 뭐지? 내 상식 이상의 뭔가가 있나 한참을 고민했다. 결국은 소스 코드를 링크해서 디버깅을 해야하나, 소스 코드 분석을 해야하나 고민하면서 Drools 메뉴얼을 훓어 보다가 머리 속에서 스파크가 팍 튀었다. 다음은 Drools

자바스크립트 보안 정책 바로알기! Same Origin Policy 웹 리퀘스트 자신이 포함된 문서와 출처가 동일한 문서나 창의 프로퍼티만 읽을 수 있다. 출처 = 프로토콜 + 호스트 + 포트 Cross Domain 전제조건 현재 웹페이지의 주소는 http://www.ryanjin.net 이다. http://www.ryanjin.com의 페이지에서 http://www.google.com의 Rest API 를 호출하여 데이터를 가져오려고 한다. 결     론 서버의 도메인, 정확히 말하면 위에서 언급한 출처가 다를 경우 cross-domain 문제가 발생한다. 이러한 cross-domain은 서버 공격 및 보안 취약성을 갖게 되므로 서로 신뢰할 수 있는 경우에만 이를 허용하는 서비스를 구축하는 것이 일반적이다. Cross Domain 제약 극복 방법 Cross domain proxy 클라이언트는 서버의 API를 호출하고 웹 서버가 실제 호출하려는 원격 서버의 API를 호출하는 방법입니다. 그리고 그 결과를 클라이언트에 돌려줍니다. Proxy 방법은 호출하는 전체 생명주기를 제어할 수 있습니다. 클라이언트에게 반환하기 전 뭔가 처리할 게 있으면 원격 서버에서 받은 데이터를 변환, 가공할 수도 있습니다. Cross domain JSON 원격서버가 지원해야지만 사용할 수 있는 방법입니다. 원격서버는 Callback 함수 성격의 추가 파라미터를 받습니다. 원격 URL을 지정할 수 있게 클라이언트에 스크립트 태그를 넣어야 합니다. 요청에 지정한 callback 함수와 그 파라미터로 JSON 객체가 응답으로 옵니다. 서버에 어떤 작업을 하지 않아도 웹서비스 호출을 구현할 수 있다는 점입니다. (참고) Jason Levitt가 XML.com에 쓴 “JSON and the Dynamic Script Tag” (참고) 원리를 알고 싶으면 “Cross domain JSON 원리”를 참조하

Java heap management 자바의 메모리 관리는 garbage collection 의 효율성을 높이기 위해 존재한다. 자바의 특징 중 하나는 JVM이 자동으로 메모리 관리를 하는 것이다. 정확히 말하자면 메모리 해제만을 자동으로 한다. 그리고 이 기능을 garbage collection이라고 한다. Fig 1. Layer of heap 그림 1에서 볼 수 있듯이, heap 메모리 영역은 Eden 과 Tenured 로 크게 2 영역으로 나눠진다. Eden Eden은 자유영역 정도로 볼 수 있다. Object의 생성/소멸이 자유롭게 또는 빈번하게 이뤄지는 영역이라는 뜻으로 볼 수 있다. Tenured Tenured는 종신 영역이라 번역할 수 있는데, object가 이곳에 들어가면 빠져 나올 수 없다고 이해하는 것이 쉽다. 실제로 이런 이름이 어울리는 이유는 생성/소멸의 빈도에 따라 object의 위치를 바꾸기 때문이다. Fig 2. Heap에서의 object 이동 그림2를 보면 heap 에서의 object의 이동을 원리를 알 수 있다. Minor GC(=Young GC) Eden 영역에 "new" 연산자에 의해 Object가 생성된다. 설정된 비율 이상의 객체가 Eden에 할당된다. Eden +From Space( S0 )에서 Minor GC (소규모 객체 해제, Young GC라고도 한다.)가 일어난다. 객체 중 참조(reference)가 없는 객체는 메모리 해제시킨다. 객체 중 참조가 남은 메모리는 To Space( S1 )으로 보낸다. 설정된 비율 이상의 객체가 Eden에 할당된다. Eden +From Space( S1 )에서 Minor GC (소규모 객체 해제, Young GC라고도 한다.)가 일어난다. 객체 중 참조(reference)가 없는 객체는 메모리 해제시킨다. 객체 중 참조가 남은 메모리는 From Space( S0 )으로 보낸

Projection Spring Data REST에서는 Projection 기능을 제공하고 있습니다. Spring Data란?   Data Access Layer에 대한 추상화 기능을 제공하는 프레임워크입니다. 간단히 설명하자면 기존에는 Database에 데이터를 저장하고 읽어오기 위해서는 Database의 종류, 스키마를 고려하여 SQL Query를 사용해서 데이터를 저장하고 읽어왔습니다. 그러나 Spring Data를 이용하게 되면 이 과정을 ORM을 사용하여 함수를 사용하여 쉽게 처리할 수 있습니다. ORM(Object Relational Mapping)란?   데이터베이스가 테이블, 필드간 상관 관계를 통해 도메인 데이터를 표현하였다고 한다면,  ORM은 Object, 클래스 간의 상관 관계를 통해 도메인 데이터를 표현하는 것을 말합니다. 다음의 링크는 Spring Data REST Documentation 중에서 Projection 부분입니다.               8. Projections and Excerpts 그러나 실제 "Projection" 기능을 사용하는데는 한가지 문제점이 있습니다. 레거시 웹서비스를 쓰고 있다거나, Spring Data  REST를 이용하지 않는다면 "Projection" 기능을 활용하는 것이 힘들다는 것입니다. Spring Data REST의 경우 데이터  Response Type이 json-hal 타입만을 지원하기 때문입니다. JSON-HAL 타입으로 경우 웹서비스 제공 입장에서 최선의 선택일 수 있습니다. 그러나 실제 프로젝트에서는 이를 쓰려는 클라이언트가 없을 경우 사용할 수 없게 될 것입니다. 그렇다면 Projection 기능만을 사용할 수 있는 방법이 없을까요? 있습니다. ProjectionFactory 를 직접 사용하는 것입니다. 다음과 같이 Spring + Gradle을 사용하여 테스트 프로젝트를 만들어보겠습니다.

REST Web Service에서 Projection을 이용한 웹 인터페이스 유연성 확보하기. Projection 기능이란?   프로젝터와 같이 실제하는 물체를 보고 싶은 형태로 볼 수 있게 도와주는 기능을 말한다. 좀 더 쉽게 말하면 실제하는 물체란 필름을 말하는 것이고, 보고 싶은 형태란 70인치 화면으로 보여주는 것을 말한다. 설정에 따라 30인치 화면으로 볼 수도 있다.   즉, Projection 기능이 있다면 상황에 맞는 화면 크기로 보여 줄 수 있는 것이다. [프로젝터] 웹 인터페이스 설계의 어려움   웹서버를 개발하는 개발자 입장에서 하나의 인터페이스라도 만드는 일은 쉽지 않다. 그렇기 때문에 웹 인터페이스의 개수를 줄이려고 노력하는 것이 일반적이다. 그러기 위해서는 좀 더 일반적인(General) 형태의 인터페이스로 설계하는 수밖에 없다. 그러나 아이러니하게도 사용자(인터페이스를 사용하는 다른 개발자) 입장에서는 이런 일반적인 인터페이스를 쓰기란 여간 어려운게 아니다. 클라이언트마다 필요한 데이터가 다르다.  REST 웹서비스에서는 리소스에 해당하는 데이터를 다음과 같이 JSON 형식의 Response로 전달해준다. 예를 들어 다음과 같이 상품 정보를 보내주는 RESR API가 있다고 해보자. GET /api/furniture/item/123334333 위의 REST API를 이용하여 다음과 같은 데이터를 받을 수 있다. { "item_id" : 1233343333 , "name" : "chair" , "category" : "furniture" , "price" : 56000 , "seller" : "Makers" , "description" : "Goo