자율 프로젝트 start

프로젝트에서 적어도 안 써본 기술 하나는 써보자 라는 다짐하에 2학기 3번째 프로젝트, 자율 프로젝트가 시작되었다. 이번에는 유행했던 점프킹과 같은 장애물을 피해 올라가는 게임을 구현하려고 하는데 이걸 멀티접속이 가능하게 하려고 한다. 당연히 웹소켓이 필요하고 지금 껏 룸을 나누지 않고 단순 웹소켓만 사용해본 나로써는 새로운 도전이라고 할 수 있다.

socket 과 websocket

일반적으로 socket 이라고 하면 tcp/ip socket을 의미한다. 그래서 이론적으로 가장 큰 차이점은 websocket은 http 레이어에서 작동하는 소켓으로 레이어가 다르다 라고 볼 수 있다. 

기본적으로 http는 요청 후 응답을 보내는 단방향 통신인데 이걸 socket 처럼 쓰고 싶어서 만들어진 기술이라고 한다. 나같은 웹개발자는 그냥 이걸 쓰는게 맞는거 같고, 다만 브라우저 별로 못 쓰는 상황이 나와서 socket.io나 socketJS 같은 기술을 사용해서 이를 보완한다.

STOMP 

simple text oriented messaging protocol의 약자이며, 텍스트 기반의 프로토콜이다. websocket은 연결된 socket에게 data처리를 직접 다하는 반면, stomp는 subscriber, sender, broker를 따로 두어 처리를 하게 된다.

subscriber(receive socket) : 채팅방에 입장하여 해당 채팅창을 구독, 즉 참여하고 있는 채팅창에 오는 메시지를 실시간으로 받아볼 수 있으려면 먼저 구독이 되어있어야 한다.

sender(send socket) : 참여하고 있는 채팅창에 글을 써서 해당하는 주소로 메시지를 전달한다.

broker : 연결된 socket들의 세션 관리를 해준다. 즉 subscriber를 구독한 채널에 연결시켜주고, sender가 그 채널에 메시지를 보내면 subscriber에게 전달해주는 중간 다리 역할을 한다.

ChatController 에서

@MessageMapping("") @SendTo("") @SendToUser("")

등의 어노테이션을 이용

클라이언트 마다 원하는 토픽(각 방에 해당)을 구독신청 해놓고, 특정 사용자가 토픽에 해당하는 메세지를 보내면 그 토픽을 구독하는 모든 클라이언트에게 보내는 구조 @MessageMapping 어노테이션에 발행하는 경로를, @SendTo와 @SendToUser 어노테이션에 구독 경로를 작성합니다. 예를 들어

@MessageMapping("/chat/{roomNo}") @SendTo("/topic/{roomNo}")

이와 같은 상황에서 /chat/{roomNo} 에 메세지를 보내면 /topic/{roomNo} 라는 토픽을 구독하는 유저들에게 모두 메세지를 뿌리는 것

다만 SendToUser의 경우 1:1 로 메세지를 전송


사용해보는 느낌으로는 spring(websocket)에서 설정을 복잡하게 해줘야 했던 걸 boot(STOMP)에서 간단하게 만들어 놓은 느낌입니다. 


gradle 

maven 이후의 차세대 빌드 방법, maven 이 2004년에 나오고 gradle은 2012년에 나왔다. 이후에 나온만큼 성능도 좋고, 10년이나 된만큼 안정적인 면도 갖췄으니 안 쓸 이유가 없다고 한다. 다만 속도가 최소 2배에서 100배까지 빠르다던데, 이클립스 때문인지 초기 프로젝트 생성이나 import 에서의 속도는 딱히 그런 느낌이 들지 않는다. maven을 처음 썼을 때 jar 파일을 일일히 가져오지 않고 그냥 2~3줄 써주면 의존성 관리 해주는거 보고 정말 신세계였는데 그와 같은 느낌은 나지 않는 다고 해야하나. 하지만 깊숙히 알아 보면 gradle이 지원하는 기능은 많은 듯 하다. 이번에는 찍먹 정도인걸로


redis

이번에 찍어먹어볼 기술 중 마지막, 항상 mongodb, redis 등의 기술에 대해 들으면 '그건 nosql이에요, 관계가 정의되지 않고, key-value 형태로 이루어져 있어요.' 라고 들었고, 나도 그리 생각하고 끝이었다. 하지만 이게 왜 쓰이는 지(읽는게 빨라서), 그렇다면 왜 빠른지(캐쉬메모리라서), 그럼 캐쉬메모리에 영속성을 부여하는 방법은 어떤 게 있는 지 정도는 이번에 적용을 위해 찾아보며 배웠다. 

영속성을 유지하기 위한 방법으로는 RDB 방법과 AOF 방법이 있다고 하는데 아직 이부분은 미적용으로 해당 부분 적용 후 포스트를 완성할 예정 


그리고 자바의 Redis Client은 두가지가 있는데 Jedis와 lettuce 전자는 JAVA + Redis 느낌으로 예전에 많이 쓰였다면 lettuce는 성능면에서 월등하기 때문에 요즘에 많이 쓰인다. 스프링부트 기준 1.xx 버전에서는 Jedis를 써야 하지만 2.0 이상버전 부터는 lettuce가 표준이 돼서 설정할 부분이 훨씬 적어 졌다.

그럼 Redis를 사용하는 방법은 또 두가지가 있다(벌써 세번째 두가지...). RedisRepository RedisTemplate 기본적으로 레포지토리를 이용하면 더욱 간편하게 쓸 수 있지만 트랜잭션 기능을 사용할 수 없다. 그래서 트랜잭션을 쓰려면 Template을 이용해야 한다.


상추참조가이드


댓글

이 블로그의 인기 게시물

git-receive-pack not permitted on 깃 허브 로그인 관련 문제