제피노스 블로그

2018-03-17T05:34:00.000+09:00

blogger 에서 내가 남기는 마지막 포스트가 될 지도 모르는 글...

오늘도 삽질을 진행했다.

phabricator 설치...

예전에 Docker 로 설치해서 일 년 넘게 운영한 적이 있었으나, 그냥 Ubuntu 에 깔끔하게 설치하는 방법을 선택했다.

그리고...

...

...

역시나 삽질은 시작되었다.

이 글을 쓰는 시점에서 LTS 는 16.4, 최신 버전은 17.10 이었는데...그냥 16.4 을 선택한게 화근이었다.

16.4 에는 PHP 7.0 이, 17.10 에는 PHP 7.1 이 기본 패키지로 들어있고, PHP 7 에서는 제대로 설치가 안된다. 16.4 에는 저장소에 phabricator 가 패키지로 올라가 있어서 제대로 설치될꺼라 생각을 했으나, PHP 7.0 에서는 apc 라는 cache 가 제공되지 않고 호환성 문제가 생겨서 제대로 설치가 안되었다. 물론 apc 을 pear 을 설치해서 pecl 로 설치하거나 apc 소스를 내려받아 직접 컴파일하는 방법도 있겠다.

난...

그냥 17.10 으로 버전을 올려서 PHP 7.1 로 그냥 시도했다. 여기에는 phabricator 가 패키지로 제공되지 않아서 일일이 수동 설치중이다...

삽질의 연속,고난의 연속이다.

16.4 에 PHP 5 버전을 설치하는 방법도 있지만, 의존성 문제에서 절대 자유로울 수 없는걸 알기에(phabricator 전용 서버가 아닌 것도 이유) 속편한게 최고다.

Apps2Fire 을 통해 Fire TV Stick 에 KODI 을 설치할 때 INSTALL_FAILED_NO_MATCHING_ABIS 가 발생하는 문제

2017-02-25T12:36:00.000+09:00

LG TV 에서 NAS 의 동영상 보는 것은 도저히 못해먹을 짓이라는 걸 드디어 인정하고(USB 로 퍼다 날라도 안되는건 안되는 것임) Amazon Fire TV Stick 을 네이버페이에 입점한 구매대행을 통해 새걸로 구입했습니다. 좀 비싸도 그냥 신경 끄고 있으면 되니까...

물건이 부족해서 오늘...주문 후 16일만에 받았는데...KODI 을 Apps2Fire 라는 앱으로 쉽게 옮길 수 있다고 하는데, INSTALL_FAILED_NO_MATCHING_ABIS 오류가 발생했습니다. 실험적으로 DS Video 을 옮겨봤는데 잘 되었습니다.

이리 저리 방법을 찾다 보니 adbLink 라는 프로그램을 알게되었고, 여전히 오류가 발생해서 INSTALL_FAILED_NO_MATCHING_ABIS 오류를 검색해보니(화면에 나온걸 다 적기 어려워서 adbLink 오류 났을 때 로그 파일 내에서 문구를 찾아냄) CPU 가 휴대전화와 조금 달라서 그런 걸로 보여졌습니다. x64 용으로 기본 설치가 됐는데, Fire TV Stick 은 x86 만 지원되는 것으로 보이네요.

kodi-17.0-Krypton-arm64-v8a.apk 대신에 kodi-17.0-Krypton-armeabi-v7a.apk 을 adbLink 프로그램으로 설치해주니 잘 되네요.

JSON 에 대한 간략한 생각

2016-10-02T01:24:00.001+09:00

제목이 좀 애매한데...그냥 개인적으로JSON 데이터 구조를 설계하는데 조심해야 할 한가지(어떻게 보면 프로그래밍에서의 설계 방식에 대한 기본 중 하나가 아닐까 하지만)에 대한 잡설입니다.

지금은 아주 약간 시간이 지났지만, JSON 에서 데이터를 만드는 부분에 있어 어떤 사람과 논쟁이 발생한 적이 있었습니다. 저는 중간에 그냥 대화가 힘들 것을 직감하고 대화를 끊었지만, 그 이후에도 다른 사람과 계속 논쟁을 이어 가더군요. 좋은 의미의 논쟁이었으면 좋았겠지만 좀 어거지 수준의 대화도 일부 있어서...그냥 눈팅하면서도 좀 짜증이 나더군요.

논쟁이 일어난 계기는 질문자가 아래와 같은 늬앙스의 질문을 했기 때문입니다.

JSON 으로 웹의 그리드에 표시할 데이터 목록을 보내려고 하는데, 생성할 때의 키 순서와 달리 실제 String 으로 변환되어 나온 JSON 에서는 생성한 순서처럼 내용이 생성되어 있지 않다. 방법이 없을까?

그리고 질문자가 올린 것을 보니, JSON Object 에 key 로 "A", "B", "C" 와 같이 순서를 위해 특정값을 넣고, 뒤에 해당 줄에 표시할 내용을 value 로 넣었더군요.

처음에 질문을 봤을 때 그냥 String 으로 직접 만들면 순서가 흐트러지지 않는다고 하려다가...이건 좀 아니다 싶어서 좀 더 원론적인 답변을 했습니다.

JSON Array 는 순서가 유지됩니다. 말씀하신 내용의 정보를 보낼 때에는 그냥 JSON Array 로 데이터를 보내시는게 맞습니다. 그렇게 내용을 변경해보세요. 받는 쪽에서도 순서가 뒤바뀌지 않기 때문에 이렇게 구조를 바꾸시는게 좋습니다.

그런데, 뒤에 어떤 사람이 Google 의 Gson 을 이용해서 입력된 순서...가 아닌, key 의 정렬을 유지한 채(key 정렬 순이 원 질문자의 의도가 맞긴 합니다)로 String 을 만들어내는 이야기 했습니다. 물론 받는 쪽은 Javascript 였으니 Gson 은 없겠지만 말입니다.

제가 이 사람의 댓글에 문제를 제기하면서 사태가 커졌습니다.

말씀하신 방법대로 정렬을 해서 보내는 방법도 좋지만, 그런 식으로 String 을 생성해도 받는 쪽에서 순서를 유지하는 방법을 쓰지 않으면 다시 순서가 흐트러지기 때문에 그런 방법은 좋지 않습니다.

이런 늬앙스였습니다.

그 사람은 질문 내용 그 자체에 대한 답변에만 충실하면 되지 않느냐, 이렇게 하면 정렬된 문자열이 나오는데 무슨 문제냐...등...반발을 심하게 했죠.

그래서, 여기에 대해서 이야기를 하려고 합니다.

먼저 JSON 의 특성 중 일부를 짚고 넘어가야 겠네요.

JSON 은 Obejct 라고 불리는 구조로 이루어져야 합니다. Object 는 key 와 value 로 이루어져 있는 단순한 집합이고, 각 key/value 쌍은 콤마로 구분되어 여러 개가 저장될 수 있습니다. 그리고 "key 는 순서가 유지되지 않습니다".
이 Object 는 String 으로 된 key 와 여러 형태의 value 을 가질 수 있는데, 숫자형(double), 문자형(String), 참/거짓(Boolean) 뿐만 아니라 null 이나 JSON Object, JSON Array 같은 구조도 가질 수 있습니다. 여기서 JSON Array 는 흔히 말하는 배열과 같은 형태 같지만, 사실 각 값들은 여러 자료형이 섞여서 들어갈 수 있기 때문에 Java 의 Object[] 나 List 에 가깝다고 이해하는게 맞습니다. List<Object> 라고 할까요.
어쨌든 표준 JSON 문장은 이런 특징 때문에 Java 라이브러리에서는 통상적으로 JSON Object 는 HashMap 으로, JSON Array 는 ArrayList 로 대응되어 구현되고 JSON String 을 Java Bean 개체와 마샬링/언마샬링 할 때에 자동으로 HashMap 과 ArrayList 로 변환되어 저장되는 경우가 대부분입니다(대부분이 이유가 JSON 을 다루는 라이브러리는 하나가 아니니까요).

그리고, JSON 은 Javascript 에서 이용되기 위해 처음 고안된 방법이다 보니 Javascript 에서 아무런 추가 라이브러리 없이 바로 처리가 가능합니다. 그리고 Javascript 에서는 key 순서를 애초에 보장하지 않기 때문에 String 으로 정렬된 형태로 받는다고 해도 결국 순서대로 Object 의 key 들을 가져오지 못합니다. 정렬의 개념도 내부적으로 없구요. 그렇기 때문에 JSON Object 의 키는 언제든 순서에 상관없이 빠르게 처리할 수 있는 형태대로 내부에서 저장하고 있다고 이해한 상태에서 개발해야지, 이를 순서대로 뽑아낼 것이라고 생각하고 프로그래밍 하는 것은 의미가 없습니다.

