24/01/15 TIL __ 메세지 큐

 

 

대용량 트래픽을 다룰 때에 좋은 기술들에 대해 찾다가 메시지큐 에 대해 알아보게 되었다.

 

 

메시지 큐에 대해 알기 전에

먼저 메시지 지향 미들웨어와 큐에 대해 간략히 살펴보자.

 

🐾 메시지 지향 미들웨어 MOM

비동기 방식으로 프로세스간 데이터를 주고받기 위한 시스템을 말한다.

메시지를 전달하는 과정에서 보관이 가능하며, 데이터 변환 또한 가능하다.

 

🪴 Queue

메시지 큐에서의 큐는 메시지를 임시로 저장하는 공간을 말한다.

데이터를 순차적으로 처리해야 하는 상황에서 효율적으로 사용되는데 선입 선출의 원칙을 따르는 부분 때문일 듯 하다. 

사실 queue는 자료구조 중 하나라고 한다. 

 

 

🌵 메시지 큐

Quere 자료구조를 채택해서 메세지를 전달하는 시스템이며, 메시지 지향 미들웨어(MOM)을 구현한 시스템이다.

찾아보니 보통 메시지를 전달하는 부분은 Producer, 메시지를 받아 소비하는 부분은 Consumer라고 하던데

이 메시지 큐가 어쩌다 대용량 트레픽 관련 키워드로 보였는지 살펴봤다.

 

기본적인 통신 방법은 End To End라고 한다.

이것은 출발지와 목적지 간에 직접적인 동선으로 통신하는걸 말한다.

 

예를 들어보자.

사과 마을에서 a가  장미마을에 b를 만나기까지 가는 길은 아주 좁아서 1번에 1명만 통과할 수 있는 수준이라고 해보자.

다른길은 없다. 오직 좁은 그 길 뿐이다.

a는 b를 만나러 가야한다. 그럼 a가 b를 만나러 가는 동안 다른 사람들은 그 길을 이용할 수 없다. 아니 이동할 수 없다.

직렬적, 순차적으로 이루어 진다고 하는데 순차적으로 이루어 진다는 것은 그동안 다른 작업을 처리하지 못함을 의미한다.

 

이게 몇개 되지 않는 요청 처리라면 상관 없겠지만, 대용량 트래픽이라면 꽤 중요한 문제가 된다. 

갑자기 10만명의 유저가 몰렸는데 1개의 요청을 처리하는 동안 계속 기다려야 한다면 제일 마지막 유저는..

끔찍하다. 대부분의 유저들은 해당 서비스를 계속해서 새로고침 하거나 나갈것이다. 

이러나 저러나 정말 좋지 않은 결과이다. 

 

이런 부분을 보완할 수 있는게 메시지큐 를 이용해 통신하는 거다. 

producer는 메시지를 consumer에게 바로 보내는게 아니라, Queue라는 곳에 넣어서 관리한다. 

consumer가 가능할 때에 데이터를 처리하게 되며, 이런 부분으로 발생하는 많은 장점들이 있다. 

 

결합도가 낮아짐에 따라서 장애전파를 방지할 수 있고 ,

유지보수의 효율도 높아지고, 확장성도 높아진다.

 

이부분도 예를 들어보자. 유저가 돈을 보내는 상황인데, a서비스 에서는 잘 보내졌다. 

그런데 b서비스 에서 받을 수 없는 상태에 놓엿을 경우,

데이터의 처리가 매우 지연될 수 있고, 데이터를 메시지큐에 넣어 보관함으로 데이터 안정성, 일관성을 올릴 수 있다.

또한 정상적인 메시지 송수신이 실패해도, 재실행이 가능하다는 것도 큰 장점이다.

 

 

그럼 이걸 어떻게 구현을 해야할까? 

아직 이부분에 대한 회의가 좀더 필요하다. 

미리 사전조사를 했지만,

실제로 어떤 방식이 효율적이고, 어떤 기술을 사용할건지 좀더 정리해 봐야할 것 같다. 

실제 구현 부분은 구현 들어갈 때에 적도록 하겠다.