2023-01-12

지난번 모듈화를 하는것에 성공하고나서 이번에는 내가 담당한 레디스와 이를 메세지 브로커로서 활용하기 위한 공부가 필요한 순간이 왔다...

 

현재 웹소켓을 담당하셨던 조원분께 도움을 받아서 웹소켓에 대한 이해도를 좀 끌어올리고

이후에는 이제 우리 프로젝트에서 웹소켓을 주고받는 과정에서 메인역할로 꼽으신 스톰프 핸들러와 이를 활용하기 위한 것에 대한 이해를 위해서 공부를 좀 진행하게 되었다.

 

아래의 참고한 블로그 링크 부터 시작...

 

스케일 업(Scale-Up)과 스케일 아웃(Scale-Out)이란?

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

[REDIS] 📚 PUB/SUB 기능 (채팅 / 구독 알림)

 

 

 

 

 

 

Redis 를 채팅에서 활용하기 위해서 알아본 Pub/Sub 개념정리

 

Publish / Subscribe 란 특정한 주체(topic) 에 대하여 해당 topic을 구독한 모두에게 메시지를 발행하는 통신 방법
채널을 구독한 수신자(클라이언트) 모두에게 메세지를 전송한다.
하나의 클라이언트가 메세지를 Publish 하면, 이 topic 에 연결되어 있는 다수의 클라가 메세지를 받을 수 있다.

 

Publish / Subscribe 구조에서 사용되는 Queue 를 보통 topic 이라고 한다.

 

따라서, 레디스의 pub/sub 은 주로 채팅 기능, 푸시 알림 등에 쓰인다.

 

다만, 레디스의 pub/sub 는 매우 단순한 구조로 되어있다.

구독 신청한 모든 sub 에 메세지를 전달하지만 따로 보관하지는 않는다.

즉, 수신자(클라) 가 메세지를 받는것을 보장하지 않기 때문에 sub 대상이 하나도 없으면 메시지 pub 역시 사라진다.

진짜 심플하게 보내는 쪽도 보내고 끝, 받는 쪽도 받고 끝이다.

 

 

- 레디스 서버를 매개로, 레디스 클라이언트간 통신을 도와준다.

- 레디스 클라이언트는 레디스 서버내 채널을 생성

- 메세지를 수신하고 싶은 클라는 사전에 해당 채널을 sub 해야 함

- 메세지를 보내는 클라이언트는 해당 채널에 메세지를 pub 가능

- 메세지를 보내는 클라이언트는 메세지를 pub 하면, sub 중인 클라이언트만 메세지를 수

 

 

 

 

 

 

STOMP (Simple Text Oriented Message Protocol)

웹소켓 만으로 채팅서버를 구현하면 메시지 포맷 형식, 통신 과정, 세션 등 일일이 처리헤야 하는 번거로움이 있다.
따라서 이를 최적화 시키기 위해서 STOMP 프로토콜을 서브 프로토콜로 사용한다.
이는, 메시지 송수신을 효율적으로 하기 위해서 나온 프로토콜 이며, 웹소켓 프로토콜 위에서 작동한다.

 

즉, 웹소켓의 상위 프로토콜이 되고 웹소켓은 stomp 의 하위 프로토콜로 생각하면 된다.

기본적으로 pub/sub 구조로 되어있고 메세지 송수신을 처리하는 부분이 확실히 정의되어 있기 때문에 개발자 입장에선 메세지 처리 할 때 stomp 스펙의 규칙만 잘 지키면 된다.

 

COMMAND
header1:value1
header2:value2

Body^@

 

위와 같은 형식으로 이루어져 있다. 위의 구조로 클라이언트 서버 간의 메세지 송수신이 이루어진다.

 

• 클라이언트는 메세지를 발송할 때 COMMAND 로 SEND 또는 SUBSCRIBE 등의 명령을 사용할 수 있다.
• header:value 형식으로 누가 받을지에 대한 정보와 메시지 정보 등이 포함된다.

 

 

 

 

 

 

 

 

 

 

