spring-amqp , rabbitmq 를 공부하고 있습니다.
rabbitmq 에 대한 국내 자료가 너무 없네요ㅜㅜ
대용량 처리를 분산 하기 위하여 spring-amqp 와 rabbitmq 를 알아보고 있는 중 입니다.
sns 서비스를 예로 들어서
조회시의 부담을 줄이기 위해 팔로워가 100만명인 사용자가 글을 작성했을 때, 인덱스 테이블에 100만행의 인서트를 하고자 합니다.
이런 경우에
web application 에서 포스트 작성 시 mq 서버로 메시지를 보내고 (was -> mq)
그걸 처리하는 별도의 컨슈머 서버가 존재하는게 맞는 구조 지요 ??
처음에는
web application에서 mq 서버로 메시지를 보내고
다시 web application 에서 그걸 리시브 해서 처리하는 구조를 생각했었습니다..
이런 식으로 처리하면 비동기 처리로서의 의미만 갖게 되는데 그렇다면 굳이 mq 를 쓸 필요없이
컨트롤러단에서는 DeferredResult 나 Callable 을 이용. 서비스단에서는 @Async 를 이용한 비동기 처리를 하면 되지 않나라는 의문을 갖게 됐습니다.
그래서 리시브 해서 작업을 처리하는 컨슈머 서버를 따로 두는게 대용량 분산 처리가 제대로 되는 것이라 생각했습니다.
amqp 의 탄생 배경에 대해서 찾아봤습니다.
- 이전에도 상용화된 MQ 제품들은 많았지만, 한가지 문제가 있다면 대부분 플랫폼 종속적인 제품들이었기 때문에 서로 다른 이기종간에 메시지를 교환하기 위해서는 메시지 포멧 컨버전을 위한 메시지 브릿지를 이용하거나 (속도 저하 발생) 시스템 자체를 통일시켜야 하는 불편함과 비효율성이 있었다. (시스템을 교체하는 것은 논외로 치고 메시지 브릿지의 경우 MQ가 금융쪽에서도 많이 사용된다는걸 감안하면 속도 및 응답성의 저하는 치명적인 약점일 수 밖에 없다) 이러한 기존의 MQ들의 약점을 보완하기 위해 등장한것이 AMQP이다. 즉, AMQP의 목적은 서로 다른 시스템간에 (비용/기술/시간적인 측면에서) 최대한 효율적인 방법으로 메시지를 교환하기 위한 MQ 프로토콜인 것이다.
위 탄생배경을 보고 제가 했던 의문이 점점 맞다는 생각이 점점 드는데요.. 그래도 확신이 없기에 이렇게 질문드립니다.
최종적으로 질문을 요약드리자면
제가 이해하기론 서로 다른 이기종간에 메시지를 주고 받을 때 최적화를 위해 탄생한게 바로 AMQP 라고 이해했는데 맞는지요?
맞다면, SEND 하는 쪽과 RECEIVE하는 쪽이 서로 다른 이기종일 때 AMQP 를 쓰는 이유가 있다고 생각되는데 맞는지요?
물론 이기종이 아니더라도 쓸 수 있지만, 최소한 서로 다른 서버(혹은 서비스)간에 메시지를 전달하는데 쓰는게 맞다고 생각하는데 맞는지요?
제가 위에서 생각했던 WEB APPLICATION 에서 MQ 서버로 메시지를 SEND 하고 그걸 다시 WEB APPLICATION에서 RECEIVE해서 쓴다면 그게 MQ를 써야할 의미가 있는지요?