😀 : 감자야 이번 프로젝트에서는 MSA 패턴으로 구축했잖아
🥔 : 네!
😀 : 그럼 우리가 각 서비스별 통신을 어떻게 했어?
🥔 : ...외부 인터페이스처럼 API로 하나요?
😀 : restAPI로 하는 것도 가능하지. 근데 속도나 권한이나 보안적 이슈가 크지.
🥔 : 어...그럼...🙄
😏 : 숙제야.
🥔 : 똻.
프로젝트의 구조를 설정할 때 거의 대부분 config 폴더에서 설정 소스 정의한다고 하셔서
config 파일들을 보다가
import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.DirectExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.amqp.rabbit.connection.CachingConnectionFactory;
import org.springframework.amqp.rabbit.connection.ConnectionFactory;
import org.springframework.amqp.rabbit.core.RabbitAdmin;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.remoting.client.AmqpProxyFactoryBean;amqp라는 패키지를 발견하여 말씀드리니 이게 맞다고 마저 공부해오라고 하셨다.^^
그래서 공부하게 된 AMQP.
📌 AMQP란?
Advanced Message Queuing Protocol.
MQ(Message Queuing)기반의 프로토콜이다.
서로 다른 시스템들 간의 최대한 효율적인 방법으로 메세지를 교환하기 위해 탄생하였다.
메시지관리, 큐잉, 라우팅(peer to peer, pub-sub), 신뢰성, 보안 등에 대해 정의하고 있다.
Spring AMQP는 Spring에서 AMQP기반 메시징 애플리케이션을 개발할 수 있도록 Spring의 개념을 적용한 라이브러리이다. 비동기 메시지 리스너, 큐 선언, exchange 선언 및 binding 기능 등 전반적은 AMQP 관련 기능을 제공한다.
📌 AMQP의 동작
- Producer(Publisher): 메시지를 보내는 곳
- Consumer(Subscriber): 메시지를 받는 곳
- Exchange: Producer로부터 메시지를 수신하는 곳. 수신한 메시지를 큐에 분배한다.
- Queue: 메시지를 저장하는 곳. 저장했다가 Consumer에게 전달한다.
- Binding: Exchange와 Queue의 mapping. 1:1 또는 1:N.
Exchange가 Producer로부터 메시지를 받고 Queue에 전달한다. Queue는 Consumer에게 메시지를 전달한다.
Exchange
- Direct Exchange
라우팅 키가 정확히 일치하는 Queue에 메시지 전송 (1:1) - Fanout Exchange
해당 Exchange에 등록된 모든 Queue에 메시지 전송 (1:N) - Topic Exchange
라우팅 키 패턴이 일치하는 Queue에 메시지 전송 - Headers Exchange
[key:value]로 이루어진 header값을 기준으로 일치하는 Queue에 메시지 전송
📌 AMQP를 사용하는 이유
애플리케이션이 DB를 사용해야한다면 일반적으로 애플리케이션에서 직접 DB 커넥션을 관리하고 DB에 데이터 관련 요청 및 응답을 받는다. 이런 경우 DB에 지연 혹은 장애가 발생 시 애플리케이션에도 직접적인 영향을 받게 된다.
AMQP를 구현한 Message Broker를 사용하면 DB 성능에 애플리케이션이 크게 구애받지 않는다.
DB 장애가 발생해도 애플리케이션은 그냥 큐에 데이터를 전달하기만 하면 되니 DB 장애에 대한 영향을 즉시 받지는 않기 때문이다.
다만, 복잡한 라우팅이 필요하여 트랜잭션 관리 난이도가 올라간다.
MSA 아키택처에서는 Server to Server API call이 잦다. 이에 따라 DB와 직접 연결되어있던 위의 상황과 동일한 상황이 발생한다. 어플리케이션2나 3에 장애가 발생하면 애플리케이션1에도 직접적인 영향이 미친다.
AMQP를 구현한 Messages Broker를 미들웨어로 넣어주게 되면 장애의 영향도가 적어지게 된다. 그리고 추후에 어플리케이션4를 추가하게 되더라도 어플리케이션1을 수정할 필요가 없다.
추가적으로 JPMorgand이라는 미국 윌가 금융의 핵심 회사에서 금융 시스템 플랫폼간 통신을 위해 개발된 미들웨어다 보니 신뢰도가 높고 중복 이슈가 거의 없기 때문에 사용한다고 한다.
📌 Message Broker
AMQP를 구현한 Messages Broker는 4가지가 있다.
- RabbitMQ
- OpenAMQ
- StormMQ
- Apache Qpid
위에 import 내용을 보면 알겠지만 이 프로젝트에서는 RabbitMQ를 사용하고 있다.
RabbitMQ가 AMQP 구현체 중 가장 빈번하게 사용되고 있다고 한다.
이유를 여쭤봤는데 미들웨어는 거기서 거기라 많이 쓰는 거 쓰는 게 좋다고...ㅎ
🥔💬
갑작스러운 질문으로 인해 이번 프로젝트의 MSA 아키텍처에서 서비스간 통신을 위해
어떤 방식 (AMQP)
어떻게 구현 (RabbitMQ)
왜 (높은 신뢰성 보장, 빠른 통신)
을 알게 되었다.
업무를 파악하려면 화면과 디비 구조부터 보면 파악하기 쉬운 것처럼
프로젝트 구조를 먼저 파악하면 그 프로젝트에서 코딩하기 쉽다며 프로젝트 구조를 파악하는 능력을 키워주시려고 한 것 같다.
다른 프로젝트 할 때도 프로젝트 구조를 파악하는 연습을 해야겠다.
📑 참고 자료
