메시지 큐의 목적 (Redis는 메시지 큐, 캐시 서버 기능 모두를 제공한다.)

 

 

 

선 요약

메시지 큐의 목적 : 클라이언트와 작업 서버 사이에 버퍼를 두어, 클라이언트의 요청과 요청에 대한 작업을 독립적으로 구성하기 위한 것이다.

 

이게 무슨 뜻일까?

요청 : 사용자의 요청. 작업 : 사용자의 요청을 처리하는 작업. 이렇게 정의하고 시작하자.

오케이. 그럼 요청과 작업을 독립적으로 구성하지 않으면 무슨 문제가 생길까?

 

예를 들어서, 카카오톡 서버의 아키텍쳐를 설계한다고 하자.

그리고 천만명이 1초에 한 번씩 메세지를 보낸다고 하자.

 

중간에 버퍼가 없다면, 요청이 곧바로 API 서버에 전달되기 때문에 결국 1초에 천만 request가 동시에 작업 서버에 전달된다.

이는 아무리 좋은 서버라고 해도 당연히 감당하기 쉽지 않다.

(참고. 스택 오버 플로우는 2013년 한 해 동안 방문한 천만 명의 사용자 전부를 단 한 대의 마스터 데이터 베이스로 처리했다고 한다.

돈만 내면 가능은 한가보네... ㅋ)

이때, 중간에 Message Queue를 두어서, Request가 들어온 순서대로 순차적으로 처리하면 작업 서버가 초당 처리해야하는 부하가 줄어들게 된다.

 

그리고 이래도 모자란다면? 중간에 Message Queue를 둠으로써 클라이언트와 작업 서버가 1:1 매칭이 되지 않으므로 (독립적으로 구성되었으므로), 필요하면 작업 서버를 병렬로 더 늘리면 된다.

 

 

https://manhyuk.github.io/redis-q/

좌충우돌 레디스 활용 기 - 메세지 큐

ㄴ 메시지 큐로서 레디스를 활용하는 글이다.

읽어볼 것. (가능하면 직접 수행해보면 더 좋을 것 같다!)

 

작업 서버에 Request를 바로 전달하지 않고, 메시지 큐를 거쳐서 전달하게 된다.

 

이것만 보면 메시지 큐를 쓰는 것이 아주 효율적인 방법처럼 보인다.

하지만 단점도 명확하다.

1. 메시지 큐가 가득차면 메시지를 다른 곳에 보존하든가 버린다.

2. 한 단계를 더 거치므로 속도가 떨어진다.

3. SPoF가 생긴다.

 

따라서 시스템에 따라서 적용을 할지 말지 잘 선택을 해야한다.

무조건 선택하는 것이 능사가 아니다.

 

https://niceman.tistory.com/200

기본적인 플로우는 다음과 같다.