1. Message Broker
서버에서 한 번 응답을 보내면 http 요청응답의 관계가 끝나게 된다. 따라서 단발성 통신이 일어난다. 한쪽이 요청을 보냈으면 반대쪽에서 요청을 보내라고 할 수는 없다.
하나의 서버는 1초에 5번 요청을 받을 수 있다. 만약 1초의 10번의 요청이 들어온다면 부하가 걸리게 된다. 이 부하들을 분산해야하는데 1초에 5번씩 요청을 처리할 수 있는 서버를 2개 만들면 이를 해결할 수 있다.
따라서 처음 1초에 10번 처리를 요청받은 서버는 1초에 5번처리를 하는 서버에 요청을 위임하게 된다. (실질적으로 하는 게 없음) 이러한 사항들을 처리하려면 단순한 http 요청과 응답의 구조로는 힘들 수 있다. 따라서 중간에 Queue를 둔다.
MSA란?
마이크로 서비스 아키텍처(Micro Service Architecture)의 약자로 단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법
2. 메시지 기반의 비동기 통신
한 서버에서 메시지를 발생시키면 이를 큐에 적재하고 그 메시지에 관심이 있는 서버가 메시지를 받는다. 이 큐를 Message Broker라고 부른다.
위와 같은 경우에는 Job Queue를 구성한다. 메시지 큐를 중간에 둠으로써 job을 큐에 쌓아두고 처리할 수 있는 양을 늘린다.
한곳에서 일어난 데이터의 변동사항을 많은 서버에 걸쳐서 돌려주는 형태의 메시징페턴을 Publish Subscribe Message Pattern 이라고 부른다.
이러한 서비스를 구성하기 위해 사용되는 대표적인 Message Broker는 Rabbit MQ가 있다.
3. RabbitMQ 설치해보기
설치과정은 생략한다.. (구글링을 통해 각자 진행..!) 설치를 완료하고 localhost:15672 를 url에 입력하면
위와 같은 페이지가 나오고 처음 서버를 실행시킨 것이라면 username과 password에 guest를 입력한다. 아래는 그렇게 입력한 후의 화면이다. (관리자 화면)
메시지를 받는 서버 쪽에서는 항상 Queue를 선언한다. (지금은 메시지를 받는 서비스가 없기 때문에 큐가 하나도 없다.)
큐에 메시지가 적재되면 큐에 관심있는 서버가 있을 경우에 그 큐에서 메시지를 꺼내서 사용하게 된다. Add a new queue를 눌러서 큐를 하나 만들어보자.
이름을 작성하고 Add queue 버튼을 누르면 위와 같이 메시지를 적재하기 위한 하나의 큐가 생성된 것을 확인할 수 있다.
그런데 직접적으로 메시지를 주고 받는 용도로 이 큐를 사용하지 않는다. exchange를 붙여줘야한다.
Exchanges 카테고리에 들어가서 amp.direct를 누르고 아래와 같이 bindings 부분에 위에서 작성한 test-queue 이름을 입력한 후 bind 버튼을 누른다. 그러면 이 큐에 exchange가 붙게 된다.
우편함이 우체국 소속된다고 비유를 들 수 있다.
레빗엔큐의 클라이언트 프로그램들은 실제로 큐에 메시지를 직접 적재하는 것이 아니라 익스체인지에 메시지를 적재하게 되면 익스체인지가 어떤 큐에 메시지를 보낼지를 결정한다.
