RabbitMQ 쓰는이유

여러분은 백엔드라고 하면 flask나 django, jsp 등등을 생각하는 경향이 있다.

뭐 틀린말은 아니지만 이는 backend중에서는 앞단이다.

내부적으로 데이터를 처리하고 가공하는 backend중에서도 뒷단이 존재한다.

즉 backend에서도 front, back이 나뉘게 된다.

 

back의 front와 back의 back, 보통 앞은 RESTful, SOAP, GraphQL등의 API서버라고 불리게 되고 뒷단은 Analysis서버라고 불리게된다.

이 둘을 한 서버에서 돌리는건 위험하다(실무에서는 한 컴퓨터에서 한 서버를 돌리니까 정확히 말하면 한 컴퓨터에서 돌리는게 위험하다고 볼 수 있다.)

왜냐하면 사용자가 접속해서 트래픽을 발생시키는 API와 데이터를 계속해서 처리하고 있는 분석서버가 같이 돌아가면

사용자가 갑자기 트래픽이 폭주하는 상황에서 뜬금없이 분석서버가 사망,

반대로 갑자기 분석할 데이터양이 늘어나서 폭주해서 API서버가 뜬금없이 죽어서 분명 분석서버가 죽었는데 로그인까지 못하는 어처구니 없는 상황이 일어난다.

그래서 서버는 계속해서 분할하는게 가용성측면에서 이득을 본다. 그리고 이렇게 해야 확장성도 용이하게 된다.

이러한 구조를 MSA(마이크로 서비스 아키텍쳐)라고 부르게된다. 어찌됬던 서버들이 분할된다는 것이다.

 

문제는 이렇게 분할된 서버들을 어떻게 데이터를 주고받을 것이냐는 것이다.

사실 그냥 다이렉트로 주고받으면 안되냐?라고 생각할 수 있다.

하지만 그렇게 하지 않는 정말 실무적인 이유가 있다.

가령 API서버와 분석서버간의 통신을 예시로 들어보자. 분석서버가 데이터 분석을 끝내고 이를 API서버로 요청해서 데이터를 적재한다고 가정하자.

근데 분석서버의 데이터가 갑자기 폭주했다고 가정하자. 이 때 API서버가 폭주하는 데이터를 버텨내지 못하고... 죽어버렸다면?

서비스는 멈추게 된다. 

 

그래서 큐에 적재하고 큐에서 완충역활을 하는 녀석이 있어주면 좋다.

데이터가 폭주하는 최악에 상황에서 어짜피 죽는건 큐다. 그럼 API서버는 무사하므로 일반 웹은 계속 돌아간다.

그럼 분석은 추가적으로 안되겠지만 DB도 무사하고 인증서버도 무사하므로 그냥 평소처럼 웹을 사용할 수 있다.

 

그런데 심지어 그런 외부의 큐가 AMQP형식을 지키고 있네?? 오 땡큐!

그런데 메이저 언어들 지원해서 심지어 서버의 형식역시 달라도 되네 오 굿!

그래서 RabbitMQ가 실무에서 자주 쓰이는 것이다.

 

요약하자면

 

1.데이터들을 쌓아두는 창고, 수틀려도 이 MQ녀석만 죽어서 서비스는 돌아간다.

2.그런데 AMQP형식을 지키고 있다. 그래서 양쪽 서버에서 AMQP형식만 맞춰주면(어뎁터만 맞추면) 잘돌아간다.

3.그런데 메이저 언어를 다 지원해서 각 언어의 장점이 맞는 부분을 사용할 수 있다.