Backend 개발자/아키텍처

Queue 를 사용하는 이유? Aws SQS, RabbitMQ, Kafka 는 어떤 목적으로 써야 하나요?

by 앵과장 2021. 11. 22. 07:09
반응형

안녕하세요
앵과장입니다.

프로젝트에서 사용은 했지만 정리가 필요한 것들 위주로 우선 작성 해보려고 합니다.

대기열 이다 대기열!!

Queue 사용목적

 

Queue는 우리가 개발하는데 있어서 다양한 목적으로 사용됩니다.
예전에는 주로 어떤메시지를 전달받아서 보내는 용도에 심플한 Queue정도 였다면

최근에는 데이터를 연결하는 파이프라인으로 또는 레거시 마이그레이션 이나 이벤트로 전달되는 최근 기술스택에서 꼭 필요로하는 테크에 중심이 되는것 같습니다.

Queue를 사용할때 고려사항

 

물론 Queue는 예전이나 지금이나 중요한 포인트는 동일합니다.

1.심플해야 합니다.
2.직관적이어야 합니다.
3.용도에 맞는 Queue를 선택해야합니다.
4.운영에 용이하며 모니터링 가능해야 합니다.
5.잘 모르는 기능은 사용하지말고 이해가 가는 만큼 목적에 맞게 사용하셔야 합니다.
6.Queue에 너무 많은 정보를 전달하기보다는 필요한 데이터만 담아야합니다.

관련 내용은 정답은 아닙니다 프로젝트에서 사용해보니 역시 심플하게 운영이 용이하게 사용하고 막연히 써보는것 보다는 정말 여기서 Queue를 사용하는게 맞는지에 대한 고민이 진행된 이후 사용해야 합니다.

이내용은 모든 오픈소스를 사용하는곳에서 공통적인 부분입니다.

Queue 오픈소스 알아보기

 

 

  RabbitMQ  

RabbitMQ 를 처음 사용한 프로젝트는 대략 8년전쯔음 같습니다.

SKT Tdeveloper 라는 서비스 플랫폼중 준 키즈 서비스에 사용되었던것 같고 기존에 SaaS형태로 잘만들어진 서비스를 mongoDB로 마이그레이션하고 Push 보내는부분을 사용했던것 같습니다.

그뒤로도 서비스 플랫폼이직 이후 위메프, 여기어때, 티몬에서도 사용했던것 같습니다.

RabbitMQ 특징
  • 구성이 쉬운편이다.
  • 유연한 라우팅이 가능하며 관리 UI가 잘알면 편하다.
  • 앞서 사용된것처럼 제품 성숙도가 있는 편입니다.
  • 삽질한 수많은 개발자들의 노하우등 구글링 검색하면 많이 나온다.(아..버전 낮을때 너땜에 2일밤을 날렸지 ㅜㅡㅜ)

 


AMQP

Message Queue 오픈소스에 기반한 표준 프로토콜 AMQP(Advanced Message Queuing Protocol) 입니다.

Spring AMQP 는 AMQP 기반 메시지 솔루션 Spring 구현체이며 Spring에서 제공하는 AMQP는 메시지 송수신을 위한 템플릿들을 제공합니다.

 

AMQP 는 OS와 플랫폼에 사용되며 시스템간 상호 운용이 가능하다고 합니다.

Header, Properties, Body, Footer 4가지 형태로 구성되어 있고 AMQP는 Binary 바이트 메시지만 지원합니다.

 

Spring AMQP 동작

Spring Framework 는 AMQP Message 어플리케이션 개발을 위한 AMQP API 제공합니다.

 

 

Producer : 메시지를 생성하고 발송하는 주체입니다. 메시지는 Queue에 저장되는데 동작방법은 Queue에 직접 접근하지 않고 항상 Exchange 를 통해 접근 가능합니다.

 

Consumer : 메시지를 수신하는 주체 입니다. Consumer는 Queue에 직접 접근하여 메시지를 가져옵니다.

 

Queue : Producer 들이 발송한 메시지들이 Consumer 소비하기 전까지 보관되는 장소입니다.

저장되는 구조는 Memory 와 Disk 방식이 존재합니다. 

Queue 는 이름으로 구분되는데 

같은 이름 같은 설정으로 Queue 생성하면 오류 없이 기존 Queue에 연결되지만,

같은 이름 다른 설정으로 Queue 생성시도하면 오류가 발생합니다.

 

Exchange : Producer 들에게 전달받은 메시지들을 어떤 Queue에 발송할지를 결정하는 객체 입니다.

4가지의 타입이 존재하며 라우터 개념이라고 보시면됩니다.

 

Binding : Exchange 에게 메시지를 라우팅 할 규칙을 지정하는 행위입니다.

특정 조건에 맞는 메시지를 특정 큐에 전송하도록 설정할수 있는데 Exchange 타입에 맞게 설정되어야 합니다.

Exchange : Queue 관계 구조는 M:N Binding 형태도 가능합니다.