Message Broker

pub/sub 는 메세지를 공급하는 객체(pub) 와 소비하는 객체(sub)를 분리해 제공하는 비동기식 메시징 방법이다.
pub 이 특정 topic 에 메세지를 보내면 해당 topic 을 구독해놓은 모든 sub 에게 메세지가 전송되는 방식이다.

 

 

다만 위의 그림을 보면 서로 직접 통신하는것이 아니라 Message Broker 를 통해서 메세지를 전달한다.

즉, Message Broker 는 pub 이 보낸 메세지를 sub 으로 전달해주는 중간 다리의 역할이다.

 

Message Broker 이 필요한 이유는 ...

 

• 느슨한 결합 : pub 는 메세지를 발신할 때 다른 서비스들에 대해 알 필요가 없다.(scale-out 에 용이 즉)
• 메세지 버퍼링 : sub 측에서 원하는 시점에 메세지를 처리할 수 있다.

스케일 업(Scale-Up)
기존 서버의 사양을 업그레이드 해서 시스템을 확장하는 것을 말한다.
CPU 나 RAM 등을 추가하거나 고성능의 부품, 서버로 교환하는 행위를 말한다.
스케일 아웃(Scale-Out)
서버를 여러대 추가하여 시스템을 확장하는 행위
서버가 여러대로 나뉘기 때문에 각 서버에 걸리는 부하를 균등하게 해주는 '로드 밸런싱' 이 필수다.

 

 

Message Broker 를 통해서 통신이 이루어지기 때문에 이 과정에서 부하가 발생하거나 브로커가 없는 시스템에 비해 속도가 느릴 수 있다는 단점 또한 존재한다.

또한, DB 를 통한 쿼리를 이용해서 쉽게 원하는 데이터에만 필터링 하여 조회할 수 있지만,

브로커를 이용하게 되면 Queue(Topic)에 적재된 그대로 사용하기 때문에 불가능하다. 따라서, 적재할 때 필터링된 데이터를 적재하던가 적재된 데이터를 Logstash 를 이용하여 필터링해서 사용해야 한다.

또한, 메세지 큐에 적재된 메세지는 주로 7일간 보관하기 때문에 장기간 보관해야하는 경우 별도의 저장소 저장해야한다.

 

또 다른 글에서 발췌 : Reids 의 자료구조 중 List 를 이용하여 Queue 구현이 가능하다.

 

대표적인 Message Broker  : Apache Kafka, Redis, RabbitMQ, Celery

 

 

 

Redis 자료 구조의 종류...

• Strings : Vinary-safe한 기본적인 key-value 구조
• Lists : String element의 모음, 순서는 삽입된 순서를 유지하며 기본적인 자료구조로 Linked List를 사용
• Sets : 유일한 값들의 모임인 자료구조, 순서는 유지되지 않음
• Sorted sets : Sets 자료구조에 score라는 값을 추가로 두어 해당 값을 기준으로 순서를 유지
• Hahses : 내부에 key-value 구조를 하나더 가지는 Reids 자료구조
• Bit arrays(bitMaps) : bit array를 다를 수 있는 자료구조
• HyperLogLogs : HyperLogLog는 집합의 원소의 개수를 추정하는 방법, Set 개선된 방법
• Streams : Redis 5.0 에서 Log나 IoT 신호와 같이 지속적으로 빠르게 발생하는 데이터를 처리하기 위해서 도입된 자료구조

 

 

Linked List 에 대한 설명

Linked list - Data Structure (자료구조)

 

뭔가... 오히려 공부를 하면 할수록 미궁에 빠지는 느낌인데...

저것들을 알아보는 것에만 나한테는 상당한 시간이었고 지금도 완전히 이해한 상태는 아닌듯 해서 좀 더 우리 프로젝트에 맞게 정리는 다음에 마저 해야겠다...