JobQueue 처리 기술 도입기

배경지식

메세지 브로커

• 이벤트 브로커로 역할 불가
• 메세지 기반 미들웨어 아키텍처
• PRODUCER, CONSUMER
• 메세지를 받아서 처리하고 나면 삭제되는 구조
• 래디스, 레빗엠큐

이벤트 브로커

• 메세지 브로커로 역할 가능
• 서비스에서 나오는 이벤트를 이벤트 큐에 저장함
  • 딱 한번 일어난 이벤트를 저장하여 → 단일진실 공급원으로 사용
  • 장애가 일어난 시간부터 다시 처리가능
  • 많은 실시간 데이터를 처리가능
• 장부를 딱 하나만 보관하고 인덱스를 통해 개별 엑세스를 관리
• 업무상 필요한 시간동안 보관 가능
• 카프카

큐와 소비자의 연관관계

OneToOne

• 하나의 큐에 하나의 애플리케이션이 있음

OneToMany

• 하나의 큐에 여러개의 애플리케이션이 있음

Redis vs RabbitMQ vs Kafka

비교1

	브로커 스케일	데이터 영속성	Consumer 연관
Redis	millions msg/sec	지원하지 않음(인메모리 저장), 데이터 덤프하여 저장할 수는 있는 듯	OneToOne, OneToMany 둘다 가능
RabbitMQ	50K/sec	지원	OneToOne, OneToMany 둘다 가능
Kafka	millions msg/sec	지원	OneToMany만 가능

비교2

	Redis	RabbitMQ	Kafka
특징	- 인메모리로 동작, 캐시처럼 사용	- 복잡한 라우팅에 사용	- 대용량 데이터처리 및 대규모 분산처리에 사용
장점	- 빠르다 - 스프링과 사용시, 자바 8버전부터 지원	- UI로 지원 - consumer가 메세지를 받았음을 확신가능 (수신 확인이 되지 않은 경우 다시 보냄)	- Consumer가 메세지 선택이 가능 - 메세지 다시 읽기 가능 (이벤트가 유지되기 때문)
단점	- 자료 소실 가능성 - UI 툴을 사용하려면 추가 다른 프로그램 설치 필요 - 설정 단계에서 GUI 지원하지 않음 - 수신자가 메시지를 받았음을 확신할 수 없음	- 스프링과 사용시, 자바 11버전 이상부터 지원	- 기술 튜토리얼이나 자료가 접근 난이도가 있음
소비방식	- 생산자가 push하여 소비자에게 보내는 방식		- 소비자가 pull 방식이 가능
기타	- 메세지 브로커		- 이벤트 브로커 - pub/sub 기반 - 파일시스템으로 관리 - partition과 offset으로 데이터를 선택

결론: RabbitMQ

• 셋다 원하는 큐 기능은 구현이 가능했으나 JobQueue를 구현하는데 있어 가장 목적과 맞는 것이 RabbitMQ라고 판단
• MessageQueue를 통해 어떻게 나눠 처리할 것인지를 구현하는데(라우팅) 목적이 있는 미들웨어라고 판단
• 튜토리얼이나 기술 접근난이도가 높지 않아보였고, 설정단계에서도 UI로 지원하는 부분도 크다고 판단
• Redis는 빠르지만 캐시처럼 동작하는 듯 했고, 우리에겐 속도가 크게 중요하지 않다고 생각
• Kafka는 대규모 분산처리에 목적이 있는 프로그램이라고 판단, 메세지큐도 구현가능하지만 원래 목적이 대규모 분산처리 시스템을 위한 것이라 아키텍처의 목적과 맞지 않는다고 판단

참고

•  redis, rabbitMQ, kafka 
• 이벤트브로커와 메세지큐 설명글(영어)
• rabbitMQ와 redis
• 스프링 공식문서 rabbitMQ 튜토리얼
• 이벤트브로커, 메세지브로커 차이 설명 동영상 
• rabbitMQ 공식문서 getstarted 튜토리얼 설명