강의

멘토링

커뮤니티

인프런 커뮤니티 질문&답변

최재량님의 프로필 이미지
최재량

작성한 질문수

RabbitMQ를 이용한 비동기 아키텍처 한방에 해결하기

12.Pub-Sub모델을 이용한 실시간 알림 (WebSocket, STOMP 이용) part 3

step 4 - fanout 관련 질문

작성

·

7

·

수정됨

0

안녕하세요, step 4에 fanout 브로드캐스팅으로 구현한 이유가 궁금해서 질문드립니다.

다른 질문을 찾아보니 아래와 같이 답변을 주셨습니다.

"정리하면 Fanout은 모든 큐에 메시지를 브로드캐스트하지만 WebSocket을 이용해 특정 뉴스 타입만 선택적으로 구독할 수 있습니다. (서로 독립적으로 동작합니다)

따라서 Pub/Sub의 성격을 이용해서 브로드 캐스트를 하는 것은 Direct나 Topic 보다 Fanout이 적합하고, 전체 브로드캐스트가 필요하지 않은 Pub/Sub의 일부 제한이 필요한 경우는 WebSocket과 STOMP를 통해서 필터링..

 

여기서 저는 왜 step4에서 Pub/Sub의 성격을 이용해서 브로드캐스팅하는지 이해가 안됩니다.

  1. 어차피 WebSocket에서 필터링할 것이라면 왜 비효율적으로 브로드캐스팅하는건가요?
    fanout보다 topic Exchange가 적합하지 않나요?

  2. 어차피 브로드캐스팅하고 모든 큐에 넣을 것이라면, javaQueue, vueQueue, springQueue로 구분할 필요가 있나요? pub/sub 모델은 아니지만, 하나의 newQueue로 관리하고 simpMessagingTemplate의 destination을 구분하는 것은 어떤가요?


답변 2

0

코드빌런님의 프로필 이미지
코드빌런
지식공유자

안녕하세요. 수강자님

1번부터 답변드리면, 예제 구조만 놓고 보면 Topic이 더 좋은 선택지입니다. 다만 step4에서 Fanout을 사용한 이유는 동작 방식에 대한 설명 (하나의 메시지를 모든 구독자에게 브로드 캐스트 하는 pub/sub의 가장 기본적인 형태)을 구현하고자 하는 측면과 실무에서 같은 뉴스 메시지를 처리하더라도 각 Consumer가 다른 로직으로 처리 해야 할 경우 (예를들면 1번은 DB에 저장, 2번은 푸시 알림, 3번은 로직 처리 등) Fanout을 통해 동일한 메시지를 받아 후작업을 처리할 수 있다는 점 이렇게 두가지 측면을 고려에서 비슷한 형태의 메시지에 대해 서로 다르게 처리하는 다수의 consumer 로서 fanout 브로드캐스팅을 지정한거라고 보시면 됩니다.
Step 4 예제는 뉴스레터라는 시나리오를 빌렸지만, 실제로 보여주고자 하는 것은 Fanout Exchange의 브로드캐스트 동작 방식입니다.

 

2번의 경우 pub/sub의 특징중 하나는 구독자 중립성입니다.
Consumer 중 하나가 장애가 나도 나머지 컨슈머는 영향을 받지 않으나 이걸 하나로 합치면 장애시 모든 뉴스처리가 중단되거나 트래픽 폭증으로 인해 지연이 발생할 때 전체 어플리케이션에 영향을 줍니다. 이런 독립성과 확장성 (하나의 타입이 추가되면 consumer만 추가 바인딩)을 고려해 서로 영향을 덜주고 처리가 보장되는 간단한 형태의 예제인 뉴스레터로 설명하였고, 말씀하신 방식도 동작은 합니다. 다만 메시지 처리 실패시 영향 범위, consumer 내부 분기 로직, 독립적 스케일링 등을 고려하면 큐를 분리하는 것이 운영 측면에서 이점이 있습니다.

단계별로 예제를 연결하다보니 예제 성격이 부족한거 같습니다만, 메시지 처리 실패시 영향 범위나 consumer 내부 분기 로직 (메시지 타입에 따라 파싱 및 판단 분기)을 고려, 독립적인 스케일링 (특정 뉴스만 트래픽이 폭증할때) 등을 고려하면 Fanout 으로 연결하고 consumer의 워커를 늘리는 등의 일관성이나 유연성을 장점으로 볼 수 있습니다.

또한 단일 큐 자체는 모니터링할 때도 상태구분이 fanout 보다 어렵습니다.

큐의 격리 레벨에서 장애나 독립 스케일링, 모니터링 이런 점을 고려할 때 fanout이 적합하다라고 보시면 되겠습니다.

감사합니다.

0

안녕하세요, 인프런 AI 인턴입니다. 최재량님.

RabbitMQ를 사용한 비동기 아키텍처에서 Fanout Exchange를 선택한 이유에 대해 설명해 드리겠습니다.

1. Fanout Exchange의 사용 이유

Fanout Exchange는 매우 단순한 방식의 메시징을 가능하게 하며, 메시지를 모든 연결된 큐에 브로드캐스트합니다. 이를 통해 다양한 구독자가 동일한 메시지를 받을 수 있도록 합니다. 이 방식은 다음과 같은 경우에 유용할 수 있습니다:

  • 알림 시스템: 긴급 알림과 같이 모든 사용자에게 즉시 알림이 전달되는 경우.
  • 로그 시스템: 시스템 로그를 수집할 때, 모든 관련 서비스가 동일한 로그를 받고 처리해야 할 때.

비효율적인 브로드캐스팅?

Fanout을 사용하면 무차별적인 메시지 발송이 이루어져 자원이 낭비될 수 있지만, 이러한 방식은 메시지 라우팅 과정을 단순화하고 수신자 측에서의 복잡한 로직을 줄여주기 때문에, 오히려 시스템 전체의 일관성과 단순성을 유지하는 이점이 있습니다.

2. 여러 큐로 구분할 필요성

각각의 큐를 구분하여 관리하는 방법은 특정 시나리오에서 메시지를 구체적으로 처리하는데 유리합니다. 예를 들어 특정 서비스는 특정 주제에 대해서만 반응할 필요가 있을 때, 큐를 구분하면 개별 소비자가 자신의 관심사에 맞는 메시지만을 처리하도록 하여 작업 부하를 분리할 수 있습니다.

하나의 큐로 관리하는 방법

하나의 큐로 관리하면서 이를 WebSocket과의 목적지(와 라우팅)에서 구분하는 방법도 가능합니다. 이 방법은 RabbitMQ에서 Direct 또는 Topic Exchange를 사용하여 라우팅하는 방법입니다. 이를 통해 클라이언트의 필요에 따라 메시지를 필터링하고, simpMessagingTemplate를 사용하여 목적지 안에서 구분하는 것이 가능합니다.

이 내용을 참고하시어 시스템 요구 사항에 가장 잘 맞는 설정을 선택하시기 바랍니다. 관련하여 더 깊이 있는 질문이나 다양한 사례가 궁금하시다면 아래 링크를 통해 추가적인 답변을 확인해 보시기를 권장드립니다:

  • “FanoutExchange 와 관련된 이해가 필요한 부분이 있으신가요?”
  • “Message Queue 관리 방법에 대해 궁금하시다면 여기를 참고하세요.”

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

최재량님의 프로필 이미지
최재량

작성한 질문수

질문하기