주제 : Message-queing-system

1. 배경 : RPC의 한계

RPC는 Transient, 클라와 서버가 동시에 돌고 있어야 하며, 대부분 sync라 성능이 떨어질 수 있다.
이에 대한 대안으로 Messaging system이 등장한다.

참고 : 버클리 Sockets

소켓

소켓은 App레이어와 Transport 레이어를 이어주는 브릿지 역할로, 커뮤니케이션 엔드포인트다.
즉 앱이 Transport layer를 사용하기 위한 수단이다.

TCP Socket Primitives(함수)

• Socket() : 소켓 객체를 OS가 만들어줌
• bind() : 컴퓨터 addr와 소켓을 연결해 port를 지정 (소켓과 특정 IP 주소 및 포트 번호를 연결)
  - 서버는 주소 + port
  -클라이언트는 bind안해도 OS가 알아서 port 해줌
• listen() : OS에 충분한 버퍼 할당을 요청해서, 서버가 기다림
• accept() : 실제 요청이 오면, "별도의 소켓"을 또 만들어서 여기서 통신함.
• connect() : 클라이언트가 서버에 연결 요청
• send(), receive()
  

Message-oriented-persisent Communication

Message queing system,
Message-Oriented-Middleware(MOM)이라고도 부른다.

위에서 말했던 RPC의 단점인 Transient가 아닌,
"Persistent aysnc communication" 수단을 제공하는 목적이다.

• 상대방이 offline이면 저장해뒀다가, 전달해줄게.
• ex. E-mail
• Async 성격이 강함
• 보내는 쪽, 받는 쪽 둘다 실행중일 필요없음
• Sender queue, Receiver queue에 보내놓고 딴짓하면 됨. 이 queue가 미들웨어인 셈.

함수

• Put(): 큐에 넣기, non-block일 경우 요청하고 딴짓하고, 꽉찼을 경우 빌때까지 block
• Get() : block - 비었으면 뭔가 찰때까지 기달, non-block : 없음? ㅅㄱ 끝
• Poll : non-block : 내가 읽을 메시지가 있니? 없음 말고
• Notify() : 매번 Get, Put 직접 하는게 아니라, 메시지가 들어오면 나한테 알려줘
  - Callback function : 앱의 함수를 미들웨어에 등록하고, 메시지가 들어오면 앱의 함수를 호출

General Architecture

• Sender App과 Sender Queue는 같은 머신이거나 LAN에 연결된 머신에 큐가 있어야 한다. 멀리 있으면 그건 그냥 보내고 말지 뭐하러 이걸쓰겠냐 인정?
• 메시지에 목적지를 담아서 큐에 보내줘야지.
  

Queue Manager

• 앱과 큐 중간에서 중재자 역할을 한다.
• Relay 라고도 불리는데, 라우터처럼, 큐 매니저끼리 서로서로 라우팅 역할을 해서 메시지를 토스 토스 한다.
• 왜 Relay가 필요? 규모가 커지면 App이 모든 큐의 주소를 알아야 하니, 관리의 문제가 생긴다.
• Relay 역할을 큐 매니저를 둬서 주소들을 관리하게 하자.

위 그림처럼, Router 역할을 하면서 동시에

Message broker

• 큐 매니저와 같은 역할일 수도 있는데,
• Heterogenuous한 서로 다른 앱에서 통신을 할 때, 얘가 압축, 포맷 변경 등을 해주는 것이다.
  

이는 EAI에서 많이 쓴다.
한 기업 내에 여러 앱이 있을 것인데, 브로커를 둬서 서로 메시지 전송이 가능해진다.
(아 그래서 내 전 회사도 이랬구나~)
회사 내 모든 앱들이 통신할 때 브로커를 거쳐서 전달한다.
Pub/Sub 모델이라고도 하며, 관심 메시지로 등록한 app에게만 전달한다.