Day 53. 🦉부엉

룰루룰루~

부엉이가 되어버렸다. 자연스럽게 새벽까지 작업을 계속 이어서 하고 있다. 내가 언제 자는지 언제 일어나는지 감각도 없고 그냥 계속 개발에 몰두하는 중이다. 작업을 하다보면 나도 모르는 사이 시간이 훌쩍 지나가버려서 하루에도 12번은 더 놀라는 것 같다.

 

오늘은 2차 스코프로 미뤄두었던 채팅 기능을 구현해보자고 했다. 웹 소켓을 사용해서 채팅 기능을 구현한 레퍼런스가 참 많아서 이것 저것 참고하며 동작 방식을 이해하고 우리 코드에 적용시켜보기로 했다. 이 녀석이 잘 구현되었는지 체크해보고 싶은데 어제 webRTC도 그렇고 이 소켓도 그렇고 프론트가 없으면 테스트를 할 수 있는 방법이 딱히 없어서 기능 구현이 잘 되었는지 의문을 버릴 수가 없다. 일단 컴파일 오류는 안나니까 되었다 생각하고 넘어가려고 하는데 걱정이 이만저만 아니긴 하다.ㅋㅋ

 

---

 

Redis는 인메모리 방식의 데이터 구조 저장소라고 알고 있어서 이녀석을 캐시 저장소라고만 알고 있었는데 redis를 활용하는 방법이 다양했다. redis는 인메모리 데이터 구조 저장소 + 데이터베이스 + 캐시 + 메세지 브로커로 사용할 수 있다. 그리고 인메모리 방식이기 때문에 속도가 훨씬 빠르다. 다만 저장이 영구적으로 되지 않고 복잡한 데이터를 저장하기엔 무리가 있다. 

 

아무튼 그래서 이 레디스를 가지고 채팅 기능을 구현해보고자 했다.웹 소켓이란 HTTP환경에서 양방향 송수신 채널을 제공하는 프로토콜이다. 양방향 송수신이 가능하니까 채팅 기능을 구현하는데 필수적이다. 그렇다고 웹소켓 만으로 채팅을 구현하느냐? Nope. 그렇게 되면 메세지 형식, 통신 과정, 세션.. 등등 일일히 관리해야만 하는 어려움이 있음. 그래서 메시징 처리에 최적화된 STOMP라는 녀석을 서브 프로토콜로 사용함. STOMP는 뭐냐면, 메시지 송수신을 효율적으로 하기 위해 등장한 프로토콜임. 메시지 송수신을 하기 위해 pub/sub 구조로 되어있고 우리는 메시징 처리를 할 때 STOMP의 규칙만 잘 지켜주면 편하게 메세지 기능을 구현할 수 있다.

 

STOMP가 메세징 처리를 전반적으로 진행하고 양방향 연결을 위해 웹 소켓이 동작을 하면 이제 메세지를 주고 받기만 하면됨. 그걸 레디스가 제공해주고 있음. 레디스에는 pub/sub 기능이 있다. 이 기능을 메세지 브로커로 사용하는 것이다. 말그대로 메세지 브로커임 ㅇㅇ (중개를 해준다는거겠지?) STOMP 프로토콜을 지원하는 RabbitMQ 같은 전용 메세지 브로커도 있다고 한다. 그렇지만 레디스를 사용하면 레디스에 세션을 관리할 수 있어서 사용한다고 한다. 

 

그래서 이 pub/sub이 뭔데? Subscribe 구독하면 Publish 발행했을 때 구독자에게 알림 notification이 감. 잘 보면 채팅 주고 받는거랑 같음. 푸시 알림에도 쓸 수 있다고 하니 나중에 SSE 기능에도 쓸 수 있는지 봐야겠음.

 

그렇게 해서 채팅을 만들고 이것들은 레디스의 캐시 메모리로 관리하여 일정 기간이 지나면 삭제되는 방향으로 진행할 것 같다. 내가 직접 만든 채팅 기능이라니.. 벌써 재밌다.

 

 

https://zangzangs.tistory.com/72

인메모리 데이터 저장소 Redis, 왜 사용할까? #Redis 파헤치기

https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-PUBSUB-%EA%B8%B0%EB%8A%A5-%EC%86%8C%EA%B0%9C-%EC%B1%84%ED%8C%85-%EA%B5%AC%EB%8F%85-%EC%95%8C%EB%A6%BC

🗃️ REDIS의 PUB/SUB 기능 (채팅 / 구독 알림)

https://velog.io/@ohjinseo/WebSocket-Spring-Boot-stomp-Redis-PubSub-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%B1%84%ED%8C%85-%EA%B5%AC%ED%98%84

[WebSocket] Spring Boot + STOMP + Redis Pub/Sub 이용한 채팅 서버 구현