우아한테크코스/레벨3

JobQueue 처리 기술 도입기

nauni 2021. 7. 14. 23:02

배경지식

메세지 브로커

  • 이벤트 브로커로 역할 불가
  • 메세지 기반 미들웨어 아키텍처
  • 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는 대규모 분산처리에 목적이 있는 프로그램이라고 판단, 메세지큐도 구현가능하지만 원래 목적이 대규모 분산처리 시스템을 위한 것이라 아키텍처의 목적과 맞지 않는다고 판단

참고

저작자표시 비영리 동일조건