Direct exchange (Unicast)
1:1 관계로 Unicast 방식에 적합, 라운드 로빈 방식(RR)으로 여러 workers(Consumer)간 task를 분리
Exchange에 바인딩 된 Queue 중에서 메시지의 라우팅 키와 매핑되어 있는 Queue로 메시지를 전달합니다.
Fanout exchange (Broadcast)
메시지의 라우팅 키를 무시하고 Exchange에 바인딩 된 모든 Queue에 메시지를 전달합니다.
Topic exchange (Multicast)

Exchange에 바인딩 된 Queue 중에서 메시지의 라우팅 키가 패턴에 맞는 Queue에게 모두 메시지를 전달합니다.

Headers exchange (Multicast)
라우팅 키 대신 메시지 헤더에 여러 속성들을 더해 속성들이 매칭되는 큐에 메시지를 전달합니다.

 

좀더 자세한 RabbitMQ Tutorials 는 아래링크를 참고하시면 됩니다.
https://www.rabbitmq.com/getstarted.html

 

RabbitMQ Tutorials — RabbitMQ

RabbitMQ Tutorials These tutorials cover the basics of creating messaging applications using RabbitMQ. You need to have the RabbitMQ server installed to go through the tutorials, please see the installation guide or use the Docker image. Executable version

www.rabbitmq.com

여러 MQ제품들이 AMQP 프로토콜을 사용한 라이브러리가 존재하며 JAVA 에서는 Erlang RabbitMQ가 대표적입니다.

 

Aws SQS  

Amazon Simple Queue Service(SQS)는 마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전관리형 메시지 대기열 서비스입니다. SQS는 메시지 중심 미들웨어를 관리하고 운영하는 데 따른 복잡성과 오버헤드를 없애고 개발자가 차별화 작업에 집중할 수 있도록 지원합니다. SQS를 사용하면 메시지를 유실하거나 다른 서비스를 가동할 필요 없이 소프트웨어 구성 요소 사이에서 어떤 볼륨의 메시지든 전송, 저장 및 수신할 수 있습니다. AWS 콘솔, 명령줄 인터페이스 또는 원하는 SDK, 3가지 간단한 명령을 사용하여 몇 분 만에 SQS를 시작할 수 있습니다.

 

SQS에서는 2가지 종류의 메시지 대기열을 제공합니다. 표준 대기열은 최대 처리량, 최선 노력 순서, 최소 1회 전달을 제공합니다. SQS FIFO 대기열은 메시지가 전송된 정확한 순서대로 정확히 한 번 처리되도록 설계되었습니다.


특징


관리 오버해드 제거

메시지 발송 개런티 

암호화 된 데이터 전송

AWS 클라우드 이점에 맞는 탄력적인 Scale Out

https://aws.amazon.com/ko/sqs/

 

Amazon SQS | 메시지 대기열 서비스 | AWS

Internet Explorer에 대한 AWS 지원이 07/31/2022에 종료됩니다. 지원되는 브라우저는 Chrome, Firefox, Edge 및 Safari입니다. 자세히 알아보기

aws.amazon.com

SNS SQS

 

 

  KafKa  

Pub-Sub 모델의 메시지 큐이며 분산환경에 특화된 특징을 가지고 있습니다.

 

Event

KafKa 에서 Producer 그리고 Consumer 데이터를 주고받는 단위 입니다.

 

Producer

이벤트를 게시(post)하는 클라이언트 어플리케이션을 의미합니다.

 

Consumer

Topic를 구독하고 얻어낸 이벤트를 처리하는 클라이언트 어플리케이션 입니다.

 

Topic

이벤트가 쓰이는 곳입니다. Producer은 Topic에 이벤트를 게시합니다. Consumer은 Topic로 부터 이벤트를 가져와 처리합니다. Topic는 파일시스템의 폴더와 유사하며 이벤트는 폴더안에 파일과 유사합니다.

Topic에 저장된 이벤트는 필요한 만큼 다시 읽을수 있습니다.

 

Broker

KafKa Server 를 의미합니다. 한클러스터 내에서 Kafka Server를 여러대 띄울수 있습니다.

 

  • Zookeeper ( Apache Zookeeper )
  • 본래 Zookeeper의 용도는 클러스터 최신 설정정보 관리, 동기화, 리더 채택 등 클러스터의 서버들이 공유하는 데이터를 관리하기 위해 사용됩니다.
  • Broker에 분산 처리된 메시지 큐의 정보들을 관리한다고 합니다.
  • 클러스터를 관리하는 Zookeeper 없이는 Kafka 구동이 불가능합니다.
  • 즉, Kafka 서버를 가동하려면 Zookeeper를 먼저 가동해줘야 합니다.( 그래서 Kafka 다운로드시 Zookeeper도 함께 제공해줍니다.)

 

KafKa 는 자주사용해본적이 없다보니 좀더 학습한뒤 추가내용 작성예정입니다.