채팅 기능을 구현하기 전 채팅은 어떤 식으로 실행되는지에 대해 공부해보려고 한다.
우선적으로 나는 채팅 기능을 구현 하는 데 있어서
sockJS
stomp
이 두가지를 사용하고자 한다.
크게 이유는 없고 처음 구현하는 것이다 보니, 많은 채팅 기능 후기들을 보며 React와 spring 개발에서는 해당 조합이 널리 쓰이는 것 같으며 관련 정보도 꽤 있는 것 같아 선택했다.
개념 파악
- socket
socket이란 네트워크상에서 실행되는 프로그램 간 통신의 종착점(Endpoint)을 말한다. 즉, 프로그램이 네트워크에서 데이터를 통신할 수 있도록 연결해주는 연결부라고 할 수 있다.
socket 통신이란 서버와 클라이언트로 이루어진 양방향 통신이다. 소켓 통신의 장점은 HTTP 통신과 같이 서버에 요청하면 응답하는 단방향 통신와는 다르게 양쪽에서 데이터를 전송할 수 있다는 점이다.
- sockJS
websocket과 비슷한 기능을 제공하는 브라우저 JS라이브러리인데, 그 범용성이 websocket보다 좋다고 한다. websocket이 지원되지 않는 최신 브라우저에서도 잘 작동하기 때문,
브라우저와 웹 서버 사이에서 짧은 지연시간과 크로스 브라우징을 지원하는데, websocket의 상위호환 느낌이 아닌가? 라고 생각이 든다.
- stomp
stomp는 단순 (또는 스트리밍) 텍스트 지향 메시징 프로토콜. spring에 종속되어 구독방식으로 사용한다. (node.JS를 이용할 경우 socket.io 를 많이 사용한다고 한다.)
이 친구를 사용하여 Message Broker 개념을 이용할 수 있는 듯 하다.
Message Broker란 Publisher(송신자)의 메세지를 Subscriber(구독자)에게 전달해주는 중간 역할을 하는 친구이다.
이 때 메세지가 쌓이는 공간을 Message Que, 그 메세지 그룹들을 Topic 이라고 한다.
예시를 들어보자
A라는 데이터를 실시간으로 수집, 관리하는 서버와
B라는 데이터를 가공하여 사용하는 서버가 있다.
보통 우리는 A가 DB에 데이터를 쌓아 주면, B가 이를 조회해서 읽고 쓸 것이다.
근데 이는 실시간 채팅과 같은 기능에 적용하기에 느리다. 그래서 이 때 Message Broker 친구를 사용한다.
A에서 메세지를 Message Que에 Publish(저장, 적재) 하고 B는 메세지를 Subcribe(사용, 구독)하여 바로 사용한다.
Message Broker를 사용하면 별도의 조회 과정 없이 Message Que를 감시하다가 저장되는 메세지가 생기면 바로바로 가져다 쓰게 된다.
이런 구조를 Publish/Subscribe(pub/sub) Pattern, 혹은 Producer/Consumer Pattern 이라고 한다.
이런 장점이 있는 Message Broker 또한 단점이 있기 마련이다.
여타 DB에 저장 조회 하는 과정에 있는 필터링 작업이 불가능하다.(Logstash 같은 다른 스킬 필요)
또, Message Que에 저장된 메세지는 장기간 보관이 불가능하다.
