Spring AMQP 맛보기 - 1. AMQP 개념

부제: RabbitMQ Spring 연동, RabbitMQ 연동

 

 이번 시리즈에서는 간단한 Spring AMQP 예제를 소개한다. 예제를 시작하기 전에 이번 포스팅에서는 AMQP라는 것에 대해 소개할 것이다.

 

1. AMQP 정의

 Advanced Message Queuing Protocol의 약자이다. 이름에서 알 수 있듯 MQ(Message Queuing)기반의 프로토콜이다. 메시지관리, 큐잉, 라우팅(peer to peer, pub-sub), 신뢰성, 보안 등에 대해 정의하고 있다.

 

 Spring AMQP는 Spring에서 AMQP기반 메시징 애플리케이션을 개발할 수 있도록 Spring의 개념을 적용한 라이브러리이다. 비동기 메시지 리스너, 큐 선언, exchange 선언 및 binding 기능 등 전반적은 AMQP 관련 기능을 제공한다.

 

2. AMQP 개념

AMQP 1짤 요약

 위 그림으로 간략하게 AMQP를 설명하겠다.

 

• Producer(Publisher): 메시지를 보내는 곳
• Consumer(Subscriber): 메시지를 받는 곳
• Exchange: Producer로부터 메시지를 수신하는 곳. 수신한 메시지를 큐에 분배한다.
• Queue: 메시지를 저장하는 곳. 저장했다가 Consumer에게 전달한다.
• Binding: Exchange와 Queue의 mapping. 1:1 또는 1:N.

간단하게 한줄요약 하면

 

Exchange가 Producer로부터 메시지를 받고 Queue에 전달한다. Queue는 Consumer에게 메시지를 전달한다.

 

 

 

 

 

 

Exchange의 Type에 따라 Publisher와 Subscriber 관계가 1:1이 될지 1:N이 될지 결정된다.

 

• Direct exchange: 메시지의 라우팅 키와 일치하는 Queue로 메시지를 전달 (1:1)
• Fanout exchange: Exchange에 binding 된 모든 Queue에 메시지를 전달(1:N)
• Topic exchange: Exchange에 binding 된 Queue 중에 메시지의 라우팅 키 패턴이 일치하는 모든 Queue에 메시지를 전달(Mulicast)

 그리고 우리가 Spring AMQP에서 정의해야할 것은 다음과 같다.

 

• 어떤 메시지 브로커(Message broker)를 사용할 것인가?
• 어떤 타입의 Exchange를 사용할 것인가
• 어떤 타입의 Queue를 몇 개나 사용할 것인가.
• Binding에 대한 정의

 

3. 왜 쓰는가

 결론부터 바로 말하자면 생산자와 소비자의 의존성을 느슨하게 만들기 위함이다. 이해를 돕기 위해 간단한 그림을 준비했다.

 

DB를 활용하는 일반적인 애플리케이션

 일반적인 애플리케이션이 DB를 사용할 경우 위와 같은 구조이다. 애플리케이션에서 직접 DB 커넥션을 관리하고 DB에 데이터 관련 요청 및 응답을 받는다. 위와 같은 구조는 주로 아래와 같은 단점이 있다.

 

• DB 지연이 앱 전체의 지연 원인이 된다.
• DB 장애시 애플리케이션도 장애가 발생한다.

 즉, DB와 애플리케이션 간 의존성이 높아서 발생하는 문제이다.(DB와 의존성이 높은 것이 꼭 안좋은 것은 아니다.) AMQP를 구현한 Message Broker를 사용하면 아래와 같이 구성할 수 있다.

 

AMQP Message Broker를 활용한 설계

 이렇게하면 DB 성능에 애플리케이션이 크게 구애받지 않겠다. DB 장애가 발생해도 애플리케이션은 그냥 큐에 데이터를 전달하기만 하면 되니 DB 장애에 대한 영향을 즉시 받지는 않는다. 다만 이렇게 의존성을 제거하면 트랜잭션 관리 난이도가 올라간다. 한편, MSA 에서도 AMQP를 활용할 수 있다.

 

 

결합도가 높고 의존성 있는 MSA 예제

 MSA 아키택처에서는 Server to Server API call이 잦다. 이에 따라 각 서버간 의존성이 올라가기도 한다. 이로 인해 발생할 수 있는 단점은 위에서 다룬 예제와 비슷하다. 애플리케이션2, 3 중 하나라도 지연되면 애플리케이션 1도 느려진다. 애플리케이션2 또는 3에서 장애가 발생하면 장애가 애플리케이션 1로 전파될 것이다.

 

메시지 큐를 활용하여 의존성을 제거한 모습

 이러한 문제점은 의존성을 제거함으로서 해소할 수 있다. 이렇게 하니까 위에서 제시된 단점을 모두 해결했다. 그리고 Application 4를 추가해야 되는 상황에서도 Application 1을 변경하지 않아도 된다.

 

 정리하면, AMQP 기반 Queue를 사용함으로써 Producer와 Consumer간 결합 구조를 느슨하게 만들 수 있다.

 

 

 

 

-끝-

 

 

 

 

 

출처 및 참고

https://ram2ram2.tistory.com/3

https://www.rabbitmq.com/

https://devahea.github.io/2019/04/22/amqp-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%9B%90%EB%A6%AC/