토픽과 큐, 트레이드 오프 분석하기

 

큐를 이용한 서비스간 통신

 

토픽을 이용한 서비스 간 통신

 

 

토픽 : 

 큐는 Producer 들이 각각의 큐의 접속 해야 하지만 토픽은 한 토픽에 한번만 연결하면 된다.아키텍처 확장성이 무엇보다 강점. 

 그리고 새로 구독하게 되는 서비스는 해당 토픽을 구독하면 되기 때문에 기존 시스템을 건들 필요가 없다.

 프로듀서의 입장에서는 무엇에 의해 어떻게 사용하는지 모르기 때문에 디커플링된다고 할 수 있다.

 

큐 :  

 큐에 전달된 데이터는 큐를 수신하는 지정된 컨슈머만 엑세스가 가능하다. 악의적인 서비스가 큐를 리스닝해서 정보가 유출 될 경우,

정작 수신하기로 된 서비스는 데이터를 받지 못해 데이터 유실(과 그로 인한 보안 침해) 을 경고하는 알림 메시지가 발송된다. 

 

토픽 : 

 토픽의 데이터를 수정하게 되면 전체 서비스의 수정에 영향이 가게 된다.

예를 들어 기존 전달되는 데이터에 A 라는 서비스가 추가 항목이 필요하다고 한다면 나머지 B , C 의 서비스는 필요 하지 않을 가능성이 있다. 하지만 토픽을 공유하는 상황에서 자신만의 계약을 가질수 없는 컨슈머들은 상대의 서비스의 영향을 받는다.  

 

큐 : 

 큐는 채널이 모두 각기 나뉘어져 있고 모든 연결이 나뉘어져 있기 때문에 보안 침해, 데이터 유실에 안전하다. (모니터링이 가능하다)

 

토픽: 

 메시지 개수를 모니터링 할 수 없고 자동 확장 ( auto-scailing ) 기능이 지원되지 않는다. 

 

큐 :

 큐를 따로 모니터링 할 수 있고 컨슈머마다 개별적으로 로드 밸런싱(부하분산) 로직을 적용 할 수 있다. 

 

 

토픽의 장점 | 단점 

아키텍처 확장성	데이터 액세스 및 보안 문제
서비스 디커플링	서로 다른 계약 혼용 불가 모니터링과 프로그래밍 방식의 확장성

 

 

 아키테처적으로 사고 하려면 각 방안의 트레이드 오프를 분석하고 주어진 상황에서 가장 나은 선택을 해야한다. 

이러한 트레이드 오프는 AMQP(Advanced Message Queuing protocol) 의 구조상 (프로듀서가 메시지를 보내는 ) 익스체인지 와 ( 컨슈머가 리스닝 하는 ) 큐를 분리 할 수 있으므로 프로그래밍 방식과 로드 밸런싱과 모니터링이 가능한 기술적인 특성과도 연관이 있다.

큐와 토픽에 대한 트레이드 오프(장점과 단점) 로  서로 확장성과 보안중 어떤 것이 더 중요한가를 떠올려 볼수 있다.

 

 

 

 

 

- 기본 용어에 대한 정리 

https://bbo-blog.tistory.com/47

 

- ActiveMQ의 Virtual Destinations를 활용한 메시지 로드밸런싱 

https://ryan-han.com/post/dev/activemq_virtual_destinations/

 

- SNS 와 SQS 연결 하는 방법

https://pink1016.tistory.com/213

 

- Amazon SQS, Amazon MQ 및 Amazon SNS 간의 차점 - Amazon Simple Queue Service  https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-difference-from-amazon-mq-sns.html