문제는, 질문자의 경우 "A", "B", "C" 와 같이 순서대로 key 을 정렬하여 String 을 저장한 뒤 받는 쪽에서 역시나 순서대로 하나씩 꺼낼 생각을 하고 있겠지만...이건 양 쪽 모두 한 사람이 프로그래밍을 하거나 문서를 잘 만들어서 이후에도 받는 쪽에서 변함없이 이렇게 처리하도록 프로그램을 유지해야 가능한 방법입니다. 예전 제 글(http://zepinos.blogspot.kr/2016/09/mybatisibatis-oralce-sequence.html)에서도 말한 적이 있지만 프로그램을 영원히 혼자서 만드는 경우가 아니라면 가급적 표준을 지키고, 문제가 발생할 가능성이 최대한 적은 쪽으로 프로그래밍을 하는 습관을 가지는게 중요합니다. 그런데 굳이 표준을 지키면서 개발할 수 있는걸 이렇게 엉뚱하게 프로그래밍을 하려고 하는 것도 그렇고(초보니까 이럴 수도 있죠), 그걸 알면서도 질문에 대한 답만 해야한다고 주장하는 것도...좀 질 나빠 보이는건 어쩔 수 없더군요.

그리고, 보통 이런 리스트를 DB 에서 가져올 때 List 개체에 담아서 가져오기 때문에 이걸 그냥 Map.put("키", List) 와 같이 담고 JSON String 으로만 변환하면 자동으로 "키" 에 JSON Array 형태로 JSON Object 들이 순서대로 담겨져 들어가있을 것입니다. 너무나 쉽고 for 을 써가면서 "A", "B", "C" 와 같이 키를 만들 필요도 없고(당연히 사용자가 매우 많아지면 서버 측의 속도 저하가 필연적으로 따라옵니다), List 의 개수가 가변적일 경우 대응하기도 쉽습니다(사실상 코드를 고칠 필요가 없습니다). 받는 쪽에서도 어떤 라이브러리를 이용하든 Array 형태의 데이터는 순서가 바뀌지도 않구요.

실제로 많은 Javascript grid 라이브러리들은 데이터를 JSON 으로 동적으로 가져올 때 JSON Array 형태로 값을 요구합니다. 그렇기 때문에, 이러한 방법은 매우 보편적인 방법이라고 할 수 있습니다. 만약, 어떤 라이브러리에서 리스트 형태의 데이터를 binding 할 때 Array 형태가 아닌 key 의 정렬 순서대로 값을 Object 에서 가져오도록 되어 있을 때...과연 이 라이브러리가 잘 짜여진 프로그램이라고 생각할 수 있을까요? 저라면...이런 라이브러리는 안쓸 것 같은데요...

특히 JSON 은 주석을 달 수 없기 때문에 데이터만 가지고 그 정보의 내용을 유추해야 하는 경우도 많고, 문서가 없을 경우 자신만의 독특한 구조로 데이터를 구성한다면 협업하는 입장에서 피해야할 개발자로 낙인 찍히기 쉽습니다. 이 점 유념했으면 좋겠습니다.
그런 의미에서, YAML 을 주목하고 있습니다. Spring Boot 의 기본 설정 파일 형식 중 하나로 이용되고 있는데, parsing 속도가 아직은 매우 느리다고 합니다만, 주석도 담을 수 있고, 계층 구조와 List 등도 모두 지원하기 때문에 JSON 을 대체하는 좋은 방법이 될 수 있을꺼란 기대가 있습니다.

마지막으로, 이 때의 일을 소회하자면...끝까지 이 내용 가지고 질질 끌면서 어거지 쓰면서 새 글까지 써대면서 질문자의 글에 대한 내용만 답변해야 하는거 아니냐고 동조자를 모으는 모습을 보이던데...중간에 빨리 발 빼길 잘했다는 생각이 들었습니다. 저와는 맞지 않는 사람이란 걸 느꼈습니다. 저와의 이 일이 있기 전에 더 큰 일이 있고, 상대방과 코드까지 공개하면서 논쟁을 벌였는데...상대방이 반말을 막 하는 모습 때문에 상대방을 안좋게 보았는데...그 때도 말꼬리 잡는 것 때문에 상대방이 좀 짜증은 났겠다는 생각이 들었습니다. 말꼬리라고 하는 것도...숲은 안보고 나무만 집요하게 들이밀면서 상대의 말실수를 가지고 끝까지 공격하는 모습은 좋지 않게 보였는데...저도 당하고 보니 다시는 상대하고 싶지 않은 사람이더군요. 그래서 내린 결론이..."절대 대응하지 않는다", "없는 사람으로 대응한다" 입니다. 이 글도 여기 쓰는 목적이고...

혹시 그 당사자가 이 글 봤다면 개인 블로그에 혼자 떠드시길 바랍니다. 해당 커뮤니티에선 제 이미지 관리(?) 차원 뿐만 아니라 공공성이 있는 곳에서 분탕치기 싫어서 조용히 있었던 거지, 당신의 내용에 동의하거나 납득하기에 그만하는게 아니라는거...알길 바랍니다. 벼로써 키는 충분히 자라기는 했는데 아직 고개를 숙이는 단계까지 가질 않은 것 같아서 이해는 하긴 합니다만, 나중에 이불킥 할 일 늘리지 마세요.

MyBatis(iBatis) 에서 Oralce 등의 Sequence 을 쓸 때 을 권장하는 이유

2016-09-17T02:20:00.000+09:00

이 글을 쓰는 시점에서 약간 지난(2~3주 쯤 된 것 같다) 시점에서 한 커뮤니티에 대략 아래와 같은 글이 올라왔다.

Oracle, MyBatis 을 쓰는데, 아래와 같이 insert 을 할 때 문제가 발생합니다.
insert into 테이블 (컬럼1, 컬럼2, ...) values (sequence.nextval, 값2, ...)
insert into 테이블 (컬럼1, 컬럼2, ...) values (sequence.currval, 값2, ...)

위와 같이 작성했는데 문제가 된다면 보통은 트랜젝션을 선언해주지 않아서 다른 세션으로 insert 가 실행되었을 가능성이 크다.

그런데, 애들 때문에 시달리는 와중에 모바일로 내용을 보고(애들 때문에 컴을 켤 엄두도 안난다)...세션 생각은 덜 한 상태에서, 조금 틀린 내용을 포함한 답을 해줬다. 질문자가 이미 트랜젝션을 해주니 문제가 해결되었다고 댓글을 달았는데, 저렇게 하지 말라고 오지랍을 떤 것이다.

물론 밤 늦게 글이 달렸었고, 그 사이 다행이도 다른 댓글이 달리지 않았고, 출근길에 전철 안에서 세션 단위로 값을 제공하기 때문에 같은 세션에선 거의 발생하지 않는다는...댓글 수정이 아주 불편한 모바일을 감안해서 약간의 변명스러운 댓글을 달았다. 물론 세션 문제를 제외하고, 저런 식의 코딩이 위험하다는 건 변함이 없었지만...

그런데, 모든 댓글에 -1 이 달렸다. 그 커뮤니티에서는 질문/답변 게시판에서 댓글에 1 점 혹은 -1 점을 줄 수 있는데, -1 점이 달린 것이었다. 그 커뮤니티가 나름 프로그래밍 쪽에서는 많은 회원을 가진 곳이긴 하지만 답변 내용이 틀렸다고 저렇게 -1 점을 막 주는 사이트는 아닌데...하면서 의문을 가졌지만 곧 의문이 풀렸다.
다른 사람들끼리 약간의 논쟁(이라 쓰고 싸움이라 읽을 수도 있다)이 벌어지면서 누가 점수를 그렇게 줬는지 알아버렸기 때문이었다. 다만, 그 사람이...내가 다시는 그 사람의 글이나 댓글 등에 반응을 일체 하지 않겠다고 혼자서 결심한 사람이었기에 문제가 되었지만...그래서 이 글을 쓰고 있는 것이기도 하다.

심지어 그 댓글들 때문에 상대에게 별 의미도 없는 -1 점 주는 행동에, 나에게 -1 점을 막 주던 그 사람은 자기에게 -1 점 줬다고 다른 사람들을 비난하기 시작했고, 그 글에서 단 한 번도 나오지 않는 MS SQL Server 에서의 문제까지 가지고 나와서 시덥잖은 변명까지 하기 시작했다.

그래서 이 글을 적는다.

먼저, 글의 내용처럼 오라클에 한해서만 예제를 테스트했다. 그리고, 이런 경우는 극히 발생하지 않는다는 것도 덧붙인다. 다만, 난 겪었었던 일이었고...그게 경력이 가지는 무서움이라는 것이다. 일하던 산업군이 다양했던 것도 한 몫 했을 것이다. 특히 금융권 같이...한 번 일하기 시작하면 그 산업군을 벗어나는 경우가 드물고, 코드 자체를 매우 보수적으로 개발하고 운영 역시 그러한 곳에서는 이런 일은 발생하지 않을꺼라 본다. 하지만, 저 질문을 한 사람에게 저걸 쓰는게 뭐 어때서...라고 추천하는 순간 이런 황당한(하지만, 사실 예상할 수도 있다) 경우를 겪을 수 있는, 일종의 버그를 만들 수 있는 코드를 작성하는 개발자 하나를 탄생하게 만드는 것이다. 물론 공개된 곳의 글이기 때문에 한 명에서 그치지 않을 수도 있고(그래서 글 내용만 가지고 기계적인 답변을 달지 말라고 그러는 것이다)...

github 에 전체 코드를 올리면 좋겠지만, 뭐 좋은 코드라고 올리겠는가...그냥 대충만 적는다.

먼저 DB 를 만든다.

create table log (seq int PRIMARY KEY , group_seq int, message varchar2(1000));
create sequence seq_log_seq;
create sequence seq_log_group_seq;

아래와 같은 두 개의 쿼리를 만든다.

<mapper namespace="com.zepinos.mapper.Log1Mapper">
    <insert id="insertLog1" parameterType="Log">
        insert into log (seq, group_seq, message) values (seq_log_seq.nextval, seq_log_group_seq.nextval, #{message})
    </insert>
</mapper>

<mapper namespace="com.zepinos.mapper.Log2Mapper">
    <insert id="insertLog2" parameterType="Log">
        insert into log (seq, group_seq, message) values (seq_log_seq.nextval, seq_log_group_seq.currval, #{message})
    </insert>
</mapper>

그리고 한 개의 서비스를 만들어서 두 쿼리를 실행하도록 한다.

@Service
public class TestServiceImpl implements TestService {

    @Autowired
    private Log1Mapper log1Mapper;
    @Autowired
    private Log2Mapper log2Mapper;

    @Transactional
    public void test() {

        Log log = new Log();
        log.setMessage("Test1");

        int result = log1Mapper.insertLog1(log);

        if (result > 0) {

            log.setMessage("Test2");

            log2Mapper.insertLog2(log);

        }

    }

}

큰 문제가 없다면, 아래와 같이 출력될 것이다.

1    1    Test1
2    1    Test2

너무 당연하다. 두번째 컬럼인 group_seq 는 일종의 레코드의 그룹을 알려주기 위해서 하나의 트랜젝션에 같은 값을 가지게 하기 위해서 저렇게 만드는 경우가 있다. 실제 내가 지금 만들고 있는 게임 서버의 로그도 저런 식으로 하나의 트랜젝션(사용자의 한 번의 작업)에 그룹을 구별하기 쉽게 하고, 순서도 별도 컬럼에서 넣기도 한다. 즉, 저런 코딩이 없는 경우가 아니란 것이다. 그리고 원 질문자의 말처럼 currval 은 잘 작동한다.

하지만, 내가 겪은 일은...아쉽게도 저런 식의 코드를 짠 사람이 뭔가 실수해서 발생한 것이 아니었다. 심지어, 문제를 일으킨 코드를 작성한 사람이 잘못한 것도 아니었다. 오히려 괜찮은 실력에, 개발자로써의 자질(게으름!)도 가지고 있었기에 발생했던 것이다.

이걸 쉽게 구현하기 위해서 다음과 같은 코드를 만들었다.

먼저, 그냥 쉽게 하기 위해서 위에서 만든 테이블에 값을 넣는 동일한 쿼리를 만들었다. 물론 내가 겪었던 사이트는 이것조차 만들지 않았다. 빨리 만드느라 이렇게 된 것이니 양해를...

<mapper namespace="com.zepinos.aspect.TimeMapper">
    <insert id="checkTime" parameterType="String">
        insert into log (seq, group_seq, message) values (seq_log_seq.nextval, seq_log_group_seq.nextval, #{message})
    </insert>
</mapper>

그리고 아래와 같은 클래스를 생성했다. 두둥...

@Aspect
public class InsertRunTimeChecker {

    @Autowired
    private TimeMapper timeMapper;

    @Around("execution(* com.zepinos.mapper.*Mapper.insert*(..))")
    public Object insertAround(final ProceedingJoinPoint joinPoint) throws Throwable {

        long time = System.nanoTime();

        Object proceed = joinPoint.proceed();

        timeMapper.checkTime("Spend Time : " + (System.nanoTime() - time));

        return proceed;

    }

}

뭐...금방 눈치챈 분들도 계시겠지만...

이 코드는 위에서 개발한 두 개의 insert 의 동작 시간을 로그에 추가적으로 남기기 위한 코드다. Aspect 을 이용해서 말이다. 다만, 그 때 당시 이걸 추가했던 사람이 insert 되었던 로그와 같은 그룹으로 넣지 않고 별도로 넣은건 나중에 일괄적으로 삭제를 하려고 했던건지 아니면 혼동을 줄이기 위해서인지는 모르겠다. 어쨌든 두 개의 시퀀스의 용도를 제대로 이해하고 있다면 위와 같은 코드를 만드는게 문제가 될 리 없다.
그리고, 보통은 insert 가 여러번 연달아서 발생하는 경우가 드문 사이트였고...여러 이유에서 저런 코드가 바로 문제시 되지 않았던 것도 서비스 후에 이 문제가 발견된 이유이기도 했다.

당연히 저렇게 해서 값이 입력되면 아래와 같은 결과 형태로 테이블에 저장된다.

1    1    Test1
2    2    Spend Time : 149358240
3    2    Test2
4    3    Spend Time : 1457061

자...이렇게 로그가 남게 되면 처음에 의도한 바와 달리 데이터가 이상하게 그룹화 되어서, 저 데이터를 봐야 하는 운영팀이나 사업팀 등은 맨붕에 빠지게 된다. 그나마 실제 상황에서 저런 일이 로그 테이블에서 발생했으니 망정이었지...

이게 왜 짜증나는 경우냐면, 그 때 당시 내가 가이드 코드들을 제공했고, 분명히 insert 시에 <selectKey> 을 이용하는 예제만 존재했기 때문이었다. 물론 나 역시 저런 식의 문제가 생길꺼라곤 생각을 못했지만...흔히 인터넷에 위 질문과 달리 <selectKey> 만 쓰는 이유도, 어떤 선각자(?)가 이런 문제를 예감하고 그랬을런지도 모른다.

왜냐하면, <selectKey> 을 쓸 경우 AOP 등이 끼어들 여지가 없고, 먼저 값을 가져온 뒤에 그 값을 가지고 insert 할 때마다 이용하기 때문에, 고의로 그 값을 변조하지 않는 이상(혹은 정말 실력이 떨어져서 thread 에서 그 값을 공유하는 코딩을 하면 망한다) 이런 문제가 발생하지 않는다. 실제 MyBatis 3 나 iBatis 2 에서는 사용법이 좀 다르긴 하나, MyBatis 3 에서는 <selectKey> 에 여러 값을 조회한 뒤, Bean 에 그 값을 넣어주기 때문에 정말 문제 발생 가능성이 떨어지고, 난 개인적으로 이런 코딩을 방어적인 코딩이라고 부른다.
그런데, 이렇게 코딩하는건...너무 예제도 많고...귀찮아서 여기엔 적지 않겠다.

중요한 건, 분명 Oracle 시퀀스에서 nextval 와 currval 을 insert 에 바로 적을 경우 문제가 발생할 부분이 존재한다는 것이다. 사실 위에서는 극적으로 보이기 위해 AOP 을 썼지만...사실 예전에 문제가 됐을 땐 Service 안에 테이블에 값을 넣는 Mapper 을 호출하도록 중간에 코드를 넣는 형태였다.

그리고, 이런 위험성을 알면서 알려주지 않는 것은...상대가 그걸 받아들일만큼의 실력이 되는지의 여부와는 상관이 없다고 본다. 오히려 문제가 있다고 하는데도 자기 주장 때문에 부득부득 우기는 모습은......그만하련다. 내 짧은 삶에 그런 걸로 시간 낭비하는 것도 짜증난다. 그 사람 입장에서도 평생 이런 문제 안겪을 확률이 높을텐데 내가 왜 나서서 이러고 있는지는 모르겠지만...

어쨌든, Oracle / MyBatis 에서 Sequence 쓸 때 그 값을 재사용한다면 습관적으로 <selectKey> 을 쓰는 걸 권한다. 물론 선실행이 필요한 Sequence 말고도 후실행되는 Auto increment 을 지원하는 다른 DBMS 에서도 그냥 생각없이 <selectKey> 쓰는게 나을 수 있겠다. 굳이 이경우 저경우 다 따질 필요도 없고, 하나의 XML Element 에서 두 번의 쿼리를 통해 이것저것 다 할 수 있어서 코드도 간결해 지니까 말이다.

꼬랑지 1. MS SQL Server 는 2012 버전부터 Sequence 을 지원한다. Auto increment 말고 Sequence 쓰는걸 추천한다. 물론 방어적인 이유 때문이다. 본인이 하는 사이트에서 문제 발생하지 않았다면 그냥 계속 써도 무방하다. 나처럼 insert 가 무지막지하게 발생하는 곳에서는 이것 때문에 고생할 수 있겠지만, 평생 이런 경우 안겪는 경우가 더 많을꺼다.

꼬랑지 2. MS SQL Server 에서는 <selectKey> 와 별개와 SELECT SCOPE_IDENTITY() 와 IDENT_CURRENT() 와 관련된 문제가 있다. 그런데, 이걸 위 주제와 연결시키는건 한마디로 지기 싫어서 논점을 흐리는 것에 지나지 않는다고 본다. 이걸 꺼내든 사람은 절대 인정하지 않겠지만...그냥 Sequence 쓰라고 한 마디 하고 싶었지만, 어쨌든 그 커뮤니티에서는 절대 응대하지 않는다...가 나의 개인방침으로 굳어졌기에...물론 여기를 찾아내서 댓글 달아도 응대할 생각 없음. (그 커뮤니티는 내 개인 사이트가 아니기 때문에 그곳이 시끄러워 지는게 절대 좋을게 없다는 판단 때문, 그냥 나만 참으면 되는 것이기에)

꼬랑지 3. 이 글에도 다른 분들의 어거지는 엥간하면 응대 안합니다. 이 문제로 싸워봐야 서로 니 생각이 옳네 내 생각이 옳네...수준이지 건설적이지 못하다고 생각합니다.

SATA 확장 카드

2016-06-17T17:56:00.001+09:00

메인모드의 SATA 포트가 부족할 때 확장 카드를 설치해서 사용할 수 있습니다.
기왕 할 꺼 8포트짜리를 추가한다면...

AOC-SAS2LP-MV8
SD-PEX40104
SI-PEX40071

같은 모델이 있습니다. AOC-SAS2LP-MV8 은 PCI-e 8x 용입니다. 그 만큼 대역폭이 커야한다는 이야기겠죠. AOC-SAS2LP-MV8 가 그나마 브랜드(Supermicro)이고 안정성이 뛰어나다고 합니다. xpenology 에서도 작동확인이 되었다고 합니다.

윈도우 창 매니저 교체

2016-06-07T12:43:00.004+09:00

기존에 Winsplit revolution + UltraMon 으로 창 위치 타일 위치로 크기 및 위치 변경 + 다른 모니터로 이동 + 전체 크기로 변경 등을 했었는데, 윈도우즈 10 으로 변경한 뒤 Winsplit revolution 이 문제가 발생하기 시작했습니다.

그래서 무엇으로 변경해야 하나...한참 찾았는데, 아쿠아 스냅(AquaSnap) 으로 한 방에 해결했습니다. 두 개를 섞어써야 했던 것을 한 프로그램 안에서 다 해결했네요.

어짜피 다른 기능은 안쓰고, UltraMon 의 작업표시줄 확장 기능은 Windows 10 에 포함되어 있어서 필요가 없어졌습니다. UltraMon 을 저렴한 가격으로 오랫동안 잘 썼지만 이젠 놔줘야 할 것 같네요. (안되면 아쿠아 스탭과 섞어 쓰죠 뭐...)

http://www.nurgo-software.com/?utm_source=AquaSnap&utm_medium=application

Vert.x 3.1.0 시작해보기...(6)

2016-05-25T10:22:00.004+09:00

제가 요즘 요긴하게 써먹고 있는 Vert.x 을 소개하고자 합니다. 폴리글랏이긴 한데, 저는 Java 만을 사용해서 개발하고 있습니다. 그래서 Java 코드만 올리겠습니다.

장문의 글을 올리기 보다는, 바로 어떤 결과가 나오는 짧은 팁만 올리고, 댓글로 보충 내용을 올리는 쪽으로 해보겠습니다. 방송 형태가 적합하겠지만, 할 줄을 몰라서...(컴맹입니다)

------------------------------------------------------------------------------------------------------

역시나 오랫만에 글을 올립니다. 요즘 좀 많이 게을러지기도 해서...

제목이 살짝 바뀌었습니다. 눈치채신 분 계신가요? 그 사이 Vert.x 의 버전이 3.0.0 에서 3.1.0 으로 올라갔습니다. 몇몇 변화점들이 눈에 띄는데, 그 중에서도 제가 구글 그룹스에 글을 남겼던 부분도 개선이 되었네요. (https://groups.google.com/forum/#!topic/vertx/-ZofvUfbzj8 )

하지만, 일반적인 사용에 있어서는 큰 변화가 없으니...제 앞의 게시물들은 여전히 변경 없이 사용 가능할 것입니다.

이번에 알아볼 것은 config 파일와 LocalMap 입니다.

먼저, config 은 vertx run 을 통해 실행될 때 설정 파일을 읽어오는 기능입니다. Vert.x 는 JSON 을 이용해서 데이터들을 주고 받는 것을 기본으로 하고 있어서인지, 설정 파일 역시 JSON 파일로 읽어올 수 있게 개발되어 있습니다. 그냥 JSON 이 들어있는 파일을 실행 시 옵션으로 가리키면 그 파일을 읽어오는 것이죠.

가령 예를 들면 아래와 같습니다.

vertx run Test6_1.java -conf config.json

-conf 에 파일 경로와 이름을 적어주면 해당 파일을 읽어들입니다. 지금은 java 파일과 같은 위치에 존재하기 때문에 특별히 경로를 적지 않았습니다만, 개발 PC 와 서버마다 VCS 외부에 파일을 위치시켜두고 실행을 배치 파일로 하도록 만들어서 각각의 config 파일을 읽게 해주면 Spring 의 profile 와 같은 역할을 할 수 있습니다. JSON 형태를 읽기 때문에 좀 더 강력하다고 할까요...

위와 같이 실행될 경우 Test6_1.java 는 start() 안에서 context.config() 으로 읽어올 수 있습니다.

하지만, 주의할 것은 이 설정 파일은 Test6_1.java 파일에서만 읽을 수 있으며, Test6_1.java 파일에서 deploy 한 다른 파일에서는 context.config() 으로 받을 수 없다는 것입니다. 대신에, deployVerticle() 시 옵션을 통해 config JSON 을 전달할 수 있습니다(물론 중간에 가공한 뒤 보낼 수도 있겠죠). 아래와 같이 말이죠.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/config.json

{
  "TestMessage": "Hello World"
}

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test6_1.java

public class Test6_1 extends AbstractVerticle {

 @Override
 public void start() throws Exception {

  super.start();

  EventBus eventBus = vertx.eventBus();
  JsonObject config = context.config();

  DeploymentOptions options = new DeploymentOptions().setConfig(config);

  vertx.deployVerticle("Test6_2.java", options);
  vertx.deployVerticle("Test6_3.java", options);

앞 글에서 살펴본 DeploymentOptions 을 통해서 여러 설정을 할 수 있는데, 그 중에 config 파일을 담아서 보내는 기능도 있습니다.

그럼, 다른 Verticle 에서 잘 받는지 구문을 만들어봐야겠죠? 아래와 같이 만들어봤습니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test6_2.java

public class Test6_2 extends AbstractVerticle {

 @Override
 public void start() throws Exception {

  super.start();

  EventBus eventBus = vertx.eventBus();
  JsonObject config = context.config();

  eventBus.consumer("Test6_2", (Message<Object> message) -> {

   String testMessage = config.getString("TestMessage");

실제로 Test6_1~Test6_3 까지 받으신 후 실행하고서, http://localhost:8080/Test6_2 라고 호출하면 브라우저에 config 안에 있던 "Hello World" 가 출력됨을 아실 수 있을 겁니다.

이번에는 LocalMap 입니다. Vert.x 2.x 에서는 SharedMap 이라고만 있었는데, Vert.x 3 가 나오면서 LocalMap 와 ClusterWideMap 으로 나뉘어졌습니다. 예전의 SharedMap 은 LocalMap 와 동일한 것입니다. Embeded 모드에선 ClusterWideMap 이 의미가 없지만, 실행 모드에서 Cluster 구성을 한 뒤에는 차이가 존재합니다. Vert.x 는 Hazelcast 을 통해 Cluster 을 제공하는데, EventBus 을 여러 instance 의 것을 분산해서 사용할 수 있는 형태입니다. 문제는 다른 JVM 이다보니 일반적인 Object 로는 값의 동기화가 안되기 때문에 Hazelcast 의 공유 Object 을 이용하는데, Vert.x 는 이것을 ClusterWideMap 을 통해서 제공합니다. LocalMap 은 Instance 마다 개별적으로 분리되기 때문에 Cluster 환경에선 LocalMap 와 ClusterWideMap 의 사용에 신중을 기해야 합니다. 그리고, ClusterWideMap 은 반드시 비동기 형태로만 작성되는 것도 유의해야 하구요(Hazelcast 는 아닌데...).

LocalMap 은 다음과 같이 String 기반으로 개체를 구분해서 사용할 수 있습니다. 다음 예제는 다른 Verticle 에서 선언한 LocalMap 을 공유해서 쓰는 것을 보여줍니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test6_2.java

public class Test6_2 extends AbstractVerticle {

 @Override
 public void start() throws Exception {

  super.start();

  EventBus eventBus = vertx.eventBus();
  JsonObject config = context.config();

  eventBus.consumer("Test6_2", (Message<Object> message) -> {

   String testMessage = config.getString("TestMessage");

   LocalMap<String, String> map = vertx.sharedData().getLocalMap("Test6.LocalMap");

   String localMapValue = map.get("LocalMapKey");

   System.out.println("LocalMapValue : " + localMapValue);

   String sCount = map.get("Count");

   if (sCount == null) {

    sCount = "0";

   }

   int count = Integer.parseInt(sCount) + 1;

   map.put("Count", Integer.toString(count));

   localMapValue = "Count" + count;

   map.put("LocalMapKey", localMapValue);

   message.reply(testMessage);

  });

 }

위의 config 와 같은 파일에 구현을 했는데, config 의 결과는 웹브라우져에 결과가 전송되도록 되어 있고, 이번 예제는 서버 측 콘솔에 결과가 출력되도록 되어 있습니다. 처음 Test6_2 을 호출하게 되면 콘솔에 LocalMapValue : null 가 출력됩니다. 하지만 다음 요청부터는 Test6_2 을 호출하든, Test6_3 을 호출하든 LocalMapValue : Count1 와 같이 개체에 값이 추가된 것을 확인할 수 있습니다. 이렇게 값을 공유할 수 있다는 것이죠.

오늘은 여기까지...

이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;

~~위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로,~~ 오류가 있다면 저에게 알려주시면 고맙겠습니다.

Vert.x 3.0.0 시작해보기...(5)

2016-05-25T10:21:00.007+09:00

------------------------------------------------------------------------------------------------------

오랫만에 글을 올리네요. 하루에 한 개씩 올릴 수 있을 줄 알았으나, 게으름을 이기지 못하네요.

이번에는 Vert.x 의 Verticle 이 가지는 아주 기초적인 특성 하나만 알아볼 것입니다. 바로 독립적으로 돌아가는 특성입니다.

먼저, 가장 기본적인 Java 에서의 싱글톤(Singleton)을 한 번 구성해봤습니다. 너무 쉬운 내용이지만, 다음 내용 설명을 위해서 기초적인 형태로 구성한 점, 양해 바랍니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test5_1.java

public class Test5_1 {

 private Test5_1() {

 }

 private static Test5_1 instance;

 public static Test5_1 getInstance() {

  if (instance == null) {

   System.out.println("Create Instance Test5_1");

   instance = new Test5_1();

  }

  return instance;

 }

}

정말 단순한 형태의 싱글톤입니다. 단지, 클래스가 생성될 때 인스턴스를 생성하게 하지 않고, 아직 인스턴스가 null 인지 확인한 뒤 생성해줄 때 로그를 한 번 출력해주고(생성되는 횟수도 알겸) 개체를 생성한 다음 결과로 인스턴스를 넘겨주도록 구성했습니다.

그리고 이걸 불러서 호출하는 클래스를 2 개 만들어 봤습니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test5_2.java

import java.util.Random;

public class Test5_2 {

 public static void main(String[] args) throws Exception {

  System.out.println("Start Test5_2");

  Test5_2 test5_2 = new Test5_2();
  Test5_3 test5_3 = new Test5_3();

  Random random = new Random(System.currentTimeMillis());

  for (int iCount = 0; iCount < 10; iCount++) {

   if (random.nextInt(2) == 0) {

    if (random.nextInt(2) == 0) {

     test5_2.test1();

    } else {

     test5_2.test2();

    }

   } else {

    if (random.nextInt(2) == 0) {

     test5_3.test3();

    } else {

     test5_3.test4();

    }

   }

  }

  System.out.println("End Test5_2");

 }

 public void test1() {

  Test5_1 test5_1 = Test5_1.getInstance();

  System.out.println("Get Instance Test5_1 : test1");

 }

 public void test2() {

  Test5_1 test5_1 = Test5_1.getInstance();

  System.out.println("Get Instance Test5_1 : test2");

 }

}

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test5_3.java

public class Test5_3 {

 public void test3() {

  Test5_1 test5_1 = Test5_1.getInstance();

  System.out.println("Get Instance Test5_1 : test3");

 }

 public void test4() {

  Test5_1 test5_1 = Test5_1.getInstance();

  System.out.println("Get Instance Test5_1 : test4");

 }

}

main 은 Test5_2 에 있고, main 이 호출되면 Random 을 이용해서 임의적으로 4 개의 매서드 중 하나를 호출해서 인스턴스를 가져오는 아주 간단한 예제입니다.

출력 결과는 다음과 같습니다.

Start Test5_2
Create Instance Test5_1
Get Instance Test5_1 : test3
Get Instance Test5_1 : test1
Get Instance Test5_1 : test2
Get Instance Test5_1 : test1
Get Instance Test5_1 : test2
Get Instance Test5_1 : test4
Get Instance Test5_1 : test1
Get Instance Test5_1 : test3
Get Instance Test5_1 : test2
Get Instance Test5_1 : test2
End Test5_2

물론 출력되는 Get Instance Test5_1 : 이후의 내용은 Random 하게 바뀌겠지만, Start 후 Create 가 한 번만 나오고 End 가 마지막에 나오는 것은 누구나 예측할 수 있을 것입니다. 이게 싱클톤이니까요. 보통 이런 싱글톤은 JDBC 을 이용해서 DB Connection 을 가져오는 문장에서 많이들 사용하셨을 겁니다.

그런데, Vert.x 에서는 이렇게 싱글톤을 이용할 경우 큰일이 납니다. 다음 예제를 한 번 보시죠.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test5_4.java

import io.vertx.core.AbstractVerticle;
import io.vertx.core.eventbus.EventBus;
import io.vertx.core.eventbus.Message;

import java.util.Random;

public class Test5_4 extends AbstractVerticle {

 @Override
 public void start() throws Exception {

  super.start();

  vertx.deployVerticle("Test5_5.java");

  EventBus eventBus = vertx.eventBus();

  eventBus.consumer("Test5_4.test1", (Message<Object> message) -> {

   Test5_1 test5_1 = Test5_1.getInstance();

   System.out.println("Get Instance Test5_1 : test1");

   message.reply(null);

  });

  eventBus.consumer("Test5_4.test2", (Message<Object> message) -> {

   Test5_1 test5_1 = Test5_1.getInstance();

   System.out.println("Get Instance Test5_1 : test2");

   message.reply(null);

  });

  Random random = new Random(System.currentTimeMillis());

  for (int iCount = 0; iCount < 10; iCount++) {

   if (random.nextInt(2) == 0) {

    if (random.nextInt(2) == 0) {

     eventBus.send("Test5_4.test1", null);

    } else {

     eventBus.send("Test5_4.test2", null);

    }

   } else {

    if (random.nextInt(2) == 0) {

     eventBus.send("Test5_5.test3", null);

    } else {

     eventBus.send("Test5_5.test4", null);

    }

   }

  }

 }

 @Override
 public void stop() throws Exception {

 }

}

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test5_5.java

import io.vertx.core.AbstractVerticle;
import io.vertx.core.eventbus.EventBus;
import io.vertx.core.eventbus.Message;

public class Test5_5 extends AbstractVerticle {

 @Override
 public void start() throws Exception {

  super.start();

  EventBus eventBus = vertx.eventBus();

  eventBus.consumer("Test5_5.test3", (Message<Object> message) -> {

   Test5_1 test5_1 = Test5_1.getInstance();

   System.out.println("Get Instance Test5_1 : test3");

   message.reply(null);

  });

  eventBus.consumer("Test5_5.test4", (Message<Object> message) -> {

   Test5_1 test5_1 = Test5_1.getInstance();

   System.out.println("Get Instance Test5_1 : test4");

   message.reply(null);

  });

 }

 @Override
 public void stop() throws Exception {

 }

}

위 예제를 보시면 메서드를 EventBus 로 단순히 바꾼 형태라는 걸 눈치채실 겁니다. 이 코드를 이용해서 Test5_4.java 을 Vert.x 로 실행하면 어떤 결과가 나올까요? 대략 아래와 같은 결과가 나옵니다.

> vertx run Test5_4.java
Create Instance Test5_1
Get Instance Test5_1 : test3
Get Instance Test5_1 : test4
Get Instance Test5_1 : test4
Create Instance Test5_1
Get Instance Test5_1 : test1
Get Instance Test5_1 : test2
Get Instance Test5_1 : test1
Get Instance Test5_1 : test2
Get Instance Test5_1 : test1
Get Instance Test5_1 : test4
Get Instance Test5_1 : test3
Succeeded in deploying verticle

예상하신 분들은 예상하셨겠지만...Create 가 두 번 발생합니다.

만약 Verticle 이 10 개라면, 10 개의 Create 가 발생한다는 이야기입니다. 즉, 모든 Verticle 은 별개로 동작하고, 이걸 내부적으로 Hazelcast 로 통신하면서 값을 전달하기 때문에 기존의 Singleton 을 가지고 하나의 접속만을 유지하면서 사용한다는 개념으로 접근해버리면, 전혀 엉뚱한 결과에 멘탈이 붕괴되는 현상을 경험하실 겁니다.

그래서, DB 접속이든 쿼리를 실행하는 구문이든, Singleton 으로 Connection 개체를 받아와서 처리하는 형태로 구성해서는 안되고, 쿼리를 처리하는 하나의 버티클을 만들고 그 안에 쿼리를 처리하는 EventBus 을 만든 뒤, 모든 요청을 그 EventBus 로 보내서 처리하고 결과만 JsonObject 등으로 받아오는 형태로 프로그램을 작성해야 합니다. 그래서, 오히려 처리가 더 힘든 면이 있지 않나 싶네요.

오늘은 여기까지...

Vert.x 3.0.0 시작해보기...(4)

2016-05-25T10:21:00.003+09:00

------------------------------------------------------------------------------------------------------

저번 글에 그래도 읽어주신다고 댓글 달아주신 분이 몇 분 계셔서...마음의 상처가 약간은 치유가 됐습니다. T_T

그래서 이번에는...또 저만의 팁이 약간 들어간 Vert.x 의 TCP Server 기능에 대해서 소개를 해보고자 합니다.

역시나 백문이 불여일타...코드를 보면서 설명을 드리겠습니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test4_1.java

vertx.createNetServer().connectHandler(socket -> {

 String handlerID = socket.writeHandlerID();

 socket.handler(buffer -> {

  String message = buffer.toString().trim();

  System.out.println(socket.remoteAddress() + " (" + handlerID + ") => " + message + "\r\n");

  socket.write("Receive => " + message + "\r\n");

 });

}).listen(9999);

HTTP Server 와 비슷하게 TCP Server 을 선언하고 처리하는 코드입니다. TCP Server 는 NetServer 라고도 불립니다. createHTTPServer() 대신에 createNetServer() 라는 Method 로 옵션을 줄 수도 있고, 주지 않을 수도 있습니다. 그리고 listen() 으로 포트를 지정해줄 수 있구요.

중요한 것은 connectHandler() 을 통해 클라이언트의 접속을 감지하고 이에 대한 처리를 할 수 있다는 것입니다. connectHandler() 는 Handler<NetSocket> 개체를 매개변수로 가지는데, 람다를 통해 NetSocket 개체를 바로 socket 이라는 이름으로 받아와 처리가 가능합니다. 물론 비동기로요...

이전에도 몇 번 언급했지만, 클라이언트가 Vert.x 의 TCP Server 로 접속을 하게 되면 고유한 ID 을 하나 부여받아서 이를 통해 사용자를 구분할 수 있게 됩니다. 그걸 받아오는 것이 socket.writeHandlerID() 입니다. 이걸 저장해두면, 저 람다 안에서는 이를 이용해서 여러가지 처리가 가능합니다.

기본적으로 가장 많이 사용하게 되는 것은 socket.handler() 입니다. 사용자가 메세지를 전송하면 Vert.x 는 handler() 이벤트를 발생시켜서 정보를 처리하게 됩니다. Handler<Buffer> 개체를 매개변수로 가지는데, 버퍼 형태로 데이터를 받아서 사용자에게 제공합니다. 보통 String 문자열로 받아올 경우 toString() 을 통해 문자를 저장할 수 있고, byte[] 형태 역시 getBytes() 로 쉽게 받아올 수 있습니다. 또한, substring 을 할 필요없이 getString() 이나 getBytes() 에 위치 정보를 매개변수로 전달해 특정 영역의 값만 가져올 수도 있고, int 나 long 같은 형태로 바로 받아올 수도 있습니다.

이렇게 받아온 정보를 콘솔에 출력한 뒤 socket.write() 로 다시 사용자에게 메세지를 보내는 것이 이 소스의 역활입니다. 일종의 Echo Server 인 셈이죠. 참 쉽죠???

기존 Java 의 TCP 처럼 Thread 을 쓸 것 없이 이렇게 간단한 문장으로 비동기로 처리되는 TCP Server 가 완성이 되었습니다.

소스를 실행한 뒤 명령 프롬프트(프로그램에서 텔넷 클라이언트를 설치해야 합니다)나 putty, SecureCRT 등의 툴로 접속을 한 뒤 타이핑을 하시면 바로바로 응답이 오는 것을 확인하실 수 있을 겁니다.

하지만, 실제 실행을 해보면 조금 테스트하기 불편한 것을 아실 수 있을 겁니다. 한 글자만 타이핑을 해도 바로 응답이 옵니다. 테스트 클라이언트를 만들어서 한 번에 문장을 보내면 괜찮을지 몰라도 손으로 테스트하기에는 여간 불편하지 않습니다. 이 문제를 어떻게 해결해야 할까요?

다음 예제를 통해 해결해 보도록 하겠습니다. 이후 예제는 아래 링크입니다. 몇 개의 예제가 하나의 소스에 있습니다. 주의해서 보세요.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test4_2.java

socket.handler(RecordParser.newDelimited("\n", buffer -> {

 String message = buffer.toString().trim();

 System.out.println(socket.remoteAddress() + " (" + handlerID + ") => " + message + "\r\n");

 socket.write("Receive => " + message + "\r\n");

}));

첫번째 소스의 handler() 부분에 RecordParser.newDelimited() 가 추가되었습니다. 그 안에서 람다가 처리되네요. 이름에서 예상되시겠지만, 이 개체의 역할은 구분자(Delimiter)를 이용해서 내용을 모아서 처리해주는 것입니다. 아주 편리한 기능입니다. TCP 나 UDP 는 한 번에 모든 문장을 전송하지 않습니다. UDP 에 비해 훨씬 우아한 처리를 하는 TCP 조차 그 우아한 내부 처리 때문에 사용자가 보낸 문자열을 여러 개로 쪼개서 전송할 때가 있습니다. 그래서 앞서와 같이 그냥 Buffer 로 받을 경우 내가 한 번에 보낸 문장이 한 번에 오지 않고 여러 요청으로 나뉘어와서 비동기 처리가 어지럽게 될 수 있습니다. 물론 TCP 특성한 요청은 반드시 1 번만 수신되고, 순서까지 지켜서 오기 때문에 직접 Queue 을 이용해 메세지를 합치는 작업을 할 수 있습니다만, 이렇게 간단하게 메세지를 합쳐서 처리를 해줍니다. "\n" 이라는 문자를 만날 때까지요.

저 구분자가 줄바꿈인건 아시죠? 이제 이 두번째 예제를 실행하시면, 줄바꿈이 나오기 전까지는 사용자에게 응답이 가지 않습니다. 편리하죠?

그리고 예제 소스를 열어보시면 뭔가 더 많은 handler 가 처리되고 있음을 아실 겁니다. drainHandelr(), endHandler(), closeHandler(), exceptionHandler() 가 그것입니다. 사용자의 접속이 일어나자마자 일어나는 이벤트도 있고(모바일 등의 환경에서 자주 일어나는 순간적인 접속 끊김 현상에 대비해 재접속일 경우 이전 접속의 처리를 이어가고자 할 때 유용합니다) 접속이 끊겼을 때 일어나는 이벤트도 있습니다. 클라이언트의 접속 끊김 방식에 따라 exceptionHander() 호출될 때도 있고, endHandler() 와 closeHandler() 만 발생하는 경우도 있을 겁니다. 상황에 맞게 이벤트 처리를 해주시면 됩니다.

주의하실 점은, exceptionHandler() 만 Throwable 개체를 제공하고, 나머지 handler 들은 모두 Void 개체를 제공한다는 것입니다. 그래서 exceptionHandler() 는 에러 메세지 기반의 처리가 가능하지만, 나머지 handler 들은 NetSocket(위에서 socket 이라는 이름으로 받아온)을 이용한 정보를 가지고만 처리를 할 수 있습니다. HandlerID 등을 알 수 있기 때문에 Map 등에 사용자 정보를 저장해뒀다가 close 가 감지될 때 사용자를 제거해준다거나, drain 가 감지될 때 이전 HandlerID 대신에 갱신을 해준다거나 하는 작업도(실제로는 handler 에서 할 수 밖에 없긴 합니다만) 만들어봄 직 합니다.

마지막으로, 저만의 응용으로 넘어갑니다. 이 예제는 3 번째 팁에서 이용했던 Test3_2.java 파일을 이용해서 내용을 추가한 것입니다. 추가된 코드를 아래에 소개합니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test4_3.java

Handler<NetSocket> handler = socket -> {

 String handlerID = socket.writeHandlerID();

 socket.handler(RecordParser.newDelimited("\n", buffer -> {

  String message = buffer.toString().trim();

  try {

   JsonObject param = new JsonObject(message);

   String method = param.getString("METHOD");

   eventBus.send("Test." + method, param, (AsyncResult<Message<String>> result) -> {

    if (result.succeeded()) {

     String returnValue = result.result().body();

     eventBus.send(handlerID, Buffer.buffer().appendString("{\"METHOD\": \"" + method + "\", \"RESULT\": \"" + returnValue + "\"}\r\n"));

    } else {

     eventBus.send(handlerID, Buffer.buffer().appendString("{\"METHOD\": \"" + method + "\", \"ERROR\": \"" + result.cause().getMessage() + "\"}\r\n"));
     result.cause().printStackTrace();

    }

   });

  } catch (Exception e) {

   socket.write(e.getMessage());

  }

 }));

};

vertx.createNetServer().connectHandler(handler)
  .listen(9999);

위에서 설명한 코드들이 대부분이라 쉽게 이해가 되실 겁니다. 실제 handler() 내부의 구현만 좀 바뀌었습니다. 내용은 크게 어렵진 않습니다.

내용의 핵심은 "JSON 으로 메세지를 넘겨주면 이를 JsonObject 개체로 만든 뒤 HTTP Server 에서 사용하던 EventBus 을 재활용해서 처리한 뒤 JSON 으로 결과를 전송한다" 입니다. 쉽죠? (고 밥 로스 선생님 따라하기)

그래도 약간의 규칙이 필요합니다. 클라이언트에서 "METHOD" 라는 키로 기존의 HTTP Server 의 URL 의 주소값을 대체하는 것입니다. 기존에 Login 와 Sleep 을 구현했으니 이 두가지를 쓸 수 있겠죠. HTTP Server 의 QueryString, 즉 매개변수 부분은 각각 키로 변수 이름을 지정하고, 값에 원래의 값을 넣으면 완벽하게 동일하게 동작하게 됩니다. 즉, 역으로 생각해서 TCP Server 를 구현하는데 telnet 등으로 테스트하기 쉽지 않을 때, HTTP Server 을 생성해두고 Postman 와 같은 툴로 쉽게 테스트를 진행할 수도 있는 것입니다. 어떠신가요? 유용하지 않나요?

그리고 예제를 유심히 보신 분은 눈치 채셨겠지만, socket.write() 로 클라이언트에게 메세지를 전송하던 부분 중 일부가 바뀌어있는 곳이 있습니다. eventBus.send(handerID, Buffer.buffer().appendString()); 형태로요. 그렇습니다. EventBus.send() 는 서버에 구현한 EventBus 말고도 접속한 클라이언트에게 메세지를 전송할 때에도 사용합니다. 나 뿐만 아니라 다른 클라이언트에게 메세지를 전송할 때에도 그 사용자의 HanderID 만 안다면 전송이 가능합니다. send() 말고도 publish() 도 존재합니다. publish() 는 send 와 달리 HandlerID 을 매개변수로 받지 않는데, 현재 서버에 접속한 모든 클라이언트에게 메세지를 보내는 기능입니다. 아울러 send() 는 오류가 발생하면 여러 사용자에게 보낼 때 중간에 전송을 중단한다고 하던데(저는 한 번에 한 명에게만 보내는 형태로만 구현해서 실제로 어떻게 그렇게 되는지는...) publish() 는 에러가 난 애들은 건너뛰고 다음 사용자에게도 전송을 한다고 하더군요.

이를 이용해서 채팅방을 구현할 때 Map 으로 사용자 정보를 저장할 개체를 생성해두고 그 채팅방에 입장할 때 HandlerID 을 Map 에 추가해두면, 사용자가 메세지를 전송해오면 Map 에서 사용자 목록을 꺼내서 그 사용자들에게 send() 로 메세지를 전송해주면 쉽게 채팅방 기능도 구현할 수 있게 됩니다.

단, 클러스터 환경에선 send() 나 publish() 을 이용한 전송에 주의를 기울여야 합니다. 해당 인스턴스에 접속한 사용자에게만 메세지를 보낼 수 있습니다. 해당 내용에 대해서 예전에 제가 적은 글을 링크로 남깁니다.

http://okky.kr/article/272544

지금까지 TCP Server 에 대해서 간단하게 알아봤는데, 사실 Vert.x 에는 HTTP 을 이용한 WebSocket 이나 SockJS 도 제공합니다. 이것 역시 TCP 와 거의 유사하게 동작하기 때문에 아주 유용하게 사용하실 수 있을 것이라 믿어 의심치 않습니다! (말이 길어지는 걸 보니...자신이 없어서 이런다는거 아시겠죠? T.T)

별 유용하지도 않으면서 쓸데없이 길기만 한 팁을 읽어주셔서 고맙습니다.

오늘은 여기까지...

Vert.x 3.0.0 시작해보기...(3)

2016-05-25T10:20:00.003+09:00

------------------------------------------------------------------------------------------------------

사실 꽤나 글을 새로 못올리고 있었는데, 찾는 분이 없는걸 보니...재미 없기만 한 내용인건 사실인가 봅니다. 그래도 칼을 빼들었으니...5회 정도까지는 글을 적어볼까 합니다.

이번에는, 드디어 Vert.x 의 꽃이라고 할 수 있는 EventBus 를 다뤄볼까 합니다.

EventBus 을 가장 쉽게 이해할 수 있는 방법은...Vert.x 을 위한 비동기 Method...정도로 정의를 내릴 수 있겠네요. 실제 Method 처럼 선언을 하고 사용을 합니다. 단지...좀 사용상의 제약이 있고 비동기로 처리를 한다는 정도의 차이가 있겠네요.

백문이 불여일타...코드를 보면서 설명을 드리겠습니다.

EventBus eventBus = vertx.eventBus();

eventBus.consumer("Test.Login", (Message<JsonObject> message) -> {

 JsonObject param = message.body();

 System.out.println(param.getString("METHOD") + " Start!!!");

 message.reply(param.getString("METHOD") + " End");

});

먼저 EventBus 을 사용하기 위해서는 vertx 개체로부터 eventBus() 을 이용해 개체를 얻어와야 합니다. 그리고 Method 선언과 마찬가지의 작업인 consumer() 을 통해 하나의 EventBus 을 등록하게 됩니다.

첫번째 매개변수는 Method 의 이름과 같은...이름, 그리고 다음 매개변수는 실제 코드 부분입니다. Message 개체 안에 매개변수를 하나의 Bean 처럼 담아서 가져올 수 있는데, 하나의 개체만 받아올 수 있기 때문에 보통 JsonObject 에 필요한 정보를 입력해서 보냅니다. 이렇게 받아온 Message 개체는 body() 을 이용해서 실제 값을 받아올 수 있습니다.

그리고 return 대신에 Message 개체의 reply() 을 통해 호출한 쪽에 결과를 전송할 수 있습니다.

그럼 이번에는 실제 호출 부분을 보겠습니다.

eventBus.send("Test." + method, param, (AsyncResult<Message<String>> result) -> {

 if (result.succeeded()) {

  String returnValue = result.result().body();

  request.response().putHeader("content-type", "application/json");
  request.response().end("{\"METHOD\": \"" + method + "\", \"RESULT\": \"" + returnValue + "\"}");

 } else {

  request.response().putHeader("content-type", "application/json");
  request.response().end("{\"METHOD\": \"" + method + "\", \"ERROR\": \"" + result.cause().getMessage() + "\"}");
  result.cause().printStackTrace();

 }

});

예전 코드에서 조금 확장을 해봤는데, 저는 주로 호출된 URL 을 이용해서 consumer() 로 선언된 EventBus 을 자동으로 호출하고, 결과를 분기해서 처리하는 방법으로 개발합니다. 생각하지 않고 그냥 이렇게 만들어두는게 개인적으로는 편하더군요.

위의 코드들이 모두 적용된 소스는 아래 깃헙에 올라가 있습니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test3_1.java

이 코드를 실행해 보시면, http://localhost:8080/Login 와 같이 호출을 할 경우 Test.Login 을 호출해서 콘솔에 메세지를 출력하고, 사용자의 브라우저에는 METHOD 와 RESULT 키가 포함된 JSON 구문이 출력될 것입니다. 물론 METHOD 부분의 글자를 조금 바꿔서 보내면...RESULT 대신에 ERROR 가 포함된 JSON 구문이 출력될 것입니다. 아쉽게도 에러 메세지는 부정확하거나 null 이 포함되어 있을 확률이 큽니다. 아직 Vert.x 의 라이브러리의 완성도가 높은 편은 아니거든요. (그렇다고 실제 서비스에 사용하지 못할 정도의 버그가 있는 건 아닙니다. 완성도가 좀 낮을 뿐...)

다음으로 아래 예제를 통해 node.js 와 마찬가지로 Vert.x 가 가지는 특징을 알아볼 수 있습니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test3_2.java

Sleep 이라는 METHOD 가 추가되었는데, 실제 두 개의 브라우저를 실행한 뒤, Sleep 을 연달아 각각 호출해보면, 첫 Sleep 의 응답이 10 초 걸릴 동안, 두번째 Sleep 의 호출이 10 + a 초가 걸린다는 것을 알 수 있을 겁니다. a 초는 첫번째 호출 후 두번째 호출을 누를 때까지의 시간을 10초에서 뺀 시간입니다. 같은 EventBus 는 하나의 처리가 끝날 때까지 다음 처리를 기다려야 한다는 조건이 있기 때문입니다. 그리고, 비동기 처리에 익숙하지 않은 분을 위한 또 하나의 팁. 86 라인의 "Send End!!!" 는 첫번째 호출 시 즉시 출력이 됩니다. EventBus 을 호출한 뒤 결과 반환을 기다리지 않고 바로 다음 문장을 실행하는 비동기 프로그래밍의 전형적인 특징입니다. 역시나 node.js 나 javascript 의 callback 등을 많이 다뤄본 분들이라면 너무나 당연한 내용을 것입니다.

문제는 이 파일에서 Sleep 을 실행한 뒤 Login 을 실행해보면, 의도와 다르게 Sleep 을 두 번 실행했을 때와 마찬가지로 앞의 Sleep 이 끝나기 전까지 Login 이 처리되지 않는 것을 알 수 있습니다.

이를 해결하기 위해서는 Verticle 이라는 것을 쪼개서 처리해야 합니다. Test3_2.java 역시 하나의 Verticle 이기 때문에 이를 나누는 것이죠.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test3_3.java

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test3_4.java

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test3_5.java

Test3_3.java 파일이 기본 파일이고, Test3_4.java, Test3_5.java 파일은 일종의 include 된 파일이라고 생각하셔도 좋습니다. 단지 include 을 하는 것과 달리 별도의 Verticle 로 돌아가기 때문에 Thread 을 쓰는 것과 같은 효과를 볼 수 있습니다.

Test3_3.java 에서 다른 두 파일을 선언하는 것을 Deploy 라고 하고, vertx.deployVerticle() 로 작업을 수행할 수 있습니다.

vertx.deployVerticle("Test3_4.java");

vertx.deployVerticle("Test3_5.java");

그리고 Method 선언과 동일하다고 말씀드린 .consumer() 을 각 파일로 이동시키는 것입니다.

그리고 vertx run Test3_3.java 을 실행한 뒤 Sleep 을 실행한 뒤 바로 Login 을 실행하면 Sleep 와 상관없이 Login 이 바로 실행되는 것을 알 수 있습니다.

그런데, Sleep 을 실행해보면 이상한 메세지들이 출력되는 것을 보실 수 있습니다. 대충 내용을 봐도 뭔가 시간이 오래 걸린다고 불평을 하는 것이라는 걸 알 수 있습니다. Vert.x 의 EventBus 는 하나의 처리에 1 초가 넘어가게 될 경우 메세지가 콘솔로 출력됩니다. 이렇게 장시간의 처리가 필요한 것은 적합하지 않기 때문에 개선을 하라는 의미입니다. 하지만, 또다른 방법으로 오랜 시간이 걸리는 작업은 EventBus 가 아닌 별도로 준비된 Worker Verticle 을 이용해서 처리하면 메세지 출력 없이 처리가 됩니다.

이를 위해 vertx.deployVerticle() 시 두번째 매개변수로 DeploymentOptions 개체를 통해 옵션값을 지정해줘야 합니다.

DeploymentOptions options = new DeploymentOptions().setWorker(true);
vertx.deployVerticle("Test3_5.java", options);

그리고, 하나의 Verticle 은 하나의 Instance 만 생성해서 처리하기 때문에 위의 예제에서는 Sleep 이 하나가 처리되기 전까지 다음 Sleep 은 앞의 Sleep 이 끝날 때까지 기다려야 하는 문제가 발생합니다. node.js 는 이를 여러개를 직접 실행하는 방법으로 약간은 무식(?)하게 해결하곤 하는데, Vert.x 에서는 그냥 Instance 수를 여러개 지정해서 띄워버리면 동시 처리개수를 늘려버릴 수 있습니다. 이는 JVM 을 사용하기 때문에 가질 수 있는 이점이기도 합니다

DeploymentOptions options = new DeploymentOptions().setWorker(true).setInstances(2);
vertx.deployVerticle("Test3_5.java", options);

이번에는 Vert.x 의 핵심이라 볼 수 있는 EventBus 의 기본적인 사용법과 간단한 특성을 잠깐 살펴봤습니다. 저번 글을 적고 난 뒤에 코드가 좀 길어질 것 같고 실수하는게 많아져서 아예 깃헙에 코드를 올리는 쪽으로 생각을 바꿨습니다. 설명이 자세하지 않더라도 소스를 실행해보시면 크게 어렵지는 않으실 겁니다. 질문 사항이 있으시면 언제든지 댓글로 올려주십시오.

오늘은 여기까지...

Vert.x 3.0.0 시작해보기...(2)

2016-05-25T10:19:00.003+09:00

------------------------------------------------------------------------------------------------------

이전 글에서 vertx.createHttpServer() 을 이용해서 웹서버를 바로 띄울 수 있다고 알려드렸습니다. 그냥 서버만 뜹니다. 아무런 동작도 하지 않구요. 이번에는 사용자가 요청한 URL 에 따라 동작하도록 한 번 만들어보겠습니다.

먼저 vertx.createHttpServer() 에 옵션을 추가하는 방법입니다.

HttpServerOptions httpServerOptions = new HttpServerOptions();
// httpServerOptions.setAcceptBacklog(10000);
// httpServerOptions.setSendBufferSize(4 * 1024);
// httpServerOptions.setReceiveBufferSize(4 * 1024);
httpServerOptions.setCompressionSupported(true);

vertx.createHttpServer(httpServerOptions)
   .listen(8080);

HttpServerOptions 라는 개체를 통해 옵션을 지정해줄 수 있습니다. 저는 보통 compressionSupported 옵션만을 이용합니다. json 을 결과를 넘겨줄 때 많은 양의 정보를 보내줄 경우 유용합니다. 게임의 기본 데이터를 시작할 때 보내는 경우 몇 메가의 텍스트 데이터를 보내야 하는데, 압축을 하게 되면 1/10 정도까지 용량을 줄여줍니다.

이번에는 사용자의 요청 URI 에 따라서 분기를 하는 방법입니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test2_1.java

Router router = Router.router(vertx);
Route route = router.route("/:METHOD");

route.handler(routingContext -> {

 HttpServerRequest request = routingContext.request();
 MultiMap params = request.params();

 String method = params.get("METHOD");
 System.out.println(method);

 request.endHandler(empty -> {

  JsonObject param = new JsonObject();
  params.forEach(entry -> param.put(entry.getKey(), entry.getValue()));

 });

});

HttpServerOptions httpServerOptions = new HttpServerOptions();
httpServerOptions.setCompressionSupported(true);

vertx.createHttpServer(httpServerOptions)
  .requestHandler(router::accept)
  .listen(8080);

사용자의 요청 주소를 Router 을 이용해서 일일이 처리하지 않고 URI 의 값에 따라서 분기해서 처리할 수 있도록 만들 수 있습니다. 위에서 /:METHOD 라고 지정되어 있는데 / 뒤에 어떤 주소를 가지느냐에 따라 매개변수 정보에 METHOD 라는 변수에 이 값을 넣어주는 것입니다. Spring MVC 에서도 REST API 에서 비슷한 기능을 보셨을 겁니다.

그래서 위의 문장을 추가한 뒤 vertx run 으로 실행해주면, 이번에는 http://localhost:8080/Login 이나 http://localhost:8080/Index 와 같은 주소 요청에 따라 화면에 Login 이나 Index 가 출력될 것입니다. 물론 아직 return 에 대해서 처리를 하지 않았기 때문에 서버를 실행한 쪽에서 콘솔 출력으로 이 값이 출력되고, 브라우져는 응답을 멍하니 기다리기만 하는 상태이지만요. http://localhost:8080/Login?val1=test1&val2=test2 와 같은 요청도 한 번 해보세요.

눈여겨 보실 점은 모든 매개변수는 MultiMap 형태로 사용자에게 제공된다는 것입니다. 그걸 아래에서 JsonObject 형태로 옮겨 담고 있습니다.(params.forEach() 보이시나요?)

다음에 배울 EventBus 는 vert.x 와 함께 제공되는 JsonObject 나 JsonArray 혹은 자바의 기본 자료형(int, long 등)과 String 등만 전송할 수 있습니다. 그래서 주로 사용하게 될 개체가 바로 JsonObject 가 되겠습니다.

마지막으로, 코드를 좀 더 확장해서 브라우저에 응답을 보내는 것을 해보겠습니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test2_2.java

Router router = Router.router(vertx);
Route route = router.route("/:METHOD");

route.handler(routingContext -> {

 HttpServerRequest request = routingContext.request();
 MultiMap params = request.params();

 String method = params.get("METHOD");
 System.out.println(method);

 request.endHandler(empty -> {

  JsonObject param = new JsonObject();
  params.forEach(entry -> param.put(entry.getKey(), entry.getValue()));

  request.response().putHeader("content-type", "application/json");
  request.response().end("{\"METHOD\": \"" + method + "\"}");

 });

});

HttpServerOptions httpServerOptions = new HttpServerOptions();
httpServerOptions.setCompressionSupported(true);

vertx.createHttpServer(httpServerOptions)
  .requestHandler(router::accept)
  .listen(8080);

요청 결과를 보내기 위해 HttpServerResponse 개체를 request 에서 얻어올 수 있습니다. 그리고 헤더 정보와 결과 문장을 보내고 연결을 종료합니다. request.response().end() 로 말이죠. 그럼 이 응답에 대한 처리는 끝납니다. 이렇게 연결을 종료하기 전에는 새로운 연결을 받지 못합니다. WAS 처럼 쓰레드를 여러개 생성한 뒤 병렬로 처리하는게 아니라 한 번에 하나씩만 처리하기 때문이죠. 이 부분을 잊지 마세요.

오늘은 여기까지...

이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;

위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로, 오류가 있다면 저에게 알려주시면 고맙겠습니다.

Vert.x 3.0.0 시작해보기...(1)

2016-05-25T10:18:00.003+09:00

------------------------------------------------------------------------------------------------------

Vert.x 는 현재 3.0.0 까지 나온 node.js 에 영감을 받아 개발된 툴킷입니다. http://vertx.io 가 공식 웹사이트이고, 구글 그룹스를 운영하고 있으며, 질문 등은 구글 그룹스에만 올리길 권고하고 있습니다. 하지만, 저 같은 영어포기자들은 안구에 습기가...T.T

웹사이트에서도 "Vert.x is a tool-kit for building reactive applications on the JVM." 라고 소개를 하고 있습니다. JVM 기반에서 돌아가기 때문에 기본은 Java 라고 생각하시면 되고, JVM 을 이용하기 때문에 멀티 쓰레드 지원을 별도로 고려할 필요가 없다는 장점이 있습니다. 또한 JVM 의 GC 을 이용하기 때문에 node.js 의 Javascript 엔진보다는 훨씬 더 효율성이 높고 Azul Systems 의 Zing 와 같은 JVM 을 구입하여 운영할 경우 더욱 성능이 올라가는 장점도 있습니다.

설치는 매우 쉽습니다. 공식 사이트에서 최신 버전의 zip 파일이나 tar.gz 파일을 내려받아 압축을 풀어주면 됩니다. bin 디렉토리에 vertx 나 vertx.bat 파일을 이용해서 개발한 소스를 실행할 수 있습니다. 또는, embeded 형태로 개발하면 기존의 실행형 파일에 기능을 내장할 수도 있고, 웹프로그램 안에도 내장할 수 있습니다. 대신, embeded 형태는 vert.x 의 cluster 기능을 이용하지 못한다거나, 사용할 수 있는 언어가 Java 와 Groovy 정도만 지원됩니다.

설치 후 VERTX_HOME 와 VERTX_OPTS 등을 환경변수에 추가해줄 수 있습니다. bin 디렉토리 역시 PATH 에 추가해두면 실행 시 편하겠죠. VERTX_OPTS 에는 -Dfile.encoding=UTF-8 을 추가해두는 게 좋습니다. 소스 파일 내에 한글을 쓸 경우 이 옵션이 빠졌을 때 컴파일 오류가 발생하거나(vertx 명령어로 실행할 때 컴파일을 합니다. class 파일을 가지고 하는게 아닙니다) 콘솔로 메세지를 출력할 때 메세지가 제대로 안보일 수 있습니다.

앞으로의 팁은 embeded 는 배제하고 vertx 명령을 통해 실행하는 방법만 소개합니다. JDK 는 8 버전을 이용합니다. 왜냐하면, 소스 코드가 짧아지거든요.

먼저 소스 코드를 아래와 같이 작성해봅니다.

https://github.com/zepinos/VertxExample/blob/master/src/main/java/Test1.java

import io.vertx.core.AbstractVerticle;

public class Test1 extends AbstractVerticle {

 @Override
 public void start() throws Exception {

  super.start();

  vertx.createHttpServer()
    .requestHandler(httpServerRequest -> {})
    .listen(8080);

 }

 @Override
 public void stop() throws Exception {

 }

}

HTTP 서버를 띄웠습니다. node.js 을 해보신 분들은 금새 아실 내용이겠네요.

그리고 Test1.java 로 저장한 뒤, Test1.java 이 있는 곳으로 이동한 뒤...

vertx run Test1.java

라고 해봅니다.

서버 실행됐습니다! 물론 아무런 동작은 안하지만, netstat -na 등의 명령으로 포트를 확인해보시면 서버가 떴음을 알 수 있습니다.

종료는 Ctrl+C 로 그냥 꺼버리시면 됩니다.

오늘은 여기까지...

Spring RestController 의 응답결과에 값 추가하기

2016-04-15T14:35:00.000+09:00

Spring RestController 을 이용해서 쉽게 JSON 이나 XML 형태의 값을 클라이언트에게 전송할 수 있습니다. 하지만, 때론 Controller 까지 그 값을 넣어주지 않았는데 일괄적으로 그 값을 보내줘야 할 때가 있습니다.

그럴 경우 하나의 방법으로 WebMvcConfigurerAdapter 을 상속받은 클래스를 만들어 configureMessageConverters 을 Override 하는 방법이 있습니다.

JSON 의 예를 들어보면, Spring 에서 JSON 은 Jackson 을 기본으로 합니다. 그럼 아래와 같은 형태의 Override 을 구현해야 합니다.

@Override
public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {

}

매개변수로 받게 되는 converters 에 새로운 MessageConverter 을 추가(add method 이용)하는 방식입니다. Jackson 은 AbstractJackson2HttpMessageConverter 을 제공하기 때문에, 이것을 이용해서 writeInternal 을 Override 해서 구현하면 됩니다. 물론 wirteInternal 에 대한 소스는 오픈소스이기 때문에 쉽게 구할 수 있기 때문에, objectWriter.writeValue(generator, value); 이전에 value 에 원하는 값을 추가하면 JSON 에 값이 추가됩니다.

configureMessageConverters 일 이용하면 JSON 뿐만 아니라 Spring 에서 기본 제공하지 않는 MessagePack 같은 것도 converter 로 추가하는 등의 작업이 가능합니다.

Spring Web 에서 request parameter 추가

2016-04-08T14:22:00.002+09:00

Spring Web 에서 Client 가 요청한 주소에 기반해서 값을 request 에서 가져올 수 있지만, 가끔 그 매개변수에 서버 쪽에서 어떤 값을 추가해서 받아야 할 필요가 있을 때가 있습니다. 저의 경우는 Spring MVC 에서 실제 요청을 받은 Controller 의 method 명을 알고자 할 때 강제로 Exception 을 발생시켜 첫번째 라인의 method 명을 알아내는 방식보다는, 이 방식으로 요청되는 주소에서 값을 얻어서(주소에 method 명이 유추되도록 구성되어야 하겠죠) request 에 추가하도록 처리하였습니다.

원리는 간단하면서도 살짝 복잡합니다. 일단 HttpServletRequest 라는 개체는 setParameter 라는 것이 존재하지 않습니다. 이와 같이 매개변수를 개발자가 마음대로 조작할 수 있을 경우 문제가 더 클 수 있기 때문입니다. 그래서 약간의 우회적인 방법이 필요합니다.

먼저, Filter 을 등록해야 합니다. Interceptor 는 불가능한 것으로 압니다. Filter 에서 doFilter method 등을 Override 받아 구현할 때 HttpServletRequest, HttpServletResponse, FilterChain 을 매개변수를 받을 것입니다. 이 때 매개변수로 받은 HttpServletRequest 개체를 생성자로 받아서 이를 확장할 HttpServletRequestWrapper 클래스를 상속받아 구현하는 것입니다. 통상적으로 request 의 getParameterMap() 을 이용해 Map 에 매개변수들을 저장한 뒤 getParameter(), getParameterMap(), getParameterNames(), getParameterValues() 등을 Override 해서 구현하고, setParameter() 을 새롭게 구현(setParameter() 는 2 개의 오버로드된 method 로 구현합니다)하는 형태가 됩니다.

이렇게 구현된 HttpServletRequestWrapper 는 HttpServletRequest 의 구현체 중 하나이기 때문에 Controller 로 전송되어도 사용에 크게 문제가 없습니다(OOP Design Pattern 의 장점).

저는 보통 이렇게 구현해놓고 씁니다.

public class HttpRequestWithModifiableParameters extends HttpServletRequestWrapper {

    Map<String, String[]> params;

    public HttpRequestWithModifiableParameters(HttpServletRequest request) {

        super(request);
        this.params = request.getParameterMap();

    }

    @Override
    public String getParameter(String name) {

        String[] paramArray = getParameterValues(name);

        if (paramArray != null && paramArray.length > 0) {

            return paramArray[0];

        } else {

            return null;

        }

    }

    @Override
    public Map<String, String[]> getParameterMap() {

        return Collections.unmodifiableMap(params);

    }

    @Override
    public Enumeration<String> getParameterNames() {

        return Collections.enumeration(params.keySet());

    }

    @Override
    public String[] getParameterValues(String name) {

        String[] result = null;
        String[] temp = params.get(name);

        if (temp != null) {

            result = new String[temp.length];
            System.arraycopy(temp, 0, result, 0, temp.length);

        }

        return result;
    }

    public void setParameter(String name, String value) {

        String[] oneParam = {value};
        setParameter(name, oneParam);

    }

    public void setParameter(String name, String[] values) {

        params.put(name, values);

    }

}

그래도 남용은 하지 말아야겠습니다.

채팅 서버 구상 (Netty + RabbitMQ)

2016-04-07T18:50:00.001+09:00

곧 출시할 서버에서 임시로 쓸 채팅 서버를 구상하였습니다.

네트워크 엔진(프라우드넷 같은)이 도입되면 거기 것을 쓸 것이고, 채팅이 중요한 부분을 차지한다고 생각도 들지 않아서 일단 땜빵 비스무리하게 구현했네요.

요구 조건은 다음과 같습니다.

사용자가 주기적으로 새로운 메세지가 있는지 확인하는 방식은 안됨. (주기적 확인)
많은 사용자가 접속할 수 있으므로 메세지 전송은 최대한 가벼워야 함. (가벼움)
채팅 내용이 많이 전송되지 않을 수 있지만, 사용자가 매우 많이 접속할 수 있으므로 수평적 확장(Scale Out)이 가능해야 함. (수평적 확장)
사용자 인증이 된 접속에게만 메세지 내용을 전파해야 함. (인증)
메세지 내용을 필터링 할 수 있어야 함. (필터링)

채팅방을 따로 만들어서 채팅하고 이런 기능은 일단 고려 대상에서 제외하고, 서버마다 개별적으로 내용이 전달되는 형태보다는 모든 서버가 논리적으로 하나의 서버인 것처럼 보이고 싶었던 것이 나의 고민이었습니다.

혼자서 이것저것 고민해봤으나 가장 괜찮은 방법은 클러스터링 된 Queue 을 이용해서 사용자들이 L4 을 통해 어떤 서버에 접속을 해 있든 자신이 받을 메세지를 Queue 에서 뽑아오는 형태가 좋을 것 같았습니다. 물론 상대가 메세지를 보내는 순간 접속이 되어 있지 않다면 그 메세지는 받을 필요가 없기 때문에 반드시 사용자별로 Queue 를 구현할 필요는 없다는 생각도 있었습니다.

그래서 구상한 물리적 구성은 다음과 같습니다.

L4 - 채팅서버 애플리케이션 - Cluster 된 RabbitMQ 서버

서버는 아주 단순합니다. 다만, RabbitMQ 서버는 Cluster 된 상태여야 합니다. 1 개의 RabbitMQ 만 있다가 서버가 중지되면 곤란하니까요. 그리고 채팅서버 애플리케이션이 동작하는 서버와 RabbitMQ 서버는 물리적으로 분리되어 있어도 상관없으나, 퍼블리셔에게 신청한 채팅서버는 분리된 형태가 아니다보니, 물리적으로 하나의 서버에 설치하는 것으로 할 계획입니다. 어짜피 채팅서버 애플리케이션은 매우 가벼울테니...

실제 채팅서버 애플리케이션은 다음과 같은 흐름을 가질 것입니다.

애플리케이션이 실행되면 RabbitMQ 에 애플리케이션 독자적인 Queue 을 선언합니다. 채팅서버 애플리케이션마다 한 개씩 가지게 됩니다. Topic 형태에 맞게 이름을 부여하겠죠.
RabbitMQ 에 TopicExchange 을 생성합니다. 위에서 만든 Queue 에 모두 전파할 수 있도록 말이죠.
위에서 만든 Queue 와 Exchanger 을 이용해 RabbitMQ 에 접속합니다.
사용자 접속 요청을 받을 수 있도록 Netty 로 decoder 와 encoder 을 생성합니다.
사용자가 접속을 하면 접속자 풀(Singleton 에 있는 Map)에 등록을 합니다.
사용자의 첫 메세지가 인증에 관련된 것이라면 인증을 처리하고 사용자 풀(Singleton 에 있는 Map)에 사용자 정보(Netty 의 Channel 이 있어야겠죠)를 입력합니다. 인증 실패 혹은 인증에 관련된 것이 아니라면 접속을 강제로 끊어야겠죠.
사용자에게 채팅 메세지가 전송되어 오면, 메세지 내용과 상황에 맞는 변조를 거쳐 RabbitMQ 에 데이터를 전송합니다. 물론 위에서 선언한 Exchanger 을 통해 전송해야하고, 이 작업을 통해 채팅 메세지는 모든 Queue 에 하나씩 전송됩니다.
각 서버는 자신이 바라보고 있는 하나의 Queue 에서 채팅 내용을 순서대로 하나씩 꺼내옵니다. 이 때 Spring Boot AMQP 같은 것을 이용하면 구현이 매우 쉽게 되겠죠.
꺼내온 내용을 처리하여 사용자 풀에 있는 모든 사용자에게 채팅 내용을 전송합니다. 사용자 풀에 Channel 이 있을 것이므로 Map 의 values 을 Collection 으로 받아와 pararellStream() 으로 처리하면 병렬 처리도 될 것입니다.

이렇게 프로그래밍 된 채팅서버를 가지고 테스트를 진행해볼 것입니다. 물론 채팅 클라이언트는 제가 만드는게 아니라서...언제 테스트를 진행할지는 의문이지만요
실제 코드는 그리 길지 않습니다. 자잘한거 다 빼면 30 라인 조금 넘으려나...

일단, 조건에 대한 만족 여부를 판단해보겠습니다.

주기적 확인 : 사용자가 메세지를 보내면 서버에서 모든 사용자에게 Channel 을 이용해서 메세지를 전송하기 때문에 연결만 유지한 상태면 됩니다. 그러므로 클라이언트에서 주기적으로 새로운 메세지가 있는지 확인할 필요가 없습니다.
가벼움 : HTTP 전송 등을 사용하지 않기 때문에 가볍습니다. Netty 에서 StringDecoder/StringEncoder 을 제공하기 때문에 평문으로 그냥 보내도 되고, ProtoBuffer 을 이용해서 보낼 수도 있겠죠. 다만, 클라이언트가 Unity 이다 보니, ProtoBuffer 는 못쓸 것 같네요. FlatBuffer 가 제공되면 좋겠는데...일단은 장기적으로 쓸 서버가 아니라서 String 으로 해보고 판단하겠습니다.
수평적 확장 : L4 만 버텨준다면 채팅서버 애플리케이션은 몇 대가 있더라도 상관 없습니다. 자신에게 접속된 사용자를 Singleton Map 으로 관리하고, 메세지가 있을 경우 그 사용자들에게 메세지만 보내주면 되니까요. RabbitMQ 역시 한 대든 여러 대든 상관 없습니다. Queue 가 어마어마하게 생길 리도 없고(채팅서버 애플리케이션이 그렇게 많이 실행될 리가 없으니까요) 서버가 늘어나도 Cluster 연결만 하면 문제 없습니다. 다만 전파속도가 얼마나 빠를지는 테스트를 안해봤네요. RabbitMQ 에 대한 분석이 조금 부족한게 문제겠네요.
인증 : Netty 에서 TCP 나 UDP(UDT) 등이 연결될 때 channelActive() 가 호출됩니다. 여기서 접속된 사용자를 저장하는게 어떤 의미가 있을지...사실 모르겠네요. 그래도 메세지를 보내면 channelRead() 가 호출되는데, 인증된 사용자 풀에 저장되어 있지 않을 경우 로그인 처리를 시도하고, 실패하면 접속을 강제로 끊어버리기 때문에(Channel.close() 을 호출) 연결만 하고 멍하니 있는 시도 등은 한 번 걸러낼 수 있겠지요. 인증된 사용자 풀이 따로 있기 때문에, 여기서 메세지 보낼 사용자 목록을 담아둘 수 있겠습니다. 좀 더 응용하면, 방에 해당하는 Map 도 만들어서 방 사용자에게만 메세지를 보내는 형태도 구현가능하겠죠. 물론, 채팅방 위주의 채팅서버라면 이런 구성보다는 매칭서버와 채팅서버를 분리하는게 좋겠죠.
필터링 : 인증된 사용자가 메세지를 보내면(channelRead() 호출) 메세지 내용을 필터링 해버리면 되지 않을까 싶네요. 보낸 메세지에 대한 로그도 남길 수 있을 것이구요.

이렇게 되겠네요.

아직 확인을 못한 부분은, 채팅서버 애플리케이션에서 RabbitMQ 서버로 접속할 때 Cluster 된 서버 목록을 지정해서 살아있는 서버에 계속 연결이 될 수 있느냐겠네요. RabbitMQ 분석을 다른 사람에게 맡겨놔서 저는 잘 몰라요.

CentOS 7 바뀐 기본 프로그램들...

2015-10-15T15:58:00.000+09:00

기본적으로 네트워크 부분이 eth0 등으로 부여되던 이름이 개별적인 이름으로 바뀌었음.

바뀌어도 너무 많이 바뀜.

1. ifconfig -> ip addr

ip 명령으로 바뀜. 물론 ifconfig 을 별도 설치할 수 있긴 함.
ifup / ifdown 은 그대로 존재하나, ip addr 을 통해 장치 이름 확인 후 그 장치 이름을 써야 함

2. 네트워크 설정 -> nmtui

이젠 기본으로 TUI 가 최소 설치에도 등장. 하지만 설치 방법은 매우 불편해짐.

3. service or chkconfig -> systemctl

service 가 존재하나 별도의 서비스들을 제어하려면 systemctl 로 해야함.
chkconfig 으로 등록하고 제어하던 시작 프로그램들 역시 systemctl 에서 제어함. 목록은 systemctl list-unit-files (기본값인 list-units 는 복잡함) 로 확인 가능.

4. iptables -> firewalld

기존에는 service stop iptables 로 서비스를 껐으나, 이젠 systemctl stop firewalled 로 끌 수 있음.

5. SELINUX

setenforce 로 SELINUX 을 제어하는 것은 동일. 하지만 설정 위치가 /etc/selinux 에서 /etc/selinux/config 으로 변경됨.

인코딩(Encoding)에 대한 이해 - (3) JSP 에서의 인코딩 설정 및 한글 매개변수 가져오기에 대한 고찰.

2015-07-06T15:49:00.000+09:00

웹 개발을 하면서 처음에는 까다롭게 다가오다가 어느 순간 의미도 모른채 그냥 그 설정 그대로 유지하는게 바로 언어에 대한 인코딩이 아닌가 합니다. 특히 정형화된 구조에서 크게 문제가 발생하지 않기 때문에 신경을 쓰지 않다가 새로운 환경으로 이전을 하게 된다거나 할 때 한글이 깨지는 등의 문제가 발생하여 고생을 할 때가 종종 있습니다.

그래서 인코딩에 대한 최소한의 내용을 알려드려 크게 당황하지 않도록 도움을 드리고자 합니다.

이 글은 초보자를 위한 글이므로, 인코딩(Encoding) 정도는 우습다는 분은 패스해주길...^^;;;

------------------------------------------------------------------------------------------------------

이번에는 HTML 이 아닌 JSP 의 인코딩 설정에 대해서 먼저 간단하게 집고 넘어가겠습니다.

JSP 는 ASP, PHP 와 같은 웹 언어들과 비슷한 것 같지만, 비교 우위에 있는 큰 장점이 하나 있습니다. 바로 훌륭한 개발툴인 이클립스(Eclipse) 등의 존재입니다.

이클립스와 같은 개발툴은 JSP 을 지원했다기 보다는 Java 와 같은 개발 언어를 지원하는데, 이를 JSP 에서도 도움을 받을 수 있어서 실제 개발을 하다 보면 ASP 나 PHP 는 ultraedit 나 editplus 와 같은 일반 텍스트 에디터로 개발을 많이 하는 반면 JSP 를 개발하는 분들은 십중팔구 이클립스를 이용합니다.

그런데, 이클립스와 같은 개발툴이 JSP 의 인코딩 방식이 무엇인지 알 수 있게 선언할 수 있는 방법이 있습니다. 바로 파일 상단에 이에 대한 선언을 하는 것입니다.

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

이런 선언을 많이 보셨을 겁니다. 이렇게 선언을 하면 이클립스와 같은 IDE 는 해당 파일이 UTF-8 로 인코딩된 파일이라는 것을 눈치채고 파일을 열어주게 됩니다.

그럼 왜 UTF-8 이 두 번 선언이 되어 있을까요?

JSP 는 먼저 서버에서 Java 로 변환이 된 뒤에 그 결과(=HTML)를 클라이언트에 전송하고, 클라이언트는 HTML 만을 해석하여 사용자에게 제공을 합니다. 그래서 HTML 의 <meta> 는 브라우저를 위한 설정값이라면, 위의 contentType 와 pageEncoding 은 서버를 위한 설정값인데, contentType 은 서버에서 생성될 HTML 의 캐릭터셋, pageEncoding 은 JSP 내의 Java 코드에 대한 캐릭터셋에 대한 정보입니다. 그래서 아래와 같이 두 가지 다른 캐릭터셋으로 정의를 한 뒤 출력할 수도 있습니다.

<%@ page language="java" contentType="text/html; charset=UNICODE" pageEncoding="EUC-KR" %>

예전에는 이렇게 정의를 해서 개발을 했던 적도 실제 있습니다. 실제 HTML 부분에는 한글 등이 없고 DBMS 에서 불러온 값만 출력해주는데, 이 데이터들이 UTF-16 으로 인코딩되어 있을 경우 pageEncoding 까지 UTF-16 으로 선언하면 Java 코드의 크기까지 같이 커지기 때문에 이와 같이 다른 캐릭터셋으로 선언해서 개발하던 적도 있었습니다. 하지만, 요즘은 그렇게 개발을 하지는 않습니다. 바로 디스크의 용량이 비약적으로 커지고 소스 크기는 그렇게 커지지 않았기 때문에 용량에 대한 부담이 거의 없기 때문입니다. 그래서 요즘은 그냥 UTF-8 로 통일해놓고 개발하는 것을 다시 한 번 권해드리는 겁니다.

그런데, HTML 에서 UTF-8 로 인코딩되어 사용자에게 정보가 보여졌는데, 게시글 입력과 같이 사용자가 한글이나 한자 등의 데이터를 입력해서 서버에 전송하게 될 때는 어떤 일이 벌어질까요?

아주 예전에 웹을 설계하던 사람들은 우리의 기대를 저버리지 않고 다국어에 대한 고려를 전혀 하지 않았습니다. 그래서 웹에서 전송되는 문자는 모두 ASCII 을 기준으로 데이터가 전송되는 것으로 설계가 되었습니다. 그래서 HTML 에서 영어가 아닌 다른 캐릭터셋으로 문서를 작성해서 전송하려면 문제가 발생했습니다. 그래서 강제로 문자열을 웹에 맞는 ASCII 로 변환한 뒤 이를 다시 원하는 문자열로 변환시켜주는 작업이 필요했습니다. 이런 작업이 URL Encoding/Decoding 입니다. ASP 에서는 Server.URLEncode 로 변환을 제공하고, Java 에서는 java.net.URLEncoder 의 encode 매서드를 이용해서 변환을 한 뒤 서버로 전송하게 해줬습니다. 혹은 Javascript 에서 변환시켜주기도 했고, 넘어온 문자열을 깨지지 않고 받기 위해서 URLDecoder.decode() 을 이용해서 받거나 request.setCharacterEncoding() 을 이용해서 직접적인 선언을 해서 받아줬습니다. 또한 받은 매개변수를 정확한 내용으로 변경하기 위해 new String(request.getParameter("매개변수명").getBytes("ISO-8859-1"), "UTF-8) 와 같이 길게 변환을 해주는 작업까지 직접 해줘야 했습니다.

하지만, 이런 불편함을 해결하기 위해서 Java 진영에서는 WAS 에서 문자열을 정해진 인코딩으로 직접 받아오는 방법을 제공하기 시작했습니다.

Java 에서 가장 많이 사용되는 Apache Tomcat 에서 주로 사용하는 <Connector> 의 URIEncoding 은 이렇게해서 만들어진 것입니다. 지금은 그냥 공식처럼 <Connector URIEncoding="UTF-8" /> 와 같이 선언하면 매개변수값을 UTF-8 로 그냥 받을 수 있지만, 예전에는 그렇지 않았습니다. 물론 이 또한 GET 에서만 제공되는 방법이고, WAS 마다 GET 을 위한 URL Encoding 명시 방법은 다르기 때문에 사용하는 WAS 에서 어떤 방식을 제공하는지 확인 후 사용해야 할 것입니다. 많이 사용하는 웹로직만 간단히 예를 들면, 웹로직의 가장 기본이 되는 weblogic.xml 파일을 생성한 뒤 다음과 같은 내용을 입력하면 Tomcat 의 URIEncoding 와 같은 효과를 가지게 됩니다.

<wls:charset-params>
    <wls:input-charset>
        <wls:resource-path>/</wls:resource-path>
        <wls:java-charset-name>EUC-KR</wls:java-charset-name>
    </wls:input-charset>
</wls:charset-params>

하지만, 이것들은 WAS 에 종속적이므로 소스 상에서 직접 제어를 하고자 할 때에는 request.setCharacterEncoding() 으로 선언하는 방법을 쓸 수 있습니다. 하지만, 개인적으로는 비효율적이라 생각합니다.

그럼 POST 방식은 어떻게 구현할까요? Spring 을 쓰시는 분들은 web.xml 에 아래와 같이 선언한 것을 많이들 보셨을 겁니다.

<filter>
   <filter-name>encodingFilter</filter-name>
   <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
   <async-supported>false</async-supported>
   <init-param>
       <param-name>encoding</param-name>
       <param-value>UTF-8</param-value>
   </init-param>
</filter>

필터를 이용한 자동 변환 방법인데, 사실 예전에 Spring 에서 이와 같이 필터를 제공해주기 전에는 CharacterEncodingFilter 와 같은 역활을 해주는 필터를 직접 사용자가 구현해서 필터로 등록해서 사용했습니다. Spring 이 많은 편리함을 제공해준다는게 이런 곳에서도 잘 나타나는 것이죠.

개인적으로 바빠지다 보니 점점 글의 내용이 빈약해진다는게 저 스스로도 느껴지네요. 다음 번에는 인코딩에 대한 마지막 글인 MySQL 에서 정보를 가져올 때 인코딩 설정을 어떻게 하는지 간략하게 알아보고 당분간 팁을 작성하는 것은 쉬어야겠네요.

인코딩(Encoding)에 대한 이해 - (2) HTML 에서의 캐릭터셋(CharSet) 지정.

2015-07-02T15:56:00.000+09:00

인코딩(Encoding)에 대한 이해 - (1) ASCII 부터 UTF-8 까지의 변화.

2015-06-29T11:50:00.000+09:00

웹 개발을 하면서 처음에는 까다롭게 다가오다가 어느 순간 의미도 모른채 그냥 그 설정 그대로 유지하는게 바로 언어에 대한 인코딩이 아닌가 합니다. 특히 정형화된 구조에서 크게 문제가 발생하지 않기 때문에 신경을 쓰지 않다가 새로운 환경으로 이전을 하게 된다거나 할 때 한글이 깨지는 등의 문제가 발생하여 고생을 할 때가 종종 있습니다.

그래서 인코딩에 대한 최소한의 내용을 알려드려 크게 당황하지 않도록 도움을 드리고자 합니다.

이 글은 초보자를 위한 글이므로, 인코딩(Encoding) 정도는 우습다는 분은 패스해주시길...^^;;;

------------------------------------------------------------------------------------------------------

일반적으로 한국어를 이용하는 분들이 프로그래밍을 하면서 가장 많이 겪게 되는 인코딩(Encoding)은 ASCII, ISO-8859-1, CP949, MS949, EUC-KR, UTF-8, UTF-16 정도일 것입니다. 이런 인코딩은 무엇을 의미하는 것일까요?

최초의 컴퓨터가 애니악이라는 것은 많은 분들이 잘 아실 겁니다. 저 역시 초등학교(국민학교) 때 애니악, 애드삭, 애드박 등 달달 외어서 전국 컴퓨터 경진대회 출전하고 했던 기억이 나네요. 중요한건 이게 아닙니다만, 어쨌든 초기에는 이런 컴퓨터가 만들어져도 천공카드라고 하는 구멍 뚫린 종이를 이용해서 입력을 했지, 사람이 인식하는 글자로 입력을 한 건 아니었습니다. 그래서 실제 문자에 대한 표준이 나오는데 십수년이 걸렸다고 하네요. 역시나 초등학교 때 BCD, ASCII, EBCDIC 코드에 대해서도 달달 외웠는데, 글자 길이에 따라서 짧은게 더 적은 비트를 이용한다...이렇게 외었더랬습니다. BCD 는 6bit, ASCII 는 7bit, EBCDIC 는 8bit...이렇게요. 가장 많이 사용하게 된 코드는 ASCII 가 되었습니다.

화면 상에 출력될 문자를 7bit 로 나타내게 된 건 영어 문화권의 국가에서 컴퓨터의 발전을 주도했기 때문이었습니다. 7bit 는 2^7 이므로 총 128 개(실제로는 127 개)의 문자를 표현할 수 있었고, 영어 대소문자 각 26 개 뿐만 아니라 화면상에 표시하기 위한(실제로는 beep 라고 하는 경고음까지) 제어문자까지 넣을 수 있는 크기였기 때문입니다.

하지만, 실제 라틴어에서 파생된 많은 언어들은 영어와 비슷하지만 몇가지 다른 문자들을 가지고 있고, 이러한 문자를 다 담는데 127 개로는 부족한 상황이 발생했습니다. 그래서 ISO 표준을 통해 ISO-8859(실제로는 ISO/IEC-8859 던가요) 를 재정하고 이런 추가 문자을 담을 수 있는 집합을 만들어냈습니다. 한 개의 추가 비트를 이용해서 문자의 수를 256 개로 늘려버린 것이죠. 하지만, 이 또한 모든 라틴 계열 문자를 담을 수는 없어서 서브 카테고리라는 것을 통해 문자 집합들을 별도로 관리하게 되었는데, 가장 보편적으로 이용되는 영어권 문자들을 라틴1이라는 영역으로 ISO-8859-1 이라고 정의한 것입니다. 물론 ISO-8859-2 도 있고...16 까지 존재한다고 기억합니다.

문제는, CJK 라고 흔히 불리는 중국/일본/한국어 같은 문자는 이런 문자 집합에 포함되지도 않았고, 포함되기 힘든 상황이었습니다.

먼저 한글입니다. 한글은 세종대왕께서 만드신 아주 과학적으로 창의적인 문자이고, 키보드로 타이핑 할 때에도 아주 효율적인 문자입니다. 하지만, 자소의 조합으로 만들어지다 보니문자를 저장할 때에는 약간의 문제가 발생합니다. "가" 라는 하나의 문자를 표현하기 위해서는 "ㄱ" 와 "ㅏ" 를 각각 저장하고 이를 조합하는 방식과 "가" 라는 글자 자체를 저장하는 방식이 있을 수 있습니다. 이를 각각 조합형과 완성형으로 부릅니다. 초반에는 이 두 진영의 의견이 엇갈렸으나, 국가에서 완성형을 채택합니다. 초기에는 현대 한국어에서만 쓰는 언어들만 코드를 부여해서 제공했는데, 드라마 "똠방각하" 가 방영하면서 문제가 생겼습니다. 정부가 지정한 완성형에서 "똠" 이 포함되지 않아 타이핑을 할 수가 없었던 것입니다. 그래서 확장 완성형이라는 코드도 나오고 표준안에 조합형도 포함시킵니다. 하지만 대세는 완성형으로 흘러가서 현재는 조합형을 거의 쓰지 않습니다. 점점 더 문자 집합을 늘리는데, 이렇게 해서 나오게 된 코드가 KSC 5601 이고 이것이 EUC-KR 입니다. 당연히 일본 쪽도 비슷한 과정을 거치면서 EUC-JP 을 만들었고 중국 역시 별도의 언어 집합을 만듭니다.

Microsoft 는 여기서 좀 더 많은 문자집합을 포함한 코드를 만들어내는데 이것이 CP949 혹은 MS949 입니다.

여기서 문자 코드가 정리되는 듯 했지만, 결국 세계화 시대에 접어들면서 하나의 문서에 여러 언어가 같이 표현될 일이 잦아졌습니다. 그래서 세계의 모든 언어에 코드를 부여해서 사용할 수 있는 문자 집합의 필요성이 대두되었고, 가장 두드러지게 강세를 보였던 두 개의 코드가 나타났습니다. 바로 UTF-16 와 UTF-8 입니다.

얼핏 보기엔 16 비트와 8 비트로 보이고, UTF-16 이 더 큰 문자 집합 같아 보이지만, 사실 그렇진 않습니다. UTF-16 은 16bit 혹은 32bit 로 표현되며, UTF-8 은 8bit~32bit(1byte~4byte, 실제로는 3byte 안에 대부분의 언어가 다 포함되어 있음) 가변 형태로 표현이 됩니다. UTF-16 은 문서 내용 앞에 BOM(Byte Order Mark) 이라고 불리는 값을 입력해서 이 문서가 UTF-16 으로 작성된 문서임을 알립니다. UTF-8 은 저장된 값의 연산을 통해 이 문서가 UTF-8 을 알 수 있도록 구성되어 있습니다. 하지만, MS 에서 UTF-8 에도 BOM 을 앞에 삽입하게 됨으로써(UTF-8 표준에는 BOM 을 넣을 필요도 없고, 넣지 않는 것을 권고하고 있고, 넣지 않는게 표준이라고 분명히 명시하고 있습니다) 메모장 등으로 저장한 UTF-8 은 앞에 BOM 이 강제로 삽입되게 되고, 이를 Java 에서 읽을 경우 BOM 영역 때문에 문서 앞이 깨지고 이상 동작이 발생하는 문제가 생기게 되었습니다. 여기서 분명 말씀드리지만, UTF-8 에서 BOM 은 빼는게 맞고, Java 는 표준에 맞는 행동을 하기 때문에 비표준 방식에서 문제가 나타나는 것일 뿐입니다. 그래서 비표준 문서를 바꾸는게 맞는 방법입니다.

어쨌든 국내에서는 초반에 UTF-16 을 좀 더 선호하는 경향이 있었습니다. UTF-8 에서 한글은 모두 16bit 안에 코드가 부여되어서 한 글자를 표현하는데 16bit 가 소비되었지만, UTF-8 에서는 24bit 영역(3바이트)에 코드가 부여되어 있어서 동일한 내용을 저장하는데 UTF-16 이 더 효율적이었기 때문이었습니다. 그래서 제가 초반에 다루었던 수많은 한국학 관련 XML 데이터들은 모두 UTF-16 으로 작성되었습니다.

하지만, UTF-8 은 UTF-16 보다 나은 장점 하나가 있었습니다. 가변 방식이다 보니, 8bit(1byte) 영역에 정의된 문자들은 UTF-16 보다 적은 공간을 차지한다는 것이었습니다. 이 8bit 영역에 정의된 문자가 바로 ISO-8859-1 에 정의된 영어권 문자들이었습니다. 앞서 말씀드렸듯이 영어권이 가장 큰 힘을 발휘하고 있는게 사실이고, 그 사람들은 자기들이 문서를 작성하는데 왜 공간을 낭비하냐는 생각이 앞섰기 때문에 UTF-8 에 더 힘을 실어 주었습니다. 게다가 UTF-8 의 8bit 영역은 ISO-8859-1 와 코드값이 일치해서 그들의 입맛에 더 맞는 형태였습니다.

그러나 예외는 있습니다. 한자가 특히 큰 문제인데요...한자는 아직도 새롭게 생겨나고 있는 언어입니다. 우리나라도 예외는 아닌데, 특히 조선시대 양반들의 경우 자신의 이름에 쓰이는 한자가 다른 사람과 동일하게 쓰이는 것을 싫어해서 원래 한자에 점 하나를 더 찍거나 선 하나를 더 긋는 식으로 새로운 한자를 만들어내기도 했습니다. 이런 문제 때문에 아직도 신출자라고 하는 형태로 해서 새로운 한자가 추가되고 있으며, 중국과 일본에서도 자신들만의 한자를 계속 만들어내고 있는 형편입니다. 그래서 이런 한자들을 써야하는 곳에서는 별도의 폰트를 만들어서 다운로드해서 쓰게 하고 있습니다.

이렇게 문자코드가 발전을 해왔는데, 사실 현재의 대세는 UTF-8 이 되어버린 상황입니다. 그래서 예전 코드를 관리하는 입장에서라면 문자 코드를 유지하는 것이 좋지만, 새로운 프로젝트에서는 UTF- 8 로 문자 집합을 통일해서 쓰는 것을 제안하는 바입니다.

다음 글에서는 HTML 에서 JSP, Java, DBMS 로 이어지는 문자 코드 설정에 대해서 글을 적어보겠습니다.

이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;

위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로, 오류가 있다면 저에게 알려주시면 고맙겠습니다.

페이징(Paging)에 대한 이해 - (3) LIMIT 와 TOP 을 이용한 게시물 가져오기.

2015-06-26T11:11:00.001+09:00

흔히 웹 개발을 처음 하는 개발자가 처음 겪게 되는 난관은 바로 게시판의 페이징(Paging)이 아닐까 합니다. 특히 DBMS 와 연동해서 개발하는 경우가 많은데, 각 DBMS 마다 페이징 방법도 많고 성능 등 신경써야 할 부분이 많이 때문에 어떤 자료를 보고 따라해야 문제가 없을지 판단하기 막막할 때가 있습니다.

그래서 페이징에 대한 원리를 파악해서 가장 기본적인 페이징 구현을 할 수 있는 방법을 알려드리고자 합니다.

이 글은 초보자를 위한 글이므로, 페이징 정도는 우습다는 분은 패스해주시길...^^;;;

------------------------------------------------------------------------------------------------------

이번에는 MySQL 이나 PostgreSQL 등에서 사용하는 LIMIT 와 MS SQL Server 의 예전 페이징 기법인 TOP 에 대해서 알아보겠습니다.

먼저 LIMIT 는 게시물을 가져오는데 최적의 방법을 제공합니다. 하지만 동일한 LIMIT 라는 이름이라도 사용방법은 사실 좀 다릅니다.

앞선 글에서 ROW NUMBER 을 이용하는 방식에서 설명 드렸듯이 순차적으로 내용을 정렬한 뒤 여기에 번호를 붙여서 번호 범위를 이용해서 게시물을 가져온다고 하였습니다. 하지만, 이렇게 번호를 붙이는 것은 LIMIT 와 같은 기능을 가지고 있지 않을 때의 이야기입니다. LIMIT 에서는 정렬된(order by 된) 게시물의 범위를 지정해 해당 게시물만 가져오는 기능이 있고, 번호를 부여한 다음 그 번호를 이용해 다시 비교를 할 필요가 없기 때문에 ROW NUMBER 보다 속도가 빠릅니다.

MySQL 에서는 다음과 같이 countPage = 10 일 때 3 페이지의 게시물을 가져올 수 있습니다.

select id, name, content, createdate
from board
order by createdate
limit (3 - 1) * 10, 10

MySQL 의 LIMIT 은 두 개의 매개변수를 가지는데, 첫번째 매개변수는 시작 위치, 두번째 매개변수는 가져올 게시물 수 입니다. 그래서 20 이후의 게시물 10 개를 가져오게 됩니다. 주의할 것은 매개변수를 1 개만 가질 수도 있는데, 이 때에는 통상적인 것처럼 첫번째 매개변수만 사용하는 것이 아니라 두번째 매개변수만 사용한다는 것입니다. 그러므로 limit 10 이라고 하면 limit 0, 10 와 동일한 것이 된다는것입니다.

PostgreSQL 의 LIMIT 은 조금 다릅니다.

select id, name, content, createdate
from board
order by createdate
limit 10 offset (3 - 1) * 10

offset 이라는 것이 추가되고, 매개변수의 위치가 바뀌었습니다. MySQL 와 마찬가지로 offset 은 생략 가능합니다. 단지 순서가 다르고 사용법이 조금 다를 뿐, 동일한 기능입니다.

위 예제에서 보셨드셔이 LIMIT 는 게시물을 가져올 때 최적의 성능과 최소한의 쿼리를 이용할 수 있다는 장점이 있습니다.

여담으로, 어떤 게시판 형태들을 보면 화면상에 ID(Index, Sequence) 대신에 화면상에 출력될 순서대로 번호를 보여주는 경우들이 있습니다. 직관적으로 게시물의 갯수 등을 파악할 때 용이합니다. 이 경우 해당 게시물에 마우스를 올려 링크 주소를 보면 화면에 표시되는 번호와 실제 이용에 이용하는 id 가 다른 번호를 가지고 있는 경우가 있습니다.

당연히 ROW NUMBER 을 이용할 때에는 순차적으로 번호를 부여한 뒤 가져오기 때문에 이 값을 이용하면 됩니다. 하지만, LIMIT 의 경우 순차적으로 번호를 부여한 것이 없기 때문에 프로그램에서 총 페이지와 현재 페이지 등을 이용해서 번호를 부여할 수 있습니다. 하지만 MySQL 등에서도 ROW NUMBER 을 부여하는 기능을 흉내낼 수 있는데, 게시물 뿐만 아니라 계층구조(오라클의 connect by 같은)을 만들 때도 이용할 수 있습니다. 방법은 다음과 같습니다.

select @ROWNUM := @ROWNUM + 1 as rnum, id, name, content, createdate
from board, (select @ROWNUM := 0) A
order by createdate
limit (3 - 1) * 10, 10

바로 변수를 이용해서 처리하는 방식입니다. 물론 총 게시물 수를 먼저 조회할 것이기 때문에 초기값을 0 이 아닌 전체 게시물 수로, 1 씩 증가시키는 대신 1 씩 감소를 시키는 형태로 변경하면 역순으로 번호를 발급할 수도 있습니다.

그럼 PostgreSQL 은???

PostgreSQL 에는 ROW NUMBER 발급을 해주는 row_number() 가 있습니다. 게시물 쪽에서는 모든 기능이 다 있는 것은 PostgreSQL 이라고 볼 수도 있겠네요. ^^;;;

오라클이나 MS SQL Server 에서도 최근에 OFFSET FETCH 라는 기능이 추가되어(오라클 12c 이상, MS SQL Server 2012 이상) LIMIT 와 같은 기능을 수행합니다. 하지만 성능 테스트를 진행해보지 못해서...들리는 말에 의하면 MS SQL Server 는 성능이 실망스럽다고 하네요.

마지막으로 TOP 방식에 대해서 알아보겠습니다. 사실 TOP 방식은 그냥 이론적으로만 알고 계시기만 해도 됩니다. 사실 TOP 이라는 키워드는 MS SQL Server 에서 제공하는 것이고, MS SQL Server 의 근간이 되는 데이터베이스도 사실 유사한 기능으로 페이징을 제공합니다.

그런데 MS SQL Server 2005 부터 row_number() 제공하면서 이 TOP 을 이용한 게시물 가져오기는 쓰지 않게 되었습니다. 성능 상의 문제도 있고, 사실 좀 멋진 방법은 아니거든요. 그래서 이번에는 그 중 대표적인 두 가지 방식만 설명하겠습니다.

SQL Server 6, 7 을 거쳐 2000 이 주로 쓰이던 시절까지도 사실 게시물이 몇십만 건씩 쌓여있는 게시판이나 업무 시스템 등은 없다고 해도 무방했습니다. 그래서 초기에 나온 페이징 방법은 그다지 좋지 못한 방법이었습니다. 흔히 NOT IN 방식이라고 표현하는데, ROW NUMBER 방식의 최외각 부등호/MySQL 의 첫번째 매개변수/PostgreSQL 의 offset 에 해당하는 제외 기능(SKIP 이라고 표현하겠습니다)을 구현하기 위해 NOT IN 을 썼습니다. 그런데 이게 성능이 별로 안좋습니다.

원리는 매우 간단합니다. totalCount = 25, countPage = 10, page = 2 인 경우라면 정렬을 한 뒤 10 까지의 게시물을 제외하고 상위 10 개의 게시물을 가져오는 것입니다.

select top 10 id, name, content, createdate
from board
where id not in (
select top (2 - 1) * 10 id
    from board
    order by createdate)
order by create date

아직도 오래된 글들을 보면 이 방식을 많이 소개하고 있을 겁니다. 문제는 NOT IN 이 성능이 꽤나 나쁘다는 것입니다. 그래서 후에 IN 을 이용한 방식도 나왔습니다만, 저는 주로 TOP 을 두 번 중첩해서 쓰는 방법을 이용했었습니다. 물론 성능은 여전히 안좋습니다.

TOP 을 두 번 이용하는 방식은 LIMIT 와 조금 비슷합니다. order by 을 이용해서 뒤집는 것인데, 인덱스 등을 이용할 수 없기 때문에 성능은 좋지 않습니다.

select top 10 A.id, A.name, A.content, A.createdate
from (
    select top 2 * 10 id, name, content, createdate
    from board
    order by createdate) A
order by createdate desc

2 페이지를 가져오기 위해 1 ~ 2 페이지의 게시물을 가져온 뒤(20개, 2 * 10) 이 결과를 뒤집어서 마지막 10 개(=countPage)을 가져오는 것이죠. 원리상 크게 어렵지는 않습니다. 실제 화면에 출력해 줄 때에는 ResultSet 이나 List 에서 역순으로 꺼내오기만 하면 됩니다.

하지만, 이 쿼리는 여기서 끝내면 안됩니다. 왜냐하면, 위 예제에서 3 페이지, 즉 마지막 페이지를 가져올 때에 문제가 생기기 때문입니다. 총 게시물이 25 개이기 때문에 3 페이지는 21 ~ 25 까지의 5 개의 게시물을 가져와야 합니다. 하지만, 위 쿼리대로라면 top 30 을 해도 실제로는 25 개의 게시물만 가져오기 때문에 외각의 top 10 을 만나면 21 ~ 25 가 아닌 16 ~ 25 사이의 게시물을 가져오게 됩니다. 그래서 중첩된 TOP 을 쓸 경우에는 반드시 외각의 TOP 은 totalCount 을 이용해서 몇 개의 게시물을 가져올지 계산한 뒤 처리해야 합니다.
다음은 Java 에서의 처리 예제입니다.

int totalCount = 25;
int countPage = 10;
int page = 3;

int countTop;
if (page * countPage > totalCount) {

    countTop = totalCount - (page - 1) * countPage;

} else {

    countTop = countPage;

}

위에서 계산된 countTop 을 이용해서 필요한 만큼만 가져오게 해야 한다는 것이죠.

혹시나 매우 오래된 시스템을 유지보수 해야할 경우 참고하시면 좋겠네요.

이로써 페이징에 대한 소개를 마무리 할 수 있게 되었네요.

초보 분들에게 많은 도움이 되었으면 좋겠네요.

다음에는 페이징 만큼의 이론적인 설명이 아닌, 아주 간단한(그냥 이렇게 해놓고 잊자는 수준의) 인코딩 방법을 설명해볼까 합니다. 제 PC 에 이클립스가 안깔려있어서 잘 될런지는 모르겠네요. 아마 DBMS 는 MySQL 만 설명을 할 것입니다. 오라클도 하고 싶지만, 접근 가능한 오라클 장비가 없어서...

이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;

위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로, 오류가 있다면 저에게 알려주시면 고맙겠습니다.

페이징(Paging)에 대한 이해 - (2) ROW NUMBER 을 이용한 게시물 가져오기.

2015-06-23T12:16:00.003+09:00

흔히 웹 개발을 처음 하는 개발자가 처음 겪게 되는 난관은 바로 게시판의 페이징(Paging)이 아닐까 합니다. 특히 DBMS 와 연동해서 개발하는 경우가 많은데, 각 DBMS 마다 페이징 방법도 많고 성능 등 신경써야 할 부분이 많이 때문에 어떤 자료를 보고 따라해야 문제가 없을지 판단하기 막막할 때가 있습니다.

그래서 페이징에 대한 원리를 파악해서 가장 기본적인 페이징 구현을 할 수 있는 방법을 알려드리고자 합니다.

이 글은 초보자를 위한 글이므로, 페이징 정도는 우습다는 분은 패스해주시길...^^;;;

------------------------------------------------------------------------------------------------------

이번에는 DBMS 에서 ROW NUMBER(오라클의 rownum, SQL Server 의 ROW_NUMBER(), MySQL 의 변수를 이용한 번호 등)을 이용한 게시물 가져오기에 대해서 설명하겠습니다.

ROW NUMBER 는 쉽게 말해 출력되는 결과물에 순차적인 번호를 달아주는 기능입니다. 필요할 때 언제든지 번호를 달아달라고 시스템에 요청을 하면 사용자에게 보내줄 데이터에 번호를 달아주게 되죠. 문제는 이 번호를 달 때 정렬이 되어 있지 않다면 번호를 엉뚱하게 달 수도 있고, 번호를 단다는 것 자체가 시스템에 부하를 줘서 정말 많은 게시물을 가지고 있는 경우 특정 영역의 게시물들을 가져오는데 그 반응이 느려진다는데 있습니다.

DBMS 는 보통 인덱스(Index) 라는 것을 가지고 있습니다. 그래서 1 억 개 이상의 데이터를 가지고 있더라도 인덱스를 이용하면 원하는 자료를 순식간에 가져올 수 있습니다. 하지만, 게시판에서는 특정 번호를 가지고 데이터를 불러올 수 없습니다. 실시간으로 계속 자료가 쌓이다보면 해당 페이지에 보일 게시물의 내용이 지속적으로 바뀌기 때문입니다. 변동이 좀 덜하거나 하면 해당 페이지에 속한 게시물이 어떤 것인지 따로 기입한 뒤 그 정보를 통해 게시물을 가져오면 속도에 대한 문제가 발생하지 않지만, 추가 뿐만 아니라 삭제의 경우 이런 페이징을 어렵게 만드는 요인입니다. 그래서, 화면에 출력되어야 할 순서대로 정렬을 한 뒤 가상의 번호인 ROW NUMBER 을 앞에 달아줘서 원하는 영역의 자료만 가져올 수 있는 방식을 취합니다.

그런데, 일반적인 게시판은 아주 단순한 특징을 하나 가지고 있습니다. 사람들은 일반적으로 페이지 번호가 3 페이지 이상인 것을 거의 읽지 않는다는 것입니다. 즉, 페이지 번호가 낮은 것을 훨씬 더 많이 조회하고 있고, 그 비율이 제 경험상 5 페이지 이하의 페이지 조회율이 95% 이상이라고 생각하고 있습니다. 그러므로 총 페이지수가 1000 페이지인 많은 글이 있는 게시판이라도 1000 페이지를 읽는데 5 초가 걸리더라도 1 페이지를 읽는데 0.01 초 밖에 걸리지 않는다면 사용자들은 그렇게 느리다고 느끼지 않는다는 것입니다. 1 페이지나 1000 페이지나 모두 2 초씩 동일하게 소비되는 것보다 더 빠르고 좋은 게시판으로 사람들은 생각한다는 것이죠. 그래서 이런 특성을 이용한 게시물 가져오기 방식을 많이 쓰게 됩니다.

그럼 테스트 데이터 구조를 정의하겠습니다. 쿼리는 오라클로 하겠습니다. 먼저, board 라는 테이블이 존재하고, id, name, content, createdate 라는 필드가 존재한다고 하겠습니다. 여기서 createdate 는 date 형의 필드이고, id 는 sequence 형태의 number 형, name 은 varchar2, content 는 crob 의 형이라고 가정하겠습니다.

일반적으로 게시판을 검색할 때에는 최근에 작성한 순서대로 게시물을 조회합니다. 그럼 다음과 같은 쿼리를 작성하게 될겁니다.

select id, name, content, createdate
from board
order by createdate

이렇게 하면 최신 순서대로 모든 게시물이 다 출력이 되겠죠. 예전처럼 ResultSet 을 직접 받아와서 처리하면 DBMS 에서 커서를 가지고 대기하다가 데이터를 요청할 때 전송하지만, 요즘 많이 쓰는 MyBatis 등은 데이터를 즉시 받아와서 resultType 이나 resultMap 에 정의된 대로 데이터를 bean 에 저장을 해버립니다. 그래서 모두 받아오면 문제가 발생하겠죠.
그래서 원하는 범위의 게시물을 가져와야 합니다.

총 게시물 수는 25 개, 한 페이지에 보여줄 게시물 수는 10 개, 현재 페이지는 3 페이지라고 가정하겠습니다. 그럼 가져와야할 게시물의 범위는? 딱 봐도 21 ~ 25입니다. 하지만, 아주 다행스럽게도 SQL 의 범위 검색은 범위가 벗어나도 있는데까지만 가져오기 때문에 21 ~ 30 사이의 게시물을 가져오라고 시켜도 알아서 21 ~ 25 까지의 게시물만 가져옵니다. 그래서 프로그램에서는 다음과 같이 시작 게시물 번호와 끝 게시물 번호를 계산해서 쿼리를 만들면 됩니다. 특별히 계산식의 해설은 하지 않겠습니다.

int totalCount = 25;
int countPage = 10;

int page = 3;

int startCount = (page - 1) * countPage + 1; // 21 이 되겠죠
int endCount = page * countPage; // 30 이 될 겁니다.

이렇게 만들어진 startCount 와 endCount 을 이용해서 DBMS 에서 원하는 게시물을 조회하는쿼리를 만들어보겠습니다. 위에서 언급했듯이 오라클의 쿼리입니다. 오라클은 ROW NUMBER 을 rownum 이라는 것으로 제공해줍니다. 사용의 편의를 위해 별칭(alias, as 을 이용해서 붙임)을 사용합니다.

먼저 페이지 번호를 붙여보겠습니다.

select rownum as rnum, id, name, content, createdate
from board
order by createdate

이렇게 해주면...순서대로 출력이 안되는걸 보실 수 있습니다. rownum 은 order by 가 이루어지기 전에 이루어진다는 걸 아실 수 있습니다. 그래서 아래와 같이 번호를 부여해야 합니다. 서브쿼리를 쓰는 거죠.

select rownum as rnum, A.id, A.name, A.content, A.createdate
from (
    select id, name, content, createdate
    from board
    order by createdate) A

이렇게 출력하면 순서대로 출력됩니다. 그럼 우리가 원하는 21 ~ 30 까지의 게시물을 가져오는 쿼리로 확장해보겠습니다.

select rownum as rnum, A.id, A.name, A.content, A.createdate
from (
    select id, name, content, createdate
    from board
    order by createdate) A
where rownum between 21 and 30
-- where rownum >= 21 and rownum <= 30

숫자 범위를 이용해 값을 가져오는 가장 대표적인 방법은 between 정도가 되겠네요. 아주 쉽게 21 ~ 30(실제로는 21 ~ 25) 의 게시물을 가져왔습니다.

끝일까요?

아쉽게도 아닙니다. DBMS 의 내부 동작 원리 상 위와 같이 페이지 내의 게시물을 가져오면 위에서 언급한 "모든 페이지 내 게시물을 가져올 때 2 초가 걸리는" 페이지가 될 수 있습니다. 아니,어쩌면 모든 페이지를 5 초 걸려서 가져올 겁니다.

왜냐하면, 저렇게 범위 검색을 하게 되면 모든 테이블 내용을 정렬한 뒤 1 부터 번호를 쭉 달아서 끝번호까지 번호를 부여한 뒤 21 ~ 30 까지의 데이터를 가져오기 때문입니다. 예제에서는 게시물이 많이 없기 때문에 충분히 빠르지만, 실제 수백, 수천 건의 데이터가 들어있으면 속도 저하가 눈에 보입니다.

그럼 어떻게 해야 할까요?

해결책 중 하나는 다음과 같은 방법입니다.

select X.rnum, X.id, X.name, X.content, X.createdate
from (
    select rownum as rnum, A.id, A.name, A.content, A.createdate
    from (
        select id, name, content, createdate
      from board
order by createdate) A
    where rownum <= 30) X
where X.rnum >= 21

좀 달라졌죠? 번거롭게 한 번 더 둘러싼 뒤 게시물을 가져옵니다. 무슨 차이가 있을까요? DBMS 는 ROW NUMBER 을 부여하다가 위와 같이 첫번째 조건을 만족하게 되면 최적화를 통해 그 아래 데이터에 대한 정보 수집을 중지합니다. 그래서 30 개까지만 임시 테이블에 저장해둔 뒤 번호를 부여하고 나머지 값들은 버립니다. 그 뒤에 30개 안에서 앞의 20 개를 버리고 21 개째부터 나머지(=30)을 가져오기 때문에 속도가 빠릅니다.

즉, 총 게시물 수가 천만개라면, 정렬 후 천만개 모두를 번호를 매기면서 21 보다 같거나 크고 30 보다 작거나 같은 것을 찾는 것과 정렬 후 천만개 중 30 개까지 번호를 매긴 뒤 그걸 따로 떼서 21 보다 같거나 큰 것만 따로 떼서 사용자에게 제공하는 것의 차이가 발생하기 때문에 속도 차이가 눈에 띄게 나타납니다.

그래서, 만약 현재 자신이 사용중인 페이지 쿼리가 between 을 쓰고 있거나 한 번의 서브쿼리을 이용한 범위 검색을 쓰고 있다면, 두 번의 서브쿼리 형태로 바꾸시길 바랍니다.

추가로, 저번 글에서 말씀드렸던 부분인데...하나의 쿼리에서 총 게시물 수를 ROW_NUMBER() 등을 통해서 위의 페이지 쿼리와 동시에 쓰는 분들이 있습니다. 위와 비슷한 이유로 속도가 느려집니다.

습관적으로 위와 같이 페이징을 할 때에는 전체 게시물 수를 얻는 쿼리 따로, 그리고 페이지 게시물을 가져오는 쿼리를 따로 쓰고, ROW NUMBER 을 이용할 때에는 between 형태를 이용하지 않도록 주의하시면 페이징을 90% 마스터 하시는 겁니다.

물론, content 나 name 은 like 검색을 통해 전후방 일치 검색을 하게 되는데 게시물이 매우 많아지면 어쩔 수 없이 느립니다. 이 때에는 검색엔진의 힘을 빌리는게 가장 좋은데, 검색엔진은 보통 결과로 위에서 설정한 id 와 같은 pk 나 uq 값을 페이징 처리까지 해서 결과로 제공합니다. 그러므로 더 쉬운 게시판 페이징을 할 수 있습니다.

마지막으로, 위와 같은 쿼리를 할 때 또 한가지 주의점을 알려드립니다. 위에서 createdate 는 일부러 날짜형으로 지정을 했습니다. 그런데, 프로그램에서는 이를 변환해서 String 형태로 받는 경우가 더 많습니다. 그래서 DBMS 에 쿼리로 질의를 할 때 변환 함수를 써서 변환을 하는데 이걸 언제하는지 고민하지 않고 개발하는 분들이 계십니다. 아래와 같이 처리하는 거죠.

select X.rnum, X.id, X.name, X.content, X.createdate
from (
    select rownum as rnum, A.id, A.name, A.content, A.createdate
    from (
        select id, name, content, to_char(createdate, 'yyyy-MM-dd') as createdate
      from board
order by createdate) A
    where rownum <= 30) X
where X.rnum >= 21

하지만, 이렇게 할 경우 모든 게시물에 대한 날짜 정보를 변환을 한 뒤에 번호를 붙여주게 됩니다. 그래서 이런 변환 함수는 해줄 수 있는 가장 마지막 단계에서 해주는게 좋습니다.

select X.rnum, X.id, X.name, X.content, to_char(X.createdate, 'yyyy-MM-dd') as createdate
from (
    select rownum as rnum, A.id, A.name, A.content, A.createdate
    from (
        select id, name, content, createdate
      from board
order by createdate) A
    where rownum <= 30) X
where X.rnum >= 21

다음에 시간이 좀 남으면 3 편도 연재해볼까 생각합니다. 요즘은 거의 쓸 일이 없는 SQL Server 의 예전 방식인 TOP 을 이용하는 방식이나 MySQL 의 LIMIT 정도가 되겠네요.

초보 분들에게 많은 도움이 되었으면 좋겠네요.

이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;

위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로, 오류가 있다면 저에게 알려주시면 고맙겠습니다.

페이징(Paging)에 대한 이해 - (1) 페이지 번호를 생성하자.

2015-06-22T14:51:00.002+09:00

흔히 웹 개발을 처음 하는 개발자가 처음 겪게 되는 난관은 바로 게시판의 페이징(Paging)이 아닐까 합니다. 특히 DBMS 와 연동해서 개발하는 경우가 많은데, 각 DBMS 마다 페이징 방법도 많고 성능 등 신경써야 할 부분이 많이 때문에 어떤 자료를 보고 따라해야 문제가 없을지 판단하기 막막할 때가 있습니다.

그래서 페이징에 대한 원리를 파악해서 가장 기본적인 페이징 구현을 할 수 있는 방법을 알려드리고자 합니다.

이 글은 초보자를 위한 글이므로, 페이징 정도는 우습다는 분은 패스해주시길...^^;;;

------------------------------------------------------------------------------------------------------

먼저, 페이징에 대한 이해를 하기 위해서는 페이징을 하기 위해 각 DBMS 가 어떤 정보를 제공해줘야 하는지 알아야 합니다. DBMS 마다 페이징을 위한 방법이 다른데, 제공하는 정보가 다르기 때문입니다.

모든 DBMS 는 내가 원하는 정보의 총 갯수를 가져오는 기능을 제공합니다. 바로 select count(*) 을 이용하는 것입니다. 이것을 이용해서 게시판 아래 출력되는 페이지 번호를 생성할 수 있습니다.
그렇다면, 해당 페이지의 게시물만 가져오는 방법은 무엇일까요?
오라클은 전통적으로 ROWNUM 을 제공합니다. 출력되는 정보에 순차적인 번호를 부여함으로써 원하는 게시물만 가져오는 방식입니다.
MS SQL Server 는 예전에는 TOP 을 이용했습니다. 출력될 정보 중 상위 몇 개를 가져온 뒤, 그 중 원하는 시작점까지 프로그램 상에서 이동을 해서 그 뒤의 것들을 가져오는 방식입니다. 하지만, 최근에는 오라클과 마찬가지로 ROW_NUMBER() 을 제공함으로써 좀 더 편한 페이징이 가능해졌습니다.
MySQL 이나 PostgreSQL 은 전통적으로 LIMIT 를 이용한 페이징을 제공했습니다. 페이징 할 때 크게 고민할 것 없이 사용이 가능하므로 매우 개발자 친화적이긴 하지만, 두 DBMS 의 LIMIT 는 의미가 약간 다르므로 주의해서 사용해야 합니다.
참고로, 제가 주로 사용하는 NoSQL 제품인 Couchbase 에서는 limit 와 skip 을 통해서 페이징을 가능합니다. 사실 내부적인 동작 원리는 비슷하지만, 어떻게 페이징된 정보를 가져오냐의 차이인 것 같습니다.

이번에는 게시판 하단에 표시되는 페이지 번호에 대해서 알아보겠습니다.

예를 들어 25 개의 게시물이 등록된 게시판(board)이 있다고 하겠습니다. 그럼 다음과 같은 Query 을 통해 총 게시물의 수(totalCount)를 가져올 수 있을 겁니다.

select count(*) as totalCount from board

그럼 프로그램에선 몇 가지 정보를 이용해서 하단의 페이지 번호를 생성할 수 있습니다.

1. 한 페이지에 출력될 게시물 수 (countList)
2. 한 화면에 출력될 페이지 수 (countPage)
3. 현재 페이지 번호 (이하 page)

처음 해야할 것은 총 몇 페이지가 존재하는지 알아내는 것입니다(총 페이지, 이하 totalPage). 이 때 필요한 것은 countList 인데, 이해를 돕기 위해 countList = 10 혹은 countList = 5 라고 가정하고 계산해보겠습니다.

25 / countList
25 / 10 = 2 나머지 5
25 / 5 = 5 나머지 0

우리가 기대하는 수는? 바로 3 와 5 입니다. Java 와 같은 언어에서는 int 형으로 보통 계산을 하기 때문에 25 /10 을 해버리면 2 만 나오게 됩니다. 그렇다고 무조건 1 을 더하게 되면 아래의 countList = 5 와 같은 경우 때문에 정확한 총 페이지 수(totalPage)을 계산할 때 무조건 1 을 더해선 안됩니다(의외로 이렇게 계산해서 마지막 페이지에 게시물 안나오는 곳이 많더군요). 위에서 보듯이 가장 정확하면서 단순한 방법은 나머지가 있을 경우에만 1 을 더해줘야 합니다. Java 로 된 최종 코드는 아래와 같이 되겠죠.

int totalCount = 25; // 물론 실제론 여긴 DBMS 에서 조회해서 들어가야 합니다.
int countList = 10;

int totalPage = totalCount / countList;

if (totalCount % countList > 0) {

    totalPage++;

}

혹은 아래와 같이 처리할 수도 있겠죠.

int totalCount = 25;
int countList = 10;

int totalPage = totalCount / countList;

if (totalCount > countList * totalPage) {

    totalPage++;

}

이렇게 하면 총 페이지 수를 알 수 있습니다. 이 값을 통해서 한 화면에 출력될 페이지 수가 10 개라고 해도, 3 페이지까지만 존재할 경우 1 에서 3 페이지까지만 하단에 출력해줄 수 있습니다(이런 처리 안해서 없는 페이지를 출력하는 곳도 많더군요).
또한, 잘못된 현재 페이지에 대한 보정도 가능합니다.
현재 페이지 번호가 총 페이지 번호보다 크다면 어떻게 해야 할까요? 현재 페이지를 강제로 총 페이지 번호로 치환하는 것도 방법이 될 것입니다.

int page = 2;

int totalCount = 25;
int countList = 10;

int totalPage = totalCount / countList;

if (totalCount % countList > 0) {

    totalPage++;

}

if (totalPage < page) {

    page = totalPage;

}

이번에는, 하단에 표시될 페이지 번호들을 어떻게 알아낼 수 있는지 알아보겠습니다. 이번 예제에는 totalCount = 255, countList = 10, countPage = 10 으로 하겠습니다. 그리고 현재 페이지인 page 는 5 와 22 의 두 가지 경우를 생각해보겠습니다. 또한, 페이지 표시 방식은 대한민국에서 가장 많이 쓰는 방식인 10 개의 페이지를 보이는 방식으로 하겠습니다. 이 방식은 현재 페이지 기준으로 앞 뒤 몇 개의 페이지를 보여주는 외국의 방식보다 대한민국에서 더 많이 쓰는 방식입니다.

먼저 page = 5 일 경우입니다. 이 경우 우리가 예상하는 결과는 하단에 1 ~ 10 까지의 페이지 번호가 표시되는 것입니다(countPage = 10 이니까요).

이런 페이지 번호 계산을 하는 방법은 몇 가지가 있습니다만, 가장 간단하고 쉬운 방법은 바로 시작 페이지 번호를 계산해내는 것입니다. page = 5 일 경우 시작 페이지(startPage)는 1, 마지막 페이지(endPage)는 시작 페이지에서 10 페이지(countPage 가 10 이니까요)까지라는 건 금방 이해하시리라 생각합니다. 그럼 page = 5 에서 어떻게 1 페이지를 찾아낼 수 있을까요? 아주 쉽습니다. 그냥 countPage 로 나눠버리면 됩니다(그리고 1 을 더해줘야 해요!). 그럼 마지막 페이지는요? countPage 을 더하면 됩니다. 단, 더한 뒤 1 을 빼주는 작업은 잊으시면 안됩니다. 왜 그런지는 생각해보시면 금방 깨닫게 되실꺼구요.

int page = 5;
int countPage = 10;

int startPage = page / 10 + 1; // 왜 1 을 더할까요?
int endPage = startPage + countPage - 1; // 왜 1 을 뺄까요?

실제 보이는 페이지는 1 ~ 10 까지이지만, 실제 페이지 번호는 0 ~9 까지로 처리하는 경우도 있습니다. 그게 Java 와 같은 언어에선 처리가 더 간단하기 때문인데요...저 역시 시작 페이지는 0 으로 해서 처리한 클래스를 만들어서 씁니다만, 이해를 돕기 위해 여기서는 1 페이지는 1 의 page 번호를 가지도록 하겠습니다.

어쨌든, 저렇게 계산을 하면 startPage = 1, endPage = 10 이라는 결과가 나옵니다.

그럼 화면에 출력할 때에는요?

int page = 5;
int countPage = 10;

int startPage = page / 10 + 1;
int endPage = startPage + countPage - 1;

for (int iCount = startPage; iCount <= endPage; iCount++) {

System.out.print(" " + iCount + " ");

}

이런 식으로 출력하면 페이지 번호가 연달아서 출력이 되겠죠.

그렇다면 page 가 22 인 경우에는요?

먼저 단순히 산수 계산을 해보면 255 개의 게시물이 있을 경우 총 26 페이지가 존재할 것이고, 22 페이지가 있는 곳에는 21 에서 30 페이지 영역일 것입니다. 하지만, 26 페이지까지이기 때문에 단순히 21 페이지에서 countPage 을 더하면 안된다는 것을 대번에 눈치 채셨을 겁니다. 그래서 이 경우에도 마지막 페이지는 총 페이지 수로 대체를 해줘야 합니다.

int page = 22;
int countList = 10;
int countPage = 10;

int totalCount = 255;

int totalPage = totalCount / countList;

if (totalCount % countList > 0) {

    totalPage++;

}

if (totalPage < page) {

    page = totalPage;

}

int startPage = page / 10 + 1;
int endPage = startPage + countPage - 1;

// 여기서 마지막 페이지를 보정해줍니다.
if (endPage > totalPage) {

endPage = totalPage;

}

// [paging]
// 이 부분은 아래에서 추가로 설명합니다.
for (int iCount = startPage; iCount <= endPage; iCount++) {

System.out.print(" " + iCount + " ");

}

대충 끝이 보이네요. 위에서 [paging] 이라고 표시된 부분에서 페이지 번호를 출력하는데, 출력을 할 때 css 코드를 넣거나 <a> 태그를 이용해서 연결을 하면 페이지 이동이 가능합니다. 이 때 현재 페이지는 굵은 글씨체로 표시하고 <a> 태그를 빼기 위해 아래와 같이 처리도 가능하겠죠.

// [paging]
// 이렇게 개선됩니다.
for (int iCount = startPage; iCount <= endPage; iCount++) {

if (iCount == page) {

System.out.print(" <b>" + iCount + "</b>");

} else {

      System.out.print(" " + iCount + " ");

}

}

보통 첫페이지 이동이나 이전 페이지, 다음페이지, 끝페이지 이동 버튼도 추가로 달아줍니다. 그래야 해당 페이지 리스트에 없는 곳으로도 이동이 될테니까요.
첫 페이지는 현재 페이지가 1 페이지가 아닐 때 표시되게 하는 경우도 있고, 시작 페이지가 1페이지가 아닐 때 표시하는 경우도 있습니다. 취향 문제죠. 어쨌든 이동하는 페이지는 항상 page = 1 이 되겠죠. 이전 페이지도 마찬가지입니다. 1 페이지가 아닐 경우 현재 페이지보다 1 페이지 앞으로 이동하도록 page - 1 값을 가지고 이동하게 하면 되죠. 다음페이지는 totalPage 와 비교해서 마찬가지로 표시해주면 됩니다.

int page = 22;
int countList = 10;
int countPage = 10;

int totalCount = 255;

int totalPage = totalCount / countList;

if (totalCount % countList > 0) {

    totalPage++;

}

if (totalPage < page) {

    page = totalPage;

}

int startPage = page / 10 + 1;
int endPage = startPage + countPage - 1;

if (endPage > totalPage) {

endPage = totalPage;

}

if (startPage > 1) {

System.out.print("<a href=\"?page=1\">처음</a>");

}

if (page > 1) {

System.out.println("<a href=\"?page=" + (page - 1) + "\">이전</a>");

}

for (int iCount = startPage; iCount <= endPage; iCount++) {

if (iCount == page) {

System.out.print(" <b>" + iCount + "</b>");

} else {

      System.out.print(" " + iCount + " ");

}

}

if (page < totalPage) {

System.out.println("<a href=\"?page=" + (page + 1) + "\">다음</a>");

}

if (endPage < totalPage) {

System.out.print("<a href=\"?page=" + totalPage + "\">끝</a>");

}

이렇게 처리하면 페이징 표시를 할 수 있게 됩니다. 참 쉽죠~~~잉? (고 밥 로스 아저씨 따라하기)

다음에는 실제 각 DBMS 에서 페이지에 해당하는 글을 읽어오는 방법에 대해서 알아보겠습니다.
그리고, 이 글을 읽으시는 분 중에, DBMS 에서 조회할 때 총 페이지 번호와 게시물을 같이 읽어오면 되지, 왜 두 번에 나눠서 요청을 하느냐...그건 비효율적이다...라고 생각하시는 분은 곧 작성해서 올릴 다음 글을 꼭 읽어주세요. 왜냐하면 잘못된 습관이기 때문입니다.

이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;

위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로, 오류가 있다면 저에게 알려주시면 고맙겠습니다.

Vert.x 3 에서 달라지는 점

2015-04-16T11:42:00.001+09:00

거창하게 제목을 달았지만, 그리 거창한 것은 아닙니다.
제가 2.x 을 쓰다가 3.x 로 교체를 하고 있는데, 작업 중 느껴지는 바뀐 점들을 정리하는 것입니다.

1. deployWorkerVerticle() 이 사라지고 deployVerticle() 로 통합되었습니다. DeploymentOptions 을 이용해 옵션을 설정해서 deploy 시 옵션 내용을 적용하는 방식입니다.

2. Vertice 대신에 AbstractVerticle 등을 상속받아 사용해야 하며, BusModBase 가 사라졌습니다. BusModBase 의 sendOK() 나 sendError() 등으로 reply() 을 처리했다면 이를 모두 수정해야 합니다.

3. EventBus.registerHandler() 가 EventBus.consumer() 로 변경되었습니다. 사용법은 대동소이합니다.

4. Logger 가 사라졌습니다. 예제에서도 System.out.println() 을 이용하는 걸 봐선, 없어진게 맞을 것 같습니다.

5. Event Loop 에서 처리 시간이 지연될 경우 지속적인 경로 로그 출력이 되고 블록 상태가 풀리는 데도 시간이 좀 걸리는 것 같습니다. 사정상 MyBatis 으로 아주 금방 처리되는 Stored Procedure 을 호출하는 걸 만들어봤는데 정말 짜증나는 상황이 연출되었습니다. 오래 걸릴 코드가 있을 경우 vertx.executeBlocking() 을 이용해 비동기 형태로 처리하게 만들어서 이를 해결할 수도 있고, 그게 아니라면 Worker 로 Verticle 을 Deploy 해서 사용해야 합니다.

6. MySQL 등의 DB 연결 및 질의를 위한 라이브러리가 기본으로 포함되었습니다. 하지만, 기능이 아직은 미약하고, 모두 비동기 방식으로 사용하기 때문에 질의를 순차적으로 여러번 보내야 할 경우 정말 짜증나는 경우가 생길 수 있습니다. 게다가 아직 Stored Procedure 을 제대로 실행하질 못하고, 결과 역시 당연히 못받아옵니다.

7. HttpServer 을 쉽게 사용할 수 있게 해주는 RouteMatcher 가 Router/Route 등으로 변경되었습니다.

8. Vertx.sharedData() 에서 이용할 수 있었던 공유 개체가 ConcurrentMap 등에서 LocalMap 와 ClusterWideMap(AsyncMap) 와 같이 나뉘어졌으며 ClusterWideMap 은 비동기 형태로 가져오며 Lock, Counter 을 이용할 수 있도록 되어 있습니다. 더 이상 Cluster 모드를 위한 외부 라이브러리 이용이 필요 없습니다.

9. ~~EventBus 역시 Cluster 에서 동일하게 사용할 수 있는 기능이 포함되었습니다.~~ EventBus 가 Cluster 에서 모두 등록이 완료될 때 이벤트를 발생해주도록 개선되었습니다.

10. DNS Client 가 추가되었습니다.

11. 내부에서 많이 사용하게 되는 JsonObject 등의 기능이 늘어났습니다. 특히 JsonArray 에서 포지션을 이용한 조회만 제공했던 2.x 버전과 달리 삭제까지 제공하게 되었습니다. stream() 역시 생겼는데, 아쉽게도 내부 개체들은 JsonObject/JsonArray 에서 HashMap/ArrayList 로 바뀌서 저장됩니다.

지금까지 작업하면서 제가 느낀 차이점들입니다. 더 많은 것들이 있지만 일단 큰 것들은 이정도네요. 잘못된 내용이나 지적사항은 언제라도 연락주십시오.

그리고 이 글은 zepinos(zepinos at nate dot com)에게 저작권이 있고 다른 곳으로 퍼갈 수 없습니다.

Vert.x with Cluster 이해하기

2015-02-23T14:49:00.001+09:00

Vert.x 에 대해서 이야기 해보고자 합니다. 주로 Vert.x 에서 제공해주는 cluster 모드에 대해서 이야기를 해볼까 합니다. (약간의 Vert.x 에 대한 지식이 있어야 이해가 될 겁니다)

Vert.x 는 Server 모드와 Embeded 모드가 있습니다. Server 모드는 Java 등으로 코드를 작성한 뒤 이를 vertx 실행자를 이용해 실행하는 방식입니다. 소스 코드를 그대로 넣어둬야 하기 때문에 직접 서버를 운영하지 않을 때에는 소스의 외부 유출이 문제가 될 수 있습니다. 반대로 Embeded 모드는 기존 코드에 상속을 받아서 구현하며 기존 코드 속에서 돌아가기 때문에 Vert.x 라이브러리만 포함하면 기존 코드 속에서 돌아갑니다.

하지만, 주로 언급할 cluster 는 Server 모드에서만 동작합니다. vertx 실행 시 -cluster 옵션을 주면 작동합니다.

cluster 는 기존에 많이 알려진 clustering 와 별다른 내용을 포함하진 않습니다. Fail-Over, Load Balancing 의 목적으로 구동되며, 이는 내장된 Hazelcast 을 기반으로 동작하기 때문에 cluster.xml (Hazelcast 의 설정파일과 일치) 을 설정하면 자동으로 연동하게 됩니다.

Vert.x 는 기본적으로 비동기 방식을 이용하고 있고, 다른 클래스의 매서드를 실행하는 것도 직접적인 호출 보다는 비동기 방식으로 호출(EventBus)하는 방식을 이용하기 때문에 Java 파일(혹은 Groovy 파일)을 Verticle 이라는 형태로 호출하게 됩니다. 그런데, 현재 정식 버전인 2.1.x 버전에서는 cluster 에서 이러한 Verticle 을 여러 서버의 것을 사용할 수 있도록 분산처리 해주는 형태이지, 공유 데이터(원래 Hazelcast 의 IMDG 로서의 역활)까지 동기화해서 처리해주지 못합니다.

게다가, NetServer 와 같이 클라이언트와의 통신이 1:1 관계가 아닌 상황에서는 더 상황이 복잡해집니다.

A/B/C 세 개의 서버가 cluster 모드로 설정이 되어 있을 경우, 클라이언트는 A 서버에 접속을 하게 됐을 때 A 에서 이를 처리하고 다시 클라이언트에게 메세지를 되돌려 줄 경우에는 문제가 없으나, 이를 EventBus 을 통해 처리를 할 경우 B 혹은 C 서버에서 이를 처리할 수 있습니다. 이 경우 A 서버에 보낸 메세지 처리 순서도 뒤죽박죽이 될 수 있고(먼저 보낸 메세지가 B 서버에서 처리되는 동안 다음 메세지가 A 서버에서 처리되어 먼저 return 될 수 있습니다) B 나 C 서버에서 처리하는 도중 클라이언트에게 직접 메세지를 보내려고 할 경우 메세지를 보낼 수 없는 문제까지 발생하게 됩니다. 클라이언트가 A 서버에 접속하게 되면 Handler ID 라는 고유값이 생성되는데, 이 고유값을 통해 클라이언트에게 메세지를 보낼 수 있습니다. 하지만 이것은 A 서버만 알 수 있는 값이고, B 서버나 C 서버는 이 값을 공유하지도 않고 클라이언트와 연결도 되어 있지 않기 때문에 메세지는 어둠 속(?)에 사라집니다.

저는 이 문제를 해결하기 위해 메세지를 발송하는 EventBus 을 각 서버별로 고유하게 만들고 클라이언트에게 메세지를 보낼 때 클라이언트가 접속한 서버의 해당 EventBus 로 메세지 내용을 보내 전송하도록 구조를 만들어 처리를 하였습니다. 이 부분은 Vert.x 개발자들도 인지하고 있지만, 왜 이런 구조가 필요한지...중요하게 생각 안하는 것 같더군요.

예를 들어보겠습니다. 1:1 채팅방을 만들 경우 처음에 한 사람이 A 서버에 접속했을 경우 A 서버에서 aaa 라는 Handler ID 을 생성한 뒤, 이 aaa 라는 Handler ID 을 Set 이나 Map(편의상 여기서는 Set 을 쓴다고 하겠습니다) 등에 저장을 합니다. 그리고 다른 한 사람이 C 서버에 접속했을 때 C 서버에서 ccc 라는 Handler ID 을 생성한 뒤 Set 을 뒤져 aaa 와 ccc 을 매칭시켜주는 시스템이라고 가정합시다.
그럼 aaa 가 접속을 했을 경우 먼저 Set 을 뒤집니다. Set 에 대기자가 없다면 aaa 에게 접속을 했으나 대기를 해야한다고 알려줘야 합니다. 그리고 기다립니다.
그리고 ccc 가 접속했을 경우 마찬가지로 Set 을 뒤집니다. Set 에 대기자 aaa 가 있으므로 자신에게 접속을 했고 aaa 와 채팅을 할 수 있다고 알려줘야 합니다. 뿐만 아니라 aaa 에게도 ccc 와 채팅을 할 수 있다고 알려줘야 합니다.
aaa 나 ccc 가 접속이 끊어졌을 때도 마찬가지 입니다. aaa 가 정상적으로 접속을 끊더라도, 혹은 비정상적으로 접속이 끊어졌더라도 ccc 에게 메세지를 보내줘야 합니다.
그런데, 위에서 나열한 행위들을 처리하는 것이 A 서버일 수도, C 서버일수도...아니면 엉뚱하게도 B 서버일 수도 있습니다. 왜냐하면 Clustering 의 부하 분산 때문입니다. aaa 의 접속이 끊어졌다는 것은 A 서버에서 이벤트로 받긴 하지만, 일반적으로 이런 메세지를 보내기 위해선 처리해야할 내용이 있을 수 있고, 그런 것을 EventBus 로 보내서 처리한 뒤 거기서 메세지를 보내게 됩니다. 이 때 EventBus 을 통해 A~C 서버 중 한 곳에 무작위로 배치되어 처리하기 때문에 문제가 발생할 수 있습니다. 또한, 하나의 요청에 대해 자신에게 메세지를 되돌려주는건 1회입니다. 자신에게 여러번 메세지를 보내야 할 수도 있고 상대에게도 메세지를 보내줘야 할 경우도 있는데 이런 경우 해당 클라이언트가 접속한 서버를 통해서만 보내야 합니다. 그래서 위에서 언급했듯이 클라이언트에게 메세지를 보내기 위한 특별한 EventBus 을 만들어 둘 필요가 있습니다(제가 고안했습니다. 매우 허접한 형태이니 양해를 바랍니다).

그런데 여기서 문제가 끝나지 않습니다. 3.0.x 버전(아직 M2 까지만 나왔습니다)에서는 기능이 보강이 되었으나 아직 정식 버전인 2.1.x 에서는 해결되지 않은 문제가 있습니다. EventBus 는 상호 사용이 가능하나, 공유 데이터를 다루는 내장 Hazelcast 을 이용한 ConcurrentSet 이나 ConcurrentMap(vertx.sharedData() 을 이용합니다)은 같은 서버의 EventBus 끼리는 데이터를 공유해도 다른 서버에 있는 EventBus 끼리는 데이터를 공유하지 못합니다. 3.0 에서는 이 부분을 해결해놓았으나 이 또한 비동기로만 구현을 해놓아서 원래의 Hazelcast 보다 사용이 불편합니다. 그래서 위의 1:1 채팅방에서 Set 에 aaa 을 넣어놓아도 사실 ccc 는 aaa 을 찾지 못하고 자신도 대기 상태가 되어버리는 문제가 생기게 됩니다.
저는 지금 2.1.5 을 이용중이기 때문에 이 문제를 간단하게 해결하기 위해서 처음 시작되는 Verticle 에 Hazelcast 설정파일(Vert.x 의 cluster.xml)을 다시 읽어 별도의 공유를 생성해서 사용하고 있습니다. 그래서 한 서버에 2 개의 Hazelcast 가 뜨게 되어 있습니다. 원래의 Hazelcast 는 위와 같은 제약이 없으므로 해당 Hazelcast 의 ISet 개체를 통해 쉽게 공유 데이터를 처리할 수 있습니다.

이처럼 Vert.x 의 cluster 는 쉽게 서버 코드를 확장할 수 있게 도와줄 것 같지만, 함정이 숨어 있습니다. 처리하는 매서드를 여러 서버에서 비동기로 처리하기 때문에 서버를 늘리면 늘릴수록 많은 접속(처리시간이 극단적으로 적고 접속량이 많은 경우 유리)을 처리하지만, 잘못 이해할 경우 원인도 모른채 동작이 이상하게 되는 현상을 맞이할 수 있게 됩니다.

이런 부분을 고려하고 Vert.x 을 이용해 프로그래밍을 하신다면 매우 가벼운, Java 로 혹은 Groovy 로 개발할 수 있는 Node,js 을 대체할 수 있는 프로그래밍을 하실 수 있을 겁니다.

그리고 이 글은 zepinos(zepinos at nate dot com)에게 저작권이 있고 다른 곳으로 퍼갈 수 없습니다.

SELinux 에서 권한 재설정

2015-02-09T16:56:00.001+09:00

그냥 cp 을 할 경우 SELinux 의 권한 정보가 같이 복사되지 않습니다.

그럴 경우...

restorecon -rv (경로)